Dynatrace vs Uptrace：迁走链路以后，哪些证据需要重新采集

凌晨的批处理晚了半小时。链路里最慢的是一个数据库调用，但值班人员还想知道：是 SQL 变了、连接池排队，还是同一台机器上的其他进程抢走了资源？这时，能看到一条 trace 只是调查的起点。

Dynatrace 与 Uptrace 都能接收 OpenTelemetry 数据。真正影响选择的是，在现有埋点之外还需要哪些运行时证据，以及谁负责让这些证据持续可用。已经把服务、日志和业务属性整理好的团队，可以认真评估 Uptrace；长期依赖 OneAgent 深度监控的团队，则应先弄清移走采集器后会失去什么。以下按 2026 年 10 月 21 日的公开文档讨论，Dynatrace 的 Grail 和 DPS 部分以 SaaS 为范围，不把它们自动套到 Managed 环境。

先从慢调用走到它的上下文

Uptrace 并非只有链路瀑布图。当前产品提供日志、指标、仪表板和告警，指标查询有 PromQL 兼容路径。一个慢批处理可以先按服务和操作分组，观察耗时分布，再打开异常请求，看同一任务的日志和资源指标。这里的前提是这些信号确实采集进来了；应用只发送 span，并不会顺便补齐主机和数据库监控。Uptrace 功能说明

例如，在已经选定的时间范围内，下面的查询按服务统计错误 span 的 P95 耗时。它用于说明查询结构，并非在某个生产项目上的实测结果：

group by service_name | p95(_dur_ms) | where _status_code = 'error'

service.name 在查询中规范化为 service_name，_dur_ms 的单位是毫秒。结果描述的是被选中错误 span 的耗时分布，不能直接当成所有用户请求的 P95；一个请求也可能包含多个 span。要研究批处理入口，就需要进一步收窄操作和 span 类型。查询参考

Uptrace 也有基于 span 关系构建的 Service Graph。服务名称、跨服务的 client/server 或 producer/consumer 关系缺失时，图上的边就可能缺失。因此，一条队列消费链断开，首先应检查消息上下文和两端埋点，而不是仅凭图的形状判断下游没有流量。Service Graph 文档

Dynatrace 的价值通常出现在下一步：请求背后的进程、运行时和基础设施证据。OneAgent 能采到的细节受操作系统、语言、框架版本和监控模式影响，应对应实际技术栈看支持矩阵。对于已经靠这些数据定位过 GC、线程或进程异常的团队，迁移时要保留的是调查能力，不只是 trace 的条数。OneAgent 支持范围

相同的 OTLP 出口，不代表相同的证据

Dynatrace 支持 OpenTelemetry 接入，所以它和 Uptrace 并不是专有采集与开放协议的二选一。可以先让一个业务服务走标准出口，再比较服务名称、环境、父子关系和日志中的 trace ID 是否一致。但 OneAgent 已经采集 OTel span 时，额外启用 OTel exporter 可能造成重复数据，需要按官方共存方式配置。Dynatrace OTel 接入、OneAgent 与 OTel 共存

采样会进一步改变看到的系统。头部采样在请求结果尚未完整出现时决策，不能保证留住所有后来发生错误的请求；尾部采样可以利用后续 span 的状态或耗时，但需要有状态的处理能力。后端换了，采样比例相同，也未必保留同一批慢任务。迁移对照应同时记录入口请求量、导出的 span 数和被保留的错误样本，不能只看两边曲线是否接近。OpenTelemetry 采样说明

对这次批处理，更有意义的验收是一条具体路径：从入口找到数据库等待，再找到该任务的重试日志，最后解释等待期间的资源变化。某一步原先来自 OneAgent、现在没有替代数据源，就应把它写成缺口，而非用“支持 OTel”跳过去。

自建 Uptrace，要接手的不止一个进程

Uptrace 自托管包含应用二进制和多个后端组件：ClickHouse 存储遥测，PostgreSQL 保存用户、项目和仪表板，Redis 用于缓存与后台任务协调。官方提供 Docker Compose、Helm、Ansible 等部署方式；这些可以简化安装，备份、容量规划和升级恢复仍然需要有人负责。自托管架构

这会改变故障时的工作分配。批处理异常时，如果遥测写入也开始积压，团队需要区分应用变慢与观测后端变慢。日志增长造成的磁盘压力、数据库升级失败后的恢复，都应计入平台运维工作。已有 ClickHouse 运维能力当然有帮助，但不能据此把新增系统的成本写成零。

许可也应按版本看。当前 Uptrace 自托管版本页把社区核心能力与付费的协作、安全和运行能力区分开；例如 Community 列出 14 天保留，付费层提供自定义保留，Team 提供 RBAC，Business 提供 SSO。页面所列用量档位按 30 天平均计算。需要公司统一登录、长期保留或特定高可用能力时，应匹配所选版本，不能把 Cloud 或商业版功能全部算进免费自建。Uptrace 版本说明

报价先对应同一批数据

Dynatrace DPS 的 Full-Stack Monitoring 使用 GiB-hours，并非简单的每台主机一个固定小时价。计量基于受监控主机内存，最低按 4 GiB，之后按 0.25 GiB 向上取整，并有 15 分钟计费间隔；日志等其他能力另有用量项。批处理机器只运行几小时，与整月常驻机器的账单结构自然不同。Full-Stack 计量

Uptrace Cloud 当前按日志和链路数据量、指标摄入数据点计量；采集频率会影响指标量，服务端丢弃也有处理收费。公开价格页的起始单价和预算上限描述存在前后不一致，应以确认的方案条款为准，不据此承诺硬性封顶或固定节省倍数。Uptrace Cloud 价格

因此，可用同一批工作负载做两份估算：受监控主机的内存和在线时间，以及各信号实际输出量、保留时间和查询需求。自建方案再加数据库资源、备份与值班工作；Cloud 方案加入跨云传输等实际支出。只有两边都保留了需要的错误证据，价格差异才值得比较。

哪些团队更适合哪条路

已有成熟 OTel 埋点、希望自己掌握遥测存储，并且能够维护后端组件的团队，Uptrace 是值得验证的选择。若不愿接手数据库，也可以评估它的 Cloud 路径，单独确认保留和预算条款。

如果慢请求调查经常依赖自动采集的运行时细节，以及服务到基础设施的现有上下文，Dynatrace 更适合先保留并优化。选择不取决于公司人数：关键是迁移后那位值班工程师能否解释同一次故障，以及这条调查路径的长期维护成本。

用一次请求检查关联是否成立

若同时评估观测云，可以用同一个批处理请求检查链路详情中的耗时、错误和关联日志。关联依赖采集与标识配置，不能靠换一个查询页面补回缺失 span。这种具体检查比先比较仪表板数量更容易发现接入差异。观测云链路详情