ClickHouse Grafana 插件 4.0 - 提升 SQL 可观测性

自 2022 年 5 月首次发布 ClickHouse Grafana 插件以来，这两项技术都已显著成熟。在最近的博客文章中，我们描述了实时 OLAP 存储的成熟度与开源标准化如何结合，使 SQL 能够应用于可观测性用例。Grafana 及其“开放式帐篷”理念是这一愿景的基础，它允许用户通过 ClickHouse 探索和可视化可观测性数据。我们意识到使用 SQL 进行可观测性的挑战之一是学习和采用 SQL，因此我们继续投资于 ClickHouse 插件以协助解决这个问题。

版本 4 的发布，体现了用户交互的新理念，其中日志和追踪在新查询构建器体验中成为一等公民。我们相信，这将最大限度地减少 SRE 编写 SQL 查询的需求，并简化基于 SQL 的可观测性，从而推动这一新兴范式向前发展。

在这篇博文中，我们将探讨版本 4.0 中用户体验的演变以及我们设计决策背后的思考。其中一部分是将 Open Telemetry (OTel) 置于插件的核心，因为我们相信这将是未来几年基于 SQL 的可观测性的基础，也是数据收集的方式。

早期版本的 ClickHouse Grafana 插件试图提供与数据无关的体验，允许用户在任何数据类型之上构建可视化。虽然此功能在版本 4 中得以保留，但用户会发现体验更为主观，并且更侧重于为可观测性数据集提供流畅的体验：这是 Grafana 的主要用例。

首次安装插件并要求用户配置数据源时，此更改将立即显现。除了能够配置默认数据库（现在还可以配置表）之外，用户还可以为其日志和追踪数据指定配置。最简单的形式是，这意味着仅为日志和/或追踪数据指定默认数据库和表。但是，您也可以指定您的数据符合 OTel 规范（以及您正在使用的特定版本）。如果您更改了默认的 OTel 架构，或者更喜欢使用自己的格式，则可以覆盖列名。

日志配置在这里非常简单 - 需要时间、日志级别和消息列，以便日志能够很好地呈现，我们稍后会看到。

追踪配置稍微复杂一些。此处所需的列是后续查询（构建完整的追踪配置文件）可以抽象出来的列。这些查询假定数据结构与 OTel 类似，因此显著偏离标准架构的用户将需要使用视图才能从此功能中受益。

早期版本的插件旨在帮助用户构建 SQL 查询，而与查询的数据类型无关。这要求用户指定他们想要构建的查询是选择行、执行聚合还是执行时间序列分析。此选择是通过命名不佳的“显示为”选项（表、聚合和时间序列）进行的。除了控制查询构建器选项本身（旨在帮助用户避免为目标查询类型键入 SQL）之外，此选项还令人困惑地控制了初始版本中数据的呈现。后来的迭代通过“格式”选项将此选项分开了。虽然这允许用户构建查询类型并按需呈现它，例如将时间序列呈现为表格，但这最终令人困惑。这导致用户恢复到可以手动输入查询的 SQL 编辑器。

版本 3

我们希望在版本 4 中优先解决这种困惑。此外，为了提供更专注于可观测性的体验，我们为日志和追踪引入了专用查询构建器。这些构建器可通过新的“查询类型”选择器获得，该选择器仅控制构建器的布局。考虑到用户仍然需要构建通用时间序列查询和聚合，这包括表格和时间序列选项。最后，对于那些拥有高级查询的用户，我们保留了通过经典 SQL 编辑器编写自己的查询的能力。

版本 4

Grafana 提供了强大的查询和呈现追踪的能力。这要求目标存储根据追踪的 ID 和其组成跨度重建整个追踪。在 ClickHouse SQL 中，这总是会导致复杂的查询，用户过去会使用参数化视图来抽象这些查询。然而，总体体验仍然不能令人满意，用户需要通过 SQL 编辑器查询视图。

在 4.0 中，用户可以使用过滤器简单地搜索追踪，例如，将结果限制为那些超过 SLA 持续时间的追踪。用于识别顶级追踪的所需查询会自动为用户生成，结果以表格格式返回，如图所示。这要求用户指定映射到所需概念的列，例如 TraceId。幸运的是，对于那些使用 OTel 架构的用户，这些映射会自动填充。

请注意，以上内容既包括深入查看追踪的能力，也包括检索关联日志的能力。后一种能力对于提供统一的可观测性体验至关重要，用户可以在不同的数据类型之间轻松导航。

“查看追踪”链接允许以 Grafana 所需的格式检索追踪的跨度，以便可以在拆分视图的右侧将其呈现为瀑布图。

如果用户希望检查特定的追踪及其跨度，现在也支持按 ID 搜索。同样，无需 SQL，只需输入 ID 并搜索即可。此特定应用程序流程适用于那些从其他可观测性来源（例如日志）识别感兴趣的追踪的用户。

这些简单地搜索和呈现追踪的方法无需编写查询，使非 SQL 从业人员也有可能享受 ClickHouse 的高压缩率和闪电般的检索速度。

日志查询构建器主要设计用于 Grafana 的 Explore 视图，用户可以在其中列出日志事件并执行向下钻取。假设您正在使用 OTel，那么现在查询日志数据应该只需要为您的 Query Type 选择 Logs，调整时间段并单击 Run Query。

如您所见，我们现在还获得了显示随时间变化的日志级别的直方图。由于现在在架构中获得了有关级别和时间字段的所需信息，我们可以自动发出所需的 GROUP BY 查询来支持此可视化。

用户可以选择将过滤器应用于这些结果，修改排序顺序或限制结果数量。所有这些都无需编写 SQL。对于那些希望深入研究的用户，可以通过经典编辑器编辑 SQL 查询。

与追踪类似，日志在调试问题时不是孤立使用的，用户对与生成日志行的请求相关的追踪感兴趣。现在，通过从日志中提取的任何追踪并将其作为可点击链接公开来支持这一点。这会导致与之前搜索追踪并单击 traceid 时演示的相同的拆分视图。

或者，用户可以通过“查看追踪日志”按钮过滤到仅与特定追踪相关的其他日志行。

虽然以上内容大大简化了日志和追踪的查询，但用户仍然需要查询时间序列数据并构建仪表板！如前所述，这可以通过为 Query Type 选择 TimeSeries 或 Table 来支持，从而呈现适当的构建器。

TimeSeries 构建器提供了一个简单的构建器，旨在按时间聚合数据。用户可以选择“简单”模式，该模式执行按时间顺序直接检索行以进行呈现，或者执行按时间聚合，从而允许使用 ClickHouse 的任何分析函数计算指标。在这两种情况下，都必须指定一个时间字段，该字段默认为第一个检测到的时间字段。可以在任一模式下指定一个系列列，这将导致自动呈现多行。下面我们展示了 2020 年至 2023 年伦敦北部英国平均房价。

如果您不查询时间序列、日志或追踪，则可以将表格构建器视为第一个“逃生舱口”。通常，这意味着您希望绘制条形图、表格或单个指标。下面我们再次使用房价数据来显示英国前 10 个邮政编码作为条形仪表。

请记住，如果以上方法都不起作用……或者，像我们一样，您只是喜欢 SQL！最后，所有这些新功能都可以组装为 Grafana 仪表板中的面板。

可观测性用户会注意到，以上内容遗漏了用例的一个重要组成部分：指标。正如我们在博客文章中讨论的那样，指标是基于 SQL 的可观测性的 3 个支柱中最不成熟的。主要原因是 ClickHouse 缺少 Prometheus 摄取接口和使用 PromQL（例如 rate ...）进行查询的方式……目前是这样 :) 任何针对此支柱的构建器都感觉像是为正确解决问题提供了劣质的解决方案。敬请期待更新！

我们看到了未来几个月增强插件的许多其他机会。日志的实时尾部跟踪是我们知道许多用户需要实时诊断问题的功能。此外，我们对 AI 服务集成到插件中的潜力感到兴奋。基于我们在云控制台中 AI 驱动的 SQL 查询建议方面取得的成功，我们现在正在探索将相同功能集成到插件中的可能性，目的是允许用户使用自然语言查询其日志和追踪。

我们应该强调，当前的插件处于 Beta 阶段。这主要是为了收集有关更改意义重大的反馈。作为我们的用户和社区，您的声音很重要，我们希望听到这些更改是否有意义以及您还希望看到什么。

在这篇文章中，我们探讨了新的 ClickHouse Grafana 插件如何将可观测性置于其新设计理念的最前沿，以及这如何极大地简化了日志和追踪的查询，同时保留了查询其他数据类型（如时间序列）的灵活性。