Datadog vs Grafana Cloud：APM、指标成本与迁移怎么选

团队已经有 Grafana 看板，告警也能找到服务，但打开一条慢请求后，还要换几个界面拼日志。这时是否换成 Datadog，取决于这些跳转到底卡在哪里：是少了采集字段，还是现有工作流确实需要重新组织？

Grafana Cloud 不只是托管几个数据后端。团队可以继续用熟悉的看板和查询，也可以购买 Application Observability 这样的现成应用分析产品。Datadog 则让团队围绕它的基础设施、APM、日志等产品逐步建立调查流程。两边都有托管服务，区别不在于谁“还要自己运维整个开源栈”。

已经把 PromQL、Grafana 和 OTel 用顺的团队，我会先看能否沿用这些投入；已经在 Datadog 里积累大量告警和调查习惯，也没有必要仅凭另一家的摄入单价就迁走。先把一条常见故障走完，再看费用，会更容易找到值得改变的部分。

作者：观测云编辑部。资料核对于 2026-10-21。本文依据官方文档分析，未做产品性能或排障速度实测。美元价格为公开起价，实际地区、合同、税费和使用范围另计。

从延迟告警走到相关日志

假设结账服务突然变慢。工程师需要知道哪些请求受影响，时间花在哪个下游，再找到同一次请求的日志。主机指标正常，并不能回答这些问题；链路数据已经入库，也不代表服务名和关联字段齐全。

Grafana Cloud 的 Application Observability 提供服务清单、服务健康和调用关系视图，底层则有 Mimir、Loki、Tempo 等托管数据服务。服务名、环境属性和所需 Span 指标准备好后，这些视图才有可靠的数据来源。缺了必需的标签或指标，问题要回到采集和生成流程处理。服务清单 · 接入所需指标与标签

Datadog 也需要相应的接入。安装基础设施 Agent 后，应用链路、浏览器会话和代码性能数据仍要看产品、语言运行时和插桩支持。团队应拿自己的结账链路确认哪些数据已经有了，哪些还得补，而不是把一次主机接入成功当作完整 APM 上线。

如果大部分时间花在补 Trace ID、统一服务名，换平台也会遇到相同工作。如果数据已经完整，工程师仍每天手工拼接上下文，现成的应用分析流程就可能值得额外付费。Grafana Cloud 可以选择继续搭自己的视图，也可以使用 Application Observability；比较费用时，要先选定这条路线。Application Observability 计费

一个请求 ID，为什么能把指标账单放大

请求数本来只按服务和环境统计。后来为了排障，把每个请求 ID 也放进指标标签，同一条指标就会产生大量不同组合。数据仍然能写入，账单却可能跟着标签数量增长。

延伸阅读2026 Prometheus + Grafana 替代方案：自建监控何时升级？→

Datadog 的自定义指标计量与指标名、标签值组合有关，套餐提供相应账户额度；启用 Metrics without Limits 后，还要区分摄取和索引。标准集成指标并不全部属于额外付费的自定义指标，因此预算要从实际指标清单出发。自定义指标计费

Grafana Cloud 同时看活跃序列和每分钟数据点，并采用计费周期内的第 95 百分位。即使标签组合不变，把抓取间隔缩短也可能增加费用。Adaptive Metrics 会根据看板、告警和查询的使用情况提出聚合建议；采用前仍应确认哪些维度会丢失。指标计费 · Adaptive Metrics

所以，先把高成本指标与使用者对应起来，通常比直接换后端更有帮助。一个没人使用、却带着请求 ID 的指标，迁过去以后仍然需要治理；已经被关键告警使用的维度，则不能只为降量就删掉。

留下看板，还要留下告警的含义

Grafana 看板 JSON 可以导出，也能放进版本管理。但数据源标识、插件和查询能力变了，同一份配置未必能原样运行。Cloud 的应用视图与 AI 调查功能，也不是一份可以直接复制到开源 Grafana 的看板。

Datadog 的看板和告警同样可以按配置管理。迁移时更容易遗漏的，是分组方式、缺失数据处理、通知路由与访问权限。例如一条告警原来只对生产环境生效，换了服务属性后，测试流量混了进去，图表有数据也不能说明迁移成功。

OpenTelemetry 可以减少重新插桩的工作。Datadog 接受 OTel，但兼容程度取决于信号与功能；Grafana 的开放协议也不会自动搬走历史查询和事件流程。先双跑一个应用，对比采样、服务身份、日志关联、告警行为和保留期，比一次导出所有看板更容易发现差异。Datadog OTel 兼容说明

这部分工作应该计入迁移成本。现有看板与告警确实好用，延续它们就有价值；配置已经难以维护，重建也可能是改善的机会。关键是哪些流程需要保留、哪些值得重新做。

费用从哪几部分长出来

以 100 台持续运行的主机为例，如果同时需要 Datadog Infrastructure Pro 和基础 APM，按公开年付起价计算：

100 ×（15 + 31）= 4,600 美元/月

这只是两个产品的小计。独立购买 APM 的年付起价为每主机每月 36 美元；31 美元是配套付费 Infrastructure 时的 APM 起价。是否购买基础设施产品，应由监控需求决定。Datadog 价格

Grafana Cloud Pro 从每月 19 美元平台费加用量开始。Application Observability 起价为每主机小时 0.025 美元；100 台主机连续运行 30 天，是 72,000 主机小时，之后还要应用额度与阶梯。2026 年 2 月 13 日起的新客户按主机小时加遥测计费，较早客户可能使用带遥测抵扣的另一种费率。Grafana 定价 · 应用分析计费规则

再给这批主机加上每月 2,000 GB 日志、1,500 GB 链路和 25,000 条指标序列，仍不能直接得到完整账单。Datadog 需要区分日志摄取、索引事件、留存和其他查询方案，APM 已含的摄取与索引额度也要先扣清。Grafana 则要分别看处理、实际写入和留存；保存链路的费用不替代 Application Observability 的主机小时费。

日志查询也会进入 Grafana Cloud 的费用模型。其每月公平使用额度是写入日志量的 100 倍，超过部分可能另计。付费日志和链路默认最低保留 30 天，更长保留按额外周期计费。采集端发出的原始字节、处理后的写入量与最终保留量，并不总是同一个数。日志计费 · 链路计费

日常只查最近一小时，与每个值班班次都扫描一个月日志，对查询和留存的要求不同。两边都应按真实使用频率估算，再加入用户体验、支持、网络和双跑期费用。免费版可以帮助小范围接入，但按产品划分的额度、保留期和支持条件，仍要与实际需求对应。

值班和 AI 会增加哪些投入

故障找到以后，还要把它交给合适的人。Datadog 提供 On-Call 和 Incident Management；Grafana IRM 提供轮班、升级、事件协作与复盘，按活跃用户计费并适用套餐额度。团队已经有值班工具，就应比较继续连接它的维护工作，与转用平台内流程的费用。Grafana IRM

Grafana Assistant 能辅助查询与调查，其用户和 Token 费用独立于 IRM、可视化费用。评估它或 Datadog Watchdog、Bits AI 时，可以沿同一次故障查看能访问哪些数据、如何呈现依据、是否遵守既有权限。本文没有验证双方 AI 的准确率，产品名称也不能代替这项比较。Assistant 能力 · Assistant 计费

哪些投入值得继续保留

PromQL、Grafana 看板和 OTel 已经稳定，主要希望减少后端运行工作，Grafana Cloud 很自然。接下来要决定的是保留自定义视图，还是采用 Application Observability 等现成流程；两者需要的工程投入和付费产品不同。

Datadog 集成、告警和调查习惯已经深入日常工作，继续使用也有充分理由。新增需求出现时，按相关产品、套餐和超额用量增补预算，比从基础设施单价推算全平台费用更可靠。

语言运行时、Profiling、数据库和日志关联是否满足需求，要放进同一个试点。常用路径已经顺畅，没有必要为了功能表多几项就迁移；每天都要跨界面重建上下文，减少这部分工作才是值得购买的收益。

观测云值得比较的部分

如果主要困难正是日志与链路分散，可以在观测云接入同一条业务链路，查看服务、Span 和相关日志。业务仍要正确传递 Trace ID，并统一服务字段；平台无法补出从未采集的数据。观测云 APM

这时比较的应是完成一次调查所需的数据、留存和人员投入。已有平台已经好用，迁移收益可能很小；多套工具需要持续维护关联配置，减少这部分工作才可能抵消新的服务费用。先按同一个故障和同一批数据看结果，再决定是否扩大接入。