Dynatrace vs OpenObserve：历史日志迁走以后，排障还剩下什么

客服拿来一个两周前的订单号，想知道付款成功后为什么一直没有发货。值班同事打开现有 APM，最近的服务健康状况很好，但当时的请求已经不在链路保留期内。调查于是回到应用日志：订单经过了哪个队列，消费者有没有重试，最后一次状态变更发生在哪里。

这时讨论 Dynatrace 和 OpenObserve，问题不只是哪个界面功能更多。团队可能需要继续保留 Dynatrace 的应用与运行环境分析，同时为大量历史日志找另一种存储和查询方式；也可能准备接管整个观测后端。两种决定的工作量不同，不宜用一个“替代”概括。

观测云编辑部 · 资料核对日期：2026 年 10 月 21 日。本文依据官方文档讨论相关产品能力，没有进行双边性能或成本实测。

先找回订单，再追到服务

OpenObserve 以日志、指标和链路为数据入口，日志查询可以使用 SQL。对上面的订单，先缩小时间范围与服务，再按业务标识查找事件，往往比从当前服务拓扑出发更直接。不过，能写 SQL 不代表业务字段已经整齐：订单号在不同服务里叫不同名字，或者错误消息只有一段文本，仍需在采集与解析时处理。

OpenObserve 的数据文件使用 Parquet，也支持 Tantivy 索引。后者包含全文词项检索与精确值索引，实际使用取决于字段和查询方式；不能把“列式存储”理解成完全没有索引，也不能把索引开启理解成所有 SQL 都同样快。时间跨度、扫描范围、缓存和查询并发仍会影响调查体验。查询与索引说明。

Dynatrace 的另一条路径，是在受支持环境里由 OneAgent 把请求、进程和主机证据联系起来。Full-Stack 提供的代码级可见性与剖析取决于运行时、平台和监控方式。它有助于继续追问“为什么这个消费者慢了”，但没有保留下来的历史日志，也不会因为存在拓扑就重新出现。Full-Stack 范围、支持矩阵。

因此，试用的第一步可以很小：选一次真实发生过、已有调查结论的订单故障，分别找回同一批证据。比较字段是否可查、日志能否连接到请求、原来的进程信息是否还在，而不是只比较首页截图。

服务图已有，证据来源仍有差别

把 OpenObserve 描述成只有日志搜索、完全没有服务拓扑，已经不准确。当前 Enterprise 提供 Service Graph，由 Trace 构建服务之间的关系；还可依据客户端或生产者 Span 的对端属性，推断没有直接插桩的依赖。Service Graph。

这里的“推断”很重要。图中出现一个数据库节点，可以说明已有请求指向它，不等于已经获得数据库内部的等待、锁或执行计划。没有传播的上下文，也不能仅凭服务图恢复。选择 OpenObserve 时，要把应用插桩、资源字段以及所选版本包含的分析能力一起考虑。

Dynatrace 同样可以接收 OpenTelemetry，并不要求所有服务只走 OneAgent。官方支持直接 OTLP 接口及 Collector 路径，也支持逐服务混合接入。OTel 解决数据传输与语义约定的一部分问题，原有实体关系、告警和调查操作仍需逐项验证。OpenTelemetry 接入。

对已经依赖 OneAgent 排查运行时问题的团队，更稳妥的分工可能是先迁历史日志，暂时保留关键服务的深度监控。这样能看清日志存储变化带来的收益，也能暴露两边需要共同维护的服务名、环境名和 Trace ID。

对象存储后面，还有一套运行系统

OpenObserve 的单节点部署可以使用本地磁盘或对象存储，元数据使用 SQLite；高可用架构则涉及多个角色、对象存储、PostgreSQL 元数据和 NATS 协调，不能把单机启动方式直接当作生产 HA 方案。写入端还使用本地 WAL，在数据进入对象存储之前存在需要保护的阶段。架构、Enterprise 部署。

对象存储可以改变长期保存数据的方式，却不会替团队完成升级、备份恢复、容量规划和租户权限管理。一次恢复演练至少要回答两个问题：已经落入对象存储的数据能否重新查询；还在写入缓冲中的数据，在节点失效后如何处理。只检查桶里文件还在，会漏掉后一段。

查询端也需要预算。平时几个人查一天的日志，与事故期间十几个工程师同时扫一个月，使用的是同一份历史数据，却不是同样的计算负载。压缩后磁盘占用很小，只能说明某项存储结果，不能直接推导查询速度或总成本。

OpenObserve 主仓库采用 AGPLv3；Enterprise 能力有独立商业范围，托管 Cloud 也有自己的计费和保留设置。代码可获取、自建基础设施、商业功能与厂商运维，是几个不同问题。项目许可、产品方案。

用同一段历史，算清留下与迁出的成本

Dynatrace DPS 的主机 Full-Stack 以 GiB-hours 计量，按十五分钟区间记录内存，向上取到 0.25 GiB 的整数倍，并有每主机 4 GiB 下限。日志等其他能力另有用量，不能只拿主机数量估算全部账单。这里讨论的是该 DPS 能力，不是所有历史合同。计量规则。

OpenObserve 自建成本则包括写入与查询计算、对象存储、元数据及协调服务、网络、备份和维护时间；选择 Cloud 或 Enterprise，要再按实际方案核对消费。两者没有一个无需业务输入就成立的固定倍数关系。

把订单调查作为计费样本，会比比较空泛的“每 GB 单价”更有用：同一批日志留多久，哪些字段必须保留，调查通常查几天，多少人会同时查询。若只把历史日志移走，Dynatrace 的应用监控仍会继续消费，迁移期还可能保留双份数据。收益应从实际减少的那部分用量计算。

历史数据的退出方式也应提前安排。保留对象文件不等于未来任意工具都能立刻解释原来的流、字段和权限；停用旧系统之前，至少要保存数据布局与导出说明，以及仍会用于审计的查询口径。

选择取决于哪一段调查值得继续投入

如果日常排障紧密依赖 OneAgent 的运行时证据，优先保住这条路径，再单独评估历史日志。若团队的主要困难是大量事件的长期查询，并且愿意承担后端运行，OpenObserve 值得用代表性数据验证；选择托管服务，则应把运维责任与商业能力写进范围。

最终应确认的是，旧订单仍能找到，正在变慢的请求仍有足够上下文，而交接后的团队知道数据在哪、谁负责恢复。这样的结果比笼统宣布某个平台功能更多或成本更低更有用。

在观测云里验证同一条请求

观测云也可以接入受支持的 OpenTelemetry 数据。若准备增加一个后端候选，可以从同一条业务请求开始，核对服务标识、链路上下文与日志字段，再判断它能否接续现有排障；标准接入不会代替应用侧的字段设计和采样决策。观测云接入说明。