Dynatrace vs Coralogix：应用调查与长期日志怎样分工

老系统的 Java 服务已经用 OneAgent 监控，服务依赖和慢请求也能看见。新的需求来自另一边：业务希望保存半年审计日志，安全团队偶尔回查，运维又不想为了这些低频数据一直支付高频查询的成本。

这时比较 Dynatrace 与 Coralogix，重点往往不是谁能画更多图，而是现有请求调查与新增日志保留怎样分工。Dynatrace 已经覆盖关键应用，保留它可能最省事；日志成为主要负载，且不同数据的使用频率差异很大，Coralogix 的处理与存储路由更值得研究。

观测云编辑部 · 资料核对于 2026-10-21。本文比较 Dynatrace SaaS/Grail 与 Coralogix 云端分析路径，不将 Dynatrace Managed 与最新 SaaS 功能混为一谈，也没有进行性能或成本实测。

已经有拓扑，为什么还要找日志

假设支付服务等待数据库连接，OneAgent 采集的调用与进程信息可以帮助缩小范围。Dynatrace 的应用监控还包括受支持技术上的代码级信息、CPU 与内存剖析，但覆盖取决于平台、运行时、Agent 版本和监控模式，不能把自动发现理解成任何应用都无需配置。OneAgent 支持矩阵、Full-Stack 范围。

这条请求是否因为某个业务规则反复重试，可能还要读应用日志。日志进入 Dynatrace 后，经 OpenPipeline 处理并存入 Grail，可以用 DQL 在 Logs、Notebooks 或看板中分析。请求、资源与日志的共同上下文需要实际采集和相应字段，并不是一张拓扑图自动生成的全部证据。Log Analytics。

Coralogix 也能接收链路并提供 Span 相关数据查询，不只是一个独立日志搜索框。沿 Span 找日志时，选中的数据集还决定查热存储还是归档。应用已经通过 OTel 输出数据，可以继续利用这条采集路径；原来依赖 OneAgent 的深度进程信息则需要另行确认去处。Span 相关数据。

因此，两边同时能显示一条 Trace，只是起点。真正要留下的是原来查明连接池等待、业务重试和下游失败的那几段证据，而不是简单比较是否存在 APM 菜单。

半年日志与最近十分钟，不必走同一条路

Coralogix 的流式处理让部分监控在数据进入过程中进行，存储与查询再按 TCO 优先级分工。High（Frequent Search）使用 OpenSearch 热存储，Medium（Monitoring）与 Low（Compliance）的原始数据保存在客户存储中，仍可用 DataPrime 查询。它不是完全没有索引，也不是所有日志都只有同一费率。TCO Optimizer。

例如支付错误需要频繁交互检索，可以留在 High；用于日常监控但不常逐条查看的记录，可以考虑 Monitoring；只是低频回查的数据，再考虑 Compliance。这里每次降低优先级都改变了使用条件：自定义看板可配置 Monitoring 数据，却不能直接把 Compliance 数据当成同样的看板来源。看板支持范围。

Dynatrace 则可以在 Grail 的日志流程里安排处理、保留和查询消费。DPS 日志既有 Retain 与 Query 分别计量的模式，也有 Retain with Included Queries，把所设时间范围内的查询包含在相应保留模式中；范围之外的数据查询仍按对应规则计量。包含查询也不是无限扫描：每 24 小时的扫描额度为所设窗口内留存日志量的 15 倍；超出时官方说明由团队协助评估、优化查询消费，而不是承诺无限使用。因此，“Dynatrace 每次查询都额外收费”也不够准确。日志 DPS 模式。

值班人员一天反复查最近几小时，和半年后偶尔回看一条记录，对模式的要求不同。把所有数据套同一保留与查询策略，可能既没有满足现场调查，也让低频数据付了不必要的费用。

有归档，不等于历史调查没有限制

Coralogix 配置客户 S3 归档后，日志与 Trace 以 Parquet 保存，桶的区域和访问权限要与服务配置匹配。数据可以按需要长期留下，但存储请求、容量、生命周期与加密仍由相应云配置和合同决定。自己的桶不是免费空间，也不是把整个 Coralogix 后端搬回机房。归档配置。

查询归档无需先把所有历史恢复为热索引，这是有用的工作差别；扫描量、结果上限和实际读取范围却仍有限制。一次跨半年、没有服务过滤的查询，与带着日期和业务标识的回查，不会产生相同负载。归档查询限制。

文件存在还不足以保证能查清事故。若写入前已删除关键字段，或者半年后的查询者没有权限，长期保存也解决不了问题。对于审计，谁能删除文件、交付是否持续、保留规则是否可验证，比产品中“Compliance”这个层级名称更重要。

Dynatrace 的包含查询模式也需要按时间范围理解。例如桶里保留三十天，只有近期一段时间采用 Included Queries，查询越过这段范围时，较旧数据仍有相应查询消费。团队日常只看新日志，月底又跨整月聚合，费用结构就可能变化。不能把“包含查询”扩展成桶中任意历史都永远免费，也不能因为一次旧查询有消费就认为配置失效。

同样，改变 Coralogix 路由不会让过去已保存的数据自动变成未来策略的样子。数据处理规则、权限与查询入口应能对应记录进入系统时的实际条件。历史事故经常跨越多次配置变更，解释查询结果时需要保留这段背景，而不仅是今天控制台上的设置。

主机数量相同，监控消费也可能不同

Dynatrace DPS 的 host-based Full-Stack 使用 memory GiB-hours。物理机或 VM 的 RAM 向上取至 0.25 GiB 的整数倍、最低按 4 GiB，监控时间按 15 分钟区间计算。它不只是“多少台主机乘多少小时”；application-only 容器监控又有自身范围和规则。Full-Stack 消费。

例如十台各 32 GiB 的 VM，全天处于该模式，在不涉及其他调整的简化条件下是：

10 × 32 GiB × 24 小时 = 7,680 GiB-hours/天

这仍是用量，不是美元账单。实际费率来自 rate card，日志、扩展 Trace 摄入及其他能力也要按适用规则加入。Full-Stack 的某些包含额度和主机范围不应重复计费，反过来，也不能因为 Agent 在运行就认为所有数据产品已经全包。

Coralogix 按数据实体与管道优先级消耗单位，日志、Span、指标的换算不同。当前文档里的 High、Medium、Low 日志每 GB 分别消耗 0.75、0.32、0.12 units，Blocked 日志也有处理消费。要估算半年保留的实际费用，还得加上所需存储与合同，而不是只看摄入单价。用量与优先级。

分开运行时，最容易漏掉中间那一跳

保留 Dynatrace 调查应用，把部分日志交给 Coralogix，并不矛盾。问题在于工程师从 Trace 跳过去以后，时间、服务、环境和请求标识是否仍然对应。两边分别搜索成功，不能证明交接已顺畅。

采集端可以按需要安排路由，但重复传输会增加网络与消费，解析规则也可能分叉。某一边改变了字段名，旧链接还能打开，查询却没有结果。这样的维护工作往往比初次接入更持久。

Dynatrace 自身也支持 OTel，并允许逐服务结合开放插桩与 OneAgent，不能把它说成纯私有数据入口。Dynatrace 与 OTel。原来用 OneAgent 自动获得的信息、外部 OTel 提供的内容与查询规则要分别保留，迁移不能只改一个 endpoint。

什么情况更值得保留现有系统

关键应用已经依赖 Dynatrace 的进程、代码与资源调查，日志又能在 Grail 中满足主要工作，继续完善现有配置通常更省事。新的历史查询模式与保留安排，可能已经足够解决新增需求。

日志是主要成本与工作来源，使用频率差别明显，而且团队愿意维护客户存储和路由策略，Coralogix 更有吸引力。收益取决于分层之后常用调查是否仍然完整，而不是“日志多就一定省数倍”。

两者分工也可行，但应明确哪些证据留在哪边，以及谁维护跨平台查询。只有这些工作少于重建全部监控的代价，组合才真正划算。

用观测云承接日志与链路调查

观测云的日志详情提供字段和关联数据入口。需要把应用、主机和链路证据集中查看时，可以接入相关数据，再观察一次原有故障能否连续查下去。

采集质量、字段与保留仍是前提。SaaS 服务能减少部分后端运行工作，自己的数据规范与原始记录管理仍要继续承担，费用也应与已有平台及双写投入一起计算。