Datadog vs CloudWatch：AWS 监控、应用排障与成本怎么选

应用、数据库都在 AWS，值班团队也熟悉 CloudWatch，继续使用现有监控通常很自然。服务变慢时，沿资源、日志和应用调用往下查，不必仅为换一套看板重新安排账号与权限。

Datadog 更值得考虑的场景，是请求还会经过另一家云或机房，几个团队每次都要互相转发截图。这里缺的未必是某一种指标，而是跨环境接续调查的方式。

两者也可以一起运行。CloudWatch 已有 Application Signals、服务依赖、SLO 与链路调查；Datadog 的 AWS 集成本身又会使用 CloudWatch 数据。选型要看哪一段工作经常卡住，以及新增平台以后究竟少维护了什么。

作者：观测云编辑部。资料核对于 2026-10-21。本文依据官方资料比较 Datadog SaaS 与 CloudWatch 的相关能力，没有进行性能、操作体验或成本实测。

接入同一个账号，得到的数据可能不同

“CloudWatch 五分钟，Datadog 秒级”把不同来源混在了一起。EC2 基本监控使用五分钟周期，详细监控是一分钟，后者可能产生额外费用。这是 EC2 的说明，不是所有 AWS 服务指标的统一规则。

Datadog 通过 AWS 集成取得 CloudWatch 指标时，同样受到源指标发布时间与取数方式影响。API 轮询、Metric Streams 和主机 Agent 是不同路径；连接云账号不会把原本低频的服务指标变成 Agent 的本地采样数据。更短的指标周期，也不等于告警会在同样短的时间内送达。Datadog AWS 集成。

例如 CPU 的原生指标已经够用，但排障还缺内存、文件系统或运行时数据，就需要补上相应采集。CloudWatch Agent 也支持本地服务器和容器环境。系统有一部分在机房，并不意味着 CloudWatch 立刻失去用途。CloudWatch Agent。

一次结账变慢，沿请求往下查

假设 ECS 上的结账接口延迟升高，时间主要花在等待数据库连接。CloudWatch 可以从 Application Signals 的服务指标和依赖关系进入调查，再看链路、日志和相关资源。SLO 与错误预算也属于它的应用观测范围，不必另买平台才有这些概念。Application Signals、SLO。

指标是否覆盖全部请求，与接入方式有关。AWS 的对照表区分 ADOT SDK 配合 CloudWatch Agent、自有 OTel SDK 配合 Collector，以及已有 X-Ray SDK 的路径。前一种组合可以保持全流量指标；后两种在 100% 采样时才有对应的全流量指标覆盖。运行时指标、Container Insights 和日志整合也存在差别。错误率看起来下降，可能与采样口径有关，不一定是服务改善了。接入方式比较。

Datadog 可以从 APM Trace 进入同一请求的日志，再看关联主机或容器。服务、环境、版本与 Trace ID 要能对应，日志字段也需要解析。日志和 Trace 独立采样时，能搜到日志不代表整条链路还在；同一个请求缺了一段，可能发生在采集、采样或保留阶段。日志与链路关联。

请求始终留在 AWS，原有 IAM 和资源信息可能已经足够。请求跨到其他环境，集中使用已接入数据的收益更明显。不过，服务之间没有传播的上下文，也不会因为换了平台自动补回来。

日志要走自己的投递路径

AWS 指标集成成功，不等于操作系统日志、应用 Trace 和历史指标都已到齐。Datadog 的日志可以通过 Amazon Data Firehose、Forwarder 等路径投递，应用 Trace 需要相应插桩；官方集成也说明，不会自动回填启用之前的历史指标。

已有 CloudWatch Logs 时，可以保留原始路径，把需要集中调查的日志再发到 Datadog。这样迁移容易回退，但长期双写也意味着两套保留、权限和消费。Firehose、Lambda、网络与相关 API 的工作并没有随着日志进入另一家平台而消失。

实际查询可以从一个很窄的问题开始：生产结账服务过去十分钟有哪些失败请求，再按请求标识找前后记录。CloudWatch Logs Insights 提供 QL、OpenSearch SQL 和 PPL，并非只能做文本过滤；Datadog 侧则查询已经摄入、解析并处于可查询保留范围的数据。CloudWatch 查询语言。

如果一次查询实际扫描 200 GB，每天执行三十次，累计就是 6,000 GB/天。这个算例不是报价，却说明了查询习惯怎样改变消费。一次事故中的宽范围搜索可能值得，日常看板反复扫同样宽的历史范围则未必必要。

多账号查看，不一定要多存一份

CloudWatch 的跨账号可观测性通过 OAM 在同一区域共享遥测访问。跨账号跨区域控制台承担相应视图的展示与切换，集中化功能则可以把选定日志、指标送到目标账号或区域。它们处理的数据对象、权限和复制行为不同。AWS 跨账号机制。

值班人员只需查看多个账号时，共享访问可能已经够用。要求集中保存、统一查询或放到指定区域，才涉及另一套数据组织方式。这比笼统地评价“跨账号是否方便”更接近实际工作。

Datadog 也需要账号和标签规范。同名服务可能属于不同环境，采集权限、敏感字段、平台所在区域、备份和支持访问各有自己的安排。集中入口省去部分切换，不能替代这些数据管理工作。

两边都保留告警时，最好让其中一边承担通知与升级，另一边提供调查数据。同一次故障收到两条内容相似的通知，很少能帮助工程师更快定位原因。

Datadog 订阅之外还有哪些费用

CloudWatch 按地区与功能计量。经典指标涉及指标数量和 API；当前 OpenTelemetry 指标路径涉及摄入 GB 与 PromQL API 扫描样本量。日志有摄入、存储和查询费用，Application Signals、Trace、告警、RUM 与 Synthetics 也按所用功能计算。CloudWatch 价格。

Datadog 主机型 APM 的年付起价为 31 美元/主机/月，配套 Infrastructure Monitoring；独立 APM 为 36 美元/主机/月起。十台主机按 Infrastructure Pro 15 美元加配套 APM 31 美元，基础小计是：

10 × (15 + 31) = 460 美元/月

这还没有包括日志、RUM、额外 Span、其他模块和 AWS 侧费用。RUM、Replay、Synthetics 等用户体验能力也需要各自接入，不能算作基础指标已经附带；安全与 AI 产品同样不能默认全部包含。Datadog 价格。

CloudWatch API 或 Metric Streams 仍在提供指标，日志仍先进入 CloudWatch 再由 Firehose 或 Lambda 转发，相应 AWS 消费就可能继续存在。应用或 Agent 直接发送的数据又是另一条路径，不应机械地都算成双份存储。

成本最后取决于指标类型与数量、日志 GB、查询频次、链路采样和保留、会话量，以及迁移期间的双写和人员投入。免费额度可以帮助起步，不能代表生产一直免费；减少交接也可能节省时间，但本文没有测量这部分收益。

什么时候继续用，什么时候增加平台

业务集中在 AWS，团队熟悉账号治理，应用语言受支持，Application Signals 和日志关联已经覆盖主要事故，继续完善 CloudWatch 很合理。现有配置和运行经验都是已经付出的投入。

调查经常跨云、跨基础设施层级，几个团队也准备统一服务标识和采集，Datadog 更值得试。它的价值来自同一次故障能否连续查下去，而不是另一个更大的总览页面。

也可以让 CloudWatch 保存适合的原生数据，把需要集中调查的部分交给 Datadog。保留、通知和费用有明确分工时，组合能复用已有系统；无差别叠加则容易留下双份数据和通知。

用观测云连接跨环境的数据

观测云的链路详情可以沿 Span 查看已采集的日志、主机和容器信息。AWS 中的请求还牵涉其他环境时，这是一条可采用的集中调查路径。

原有 CloudWatch 不必因此全部替换。需要集中使用的数据接入观测云，其余数据沿用现有方式；关联仍依赖标识与采集范围。服务费、双写和运行投入合在一起，才是这项选择的实际成本。