Datadog vs IBM Instana：自动发现、历史请求与运行成本

服务刚扩容，订单延迟就开始上升。值班同事先看到几个新容器，又发现其中一个服务还在等待旧的消息队列。此时最需要的不是更多红色图表，而是把这次请求、当时的依赖关系和刚发生的变更放到一起。

IBM Instana 值得从自动发现与应用上下文这条路径评估；Datadog 则适合已经围绕服务、日志、基础设施和发布版本协作的团队。选择不该简化成“大企业选 Instana，云原生选 Datadog”：两者都覆盖混合与云环境，实际差别落在支持的技术、调查方式和后端运行责任上。

作者：观测云编辑部。资料核对于 2026-10-21。本文依据官方文档，没有进行双方采集开销、告警准确率或排障速度实测。

新进程出现之后，平台看到了什么

Instana 的 host Agent 发现受支持的技术，再加载相应 sensor 和 tracer。部分 sensor 可以自动配置，另一些仍需要凭据或额外设置。主机、云服务、Serverless、网站和移动应用也有不同类型的采集组件，不能把“一个 host Agent”扩展成任何部署形态都无需其他工作。Instana 组件、技术与配置。

例如，发现 JVM 与追踪一条跨消息队列的订单调用不是同一件事。前者说明运行时进入了视野，后者还依赖相关语言、消息组件和上下文传播的支持。Instana 的 Dynamic Graph 为 trace 加入服务和基础设施上下文，但不能凭空补上未插桩的业务步骤。追踪机制。

Datadog 也需要把服务采集配置好，再通过服务页面、trace 和关联数据调查请求。对已有 Datadog 团队，延续统一的服务名、环境和版本，往往比再建设一套身份映射更省工作。OpenTelemetry 可以作为接入路径，但各路径的功能支持并不完全相同，应用能发出 OTLP 也不代表所有原生功能会自动出现。APM 入门、OTel 兼容范围。

一个有代表性的检查是：保留一次跨服务失败请求，沿它找到应用、容器、主机和队列，再看扩容前后的变化。缺少某条边时，先判断是实际没有调用，还是数据没有被采到。图谱上看不到依赖，不能直接作为系统不存在依赖的证据。

一秒指标与历史请求是两回事

Instana 官方说明，多数 sensor 默认以一秒粒度采集指标，随后会进行时间聚合。查询范围扩大后，返回的粒度也会变化；Analyze Infrastructure 和自定义看板最细显示粒度为十秒。因此，“一秒采集”不能写成所有指标在任意历史范围都能按一秒查询。基础设施指标。

这会影响对短暂抖动的解释。当天查看几十秒的异常，与一个月后看整个下午的趋势，承担的是不同任务。聚合后的均值没有出现明显尖峰，不能证明当时没有短时拥塞；需要对照当时保留的请求和最大值等合适统计量。

“全量追踪”也必须加上时间范围。当前 Instana trace 分析文档说明，完整 traces 和 calls 保留七天，超过七天的分析会出现近似数据；应用视角的准确指标保留三十一天，再往前指标也变为近似。若查询窗口跨过七天界线，整个窗口可能按近似数据分析。罕见请求未必出现在历史抽样中。这里描述的是分析文档中的默认窗口；自托管 Custom Edition 可在支持范围内调整短期完整数据保留，不能把七天当作所有部署的硬上限。后端保留配置。Traces 与 calls 分析。

Datadog 把摄取与保留显式分开。最近十五分钟的 Live 查询覆盖已摄取 span，自定义保留过滤器保留的 span 可供十五天查询；智能保留另有自己的选择与期限规则。入口处已经丢掉的数据不会由保留过滤器恢复。比较客户隔周反馈的问题时，应比较最终能查到的请求，而不是把一方宣传中的“全量”与另一方配置里的“采样”直接对立。Trace Explorer、Trace retention。

从应用现场继续查日志

Instana 已有 Logs in Context 和日志分析，不能沿用“日志只能接外部产品”的旧说法。日志分析提供过滤与分组；Fast query mode 使用采样加快大数据量查询，展示的计数是近似值。排查某个确切请求时，这个开关的意义与看整体趋势时不同。日志分析。

Datadog 同样需要正确解析日志中的 trace 与 span 标识，才能把错误消息接回请求。即使采用同一平台，日志留存短于 trace 留存，较早的请求详情里也可能没有对应日志。Datadog 日志关联。

两家的用户侧监控也应独立接入。后端接口正常不代表浏览器请求成功，更不代表页面渲染顺畅。移动端和网站的数据应按实际采集方式、许可与留存纳入方案，而不是从“全栈”一词推断所有用户现场都已经保存。类似地，异常提示和事件关联适合缩小调查范围，不能作为已经证明根因或可以无审批修复的保证。

SaaS 与自托管，谁负责升级和容量

Instana 当前有 IBM 运行的 SaaS，以及 Self-hosted Standard、Self-hosted Custom 两种主要自托管路径。Standard 使用 stanctl 简化部署；Custom 面向 Kubernetes 等更复杂环境，需要相应的集群与数据存储运维能力。旧的 Docker Classic 仍存在，但官方已不再主动发展，不能拿它作为新部署的默认建议。部署选项。

自托管给企业安排数据位置和运行环境的空间，也把容量、备份、故障恢复和升级工作留在企业一侧。自动发现应用与自动维护整个观测后端是两件事。Datadog 的 SaaS 模式减少了后端集群工作，但企业仍负责采集端、网络、访问和数据内容。已有明确内网部署要求时，先解决这层差异，再比较界面。

某些 IBM 基础设施也不是装 Agent 后自动全部启用。官方 SaaS 部署说明列出 vSphere、IBM Z HMC、Power HMC 等默认关闭、需要联系支持启用的监控项。已有 IBM 资产可以成为评估 Instana 的理由，却不构成无需确认版本和接入要求的通行证。部署步骤。

主机许可里还有数据用量

Instana 当前公开起价包括 SaaS 每 MVS 每月 21.20 美元，以及自托管每 MVS 每年 385.20 美元，并另列按使用量方案。MVS 是许可计量单位，Essentials 与 Standard 的能力不同，不能把最低基础设施价格当成完整 APM 报价。公开价格不含适用税费，地区与供应情况也有差异。Instana 价格。

SaaS 的公平使用政策另有数据量：Standard 每 MVS 每月 325 GB，Essentials 为 50 GB，可在对应许可额度之间汇总。十份 Standard 许可对应的基础额度是 3250 GB，而不是无上限；超过额度还涉及额外摄取。政策定义直接第三方日志不计入这个摄取口径，不应把日志直接混进同一预算桶。公平使用政策。

Logs in Context 尤其要按实际方案确认：当前价格页把它列为 SaaS 附加项，也标明自托管包含；部署介绍中的包含口径又有所不同。预算应采用具体订单的日志授权和保留条件，而非从其中一个宣传表格推导“所有日志免费”。

Datadog 则按选用的基础设施、APM、日志等产品建立预算，并分别观察摄取与索引用量。主机少而请求很密集的应用，和主机多而流量平稳的应用，不应按同一个“每主机价格”推导全部成本。Datadog 价格、APM 用量指标。

让部署和调查习惯决定选择

需要自托管后端，技术栈在 Instana 支持范围内，又希望持续发现进程和依赖的团队，可以优先评估 Instana。把最近一周的故障与更久的历史调查一起演练，能避免直到上线后才发现粒度或保留方式不合适。

已经围绕 Datadog 建立服务标签、日志管道、发布观察和告警流程，或者更希望采用 SaaS 后端的团队，继续扩展 Datadog 通常更顺手。迁移的理由应是现有流程持续解决不了的问题，而不是集成数量或“全自动”的口号。

在观测云里保留相同的调查线索

观测云的链路详情可以展示已采集请求以及关联日志、资源信息，适合拿同一条跨服务请求比较调查路径。关联标识和保留策略仍由团队设计；较早的请求、日志与资源现场能否同时存在，比单独多保存一种信号更影响复盘质量。链路详情。