Datadog vs Coralogix：历史日志、存储分层与查询成本

月底复盘支付事故，团队想找两周前的一条重试日志。当天的告警早已处理，在线日志却只保留了七天。现在的问题不是有没有 APM，而是这条记录是否还在、要从哪里查，以及为这类偶尔发生的调查付出了多少费用。

这也是 Datadog 与 Coralogix 值得放在一起比较的地方。已有 Datadog 的请求、主机和日志关联，继续完善分层保留可能比迁平台省事；大量工作围绕日志展开，数据又有明显的冷热差别，Coralogix 的流式处理与优先级路由值得认真研究。两者都能使用客户自己的归档存储，不能按“数据在厂商手里还是自己手里”简单分组。

观测云编辑部 · 资料核对于 2026-10-21。本文讨论两家的云端分析服务，依据官方文档说明查询、保留与消费机制，未进行性能或账单实测。

一条日志为什么有几种去处

Coralogix 在数据进入时执行处理与路由，TCO Optimizer 再按策略决定优先级。High（Frequent Search）进入以 OpenSearch 为基础的热存储；Medium（Monitoring）与 Low（Compliance）的原始数据进入客户存储，仍可通过 DataPrime 查询。流式处理减少某些分析对预先索引的依赖，不等于整个产品没有索引。TCO 优先级。

这些层级也不只是速度不同。Monitoring 支持相应监控与看板流程，Compliance 的功能范围更窄。查询页面能找到一条低优先级记录，不代表同一个查询就能用于自定义看板。官方文档明确：看板默认查 Frequent Search，Monitoring 需要加入对应数据，Compliance 不用于这类看板。看板与数据层。

因此，把健康检查日志降到低优先级之前，要先看它是否参与告警或看板。保存下来和继续参与日常监控，是两件事。策略按顺序匹配，未匹配的数据默认进入 High，漏掉一条路由规则也可能让消费与预期不同。

Datadog 同样不只有“全部索引”一种选择。Standard Indexing 面向经常调查的日志；Flex Logs 将存储与查询计算分开；归档则适合更少访问的历史。Flex 可以用于长期检索和看板，但当前不支持 Monitors 与 Watchdog，不能把标准层的实时用途原样搬过去。Flex Logs。

两周前的请求怎样重新找到

在 Coralogix 配好归档之后，可以从相应数据集查询历史，而不必先把全部内容恢复为热索引。直接查询仍然有扫描量、结果数量与权限限制，宽范围调查也可能比热存储慢。返回上限不是匹配记录总数，页面只显示一部分结果时，不能据此断定其他事件不存在。归档查询。

Datadog 可以把已摄入日志送到客户的 S3、Azure 或 Google Cloud 存储，不论它是否进入索引。当前文档提供 Archive Search 直接查询归档，也保留 Search & Rehydration 路径以获得相应平台能力与保留期。因此，“Datadog 查历史必然全部重新索引”已经不适合作为普遍判断。日志归档、日志配置。

实际调查通常先有服务、日期和请求标识。把这些范围带进查询，既减少读取，也让结果更容易解释。如果原来的请求 ID 根本没有写进日志，或者写入前已被过滤，两家的归档入口都不能把它补回来。

查询结果还可能受到后端语义影响。Coralogix 文档给出一个容易忽略的例子：Frequent Search 由 OpenSearch 支撑，空数组字段不会按普通字段索引；归档数据则保留数组语义。同一个“字段等于 null”筛选，在两条路径上可能得到不同结果。需要找空数组时，官方建议明确检查数组长度，不要把空数组与字段缺失混在一起。DataPrime 限制。

这对历史回查很实际。某个业务字段在新版本中从缺失改为空数组，月份报表突然变化，未必是业务量变化，也可能是查询路径和字段表示改变。保存几条已知记录及其预期含义，比只确认查询返回成功更能发现这种迁移问题。本文没有实际运行这组查询，不将文档中的语义差别解释为性能结论。

自己的桶仍然需要有人维护

Coralogix 的 S3 归档将日志与链路写为 Parquet，对应桶需要匹配账户区域并配置访问权限；指标归档另行配置。保存时间可以按需要安排，但云存储容量、请求、生命周期和密钥管理并不会免费，也不等于整个分析后端都部署在客户环境。S3 归档设置。

桶里的文件能被另一套工具读取，有助于保留选择余地；原来的字段处理、DataPrime 查询、看板、告警和权限仍需要重新安排。拥有文件与迁移后能完成同一次调查之间，还有工程工作。Datadog 的客户归档也有同样的问题，压缩 JSON 文件不会自动带走整个平台配置。

权限或生命周期规则改错以后，日志可能无法继续写入，或者比业务预期更早删除。是否能收到交付异常、谁负责恢复权限，比“无限留存”四个字更影响历史记录能否真正派上用场。

日志费用不能只乘每天的 GB

Datadog 的摄入、索引、Flex 存储与计算、归档及查询路径需要分别核算。把一条日志排除出标准索引，不会撤销它已经发生的摄入；选择不同历史查询方式，也会改变费用组成。产品价格。

Coralogix 当前使用单位消费模型，日志按优先级消耗不同单位。官方列出的每 GB 日志，High 为 0.75 units，Medium 为 0.32，Low 为 0.12，Blocked 为 0.08。Blocked 日志在摄入时被丢弃，但仍有处理消费，不是免费保留层。用量计量。

假设每天 100 GB，其中 20 GB 经常查询、60 GB 用于监控、20 GB 仅作低频历史调查，按上述公开比例：

20 × 0.75 + 60 × 0.32 + 20 × 0.12 = 36.6 units/天
全部进入 High：100 × 0.75 = 75 units/天

这个差异来自路由，不是双方总成本的对照。它还没有包含客户存储、其他信号与合同条件，也不能保证把日志降级后原来的看板和告警继续工作。官方单位比例、实际单价与账户配额应分别看，别把一次示例直接当成采购预算。

日志能查到以后，能否接着看请求

支付服务的错误日志只说明调用失败，等待发生在哪个下游，仍要看链路。Datadog 的日志与 Trace 关联需要正确的标识、字段解析和服务标签，数据也必须仍在相应保留期内。日志与链路关联。

Coralogix 也提供 Span 相关数据入口。其日志数据集选择会决定查询 Frequent Search 还是归档，因此链路附近能否看到日志，还受到归档配置与所选层级影响。Span 相关数据。这不是“有 APM”三个字能完全说明的使用差别。

通知和轮值也不应沿用旧的缺功能判断。Datadog 已有 On-Call，是否购买、怎样与现有事件流程配合，要按具体产品安排；不能笼统说两家都必须另外购买第三方轮值产品。Datadog On-Call。

哪些重复工作值得为它换平台

请求调查已经深入使用 Datadog，问题主要是历史日志贵或保留不足，先整理 Standard、Flex 与归档的分工更合理。减少长期放在昂贵查询路径上的低频数据，可能已经能解决主要问题。

日志量大且冷热用途分明，团队愿意维护优先级规则与客户存储，Coralogix 更值得尝试。它的价值来自数据路由与使用方式匹配，而不是“没有索引，所以永远更便宜”。两周前的请求能否查清、日常看板是否仍完整，比单一摄入单价更重要。

在观测云里继续调查日志

观测云的日志详情提供字段筛选和相关数据入口。已有日志平台却经常停在孤立错误记录时，可以把需要共同调查的数据接入，再看能否沿服务、主机与链路接续分析。

关联字段、保留和源端采集仍由业务侧安排。是否增加另一套平台，应与原有存储、双写和维护投入一起比较，不必为集中显示而无差别复制全部历史。