Dynatrace vs SigNoz：OTel 接通以后，迁移还没做完

团队已经把服务接入 OpenTelemetry Collector，准备把遥测再发一份到 SigNoz。第一天，几个服务都有了曲线和 Trace，切换看起来只差一个 endpoint。直到值班同事用旧告警调查一次异步订单延迟，才发现新系统里的服务名称不一致，队列两端没有连上，过去会用到的进程信息也不在同一条路径上。

Dynatrace 与 SigNoz 的比较，最有价值的部分就在这里：数据能进入另一个后端以后，原来那段调查能否继续。标准化插桩确实给迁移增加了选择，但应用采集、后端运行与日常使用仍是三件相互关联的工作。

观测云编辑部 · 资料核对日期：2026 年 10 月 21 日。本文讨论官方文档中的能力和部署方式，不声称做过双边性能或成本实测。

endpoint 换了，服务含义不会自动统一

SigNoz 以 OpenTelemetry 为主要采集基础，由其 OTel Collector 接收和处理遥测，写入 ClickHouse；应用可以直接接入，也可以经过已有 Collector。它把日志、指标和链路放进同一个产品，不只是一个 Trace 查看器。技术架构。

但一个异步订单能否完整展开，要看应用有没有把上下文带过队列，生产者和消费者如何记录操作，环境与服务标识是否一致。日志里只有订单号而没有 Trace ID，仍可能通过业务字段人工查找，却不会因为两类数据进了同一后端就自动成为同一条链路。

因此，双写初期适合选一条已经理解的业务路径，而不是立即把所有服务流量复制过去。保留其成功、超时与重试样本，比较事件时间、服务边界、错误状态和关键业务字段。这样可以区分采集缺口与后端使用差异。

Dynatrace 本身也支持直接 OTLP 与 Collector 接入，选择 OTel 不要求同时放弃 Dynatrace。团队可以先统一应用的输出，再决定哪部分分析工作值得迁移。Dynatrace OTel 接入。

OneAgent 留下的证据，要单独安排

OneAgent 的深度监控可以在受支持的运行时里提供方法、进程和剖析信息。换成 OTel SDK 以后，自动插桩覆盖、业务 Span 与资源采集可能不同。新后端已经收到 Trace，只能证明这份遥测传到了，不能证明原来的排障范围等量保留。Full-Stack 范围、支持矩阵。

过渡时同时运行 OneAgent 和 OTel，还要区分它们的协作方式。Dynatrace 的 OTel Span Sensor 可以捕获相应 OTel API 调用；若同一数据又经 OTLP 送回 Dynatrace，可能出现重复。语言和版本的具体行为应按官方配置核对。OneAgent 与 OTel。

把一份数据路由到两个后端，与两套插桩各自生成一份数据，不是同一个问题。前者增加出口、队列和消费，后者还可能改变链路结构。迁移期间请求数量突然翻倍，先检查这两条路径，别立刻把它当成流量变化。

Collector 也不是无限缓冲。官方建议为远端 exporter 配置发送队列与重试，必要时用持久存储保护重启期间的数据；队列满、重试期限耗尽或磁盘故障仍可能造成损失。双写是否会受到某一后端故障影响，应在实际 pipeline 配置下验证。Collector 韧性。

启动 SigNoz 与长期运行 SigNoz 是两段工作

当前 SigNoz Docker 文档已调整安装方式：从 v0.130 起，旧的 install.sh 和仓库附带 Compose 被弃用，文档转向 Foundry 生成并管理配置。当前示例除了 SigNoz 与 OTel Collector，还包含 ClickHouse、ClickHouse Keeper 和 PostgreSQL 元数据组件。不能继续沿用“只启动一个 ClickHouse 就够了”的描述。Docker 安装。

这条路径可以帮助启动环境，但单机 Compose 并不自动成为高可用方案。到了长期运行阶段，需要安排数据增长、备份恢复、组件升级、磁盘余量和查询高峰。ClickHouse 是存储引擎选择，不是无需维护的承诺。

例如，当历史查询与持续写入争用资源时，问题不只是给界面加一个超时。团队需要知道是查询范围过大、后台存储任务占用资源，还是实例容量确实不足。至少应让维护者能从观测页面回到数据库和 Collector 的运行状态，并在数据保留策略变化时重新评估容量。

部署责任也有不同选项。SigNoz Cloud 由厂商托管；Enterprise Self-Hosted 是客户运行并获得支持；BYOC 则由 SigNoz 团队在客户云里运行。把“数据在自己云中”直接等同“全部自己运维”，会混淆后两种方案。Enterprise 部署范围。

开放采集降低迁移成本，但没有替你搬走使用习惯

SigNoz 主仓库在企业目录等例外之外采用 MIT 许可，企业代码及第三方组件有各自条款。应按需要使用的版本和功能判断，不应把整个商业产品概括为完全免费。仓库许可。

OTel 可以减少应用和专有 SDK 的耦合，但看板、查询、告警阈值、权限、历史数据和自动化接口仍有迁移工作。原来一条错误率告警若统计的是全部请求，搬到按采样 Span 得到的查询后，需要重新确认分子分母，而不是只改服务名称。

对异步订单，最值得留下的是业务语义：从接单到完成允许多久，重试何时算失败，队列堆积与处理慢分别触发谁。把这些定义写清楚，再在新平台重建，才能避免页面看起来一致、告警意义却变了。

退出旧系统也不需要套用固定时间表。可以在关键告警、历史调查、访问权限与恢复流程验收后，再决定保留多久的旧查询入口。审计需要三个月历史，与团队习惯多看三个月旧界面，是不同理由。

两种账单，应按同一段业务估算

Dynatrace DPS 的主机 Full-Stack 使用 GiB-hours 计量，按十五分钟区间记录内存、向上取至 0.25 GiB 整数倍，并有 4 GiB 主机下限；日志等能力另计。它不是只看主机台数的统一套餐。计量规则。

SigNoz Cloud 当前按日志和链路数据量、指标样本等消费计量，并有最低月消费和保留期设置；自建则要计算基础设施、商业支持及维护投入。把 Cloud 单价与另一平台完整合同相除，无法得出可靠的省钱倍数。SigNoz 方案。

对同一条订单链路，先确定采样、日志保留和指标采集频率，再记录正常日与峰值日的用量。双写期的额外消费和停止 OneAgent 后是否仍需另行补采进程信息，也应算进去。选择应建立在实际保留的调查能力上，而不是少采了一部分数据后的表面差价。

先迁一个能验收的调查，再迁整个平台

已经围绕 OTel 建立采集，并愿意管理后端或选择相应托管方案的团队，可以认真评估 SigNoz。若日常故障高度依赖 OneAgent 的深度运行时证据，则先明确哪些证据要保留、哪些可以通过新的采集路径补齐。继续使用 Dynatrace 与推进 OTel，也并不矛盾。

一个合适的阶段目标，是让那次异步订单延迟在新系统中仍能被发现、解释并交给正确的人处理。完成这件事以后，再扩到更多服务，比一次复制全部流量更容易知道迁移究竟改变了什么。

在观测云中保留可验证的接入路径

观测云也支持相应 OTel 接入。若希望比较另一个后端，可以复用同一条业务样本，核对资源字段、链路上下文和日志关联；先让排障过程可复现，再决定采集与平台的长期分工。观测云 OTel 文档。