Grafana Cloud vs Elastic Observability：查询迁移不只是换个搜索框

团队准备把一条错误告警从 Kibana 搬到 Grafana。两边都能搜索日志，服务名也对上了，可同一小时的错误数始终不同。有人怀疑丢数，继续往下看，才发现旧查询匹配的是经过分词的字段，新查询匹配的是整行中的字面字符串。

这也是比较 Grafana Cloud 与 Elastic Observability 的一个好起点：先看现有调查和告警依赖什么语义，再谈平台迁移。Grafana Cloud 更容易接续 Prometheus、LogQL 与 Grafana 工作流；Elastic 的字段建模、搜索和聚合适合围绕事件展开调查。两边都不止一种信号，也不能仅凭“有无全文索引”判断性能和总成本。本文依据 2026 年 10 月 21 日的官方文档，比较托管产品，并区分 Elastic Cloud Hosted 与 Serverless。

让告警数相同，先让查询含义相同

下面两个示例看起来都在找 checkout 的超时，但不能直接认为等价。它们假设对应字段和标签已经存在，只用于说明语义，没有声称经过生产验证。

{service_name="checkout"} |= "timeout"

service.name: "checkout" AND message: "timeout"

LogQL 的 |= 对原始日志行做区分大小写的子串匹配；timeout 不会自动匹配 timed out。KQL 则按字段查询，message 若是 text 类型，匹配会受分析器影响；若是 keyword 等类型，行为又不同。加了引号也不意味着自动变成对原始字符串的同一种搜索。LogQL 查询、KQL 语法、Elastic text 字段

对于告警迁移，最省返工的办法是先准备一小组带已知结果的事件：大小写不同的超时、包含重试的错误、没有 message 的记录和一条正常请求。分别确认哪些应计入错误，再写查询。否则两张曲线看起来接近，也可能在真正触发告警的那类异常上完全不同。

还要分开过滤与统计。KQL 本身表达筛选条件，分组计数可以在可视化或 ES|QL 中完成；ES|QL 的 STATS ... BY 才是聚合步骤。LogQL 也有从日志计算指标的路径，迁移时仍须保持时间窗口、分组、分母和重复记录处理一致，不能把“错误日志条数”直接叫作“请求错误率”。ES|QL 聚合

字段治理会以不同方式回到日常工作

Loki 使用标签选择流，适合先从服务、环境等稳定维度缩小范围。请求 ID 之类高基数值不宜随意变成索引标签，可以放在结构化元数据或日志内容中查询。这样，团队需要维护的是哪些属性作为入口、哪些字段留给后续筛选。Loki 结构化元数据

Elastic 则需要关注字段映射与数据类型。状态码究竟是数值还是字符串，业务 ID 是否作为精确匹配字段，message 如何被分析，都影响过滤、排序和聚合。已有成熟 ingest pipeline、字段约定与 Kibana 调查流程的团队，换平台时迁走的不是一份文本，而是这些约定。Elastic 字段类型

两种方式都需要治理。前者不能把所有字段升成标签，后者不能用一个映射覆盖所有来源后就不再检查。对混杂历史日志做宽范围检索，与对已知服务快速定位最近错误，是不同工作负载；没有相同数据、范围和并发的实测，就不应给出谁必然更快的结论。

先确定要买哪一种 Elastic

Elastic Cloud Hosted 按配置资源运行，用户仍对容量与升级时机有控制。Serverless 由 Elastic 管理底层容量、扩缩与升级，采用用量模式。使用 Serverless 后，不应照搬 Hosted 的节点维护和 ILM 操作；它的保留路径使用 data stream lifecycle。这些差异会影响迁移脚本和日常职责，而不仅是账单标题。Hosted 与 Serverless 对照

Serverless 又分 Logs Essentials 与 Complete。前者面向日志，后者包含 APM 和基础设施指标。若目标是从日志进入慢请求和资源变化，不能用纯日志层的价格代表整套方案。Logs Essentials 范围

Grafana Cloud 同样不等于把开源组件自己装起来。已有本地 Grafana 看板可以降低部分学习与迁移成本，但数据源地址、标签、规则和访问权限仍要对齐。托管服务免去一部分后端维护，并不自动完成这些内容工作。

日志后面的请求证据能否接上

Grafana Cloud 当前 Application Observability 的 Knowledge Graph 体验提供服务视图、请求指标和关联遥测；旧账号也可能仍使用 classic 体验。团队可以沿现有 OTel 服务属性和 Prometheus 指标继续构建调查入口，但单独接入 Loki 并不代表应用可观测性已经配置完成。Application Observability

Elastic 的接入与采样也要对应部署路径。当前官方对照表中，Serverless 不支持 APM Tail-based sampling，却支持自行管理的 Elastic OpenTelemetry 尾部采样路径；Managed OTLP Endpoint 本身不执行尾采样。因此，“Serverless 没有尾采样”和“Hosted 配置可以原样复制”都不准确。选择采集链路时，应确认究竟由哪个组件执行策略，以及错误 trace 是否在进入后端之前就已被丢弃。Elastic 部署能力对照

日志里的请求标识能把调查带到 trace，但采样决定了那里还有多少内容。如果两边留下的是不同片段，错误数的差异就可能来自采集、查询或采样，而不是迁移丢数。固定请求标识、输入事件与时间范围，才能把这些原因分开；一次搬完所有仪表板反而会让差异更难追溯。

这也是观测云日志关联需要处理的实际问题：字段解析和时间范围决定找到哪些日志，请求标识和保留的数据决定能否接上 trace。页面上有跳转入口，并不代表被采样丢弃或已过保留期的链路还能找回。观测云日志关联

把计量拆到能够估算的单位

Grafana Cloud 日志按处理、写入、额外保留和超出公平使用额度的查询量计量。服务端优化减少写入，并不抹去优化前的处理量。Application Observability 产品通常另外使用 host hours，再加它产生的遥测费用；受支持的 serverless 环境改按遥测量计费。2026 年 2 月 13 日之前开通的账户仍有文档所列的遥测抵扣，具体适用合同需确认；自行构建看板与告警并不产生该产品的主机小时费用。日志计量、应用计费

指标还需要看活跃序列与每分钟数据点数（DPM）：先分别取账期 P95，再比较活跃序列与按 included DPM 换算后的数据点量，取较大者。相同序列数改成更密集的采集，也可能改变用量，不能只数标签组合。Grafana Cloud 指标计量

Elastic Observability Serverless 的核心数据计量是摄入与保留，按 ingest pipeline 完成丰富与规范化之后、Elasticsearch 压缩之前的数据大小计算。TSDB 模式的指标费率与普通日志、链路不同，额外能力也可能有自己的收费。把已有索引的压缩磁盘大小代入每 GB 报价，容易低估；Hosted 则应按资源配置另算。Elastic Serverless 计费维度

实际预算可以先固定一周有代表性的输入，记录各信号的输出量、保留要求和调查频率，再扩大到月度。迁移期的双写、查询改造与值班培训也属于成本。只有查询结果和需要的功能对齐后，估算才是在比较同一件事。

让现有调查方式参与选型

如果主要资产是 Prometheus 指标、Grafana 看板和从已知服务出发的调查路径，Grafana Cloud 更容易延续团队习惯。若团队长期依赖细致字段建模、Kibana 搜索与事件聚合，Elastic 通常值得优先保留或评估其托管方案；选择 Serverless 时再接受它对应的控制范围与产品限制。

最后决定不应只看搜索框是否顺手。那条错误告警能否保持原来的含义，值班人员能否继续找到同一批异常并解释原因，才是迁移成功的标准。