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 的高压缩率和闪电般的检索速度。

Logs 查询构建器主要设计用于 Grafana 的 Explore 视图，用户可以在其中列出日志事件并执行深入分析。假设您使用的是 OTel，现在查询日志数据只需要在“查询类型”中选择“Logs”，调整时间段并点击“运行查询”。

如您所见，我们现在还获得了一个直方图，显示了日志级别随时间的变化。由于现在在模式中拥有了有关级别和时间字段的必要信息，因此我们可以自动发出必要的 GROUP BY 查询来为该可视化提供支持。

用户可以选择将过滤器应用于这些结果，修改排序顺序或限制结果数量。所有这些都无需编写 SQL。对于那些想要深入挖掘的人来说，可以通过经典编辑器查看 SQL 查询以进行编辑。

与跟踪类似，在调试问题时不会孤立地使用日志，用户会对与生成日志行的请求相关的跟踪感兴趣。现在支持从日志中提取的任何跟踪，并以可点击的链接的形式公开。这将导致与之前在搜索跟踪并点击跟踪 ID 时相同的拆分视图。

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

虽然以上内容极大地简化了日志和跟踪的查询，但用户仍然需要能够查询时间序列数据并构建仪表板！如上所述，可以通过为“查询类型”选择“TimeSeries”或“Table”来支持此功能，这将呈现相应的构建器。

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

Table 构建器可以被视为第一个“逃生舱”，如果您没有查询时间序列、日志或跟踪。通常这意味着您正在寻找绘制条形图、表格或单个指标。下面我们再次使用房价数据来显示英国排名前 10 位的邮政编码作为条形图。

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

可观察性用户会注意到，上述内容省略了用例中一个重要的组成部分：指标。正如我们在博客文章中所述，指标是基于 SQL 的可观察性三个支柱中最不成熟的一个。主要原因是 ClickHouse 缺少 Prometheus 的摄取接口，并且无法使用诸如 rate…之类的函数以 PromQL 进行查询…暂时如此 :) 针对此支柱的任何构建器都感觉会提供一个不如正确解决问题的解决方案。敬请关注更新！

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

我们应该强调，当前插件处于测试阶段。这主要是为了收集反馈，因为变化很大。作为我们的用户和社区，您的声音很重要，我们想听听这些变化是否合理，以及您还想看到什么。

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