Datadog vs Prometheus：自建指标体系还是购买可观测平台

Kubernetes 集群已经暴露了 /metrics，值班人员也熟悉现有 PromQL。错误率告警响起以后，大家仍要去另一套系统找日志，再拿 Trace ID 查链路。Prometheus 已经把异常报出来了，缺的却是后半段调查。

如果主要需求仍是指标监控，Prometheus 和已有规则通常值得保留。需要更长历史，就处理存储；告警路由混乱，就整理规则。只有当日志、链路和用户体验之间的调查持续占用大量时间，购买 Datadog 这类托管平台才可能省下更大一部分组合与维护工作。

观测云编辑部 · 资料核对于 2026-10-21。下文讨论采集、调查与持续运行的区别，未进行生产负载或总成本实测。

告警以后，还要去哪里找证据

Prometheus围绕带标签的时间序列工作：采集、存储、PromQL 查询、记录规则和告警规则。完整日志、Span 与浏览器会话属于其他系统，exemplar 能提供关联线索，也不等于已经有了追踪存储。

Datadog 将指标、日志、APM、RUM 等放在同一平台中，但它们仍有各自的数据模型和接入要求，也按相应产品核算。托管后端减少一些存储维护工作，服务标识、权限、采集质量和使用量仍需要团队管理。

Pull 与 push 已经不是清晰的分界线

Prometheus 常见部署通过服务发现找到目标，再定时抓取 HTTP 指标端点。抓取失败本身也能成为监控信号，应用侧不必知道每个读取者是谁。

但“Prometheus 只支持拉取”已经不准确。当前版本可通过 --web.enable-otlp-receiver 开启 OTLP HTTP 指标接收，路径为 /api/v1/otlp/v1/metrics；默认关闭，部署时需限制访问。remote write 接收也有单独的显式启用配置。接收这些指标不会让 Prometheus 变成日志与追踪存储。Prometheus OTel 指南。

Datadog Agent 通常将采集结果上报云端，但其 OpenMetrics 集成本身可以抓取 Prometheus/OpenMetrics 端点。因此可以保留 exporter，不必为了更换分析平台就重写所有应用指标。需要注意，这条集成采集的指标按自定义指标处理；把所有指标用通配符全部抓走，可能带来额外消费。

抓到同一端点，查询结果仍可能不同。counter 怎样计算增长、histogram 怎样聚合、标签和名称怎样转换，都会影响结果；毫秒变成秒却沿用原阈值，曲线看起来正常，告警已经变了。原有 PromQL 的统计含义需要留下，不能用“格式兼容”代替。

把后半段调查接起来

假设 checkout 服务错误率升高。Prometheus 可以用请求计数器计算失败比例，通过告警规则触发通知；Alertmanager处理分组、去重、静默与路由。值班人员再按服务、环境和时间范围进入日志系统，找到 Trace ID 后继续查追踪后端。

这条组合路线可以很好用，但每一次跳转都需要维护：标签如何命名，链接怎样传递时间，两个后端保留多长历史，由谁接收告警。仅部署 Prometheus 和一张 Grafana 看板，不会自动完成这些关联。

Datadog 可以在已接入的 APM、日志和基础设施数据之间继续调查，但仍要满足日志与链路关联所需的标识与解析条件。它减少的是部分平台组合工作，不会补回没有采集或已经采样丢弃的数据。

长期保留和高可用是两件事

Prometheus 的本地 TSDB 可以配置保留时间，并非“超过十五天就必须外接存储”。十五天是未配置时间和容量保留限制时的默认值，合理规划也可以本地保留更久。真正的边界是：本地存储不提供内置集群复制，单机磁盘与节点故障仍要自己处理。Prometheus 存储。

两个 Prometheus 副本抓取同一目标，可以提供冗余采集和规则评估，但不会自动变成一个复制数据库或全局查询入口。Alertmanager 的通知去重也不等于时间序列去重。多集群统一查询、对象存储和长期保留可以借助 Thanos、Mimir 等外部系统，具体可用性与查询行为要随架构设计。

Datadog 的托管后端把一部分存储运维交给服务商，但不是取消容量管理。指标基数、摄入范围、保留策略、权限和网络中断后的行为仍需关注。业务服务能正常运行，也不代表观测数据一定完整送达。

“免费”和“零锁定”都容易掩盖工程成本

Prometheus 采用 Apache 2.0 许可，不收取软件许可费；机器、磁盘、备份、升级、值班和规则维护仍需要投入。无法用“少于一百个节点就几乎零成本”作普遍判断：节点数相同，高基数标签或高频采集也能带来完全不同的负载。

Datadog 则应分别估算基础设施、自定义指标、APM、日志、RUM 等实际使用部分。OpenMetrics 接入只是其中一条消费路径，标签组合和所选计费配置都值得提前观察。OpenMetrics 费用提示、Datadog 价格目录。

PromQL、exporter 与开放协议让接入和查询更易复用，但不意味着迁移没有成本。recording rules、看板、告警、权限、历史数据和人员经验都属于现有系统资产。Datadog 同样可以通过 OTel 等路径降低应用侧耦合，却不能因此保证平台配置通用。

活跃时间序列增加、采样间隔缩短、保留期拉长，都可能改变存储和查询负载。能接受节点故障后少量数据缺口，与要求快速恢复完整历史，也不是同一份自建预算。平台团队已有相应经验时，新增维护成本可能不高；业务工程师还要轮流处理磁盘和升级，商业服务费就应与这些时间一起比较。

继续用 Prometheus，还是增加托管平台

指标监控已经用顺，PromQL 和告警规则也稳定，继续用 Prometheus 很合理。长期存储、日志和追踪可以按实际缺口增加，不需要为了一个未来可能出现的需求先装齐所有组件。

如果每次故障都要在多个后端之间重复寻找证据，团队又不想长期维护这套组合，Datadog 更有吸引力。它能替团队承担部分平台工作，实际需要的模块、采集与关联配置仍要做好。

已有 Prometheus 的团队可以采用渐进方式：保留现有告警，将一个服务的选定指标送到新平台，比较语义、关联效果与实际消费，确认后再迁移规则。这样既能利用已有资产，也能看清新平台究竟替团队承担了什么工作。

保留 exporter，接入观测云

保留 exporter 也可以逐步尝试其他后端。例如观测云 DataKit 的 Prometheus Exporter 采集器能够读取已有端点。先接一个服务，原有指标体系仍可运行，再对照名称、标签、单位和周期；不必为了换分析入口就先重写全部应用指标。