Dynatrace vs Elastic Observability：请求调查、日志查询和部署成本

结账接口变慢，日志里同时出现几种超时。已有 Elastic 的团队可能先打开 Discover，按服务和请求标识筛选；已部署 Dynatrace 的团队则可能先从异常服务进入 trace，再找关联日志。两种路径都能推进调查，差别在于哪一种已经接近团队每天的工作。

比较 Dynatrace 与 Elastic Observability，不能只用“自动化平台对自建搜索引擎”概括。Elastic 有自建、Cloud Hosted 和 Serverless，运行责任并不相同；Dynatrace 的 SaaS 新体验与 Managed 也不能视为同一份功能清单。先确定部署形态，日志与应用能力的比较才有意义。

作者：观测云编辑部。资料核对于 2026-10-21。文中查询用于解释语义，未在双方平台实测，也没有性能或成本排名。

从服务现场进入日志

Dynatrace 的 Full-Stack Monitoring 为受支持环境提供分布式追踪、代码与进程层信息。OneAgent 能减少部分发现与插桩配置，但支持的操作系统、运行时和版本仍有明确范围，Serverless 与主机采集也有各自要求。不能把一个 Agent 的安装成功理解成所有业务路径都已覆盖。技术支持范围、Full-Stack Monitoring。

一次实际调查会从“哪个服务变慢”继续问“请求在哪一段等待”。如果是数据库调用变慢，再看对应时段的日志、资源和部署变化。平台提供的上下文能帮助缩小范围，仍应保留原始证据；几条异常同时出现，不足以保证其中某条就是唯一根因。

Elastic Observability 同样不只是日志搜索框。Serverless Complete 包含 APM 和基础设施指标，Hosted 也有应用监控与追踪路径。应用仍需发送相应数据，现有 Elasticsearch 日志索引不会自动变成分布式 trace。已有服务字段、日志解析规则与 Kibana 工作习惯的团队，可以把应用观测接在这些资产上。Logs Essentials 与 Complete、部署能力对照。

相似查询不一定回答同一个问题

假设两边已把服务字段统一为 service.name，Dynatrace 日志正文使用 content。下面的 DQL 示意按服务查找包含 timeout 子串的日志；还应在界面选定所需时间窗口。

fetch logs
| filter service.name == "checkout"
| filter contains(content, "timeout")

contains 默认区分大小写，查的是子串。timeout 与 timed out 不是同一段字符，不能因为两者都表示超时就假定查询都会命中。DQL 字符串函数。

Elastic 中，若日志正文是经过分析的 message 文本字段，可以在 Discover 使用 KQL：

service.name: "checkout" AND message: "timeout"

这里的匹配受字段映射和分析器影响，不是前面子串函数的逐字等价翻译。KQL 用来筛选文档；需要在查询里计算分组统计，可以使用 ES|QL 等合适方式。把原告警换一种语法后仍然返回结果，不代表覆盖了同一批错误。KQL、ES|QL 统计。

迁移时值得保留一小批真实格式样本：不同大小写、缺字段、不同错误措辞与多行堆栈。先确认哪些记录应被命中，再谈查询速度。字段类型也会影响后续聚合；把耗时字符串当成数值使用，需要明确转换失败的处理，而不是把坏数据静默排除后宣布错误变少。

Dynatrace 的 OpenPipeline 可在日志进入 Grail 前做提取、规范化和路由等处理。因此，Grail 的灵活查询不等于无需数据治理。Elastic 同样需要合理的字段和管道设计；已有解析与权限规则的价值，通常比“哪家搜索更强”的形容词更容易算清。Dynatrace 日志处理。

托管服务也有不同的责任划分

自建 Elastic 时，集群容量、升级、备份与恢复由自己承担。Cloud Hosted 让供应商运行托管服务，用户仍需选择容量配置并安排升级等事项；Serverless 则由 Elastic 管理底层节点、分片和扩缩容，项目不需要选择 Stack 版本。不能把所有 Elastic 用户都写成必须自己运维 Elasticsearch 集群。Serverless 架构。

少做基础设施工作会伴随不同的控制方式。Serverless 使用数据流生命周期，而不是 Hosted 的 ILM 配置方式；也不能把原集群的节点设置和分片策略原封不动搬过去。应用侧当前也有差异：官方表列出 Elastic APM 尾部采样在 Serverless 不可用，而 EDOT 尾部采样可用。这是两条采样实现的区别，不应缩成“Serverless 完全不能尾部采样”。Hosted 与 Serverless。

Dynatrace Managed 则有单独的产品文档与部署范围。本文涉及的 Grail 新体验应按 SaaS 功能检查，例如 Clouds 应用明确要求由 Grail 与 AppEngine 支持的 SaaS 环境。不能看到 Managed 可以部署在客户环境，就默认它也提供全部新 SaaS 应用。Managed 文档、Clouds 前提。

有数据位置要求时，应把实际区域、采集出口、备份和支持访问一起确定。自建可以提供控制，却不自动完成权限或合规；SaaS 可以减少集群工作，也不会替企业决定哪些字段允许上传。

留存和查询频率会改变费用

Dynatrace 当前美元价目表列出 Full-Stack Monitoring 每 memory-GiB-hour 0.01 美元。主机模式依据被监控主机配置的内存计算，不是 OneAgent 实际占用多少内存；主机最低按 4 GiB，内存向上取至 0.25 GiB 的整数倍，计量按十五分钟区间。相同主机数配不同内存，费用就可能不同。价目表、内存计量。

日志的标准用量模型又分为摄取处理、保留和查询扫描量。另有 Retain with Included Queries，以 GiB-day 计量适用期限内的保留及包含查询，不能写成所有日志查询都必然单独计费。它也不是无限扫描：每二十四小时的扫描额度为包含窗口内留存日志量的十五倍，超出后官方会协助评估和优化查询消费。应选择与实际查询频率匹配的模式，超过包含期限的存储另按相应规则计算。包含查询的保留。

Elastic Cloud Hosted 主要按配置资源估价；Observability Serverless 则按摄取和保留等消费维度计算。其计费数据量取摄取管道结束后、丰富与规范化完成但尚未压缩的数据，不是磁盘上的压缩索引大小。time series index mode 下的指标有不同费率，也不能把普通日志的单价直接套给全部指标。Serverless 计费。

一个不依赖产品的例子是，每天 100 GiB 日志全部留三十天，对应约 3000 GiB 稳态原始留存；若 80% 留三天、20% 留三十天，则为 840 GiB。这个算式没有包含索引、副本、压缩和厂商计费转换，不能直接当账单。它说明在挑后端之前，先区分数据价值，已经会明显改变所需容量。

还要区分交互排障和宽范围分析。一天里几十次按服务找错误，与每天跨数月日志反复聚合，对查询计算的压力不同。自建 Elastic 的资源费用并不等于只有磁盘；Dynatrace 的扫描量也不应只按单次演示推测。这里没有同负载测试，无法推导任何一方天然更便宜。

已有工作方式能不能继续使用

团队围绕应用性能调查，愿意采用受支持技术的自动发现，并且所选 SaaS 能力与环境匹配，可以优先评估 Dynatrace。让服务、请求和资源上下文成为日常入口，比另建一套人工关联流程更有吸引力。

已有成熟 Elastic 字段、查询、日志管道和运维经验，或者日志分析是主要工作，继续扩展 Elastic Observability 往往更自然。没有集群团队时可以评估 Hosted 或 Serverless，但要按具体功能选择，不能以部署名称推断完全等价。

双方并存也可以有清楚分工：应用现场保留在一个平台，长周期日志分析留在另一个平台。此时应维护一致的服务与请求标识，同时计算双写、双留存和查询权限，避免把两套费用包装成免费互补。

在观测云里比较同一条调查路径

观测云的链路详情提供请求、相关日志与资源信息的调查入口，可以拿同一条慢请求比较查证步骤。所需信号仍要实际采集并在相同时间范围内保留；选服务时，值得把这些配置工作与后端运维责任一起算进去。链路详情。