Datadog vs SigNoz：OTel、部署责任与迁移成本怎么选

已经用 OpenTelemetry 采集应用数据，日常主要查链路、指标和日志，SigNoz 很容易进入候选名单。尤其是 Datadog 账单上涨以后，团队会想知道：保持现有插桩，换一个后端，能不能继续完成同样的调查？

如果已经依赖 Datadog 的浏览器回放、合成测试、安全调查和多个团队的告警流程，迁移就不只是换一个遥测出口。那些平时顺手使用的功能，需要分别找到去处。

所以可以先从一个服务开始，而不是从“开源一定省钱”开始。SigNoz 有托管 Cloud，也有自托管版本；Datadog 支持 OpenTelemetry。真正影响选择的，是数据进来以后怎样使用，以及后端由谁持续运行。

作者：观测云编辑部。资料核对于 2026-10-21。本文依据官方资料讨论 Datadog SaaS、SigNoz Cloud Teams、Community 与相关企业交付方式，没有进行性能或成本实测。

同一个请求，能不能找到它的日志

假设订单接口偶发超时，数据库查询不慢，时间却耗在下游重试。工程师先找到慢请求的 Trace，展开重试所在的 Span，再看这一段调用留下了什么日志。只有服务名称出现在首页，还不足以完成这次调查。

SigNoz 用 trace_id、span_id 关联日志。受支持的 OTel 日志集成可以在活动 Span 上下文里携带这些标识；文件日志或 Kubernetes 日志则可能需要解析和字段映射。日志正文里有一串请求 ID，与平台已经把它识别为 Trace 字段，是两个不同状态。日志与链路关联、链路字段解析。

Datadog 同样依赖正确的日志字段、Trace 标识、服务与环境标签。两边显示的请求数不同，可能是采样或聚合口径不同；延迟分位数也会随时间窗、请求范围和过滤条件变化。一个平台图上的数字更低，不能直接解释为应用更快。Datadog 日志关联。

这条请求如果需要继续查主机或容器，还要有对应资源数据。平台里同时存在三类信号，只说明数据有了入口；能否从当前请求顺着查到下一步，才决定它们对值班有没有帮助。

保留 OTel 插桩以后，哪些东西还要搬

SigNoz 以 OTel Collector 组织采集，把遥测写入 ClickHouse。OTLP 是重要入口，但不是唯一输入；官方架构还列出 Jaeger、Zipkin、Kafka 等来源，实际使用取决于接收器和配置。ClickHouse 承担遥测存储，也不意味着生产部署只有一个数据库进程。SigNoz 架构。

Datadog 的 DDOT、上游 Collector、直接 OTLP 路径各有功能支持范围。选择保留原 SDK 还是调整采集路径，会影响服务指标、Profiling、应用安全等能力。Trace 已经到达，并不能说明原来使用的每个功能都已随之迁移。Datadog OTel 兼容矩阵。

开放插桩的好处，是应用不必为每次后端变化全部重写。仪表盘查询、告警规则、权限、历史数据和人员习惯仍然留在平台这一侧。它减少了某些迁移工作，并没有把迁移成本降到零。

比较适合的起步方式，是一个范围可控的服务暂时双写。指标单位与聚合、资源属性、日志时间和 Trace 连贯性一致以后，再接续最重要的告警。Collector 的队列、重试和出口流量也会增加，因此双写是一段有成本的过渡，不必永久保留。

自托管省下的服务费，要换成哪些工作

SigNoz Community 可以自行部署，运行团队也就接过写入峰值、查询并发、磁盘、备份、升级与恢复。安装在一台机器上能够接收数据，不代表这台机器足以应对生产中的保留量和并发查询。日志大小、Span 大小与指标基数不同，同样数量的服务也可能带来完全不同的负载。自托管安装。

许可与功能也分开存在。主仓库普通代码、ee/ 企业代码和第三方组件适用的许可并不完全相同；Community 与付费版本也不是同一份权益。SigNoz 许可证。身份认证应落实到具体登录方式、角色与审计能力，不能用“所有 SSO 都在企业版”概括；价格页标注尚未推出的功能，也不能作为今天已经具备的能力。

不准备维护后端时，可以选择 SigNoz Cloud。企业 BYOC 由厂商在客户云账号内运行部署，企业自托管则由客户运行、厂商提供相应支持。两者都把数据放在客户环境里，却交给不同的人维护。SigNoz 企业交付。

Datadog 在本文中比较的是厂商运行的 SaaS 后端。客户仍要配置 Agent、采集权限、采样和保留，但不负责自行部署它的分析后端。自托管控制更多，托管服务承担更多运行工作，费用要与这些职责一起看。

标签变多，按样本收费也会增长

SigNoz Cloud Teams 当前公开起步费用为 49 美元/月，包含 49 美元用量。默认价格展示中，日志和链路是 0.30 美元/摄入 GB，保留 15 天；指标是 0.10 美元/百万样本，保留一个月。更长保留期、企业方案与自托管需要使用各自口径。SigNoz 价格。

按样本计费没有单独的主机费，但基数仍然会改变结果。10,000 条活跃时间序列，每 30 秒导出一次，按 30 天算：

10,000 × 2 × 60 × 24 × 30 = 864,000,000 个样本
864 × 0.10 = 86.40 美元指标用量

这个数还不含日志和链路，也不是在最低消费 49 美元之上再完整加一次。先合计用量，再应用包含额度和最低消费规则。序列数量或导出频率翻倍，样本量也会随之变化。指标计费说明。

Datadog 按实际使用的产品计费。主机型 APM 年付 31 美元/主机/月起需要配套 Infrastructure Monitoring，独立 APM 为 36 美元/主机/月起；日志、RUM、其他模块与超出所含额度的用量可能另行收费。只取 SigNoz 的一项摄入费，与 Datadog 整份账单比较，得到的并不是同一服务范围的差价。Datadog 价格。

自托管则把一部分费用移到计算、磁盘、备份、网络与人力。减少噪声日志、控制指标基数、调整采样和保留期，在任何方案里都有价值。这里的美元算例只说明用量关系，不包含税费、地区与合同差异，也没有测得固定节省比例。

原有的特殊功能值得单独留下

错误率和慢请求能够查到以后，常用但不在基础链路里的工作往往才浮现出来：浏览器回放、合成测试、安全检测、剖析，以及已经连好的第三方通知。

SigNoz 当前有前端 Web Vitals 与移动端监控相关能力，不能简单说它没有前端观测；这些能力也不意味着它与 Datadog 每种回放、合成测试或安全产品完全相同。版本与功能范围。某些功能仍然有用，可以暂时保留原工具，不必为了架构整齐一并撤掉。

历史查询、权限和告警路由也属于同一份迁移工作。让平时值班的人沿着一条已知故障操作，比只确认 SDK 能发出数据更有意义：他要能找到入口、理解服务上下文，并继续完成下一步调查。旧路径何时停止，应由这些实际使用情况决定。

什么情况继续用 Datadog，什么情况换 SigNoz

主要需要日志、指标和链路，已经有 OTel 基础，又希望按数据用量估算费用，SigNoz Cloud 是直接的候选。需要自行控制部署和存储，而且有团队负责容量、备份与升级，自托管 SigNoz 更符合这份责任分工。

Datadog 的跨产品调查、集成和组织流程已经使用深入，继续保留也很合理。现有配置与人员经验有价值，只要这些价值仍值得相应订阅与用量费用，就不必为了较低的起步价格重新建设。

需求逐渐变化时，可以只迁移一部分服务。新平台接得住常见故障，也能在费用和维护投入上改善现状，才是更充分的迁移理由。

把观测云作为另一条调查路径

观测云的链路详情能从 Span 继续查看已采集日志及相关主机、容器。团队需要集中应用与资源信息时，可以把同一服务接进来，沿原有故障场景使用。

服务、请求标识与采集范围仍要由业务侧安排。是否选观测云，取决于这些关联能否减少调查中断，以及服务费用与原有平台、迁移投入的总和；已有插桩和有用的工具不必一开始全部替换。