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

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

如果团队已经在 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 的可扩展计算方案将存储与查询计算分别计费，Starter 则将两者打包；归档则适合更少访问的历史。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/天

同样是每天 100 GB，仅仅安排不同的去处，消费单位就差了近一半。但这还不是双方的总成本对照：客户存储、其他信号与合同条件没有算进来，日志降级后，原来的看板和告警也未必继续工作。消费比例说明怎么计量，实际单价与账户配额才决定最后付多少钱。

这类整理在观测云里也可以先做。普通日志索引可以分别设置保留期，日常应用日志不必都跟着审计记录长期保存。申请开通多索引后，日志按顺序进入首个命中的普通索引；如果把“所有生产日志”排在“生产审计日志”前面，后者就可能提前被接走，落入错误的保留策略。把用途和路由理顺，才知道哪些存储费用确实还有必要承担。日志索引

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

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

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

观测云的日志详情也从记录里的字段接到相关资源；在 Trace 详情中，可以继续查看同一 trace_id 的日志，以及相关主机、Pod 的指标。回到那次支付重试，工程师找到错误日志后，接着看的就是这次请求经过了哪里、相关资源当时有什么变化，少一次在不同界面之间手工对时间和标识的过程。前提是字段能够对应，相关数据已经接入。

保留期也得覆盖这段调查过程。如果日志保存三十天，Trace 只保留七天，两周后还能看到 trace ID，却已经没有对应链路。这种断点不会因为换了一套关联界面就消失。无论使用 Datadog、Coralogix，还是把相关数据接入观测云，日志与链路需要一起安排保留策略。链路详情

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

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

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

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

增加一套平台，也会增加服务费用，过渡期间的旧存储和双写未必能马上停掉。需要把日志、链路和资源数据接到同一次调查里时，观测云值得一起比较；但集中查看不要求无差别复制全部历史。最后要算清的，是怎样让这条调查路径长期可用，以及为它保留了多少数据、维护了多少配置和后端。