Prometheus + Grafana 替代方案：扩展自建，还是改用托管平台

如果现有 Prometheus 和 Grafana 已经能支撑值班，我不建议仅为换一套界面而迁移。指标容量不够，可以先扩展后端；没有人持续维护存储、升级和恢复，再考虑托管。真正值得换一整套平台的情况，是日志、链路和资源数据虽然都有，工程师仍要在几个系统里重建同一次故障的上下文。

Prometheus 与 Grafana 原本就是互补的：前者采集、保存和查询指标，执行 recording rule 与告警规则；后者连接数据源，提供探索、仪表板和告警能力。讨论 Prometheus + Grafana 替代方案，应先看卡住的是采集、存储，还是调查流程。只换 Grafana，不会替换 Prometheus 的数据后端。Prometheus 架构 · Grafana 数据源

观测云编辑部 · 2026 年 10 月 28 日。本文根据官方资料讨论自建与托管的工程取舍，观测云也是候选产品。文中算式使用明确假设，不是生产压测或客户节省结果。

先把需要改变的那一层找出来

长期留存和跨集群查询是主要问题时，Thanos、Mimir 或 VictoriaMetrics 这类指标后端值得先看。现有 exporter、PromQL 和 Grafana 工作方式有机会继续使用；新增组件的容量、可用性和升级则仍由平台团队承担。它们各有自己的架构与兼容范围，也不会因为接住指标就同时补齐日志、链路与用户体验。

希望保留 Grafana，又不想继续运行后端，可以比较 Grafana Cloud 和相应云厂商的托管 Prometheus。Grafana Cloud 与自建 LGTM 是两种交付方式：Loki、Grafana、Tempo、Mimir 可以组成多信号栈，但自建时仍要运行、升级和恢复这些组件。商业 SaaS、Elastic Observability 与观测云等完整平台，则把问题进一步移到跨信号调查和实际交付范围上。

路线之间的差别是持续要做什么。Prometheus 使用 Apache 2.0 许可，Grafana OSS 使用 AGPLv3；所选发行版、插件和附加产品还要按各自条款处理。软件能够自行部署，并不意味着运行和集成工作可以不计成本。Prometheus 许可 · Grafana 许可

先算序列与采集频率，再比较单价

高基数会跟着数据一起迁移。把请求 ID 或用户 ID 放进指标标签，持续增长的是标签组合形成的时间序列；新后端可以承载更多序列，却不会自动决定哪些组合值得保留。Prometheus 数据模型

用一个简单的假设说明：20 个服务，每个服务 10 个接口、5 个状态，每种组合在 8 个 Pod 上都实际产生一个标量指标，就有 20 × 10 × 5 × 8 = 8,000 条序列。每 15 秒采一次，每分钟约 32,000 个样本；改为 60 秒，每分钟约 8,000 个样本。序列数没变，采集样本量降到四分之一。这只是一项标量指标的稳态算式，未计重启、序列 churn、直方图或副本。

减少标签维度会失去相应切片，延长间隔会降低时间分辨率。判断能否接受，应回到实际查询和告警窗口。只看仪表板不使用的维度，可以考虑提前聚合或过滤；按 Pod 定位问题仍有必要时，就要保留能完成这项工作的数据。

Grafana Cloud Metrics 的费用与活跃序列、每分钟数据点（DPM）有关。其他服务可能使用不同计量单位；字节量、序列和数据点不能直接互换。比较托管费用前，把发送范围、频率、留存和查询需要固定下来，差额才有意义。Grafana Cloud 指标计费

remote write 接通以后，规则和历史还有各自的去向

Prometheus server 为每个 remote write 目的地维护发送队列，从 WAL 读取样本，再分片发送给接收端。目的地变慢会形成积压；本地可查询，不代表远端已收到。网络恢复后还要有足够发送能力追上新增数据，WAL 也不是无限期的离线归档。remote write 的队列与恢复

这也是保留现有采集端的价值：可以先改变写入目的地，而不急着更换所有 exporter。与此同时，已经保存的历史数据、recording rule、告警规则和 Grafana 仪表板是不同资产，需要选择保留、导入或重建的路径。

HA 副本尤其容易带来误判。Grafana Cloud Metrics 默认支持按 cluster 和 __replica__ 识别、去重 HA Prometheus 的数据：同一组副本共享 cluster，副本标识各不相同。这是接收端的约定，不是 remote write 协议对所有后端承诺的行为。更换接收端时，副本标识、去重方式和实际收到的序列应一起核对。Grafana Cloud HA 数据接入

观测云的 DataKit 提供 Prometheus Remote Write 接收器，现有采集路径可以由此延续。字段映射需要提前处理：未覆盖 measurement 等命名配置时，go_memstats_heap_objects 默认会拆为 measurement go 与字段 memstats_heap_objects；keep_exist_metric_name = true 可以保留完整原始字段名。接收到样本之后，原查询中的名称和筛选条件仍要与新模型对齐。观测云也提供 MetricsQL 查询入口，兼容语法的存在不能代替对实际查询结果的核对。

调查入口能否连起来，取决于数据约定

Grafana 已经可以连接多种数据源，Prometheus 数据源也支持配置 exemplar 到链路的跳转。现有栈若已具备合适的日志和链路后端、稳定标识和可用链接，继续完善它通常比全面迁移更省事。Grafana Prometheus 数据源配置

平台团队需要额外维护的，是服务名、环境、时间范围和权限如何穿过这些系统。错误率告警中的 service 能否筛到相同服务的日志，日志里的 trace_id 能否找到仍在保留期内的 Trace，决定了这条调查路径是否可用。

观测云的工作空间可以承接指标、日志、链路和 RUM，链路详情也有对应的关联入口。日志与链路使用一致的标识、相关数据已经采集并仍可查询时，工程师可以沿平台提供的入口继续调查，减少自己维护跳转和多个后台的工作。字段与留存仍要由团队安排；一个没有采到的请求不会因平台统一而补出来。日志与链路关联

AI 辅助同样应落在这条数据路径上。Obsy Agent Teams 可以使用已配置工具和获授权数据处理任务；价值在于帮工程师推进调查，引用的事件、筛选条件和时间范围仍应能被复核。工具入口连通，与已经找到可执行的根因，是两项不同的结果。Agent Teams 任务

告警资产与持续费用，决定最后要迁多少

Alertmanager 已有去重、分组、路由、静默和抑制能力。集群故障引发下游告警时，可以通过抑制减少重复通知；服务归属、阈值和路由配置错误，换平台以后仍要修。迁移应保留需要行动的告警和处理指引，而不是只追求通知数量变少。Alertmanager

历史仪表板也要按用途保留。低频的灾难恢复与合规监控，不能只因最近 90 天没人打开就删除。真正进入迁移范围的查询，应看单位、聚合、缺失数据和时间窗口是否保持含义；告警还要继续看评估周期、等待时间和通知路由。

费用可以拆成一个清楚的首年模型：

首年投入
= 12 ×（平台账单 + 客户侧采集资源 + 网络费用 + 仍需承担的运行成本）
+ 一次性迁移成本
+ 迁移期额外支出

工程时间与现金支出分别列出；并行运行只计超出稳定方案的额外部分，避免重复计算。观测云也应按所选版本和实际摄入、处理、存储及计算等项目报价，而不是只取一个指标单价。观测云企业版计费

指标后端是主要约束，就先扩展指标后端。希望保留 Grafana 并减少后端运行工作，先看相应托管服务。 当跨信号调查和分散系统维护持续消耗团队时间，观测云这类统一平台才值得作为更大范围的替代方案比较。扩大到哪一层，由真正能停掉的旧组件、保留下来的调查能力，以及持续费用共同决定。