Grafana Cloud vs Coralogix：把日志留下以后，还要怎样查

客户带着一笔订单来找支持团队，只有订单号和大约的日期，不知道请求经过了哪个服务。工程师把时间往前拉了一周，才发现平时顺手的“服务 + 最近十五分钟”已经不够用了。日志是否还在、该查哪份数据、查出来能否继续关联请求，开始比仪表板上有多少图更重要。

Grafana Cloud 与 Coralogix 都能接收多种遥测。两者的区别，在这类调查中会落到具体的数据组织上：Grafana Cloud 的 Loki 日志以标签选择流，再对日志内容和元数据查询；Coralogix 则可以按优先级安排热数据与客户存储中的数据，同时改变可用的分析功能。以下以 2026 年 10 月 21 日的托管产品文档为依据，不把开源 Loki 自建方案算作 Grafana Cloud，也不把客户拥有 S3 桶等同于自建了完整 Coralogix 平台。

订单号该放在哪里

在 Loki 中，服务和环境这类稳定、低基数的信息适合做流标签。订单号、用户 ID、trace ID 不宜都升成索引标签，否则标签组合会产生大量流。结构化元数据可以携带高基数字段而不把它们变成索引标签；JSON 日志中的业务字段也可以在查询时解析。Loki 标签设计、结构化元数据

假设订单服务的 JSON 日志已写入 order_id，并且 service_name 是实际存在的流标签，可以用下面的示意查询寻找订单。环境名称和字段需要对应自己的接入配置：

{service_name="checkout"} | json | __error__="" | order_id="A-1042"

这里先限定流，再解析 JSON，排除解析错误，最后过滤业务字段。它不是任意数据集都能直接复制的配置。若订单可能跨多个服务，就要扩大流选择范围；这通常也扩大要处理的数据范围。Loki 支持内容过滤和解析，不能把它概括成“不能全文搜索”，更不能仅凭索引模型宣布它在所有调查中都更慢。LogQL 日志查询

这个顺序带来一个实际取舍：如果值班入口大多是已知服务的错误告警，现成的标签和 Grafana 工作流很顺手；如果入口经常只是零散业务字段，团队需要提前设计查询范围和字段保留，不能等事故发生后才补日志。

Coralogix 的优先级是使用方式，不只是价格档

Coralogix 的 High（Frequent Search）使用 OpenSearch 热存储；Medium（Monitoring）和 Low（Compliance）的原始数据保存在客户存储中，通过 DataPrime 查询。Low 可用功能少于 High 和 Medium。把付款失败日志降到 Low 后仍能找回某条记录，不代表原有告警和仪表板可以照常使用。TCO Optimizer

因此，订单调查里可以把近期需要频繁排查的数据、持续参与监控的数据，以及主要用于追溯的历史记录分别考虑。优先级选择应跟着这些用途走。若把所有数据统一降档，只对比“还能搜索”，很容易漏掉团队平时依赖的实时处理能力。

它也不是“所有数据只在客户桶里、从来没有索引成本”的架构。热查询路径确实存在，客户桶需要正确配置；拥有原始对象，也不意味着查询界面、规则、仪表板和权限配置可以原样搬走。退出方案应包括这些配置的迁移，而不只是下载文件。

一周前的数据怎样回到调查里

Coralogix 的 Explore 可以直接查询 S3 归档，支持 DataPrime、Lucene 等路径，不必先把每次调查的数据重新索引。但这里仍有权限、处理字节、扫描文件数和返回结果上限。看到了几千条记录，不等于已经导出了整份历史数据；范围很宽时要收窄条件，或使用合适的归档与后台查询入口。归档查询文档

归档生命周期同样需要有人负责。TCO 的保留标签可以配合云存储生命周期规则，实际删除由存储端控制。把页面上的保留选项改长，无法恢复已经被桶规则删除的对象。应让订单追溯要求同时落在采集路由、对象保留和调查权限上。保留与路由配置

Grafana Cloud 的调查则依赖所选日志保留期。延长保留是面向后续可用数据的配置，不能让已经过期的日志重新出现。若日志留得比 trace 久，订单记录可能还查得到，却没有对应链路可打开。这是信号之间的保留差异，不是关联按钮失效。Grafana Cloud 日志保留

从日志转到应用，需要额外的上下文

Grafana Cloud 的 Application Observability 提供服务、请求指标和关联遥测工作流，当前 Knowledge Graph 体验与旧版界面有所区别。已有 Prometheus 指标、OTel 服务属性和 Grafana 看板的团队，可以把熟悉的入口延伸到请求调查；但只接入 Loki 并不等于已经启用了整套应用可观测性。Application Observability

Coralogix 也有 APM、服务目录和服务图。选择日志优先级时，需要一并考虑参与 APM 的数据路径，而不能把它视为日志平台外的独立小开关。对同一订单，是否保留正确的 trace ID、span 关系及服务属性，决定了从记录走到调用链是否顺畅。Coralogix APM

一个有用的对照范围不必覆盖全部业务。选一条涉及网关、订单与支付的路径，让两边都能解释一次成功和一次失败：先找到业务记录，再定位具体请求，最后返回对应服务的变化。这样可以区分产品能力与尚未完成的接入工作。

把日常调查也算进账单

Grafana Cloud 日志有 processed、written、retained 和 queried 四种计量。Adaptive Telemetry 丢弃数据可以减少写入量，但接收后优化之前的处理量仍有计量；查询超过公平使用额度也可能收费。不要把压缩后的对象存储大小直接当成全部日志费用。日志计量

使用 Application Observability 产品还需计算 host hours，加上指标、日志、链路和 profile 的遥测费用；只自行构建仪表板和告警则不产生这项产品的主机小时收费。旧客户方案与当前新方案可能不同，应对应账号实际条款，不能统一套用旧额度抵扣。应用可观测性计费

Coralogix 使用用量单位，不同信号和优先级有不同换算；Blocked 日志也有摄入处理费用，不是进入平台后丢弃就完全免费。估算时应加入客户桶的存储、请求及适用的传输支出，再记录常见调查涉及哪些优先级。两边没有可以脱离数据用途直接比较的“每 GB 总价”。Coralogix 用量说明

哪种组织方式更适合团队

已有 Grafana 与 Prometheus 工作流、查询通常从已知服务出发，且愿意持续治理标签和字段的团队，Grafana Cloud 往往更容易接续现有工作。需要围绕日志用途精细安排优先级、客户归档与历史调查的团队，则值得重点验证 Coralogix 的路由和权限设计。

判断依据应是一周前那笔订单能否完整解释，以及保存这条调查路径需要多少平台维护和用量。没有实测数据时，无法从“无索引”口号、某个起步价或供应商所在地推导出性能、成本或合规的统一赢家。

在观测云中核对同一笔订单

评估观测云时，也可以沿订单日志检查关联链路。日志中的 trace 标识、服务字段和时间范围需要正确配置，相关数据也必须仍在保留期内。把这条路径走通，才能讨论是否适合团队的日常调查。观测云日志关联