Dynatrace vs IBM Instana：故障过去一周，链路还剩多少

客户在周一反馈上上周的一次支付失败。监控上仍能看到那天错误率升高，但工程师要找的是一个具体请求：经过哪些服务、数据库返回了什么、当时哪个实例正在扩容。趋势还在，不等于请求现场还在。

比较 Dynatrace 与 IBM Instana，这比“哪家自动化更强”更容易得到有用答案。两家都能发现受支持的应用与基础设施，也都提供请求调查；差别会出现在采集方式、历史数据的粒度、部署责任以及为保留这些证据付出的成本。

观测云编辑部 · 资料核对于 2026-10-21。本文比较 Dynatrace SaaS/DPS 与 Instana 对应部署，涉及客户环境部署时另行说明。没有进行根因准确率、性能或费用实测。

自动发现以后，还要沿请求走一遍

OneAgent 的深度应用监控和 Instana 的技术传感器都依赖支持范围。语言、框架、运行时版本、权限和远程服务的连接方式会改变可见内容。安装一个组件，不能保证数据库、队列和业务方法自动获得相同深度。OneAgent 支持矩阵、Instana 支持技术。

可以从一笔有异步队列的订单开始：前端请求结束以后，后台任务是否仍能接到原来的 Trace？若跨队列上下文丢失，平台可能各自看到了两个健康服务，却无法解释它们属于同一业务动作。此时需要调整传播与插桩，增加一个拓扑面板并不能补回请求关系。

已有 IBM 系统值得检查相应传感器，但“同一个厂商”不是配置自动完成的证据。部分能力需要额外启用；其他技术也应按具体版本判断，而不是凭品牌把某家从候选中排除。

一秒采集不是所有历史都能看一秒

Instana 多数传感器默认以一秒粒度采集指标，后台会聚合。查询时间范围越长，取回的数据粒度也会变化；Analyze Infrastructure 与自定义看板的最小显示粒度为十秒。一个月后的小时均值不能用来证明当时没有几秒钟的资源抖动。基础设施指标。

请求历史还需要单独看。当前分析文档按默认设置说明：完整 traces 和 calls 保留七天，之后分析可能基于近似数据；应用视角的准确指标保留三十一天。如果查询起点越过七天，整个窗口可能使用近似数据，即使其中一部分仍有完整记录。Trace 与 call 分析。

七天不是全部部署的硬上限。自托管 Custom Edition 的短期完整数据保留可在文档支持的二至三十一天内配置，改变保留设置也有新旧数据过渡行为。延长配置不会重新创造早已删除的请求，容量和升级工作同样需要安排。自托管保留配置。

因此，完整采集与长期逐条可查应分别写进需求。用于总体趋势的近似数据可以有价值，但它不能承诺某个罕见失败一定能在两周后找回。

Dynatrace 的采样规则从哪里生效

Dynatrace Adaptive Traffic Management 会根据可用追踪量调整 OneAgent 的采集比例。它可以优先保留某些请求类型，但“尽量保留罕见请求”不是每次失败都必然留下的保证。扩展摄取、固定比例或特定请求规则也会改变消费。DPS 追踪采集。

一个容易影响配置的细节是入口。OneAgent 这条路径的采样决定在链路起点作出，并随上下文传播。如果外部请求先进入 ingress，再调用 checkout，只在 checkout 所属范围修改规则，未必能改变这些请求的采集率；它可能只影响在那里新发起的后台任务。需要完整保留的业务流，应从实际入口安排规则。

这也说明“采样对全量”不是足够完整的比较。Instana 的历史窗口可能转为近似，Dynatrace 的采集率和保留也各有配置。最终要核对的是一次请求在发生时有没有被采到、跨服务是否完整、投诉到来时是否仍可查询。

日志和自动分析要有可追查的依据

Instana 并非只能跳到外部日志工具。它有 Logs in Context，日志分析的 Fast 查询模式也会显示近似数量，不能把快速结果当成所有记录的精确计数。日志分析。

Dynatrace 可以把日志放入 Grail 与应用上下文一起调查，但具体保留和查询消费仍取决于所用模式。排障时要确认日志与 Trace 的时间、标识和权限一致；只延长其中一种信号的保留期，未必能延长完整现场。

两家的异常分析和事件关联都可以帮助缩小范围，结论仍应回到证据。一次数据库变慢与应用错误同时出现，可能存在依赖，也可能有共同的上游原因。本文不把产品对“因果”的描述换成确定性答案，更不会据此建议未经验证就自动执行修复。

自托管改变的是持续责任

Instana 有 SaaS、由 stanctl 简化安装的 Self-Hosted Standard Edition，以及在 Kubernetes 上自行管理更多组件的 Custom Edition。旧 Classic/Docker 路径不应作为新部署的默认起点。选择自托管后，存储、备份、扩容、证书和升级仍需要明确负责人。部署选项。

Dynatrace Managed 也需要与最新 SaaS 平台分开评估。比如当前 Clouds 应用明确依赖 SaaS、Grail 和 AppEngine；存在 Managed 版本，并不表示任意 SaaS 页面上的能力都能照搬到客户环境。Clouds 前提条件。

如果后端必须由自己的团队运行，这个要求应在功能演示前确定。反过来，只是希望保留更多请求，未必需要迁成自托管；先计算所需容量、许可和持续维护，再判断控制权是否值得这份工作。

主机数相同，许可消费仍可能不同

Dynatrace host-based Full-Stack 以 memory GiB-hours 计量：物理机和 VM 最低按 4 GiB，内存向上取至 0.25 GiB 的整数倍，监控按十五分钟区间计算。它不是统一的每台主机固定价，应用专用容器又有自身规则。Full-Stack 用量。

Instana 当前 SaaS 公示起价为每 MVS 每月 21.20 美元，自托管为每 MVS 每年 385.20 美元；Essentials 与 Standard 的能力范围不同，最低起价不能直接当作全栈方案报价。Standard SaaS 的公平使用摄入为每 MVS 每月 325 GB，Essentials 为 50 GB，并可在相应授权间平均使用。十个 Standard MVS 对应 3250 GB，不意味着超过后自动停止接收，而是可能产生额外消费。Instana 价格与用量。

同一价格页将 Logs in Context 列为 SaaS 附加项，并标注自托管包含；其他产品介绍的包含措辞存在差异，采购应采用具体订单的授权、保留和用量条件。不要从“all-in-one”推导全部日志永久免费，也不要假设已有 IBM 合同必然带来某个折扣。

哪个方案更适合下一次复盘

需要自托管、技术栈在 Instana 支持范围内，又希望用持续发现和近期完整请求调查服务的团队，可以优先评估 Instana。把超过默认短期窗口的投诉一起纳入演练，能提前暴露保留配置和容量问题。

OneAgent 的代码、进程和资源信息已经深入值班，Grail 查询和现有服务模型也能满足工作，继续完善 Dynatrace 更有吸引力。采样规则应围绕入口与重要业务安排，而不是笼统要求“AI 不丢重要数据”。

两者的取舍最终落在故障当天和数周后的同一条请求上。能否接续证据、解释数据缺口、维护后端并承担实际用量，比一张总体评分更能说明长期适合度。

在观测云中保留复盘线索

观测云链路详情可以将已采集请求与关联日志、资源信息放在同一调查路径中。配置一致的服务和请求标识，并让相关数据保留到需要复盘的时间，才能持续利用这条路径。链路详情。

它不能恢复未采集或已经过期的数据。比较后端时，应把同一组近期和历史故障交给实际值班人员，观察哪些证据真正帮助解释问题。