Dynatrace vs Dash0：从 OneAgent 迁向 OTel，要留下哪些能力

团队准备把一批 Java 服务从 OneAgent 插桩逐步转向 OpenTelemetry。第一个服务已经能向新后端发送 Trace，但原来的慢请求页还能看到进程、方法和主机信息，新页面只有几段 HTTP 调用。数据没有完全丢失，调查能力却已经变了。

Dynatrace 与 Dash0 的差别，适合从这类迁移开始理解。前者可以利用受支持环境里的 OneAgent 深度监控，也支持 OTel；后者围绕 OTel 遥测组织数据、查询和看板。选择开放插桩是应用侧决定，是否替换已经使用深入的分析与响应流程，则是另一项决定。

观测云编辑部 · 资料核对于 2026-10-21。本文讨论 Dynatrace SaaS/DPS 与 Dash0 的相关工作方式，没有进行双边部署、性能排名或成本实测。示例用于解释覆盖与用量。

先认清原来的信息是怎么来的

OneAgent 的能力随操作系统、运行时、版本和监控模式变化。Full-Stack 在受支持技术上提供分布式追踪、代码级可见性、CPU/内存剖析及进程监控；基础主机发现与深度应用监控也不是相同范围。支持矩阵、Full-Stack。

迁移以后只剩 HTTP Span，可能是新的插桩还没覆盖数据库驱动、线程等待或业务方法，也可能缺少资源采集。不能由 Trace 已经到达推导成原有能力全部搬过来了；同样，也不能因为采用 OneAgent 就假定全部技术都自动支持。

Dash0 的自动插桩与 Collector 可以减少手工接入，但仍要选择受支持的语言和路径。以 Python distribution 为例，本地 Collector 和直接发送的设置不同，直接发送需要地区入口、认证 header 与数据集配置。Dash0 接入示例。没有埋出的业务操作、没有传递的上下文，分析后端无法自动还原。

两套插桩共存，不只是发两份数据

迁移期间保留 OneAgent，再加 OTel SDK，是常见过渡方式，但要避免同一段调用被两种路径重复记录。

Dynatrace 的 OneAgent Span Sensor 可以捕获相应 OTel API 调用并加入自身链路。这类 Span 按 OneAgent 数据处理；如果同时把它们通过 OTLP 发送到同一后端，官方明确提示会产生重复。不同语言和版本还有去重与互操作限制。OneAgent 与 OTel、Sensor 配置。

因此，请求数量翻倍时，先分清采集路径，不要直接解释为业务流量增长。把一份已有 OTel 数据从 Collector 路由到两个后端，与两套自动插桩各自生成 Span，造成的问题不同。前者仍有出口、队列、重试和消费，后者还可能改变链路结构。

Dash0 的 datasets 也影响结果。需要关联的日志与 Trace 应在同一个 dataset，写入令牌要有权限；只在一个后台页面看见数据，不代表它已经与其他信号处于相同上下文。数据集。

把旧的错误率告警留下来

原来的 Dynatrace 查询、服务实体、问题处理和通知规则不会随着 OTLP 自动导出。迁移一条“订单失败率升高”的告警，需要保留它到底在数什么：全部请求、被保留的 Span，还是某一种异常记录。

Dash0 的 Query Builder 可以使用 PromQL，并能从查询创建 check rule 或看板；日志和 Span 也能作为按需生成的 synthetic metrics 参与分析。但查询语义仍然要正确，平台支持 PromQL 不代表所有原查询可以只换一个名称。Query Builder、Synthetic metrics。

一个具体细节是错误比例。Dash0 官方 tracing query 示例中的结果使用 0 到 1，界面再显示成百分数，规则阈值也应按 0 到 1 设置。想表达 5%，却把阈值填成 5，可能让本应触发的规则一直安静。这是单位与展示的区别，不是模型自动推理能够替代的配置。Tracing 查询示例。

Dash0 看板采用 Perses 格式，导出后更容易保存和在兼容系统间使用。数据源、查询、权限与通知仍各有配置，不能据此许诺没有供应商迁移成本。看板与 Perses。

主机扩容与请求增多，账单受影响的方式不同

Dynatrace DPS 的 host-based Full-Stack 根据监控主机的 RAM 与时长计算 memory GiB-hours，采用 15 分钟区间；物理机和 VM 最低按 4 GiB，RAM 向上取至 0.25 GiB 的整数倍。应用专用容器监控又有不同计算范围，不能一概称作固定主机价。DPS 用量。

因此，主机内存翻倍会改变这部分消费，即使请求量没有翻倍。Trace 摄入、日志及其他能力还有各自额度和计量，最终金额取决于 rate card 与实际使用，不能用“超过五百台就该选某产品”作为普遍门槛。

Dash0 的 telemetry 按信号数拆分摄入与存储。假设 10,000 条活跃指标序列每 30 秒导出一次，持续 30 天，产生 8.64 亿个数据点。按当前基础费率每百万 0.020 美元摄入、0.180 美元存储，全部保留时的指标小计为：

864 × (0.020 + 0.180) = 172.80 美元

这个例子使用当前 13 个月指标保留口径，没有包括其他信号、阶梯或合同差异。新增标签组合和导出频率会改变样本数；没有主机单价，不代表主机扩容不会通过更多指标间接增加消费。Dash0 价格。

降低噪声以前，先看哪份证据会消失

当前 Dash0 在 SignalControl 过滤后只对保留到 SignalStore 的部分计存储费，摄入仍对进入服务的信号计量。日志和 Span 的公开基础口径分别为每百万 0.060 美元摄入与 0.540 美元存储、保留 30 天。把过滤理解成“已经发来的数据全部不收费”，会低估费用。

如果日志与 Span 驱动某个 synthetic metric，丢弃原始记录也可能改变后续调查与聚合。采样减少的是需要保存的数据，也减少了能逐条回查的请求。故障时留下什么，不能只由正常月份的成本曲线决定。

AI 也有独立使用边界。Dash0 当前 Agent0 按 credits，代码分析产品按用户席位计费；不能用早期按信号收费的说明覆盖全部新产品。Dynatrace 的自动分析同样需要足够的数据和上下文。本文没有用一段演示结果判断两家根因分析谁更准。

另一个容易混淆的变化是时间范围。旧系统保留的链路、新系统刚开始收到的链路，以及告警统计使用的数据窗口可能并不相同。刚接入的服务在一小时图上少一段，不一定是采集丢失；双写期间同一请求被两套插桩重复产生，也不意味着真实失败次数更多。对照时需要先固定起止时间和请求范围，再解释图上的差异。

方法级信息也要按它原来解决的问题判断。如果团队主要靠数据库与外部调用的 Span 定位，补齐这些路径可能已经够用；如果经常依赖代码剖析找到 CPU 热点，只留下请求时间线就失去了重要证据。没有必要为每个可选功能追求完全一致，但经常使用的那部分不能只因新页面已经有数据就被省略。

新系统开始值班，旧系统才能慢慢退出

已经有完整 OTel 数据规范，日常围绕日志、Trace 与 PromQL 调查，Dash0 更容易贴合这套工作方式。它的价值在于接入、数据模型与人员经验一致，不是所有历史资产都能直接搬过去。

OneAgent 的代码、进程与资源信息已经深入值班流程，或者环境里存在大量受支持但尚未补齐 OTel 覆盖的技术，保留 Dynatrace 更合理。也可以先迁移边界清楚的服务，让其他部分继续运行，没必要为开放标准一次性撤掉有用证据。

判断迁移是否完成，应看接班工程师能否找到失败请求、理解相关资源并收到正确通知。历史回查、权限和升级流程仍能工作之后，再停止旧路径，才不会把费用降低变成调查断档。

通过 OTel 接入观测云

观测云的OpenTelemetry 接入可作为另一条后端路径。保留受支持的插桩，按服务接入相关遥测，再沿原有故障检查链路和日志是否相互对应。

这仍然需要字段、采样与权限安排，也有服务和过渡期消费。平台选择最终应落在持续调查与运行工作上，而不是仅凭一个开放协议标志完成。