New Relic vs Coralogix：日志分层以后，调查还能走到哪一步

围绕月末订单排障，比较应用上下文、TCO优先级、客户桶、历史查询与不同用量模型。

观测云编辑部 6 分钟阅读更新于 2026-10-21

月底才出现的订单差异，往往把日志预算问题变成排障问题。平时几乎不查的成功记录，突然需要和付款失败、重试链路一起回看。如果这些数据已经被丢弃，或者只留下聚合数字，采购时承诺的“保留更久”就无法完成这次调查。

New Relic 与 Coralogix 都提供日志和应用性能能力，但组织证据的方式不同。前者可以围绕 APM 实体与 NRQL 调查延续已有工作；后者的 TCO 优先级把存储位置、查询方式和功能权利一起纳入数据治理。选型需要追问：降低日志成本以后，原来的调查还剩下哪些步骤？本文依据 2026 年 10 月 21 日官方资料，不将厂商展示的节省比例当作相同工作负载的实测结论。

从服务异常走向具体订单

New Relic 的 APM logs in context 可以把日志与服务实体、trace 和 span 连接。团队从服务错误率上升进入相关请求，再查看调用期间的日志；已有日志转发器时，也可以让 Agent 只负责装饰关联元数据，避免重复发送。这样的路线适合已经围绕 APM 服务组织告警与值班的团队。日志关联

Coralogix 也不是只有日志搜索。当前 APM 接入说明包含 Service Catalog、服务地图、RED 指标与分布式追踪：应用产生 spans，OTel Collector 转发，再生成支撑 APM 的 Span Metrics。服务名与日志 subsystem 等约定需要对齐，链路与日志才方便交接。采样前已经丢掉的调用，不会因为后来生成了服务地图就重新出现。APM 接入机制

同一个订单可能经过多次请求与补偿任务，业务标识应当贯穿日志，trace ID 则指向某次执行。若只保留服务级错误率，能够发现某天发生异常，却未必能解释某笔订单究竟停在哪里。两种产品都需要应用端把这层含义写进数据。

Coralogix 分层同时改变存储与使用方式

TCO Optimizer 当前将 High 对应 Frequent Search，数据进入 Coralogix 的 OpenSearch 热存储；Medium 和 Low 的原始数据在客户拥有的存储中，通过 DataPrime 查询。Medium 保留较广的监控能力，Low 的功能集合更小，不能假设降到 Low 后原来的告警与自定义仪表板仍然可用。Low 仍支持 APM Span Metrics，服务地图和目录也不依赖优先级，具体能力要按当前矩阵区分。优先级与功能矩阵

这使“全部数据只在客户桶里”和“完全没有索引差异”都成为不准确的概括。High 与 Medium/Low 的调查体验并不相同；配置归档后，High 还可以向 S3 写后台归档副本。对持续排障的重要数据保留快速查询，对较少查询的数据使用其他优先级，是需要结合真实访问习惯作出的配置选择。

策略按顺序匹配，改变策略也不会重新分类已经接入的数据。Block 更不是一种便宜的冷存储：日志会被丢弃，无法从归档找回；blocked spans 保留名称、时间和层级，但移除属性、事件与负载。一个还能打开的 span，如果已经失去订单属性，也可能无法回答原来的业务问题。TCO 路由说明

归档可以直接查，但不是没有条件

Coralogix 文档中的旧归档入口是 Explore → Logs → Archive → CX-Data，可以直接查询 S3 数据，不必为每次调查先恢复索引。这里的 Lucene 查询用于日志，DataPrime 可查询日志或 spans。该入口列出的限制包括处理字节上限为日接入量的 30%、最多扫描 50 万个 Parquet 文件，日志默认返回 2,000 条；结果和导出还有各自上限。这些是该归档入口的限制，不是所有 DataPrime 查询的统一配额。时间范围可以很长，不代表一次查询能无边界地处理全部历史。Explore 归档查询

归档的实际保留也要与存储配置一致。Medium/Low 的 retention 标签写到 Parquet 文件上，由客户云存储生命周期规则决定删除；Coralogix 不替客户执行这项删除管理。自定义数据集还有自身 Dataset Definition 的保留约束。要查三个月前的订单，前提是对象仍然存在、权限仍然可用，而不只是控制台保留了数据集名称。策略与归档设置

New Relic 则通过数据类型和账户设置管理保留。不能把日志、Span、Transaction 和 TransactionTrace 都写成统一的八天或九十天。对于月底才调查的问题，应分别确认业务日志与对应链路的有效窗口；一边仍在、另一边过期，关联入口也只能提供部分证据。保留管理

降低接入量时，保留什么比删多少重要

New Relic 当前 Pipeline Control 区分运行在客户环境的 gateway 与运行在平台侧的 cloud rules。前者可以在离开网络前处理，后者处理已经到达 New Relic endpoint 的数据；当前 cloud rules API 文档要求 Compute 用量计费方案。它们不能被描述为所有账户默认拥有的同一项免费过滤能力。Gateway、Cloud rules 条件

无论在哪个平台，一条“丢弃全部成功请求”的规则都会让后来的成功/失败对比变困难。更稳妥的起点是选定具体数据源，检查被删字段是否承担关联、审计或去重用途，再用预期事件验证。过滤规则减少的数据量，是治理结果的一部分；无法再回答的问题也是。

Coralogix 的多目的地日志路由会复制匹配数据，并分别计费。它与 High 自带的后台归档副本不是同一回事。为了给两个团队各留一份数据而增加目的地，可能改变单位消耗；这项变化应与存储权限设计一起考虑。多目的地路由

用同一调查窗口估算费用

Coralogix 当前用量文档将一 unit 定为 1.50 美元：每 GB 日志的 High、Medium、Low、Blocked 分别为 0.75、0.32、0.12、0.08 units。指标与 traces 有各自换算，不能把所有遥测都乘同一个日志单价；Blocked 仍有处理成本。客户桶的存储、访问及维护也应进入总预算。用量计量

New Relic 的当前选项包括 Data + User 与仍处于 Preview 的 Data + Core Compute，后者需联系账户代表，另有 Advanced Compute。接入量、用户或计算、保留的组合取决于合同与设置。因此这不是“按人头”和“按 GB”两个数字的简单相除。计费说明

如果团队已用 New Relic 的服务实体、NRQL 和告警完成跨团队协作，保留这套调查路径可能比更换日志后端更重要。若主要矛盾是大量日志的长期保留与不同查询频率，希望明确控制优先级及客户存储，并能承担策略和桶生命周期治理，Coralogix 值得重点验证。最终比较应使用同一笔历史订单：能否找到它、能否解释它，以及下一次调查需要多少操作和消耗。