Grafana Cloud 与 SigNoz：从现有监控走向应用排障

一套 Prometheus 告警已经用了几年，服务却刚开始接入 OpenTelemetry。团队想知道一次结算超时究竟卡在哪个下游，也想保住原来判断容量和可用性的仪表盘。此时比较 Grafana Cloud 与 SigNoz，问题并不是“多个数据库和一个数据库谁先进”，而是新链路能否接进已有的工作方式，以及团队准备把多少平台维护留在自己手里。

两者都能接收遥测并提供应用排障能力，但产品组织方式不同。Grafana Cloud 延续 Grafana 的数据源、查询和可视化体系；SigNoz 把 OpenTelemetry 数据收集、ClickHouse 存储和应用分析放在一套产品里。后者也有托管服务，前者也不是要求客户自行运行整套开源组件。先分清购买的服务与自己维护的系统，后面的成本比较才有意义。

先把现有的查询资产算进去

如果值班流程已经围绕 PromQL、Grafana 仪表盘和告警展开，保留这些资产有实际价值。需要迁移的不只是图表，还有阈值的由来、变量、分组方式，以及告警发生后值班人员通常点向哪里。Grafana Cloud 可以延续这套使用习惯，但现有数据源的连接、权限和具体配置仍需逐项确认，不能把“同一个界面”理解成不需要迁移工作。

SigNoz 也不是只能写 SQL。它的指标查询文档区分了可视化 Query Builder 与仪表盘里的 ClickHouse SQL、PromQL；链路查询则可以按 Span 属性筛选，并描述 Trace 内父子或后代关系。熟悉 PromQL 的人有可以复用的知识，但 Grafana 的整套面板、插件和告警行为不会因此原样搬过去。SigNoz 链路查询说明给出的能力，比“支持一种查询语言”更接近真正的应用排障需求。

可以先挑一张最重要的服务仪表盘来迁移：总请求数是否一致，错误率的分母是否相同，延迟图使用的是原始分布还是另一种聚合。数字出现差异时，先检查采集和聚合语义。界面上有相同的函数名，并不足以说明两幅图表达了同一件事。

从一条慢请求连接到相关证据

SigNoz 的架构以 OpenTelemetry Collector 接入数据，以 ClickHouse 存储遥测，再通过 SigNoz 服务提供查询和界面。这种组织方式让指标、日志、链路有共同的产品入口，但数据放在同一种存储中，并不会自动补出缺失的请求上下文。

一次支付请求的日志若没有 Trace ID，或者应用把生产与测试环境都叫成同一个服务，排查仍会遇到断点。无论选哪一边，都应先约定服务名、环境、版本和链路上下文的传递方式，再确认采样之后哪些请求还保留完整证据。OpenTelemetry 能减少采集协议的绑定，不会自动统一既有字段、告警定义或历史数据。

Grafana Cloud 的应用产品也不能简单概括为几个空白仪表盘。当前 Application Observability围绕服务目录、遥测质量和关联调查提供工作流程；新旧组织的产品体验有切换边界，2026 年 9 月 7 日以前接入的组织还可能使用经典版本。评估时应看实际账户中的产品，而不是拿某个开源组件的功能列表代替整个 Cloud 服务。

更有用的试用任务是让一位不熟悉系统的同事，从结算服务的错误告警找到受影响版本、失败请求和相关日志。记录他在哪一步需要问人、手填字段或切换工具。这是在验证团队的调查路径，不是在给数据库架构打分。

自建的控制权，也包含恢复责任

若两边都使用托管服务，团队主要维护采集配置、数据治理、权限和使用量。不能因为 Grafana Cloud 底层采用不同遥测组件，就把多个存储集群的日常升级算到客户头上。

SigNoz 自建则是另一项选择。当前 Linux 安装指南的 systemd 方案涉及 SigNoz、ClickHouse、ClickHouse Keeper、PostgreSQL、Collector 和数据库迁移服务。它说明了一个重要边界：统一遥测存储不等于只有一个进程，也不等于只备份 ClickHouse 就完成了恢复设计。

交接给运维时，应能回答谁检查队列积压、磁盘还能承受多久写入、升级失败怎样退回，以及业务配置和遥测数据能否一起恢复。最好在隔离环境中做一次恢复演练，再决定保留策略。购买支持可以改变故障求助渠道，却不会自然替团队接管所有系统操作。

SigNoz 的部署与报价说明也区分了由厂商管理的 BYOC 与企业自托管支持。两者都可能把数据放在客户可控的环境，运行职责却不同。选型会议中如果只写“私有部署”，很容易把这种差别漏掉。

账单反映的是不同的使用习惯

SigNoz Cloud 当前 Teams 起价为每月 49 美元，包含等值用量；价格页默认展示日志和链路各 0.30 美元/GB、15 天留存，指标 0.10 美元/百万样本、一个月留存。调整留存或采用企业合同，需要重新核对对应价格，不能把页面上的一组默认值延伸到所有方案。

Grafana Cloud 则需要按信号和所用产品拆开看。指标计费同时考虑活跃序列与每分钟数据点，分别取计费周期的第 95 百分位，再按包含的采样密度换算、取较高者。相同指标名并不意味着相同费用：标签组合和发送频率都可能改变结果。

日志费用包括处理、写入、额外留存与超过公平使用额度的查询量。额度按每个 stack 每月写入量的 100 倍计算。若日志到达云端之后再由 Adaptive Telemetry 丢弃，写入量会下降，处理量不会一并消失。这让“在哪里过滤”成为成本设计的一部分。

使用 Grafana 的 Application Observability 产品还涉及主机小时和遥测费用。2026 年 2 月 13 日及以后开始使用的客户没有旧模式的遥测抵扣；更早客户适用较高主机费率及相应抵扣。自己用仪表盘和告警搭建应用监控，不收这项产品的主机小时费，但仍有遥测与可视化费用；文档所列无服务器环境按遥测计费。

因此，比较时应带上同一组生产用量：指标的标签分布和频率、采样后的链路字节、日志到达与写入字节、查询习惯及留存要求。用其中一项的低单价推导总价，会把另外几项真实工作量藏起来。

用迁移的下一步决定平台

已有成熟 Grafana 工作流，希望逐步补齐应用调查的团队，可以优先验证 Grafana Cloud 如何接住现有资产。希望围绕 OpenTelemetry 建立新的统一入口，或愿意明确承担自建职责的团队，可以深入试用 SigNoz。两种方向都不要求立刻迁走全部历史数据。

一个稳妥的阶段目标是迁入一组真实服务，同时保留旧告警作为对照。核对一次故障、一次发布和一次容量变化，再让接班人员独立完成同样的调查。到这一步，维护成本、数据缺口和查询习惯的差异才会从产品介绍变成可以讨论的事实。

如果这次迁移还要一起整理日志与链路的关联，可以把观测云作为同一条调查路径的另一个验证对象：使用已经采集的 Trace 和 Span，检查能否通过匹配字段找到相关日志，而不是重新设计一组只供演示的数据。观测云链路详情文档说明了相关数据的查看方式；关联是否成立，仍取决于采集、上下文、权限与留存。

资料核对日期：2026 年 10 月 21 日。本文依据官方资料讨论机制与选择条件，未进行两平台性能基准测试。