在巴塞罗那举行的 GrafanaCON 2026 大会上，Grafana Labs 发布了 Grafana 13。该版本在数据采集层采用了基于 Loki Kafka 的新架构，并在 Grafana Cloud 中引入了 AI 可观测性功能，用于实时监控和评估 AI 系统。特别值得一提的是，大会还发布了一款名为 GCX 的新命令行工具（CLI），旨在将 Grafana Cloud 数据呈现于代理开发环境中。

传统 Loki 架构通过复制机制实现高可用：每条传入的日志行都会发送给三个摄入器，形成了 3 倍的复制因子。理论上看来，这很简单。但问题在于，去重依赖于文件命名：如果摄入器覆盖的时间范围相同，它们生成的文件名就会完全相同，而这些重复的文件就会被合并。

以前和现在的 Loki 架构

Grafana Labs 软件工程师 Trevor Whitney 在 GrafanaCON 的一次简报会上解释了其工作原理：

在分布式系统中，数据采集器之间会存在轻微的时间漂移，而如果采集器之间的时间同步出现任何偏差，这些文件就会无法按文件名去重。我们的内部指标显示，实际上，我们最终存储的数据量平均为原始数据的 2.3 倍。也就是说，对于每条采集到的日志行，我们都会将其存储 2.3 次。

这个 2.3 倍不是个抽象概念，它处处都有体现：数据摄入时的 CPU 占用、内存压力、网络成本、对象存储费用，以及在查询时即时处理重复数据。

新架构用 Kafka 作为持久化层，取代了“摄入时复制”的策略。日志仅需写入 Kafka 一次，摄入器从队列中读取数据，实际复制因子降至 1。结合经过重新设计的查询引擎（该引擎可在分区间分配工作并并行执行），Grafana 声称，在聚合查询中，扫描的数据量最多可减少 20 倍，性能提升 10 倍。

这里有一个值得专门提及的权衡。Loki 最初的设计原则是依赖最小化：仅提供对象存储，别无其他。而新架构打破了这一原则。Whitney 对此直言不讳：

到目前为止，我们唯一的依赖项是对象存储，这其实从项目伊始就是我们的目标之一。所以没错，这次确实引入了第二个依赖项。现在，任何 Loki 分布式部署都需要对象存储和 Kafka。

单二进制文件部署不会受影响；本地环境或家庭实验室无需进行复制协调，因此仅使用文件系统或对象存储即可正常运行。但任何大规模运行 Loki 的用户都需要将 Kafka 纳入其运营范畴。

在 GrafanaCON 大会期间，一款名为 GCX 的 Agent-aware 新型命令行工具正式进入公开预览阶段。该工具旨在将可观测性集成到 AI 驱动的工作流中。其设计理念很简单：如今许多工程师每天大部分时间都在 Claude Code、Cursor 或 GitHub Copilot 中度过，而当生产环境出现故障时，工作流会迫使他们进行上下文切换：先切换到 Grafana，浏览仪表盘，再返回编辑器，最后再回到 Grafana 验证修复是否生效。GCX 正是为了消除这种循环而设计的。

负责 GCX 项目的 Ward Bekker 在现场演示中阐述了开发该 CLI 工具的原因：

命令行界面（CLI）从未过时，但如今无疑更受青睐，这主要得益于基于代理的编码工具。许多人发现，在命令行中将 CLI 与 Cursor 或 Claude Code 结合使用，效果极为显著。

Bekker 演示了一个典型的场景：综合监控检测到电子商务订单流中的故障；Grafana Assistant 运行自动根因分析；GCX 将该分析结果连同相关源文件一并导入 Claude Code；Claude Code 提出并应用修复方案；随后 GCX 直接查询综合监控指标确认系统是否已经恢复正常。整个过程无需打开任何浏览器标签页。

Grafana Labs 并未押注于单一集成模式。该团队正在开发 GCX 命令行工具（CLI），同时也在并行开发远程 MCP 服务器。他们的观点是：这两种方式分别面向不同的用户群体，且各自都有值得支持的应用场景。

这些公告与 Grafana 13 同步发布，该版本将动态仪表板作为正式版功能推出，新增了对基于 Git 的工作流的支持，并将数据源生态系统扩展至超过 170 种集成。Grafana Labs 还发布了一款 AI 可观测性产品的公开预览版，专为在生产环境中监控基于大型语言模型（LLM）的应用程序的团队而设计。

Grafana 13 和 Loki 的更新现在已经发布。GCX 已经进入公开预览阶段。AI 可观测性解决方案也在 Grafana Cloud 中进入公开预览阶段。

声明：本文为 InfoQ 翻译，未经许可禁止转载。

原文链接：https://www.infoq.com/news/2026/04/grafana-loki-ai-agents/