Datadog vs Uptrace：已有 OpenTelemetry，后端该托管还是自建

几个服务已经接好了 OpenTelemetry，Collector 也在稳定运行。下一步选后端时，Uptrace 很容易进入候选名单：接收现有遥测数据，围绕 Trace、日志和指标开展调查，还能部署在自己的环境里。Datadog 则可能已经承接了公司的主机监控、告警和其他运维流程。

这个选择的关键，不是哪个产品用更少的组件就能跑出一张图，而是团队想买一套现成工作流，还是愿意继续建设与维护自己的遥测后端。Uptrace Cloud 和自建 Uptrace 又是两种不同安排，不能把它们的价格与责任混在一起。

资料核对于 2026-10-21，依据官方文档分析，未开展双方性能测试。算例只用于解释数据规模。

接收 OTel，不等于完成迁移

Uptrace 以 OpenTelemetry 接入为重要路径，可以处理 Trace、指标和日志。已有 SDK 与 Collector 时，通常能复用一部分采集工作，但仍需核对端点、凭据、资源属性与信号配置。接收到 Span 只是开始，还要确认服务名、环境、错误状态和时间信息能否支持实际调查。Uptrace 接入指南。

Datadog 也支持 OpenTelemetry，只是不同接入路径与产品能力有兼容性区别。因此不能把它描述成必须全部换回专有 SDK。迁移前应列出团队真正使用的能力，再查看所选 OTel 路径是否满足要求。Datadog OTel 兼容性。

例如，旧平台的告警按接口聚合，新平台却把带订单号的 URL 当成操作名，曲线就会被拆散。又如测试与生产服务共用同一个名字，导入成功以后还得重新分组。此类命名问题不会因为协议标准化而自动消失，越早统一，后续更换后端越容易。

迁移还应该保留一条跨消息队列的真实业务调用。生产端与消费端的上下文若没有接上，后端里会出现两段各自完整的 Trace。工程师仍然需要靠业务 ID 拼接。选型试用不妨从这个最难的路径开始，而不是只展示同步 HTTP 请求。

查询能力要按工作流验证

Uptrace 不是只有 Trace 的查看器，它也提供日志、指标、错误分析与告警。Datadog 的产品范围更广，但“范围广”只有在团队确实使用那些能力时，才值得体现在采购中。需要替代的功能应该逐项落实，而不是用“覆盖八成需求”这样的数字代替验证。Uptrace 产品与文档入口。

主动检查就是一个例子。Uptrace 有通过 OTel Collector httpcheck 接收器定期检查 HTTP 端点的文档，所以不能说它完全没有合成监测路径。但这种自行部署的端点检查，也不应直接等同于包含托管探测节点、浏览器交互步骤和测试运维的完整服务。Uptrace HTTP 检查。

从已有 Datadog 迁移时，可以拿一条真实告警做验收：同样的窗口和阈值能否表达，缺数据时如何处理，通知能否找到对应值班人，点击后有没有所需的调用链。一个按钮能否找到，不如完整过程能否继续工作重要。

自建并不是只有一个二进制

当前 Uptrace 自建文档列出 Uptrace 程序以及 ClickHouse、PostgreSQL、Redis 三项依赖。ClickHouse 存储遥测，PostgreSQL 保存用户、项目和仪表板等信息，Redis 参与缓存与后台协调。部署工具可以简化安装，却不会消除这些组件的容量、备份和升级责任。自建结构。

团队已经熟悉 ClickHouse，确实能复用经验；没有这类经验时，不能把单个容器启动成功当成长期维护能力。要知道数据保留由谁配置，备份是否覆盖配置库，升级失败能否恢复，以及平台本身出问题时去哪里看诊断信息。

恢复演练可以从一个小环境开始：保存一段已知调用，备份必要数据与配置，重建以后重新查询并验证权限。这样才知道备份包含了哪些内容，也能发现查询数据还在、项目配置却缺失的情况。自建带来的控制权，最终要落实成有人能完成的操作。

写入高峰会把维护差异放大

ClickHouse 是分析数据库，但采用它并不自动保证任意数据量都能快速查询。Uptrace 的扩容文档讨论了处理缓冲、写入批次、数据分片和 Kafka。特别是内存缓冲满时，进入的数据可能被丢弃；增大缓冲能吸收部分短时波动，但也要为内存留出空间。Uptrace 扩容。

假设后端每秒新增 10 MB 待写入数据，存储短暂停顿六十秒，积压原始量就是 600 MB。它还不是进程需要的全部内存，因为数据结构、其他信号和并发查询也会占用资源。这个量级足以说明，不能只按照安静时的进程内存决定资源限额。

Kafka 可用于解耦与缓冲，但当前文档把相应集成限定在 Enterprise；引入后还要维护新的队列系统。是否值得，取决于能容忍多久的后端停顿，以及谁来维护它。更复杂的结构并非总是更好，完全不处理积压也不是免费的简化。

选择 Cloud 或明确约定的托管交付，可以把更多后端运维交给厂商。客户仍要管理采集、业务字段和发送失败，且应确认服务恢复与支持范围。它与自行维护数据库的责任差异，比安装页面上需要几条命令重要。

免费、自建订阅和 Cloud 分开算

截至核对日，Uptrace 公共仓库的主许可文件为 AGPLv3；自建发行与商业功能应按所用版本和对应条款核对，不能笼统称为 Apache 或 BSL。当前自建方案区分 Community 与多个付费档位，留存、访问管理、扩容和支持并不都属于同一层。Uptrace 许可、自建版本。

自建付费版采用版本订阅与适用用量档位，云端则有自己的数据计量。当前 Cloud 页面按 Trace、日志和指标区分计算，指标说明采用接收的数据点。只知道有多少条序列还不够：相同序列每三十秒采一次，比每六十秒采一次产生更多数据点。额外留存也应单独核对。Uptrace Cloud 价格。

估算时先测量一段真实负载的字节数与数据点，再加入增长、高峰和保留期。不要把厂商演示中的平均 Span 大小当成自己的记录大小，业务属性和异常堆栈都可能改变它。网络出口与自建基础设施也不是软件订阅的一部分。

Datadog 的费用同样按所选产品计算。迁走 APM，却继续使用原来的日志、基础设施或浏览器监控，不能把整张旧账单都计作节省。还应把迁移期间双写、历史数据留存和告警重建的工作放进预算。

也别忽略退出试用时的安排。哪些配置可以导出，旧告警什么时候停用，历史链接在迁移后还能保留多久，都应该有人负责。如果业务仍然依赖旧平台里的事故记录，就需要保留访问方式或明确迁移策略，不能在新平台出现第一条 Trace 后就立即关闭旧服务。

团队规模不大时，一项后台升级也可能占用原本负责业务发布的人。把这类工作排进日历，再评估能否长期承担，比把维护工时默认记为零更接近真实成本。

把维护能力作为选型条件

OTel 已经统一、需要的调查方式比较集中，且团队愿意承担数据库维护时，自建 Uptrace 值得验证；希望沿用其工作流但不维护后端，则应单独评估 Cloud 或托管方案。Datadog 已形成成熟跨产品流程时，替换应由实际瓶颈推动，而不是只因为另一个产品能免费启动。

观测云也支持通过相应接入方式开展服务与链路调查。采用 SaaS 可以减少后端建设，私有部署则需明确维护分工；业务属性、采样和上下文传播仍由应用与平台团队共同负责。让同一笔业务请求在候选平台里走完告警、定位、复核的过程，再比较预算与责任，才能看清哪种方案真正适合长期使用。观测云 APM。