Datadog vs Dash0：OTel 接入、过滤位置与信号计费

平台团队把几个服务改成 OpenTelemetry，指标、日志和 Trace 都能发出去了。月底却发现，减少了看板里的噪声，账单没有按同样比例下降。接入协议统一以后，过滤发生在哪里、哪些数据仍被计量，成为新的问题。

Datadog 与 Dash0 的比较很适合从这里开始。已有 Datadog 的调查和告警流程，保留 OTel 插桩并不要求立刻换平台；想围绕 OTel 数据组织查询、看板和成本控制，Dash0 提供了另一套路径。开放协议能够减少应用侧改动，却不能让任意后端切换都免配置。

观测云编辑部 · 资料核对于 2026-10-21。本文根据当前官方文档讨论 SaaS 接入与使用方式，未进行性能、AI 效果或实际账单测试。

三类数据发出去了，为什么仍然关联不上

假设订单请求超时，Trace 进入生产数据集，应用日志却进入测试数据集。每份数据单独搜索都能找到，点击链路时却没有相关日志。这种情况与平台是否“OTel 原生”没有矛盾，问题出在数据组织。

Dash0 用 datasets 分隔组织内的遥测，官方要求需要关联的数据处于同一个 dataset。发送时可用 Dash0-Dataset header 指定目标，令牌也必须拥有对应写权限；省略该 header 时，会使用令牌的默认摄入数据集。Datasets。

随后才是服务名、环境、时间和 Trace/Span 标识。自动插桩能覆盖受支持的库，业务流程中的特殊等待、异步任务或自定义操作，仍可能需要补充。地区端点、认证与 Collector 管道也不能省掉。Dash0 的 Python 接入示例同时展示了本地 Collector 与直接发送路径，并要求直接发送时带上认证和数据集信息。接入示例。

Datadog 同样支持 OTel。DDOT、上游 Collector 和直接 OTLP 的功能矩阵不同，已有 SDK 发来的 Trace 能显示，不代表服务指标、Profiling 或应用安全等原来使用的能力全部等价。Datadog 兼容矩阵。选接入路径时，应该留下的是工程师实际依赖的证据，而不只是连接成功。

同一条错误率曲线，计算方式可能变了

Dash0 的指标查询支持 PromQL，看板采用 Perses 格式。这有助于保存查询与可导出的看板定义，但查询里的名称、标签和数据源仍需要对应。官方也说明 PromQL 有 Dash0 特定行为，建议适用时通过 otel_metric_name 选择原始 OTel 指标，而不是假定名称转换以后完全相同。指标查询、看板格式。

比如迁移一张累计请求数图，视觉查询可能自动采用增长量，手写 PromQL 却需要自己明确 increase() 或适合任务的表达式。把累计计数直接画成失败率，界面仍会产生一条曲线，含义已经错了。

Dash0 还把日志、Span 等原始遥测按需表达为 synthetic metrics，可以用同一查询方式分析。它们不是此前已独立保存的一组普通时间序列，结果取决于相关原始数据。Synthetic metrics。因此，删除“看起来重复”的日志之前，要看团队是否用这些日志生成调查视图。

Datadog 原来的查询、Monitors、权限与通知路由不会因为导出 OTLP 就一起迁移。Perses 能带走兼容格式的定义，也不保证任意 Datadog 看板直接导入即可使用。协议、可视化格式与平台配置，分别解决不同的迁移工作。

过滤发生在摄入前，还是摄入后

Dash0 当前价格页将 telemetry 拆成 Ingestion 与 SignalStore 存储。所有进入服务的信号先按摄入计量，经 SignalControl 过滤掉的部分不再付存储费，但摄入费用仍存在。这与旧介绍里笼统的“过滤就不计费”不同。Dash0 当前价格。

当前公开基础费率中，日志记录与 Span 每百万分别为 0.060 美元摄入、0.540 美元存储，后者对应 30 天保留；指标数据点每百万为 0.020 美元摄入、0.180 美元存储，对应 13 个月保留。高用量阶梯、SignalControl Edge 与合同会继续影响计费，不能把基础费率当成所有规模的固定报价。

假设一个月发送一亿条日志，随后在服务中保留两千万条，不考虑阶梯和其他消费：

100 × 0.060 + 20 × 0.540 = 16.80 美元

如果一亿条都保留，同一基础口径为 60 美元。这只是日志计量算例，不包括 Span、指标、Web、Synthetics 或 AI。若在客户自己的 Collector 中提前丢弃，未发送的记录不会经过同一摄入路径，但也从此没有这份排障证据，Collector 的运行成本仍在。

按记录计费也需要知道记录从哪里来

按信号数收费不等于日志数量稳定。一次请求写十行日志还是一百行，重试是否重复输出，业务流量是否翻倍，都会改变条数。指标也类似：标签组合增加后，时间序列增多，每次导出就会产生更多数据点。

同一百 GB 日志，可能是少量大记录，也可能是大量小记录。因此，把 Datadog 某个按 GB 的摄入费率与 Dash0 每百万条的费率直接相比，缺少必要的换算输入。记录大小仍影响传输、SDK 和 Collector 资源，不能由计价单位推导为无限负载。

Datadog 要按实际模块合计基础设施、APM、日志、RUM 等消费；日志又有 Standard、Flex 与归档等路径。主机型 APM 当前年付配套 Infrastructure Monitoring 为 31 美元/主机/月起，独立 APM 为 36 美元起，不能只取一个单价代表全部调查成本。Datadog 价格。

Dash0 也不应被概括成“任何功能都只按遥测条数”。当前 Agent0 使用 credits，代码分析产品按用户席位计费。历史上取消 telemetry 基础订阅费的公告，不能替代今天所有产品和合同的报价说明。

预算控制本身也会影响数据可用性。Dash0 文档说明，接近月度预算上限时会告警，并在宽限期后暂停摄入。它能约束消费，但不能保证故障高峰中的全部数据仍被保留。临近上限时恰好遇到异常流量，团队需要有人处理预算通知，而不是等业务事故结束后才发现观测中断。费用与预算控制。

因此，正常日志和异常日志不能只按平均条数一起削减。一个平时很安静的服务，出错时可能连续输出重试；这既增加账单，也恰好是最需要调查的记录。保留哪些细节、哪些内容可以在源头汇总，应由业务价值与故障处理共同决定，单纯追求每月数字更低可能把成本转移到值班时间。

把通知和实际使用一起迁过去

告警规则能算出结果，下一步还要有人接到通知。Datadog 已有 On-Call 产品，不能继续沿用“没有轮值能力”的旧比较。On-Call。Dash0 的查询可以转成 check rule，但团队仍要安排通知目标、升级与处理责任，不能用一张成功发消息的截图证明整套响应流程已迁好。

浏览器体验、合成测试、剖析、安全和 AI 也是各自有接入与权益的工作。本文不按产品年龄推断这些功能不存在或天然更成熟；当前 Dash0 价格页已列出 Web 与 Synthetics 等内容。已有功能如果仍在解决问题，可以暂时保留原平台，而不是为追求架构整齐一次撤掉。

什么情况下值得改换调查入口

已有 OTel 数据规范，常用查询以 PromQL 为主，又愿意按数据集和信号消费管理平台，Dash0 比较贴近这套习惯。收益来自数据模型、查询和团队经验一致，而不是“零锁定”保证。

Datadog 的跨模块调查与响应流程已经使用深入，继续保留也合理。先用一个服务验证数据、查询与费用的变化，再决定迁移多少，比把全部采集同时切走更容易看清真正省下的工作。

沿用 OTel 接入观测云

观测云提供OpenTelemetry 接入。已有插桩可以按支持的路径复用，把需要共同调查的日志、指标与链路接入，再确认服务标识和关联是否完整。

接入标准减少应用侧变化，采样、查询、看板和通知仍要对应业务。增加观测云同样应计算服务费与迁移投入，不能仅凭协议相同就假设原有配置全部通用。