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

最新推荐文章于 2024-04-13 09:56:45 发布

ClickHouseDB

最新推荐文章于 2024-04-13 09:56:45 发布

阅读量954

点赞数 16

分类专栏：产品文章标签：数据库

本文链接：https://blog.csdn.net/ClickHouseDB/article/details/136597523

版权

产品专栏收录该内容

8 篇文章 2 订阅

订阅专栏

本文字数：3396；估计阅读时间：9 分钟

作者：Clickhouse team

审校：庄晓东（魏庄）

本文在公众号【ClickHouseInc】首发

自2022年5月Grafana的ClickHouse插件首次发布以来，两种技术都有了长足的发展。在最近的一篇博文中，我们描述了实时OLAP存储的成熟度，与开源标准化如何使SQL应用于可观测性用例成为可能。使用户能够通过ClickHouse探索和可视化可观测性数据。我们深知使用SQL进行可观测性的挑战之一是：学习和使用SQL，因此我们继续投资于ClickHouse插件以协助解决这个问题。

版本4的发布看到了用户交互的新哲学，其中日志和跟踪成为新查询构建器体验中的重要组成部分。我们相信这将最小化SRE编写SQL查询的需求，并简化基于SQL的可观测性，推动这种新兴范式向前迈进。

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

将OpenTelemetry作为一等公民

早期版本的ClickHouse Grafana插件试图提供一个数据不可知的体验，允许用户在任何数据类型上构建可视化。虽然这种功能在版本4中得以保留，但用户会发现体验更加直观，并专注于为可观测性数据集（Grafana的主要用例）提供流畅的体验。

当插件首次安装，并且用户需要配置数据源时，这种变化将显而易见。除了能够配置默认数据库（现在还包括表），用户还可以为其日志和/或跟踪数据指定配置。简单地说，这意味着仅需指定日志和/或跟踪数据的默认数据库和表。但是，您还可以指定您的数据符合OTel规范（以及您使用的特定版本）。如果您对默认的OTel模式进行了更改，或者更喜欢使用自己的格式，则可以覆盖列名称。

这里的日志配置非常简单 - 需要一个时间、日志级别和消息列，以便日志可以在后面的查询中得到良好的呈现，我们稍后会看到。

跟踪配置稍微复杂一些。这里需要的列是为了使后续的查询能够构建完整的跟踪概要。这些查询假定数据的结构与OTel类似，因此严重偏离标准模式的用户需要使用视图才能从此功能中受益。

简化的体验

早期版本的插件旨在帮助用户构建SQL查询，不考虑正在查询的数据类型。这要求用户指定他们是否想要构建选择行、执行聚合或执行时间序列分析的查询。通过“显示为”选项，控制查询构建器选项本身，以帮助用户避免为目标查询类型输入SQL，这个选择在初始版本中被称为“显示为”选项，混淆了使用。后来的迭代通过“格式”选项对此进行了分离。虽然这使用户可以构建查询类型，并根据需要呈现它，例如将时间序列呈现为表格，但这最终仍然令人困惑。用户最终会回到SQL编辑器，可以在那里手动输入查询。

version 3

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

version 4

查询追踪

Grafana提供了查询和呈现追踪的丰富功能。这需要目标存储根据其id重构整个追踪，以及其组成的跨度。在ClickHouse SQL中，这必然会导致复杂的查询，用户历来会通过参数化视图来隐藏这些查询。然而，整体体验仍然不尽如人意，用户需要通过SQL编辑器查询视图。

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

请注意，以上内容包括了进入追踪并检索相关日志的能力。后者是提供统一可观测性体验的基础，用户可以轻松地在不同数据类型之间进行导航。

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

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

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

查询日志

日志查询构建器主要设计用于与Grafana的探索视图一起使用，用户可以列出日志事件并进行钻取。假设您正在使用OTel，现在查询日志数据不应需要更多操作，只需为您的查询类型选择日志，调整时间段，然后点击运行查询即可。

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

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

与追踪类似，在调试问题时，日志并不是孤立消费的，用户还对生成日志行的请求相关的追踪感兴趣。现在，任何从日志中提取的追踪都作为可点击的链接显示出来。这将导致与先前搜索追踪并单击追踪id时演示的相同分割视图。

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

其他数据类型

尽管以上明显简化了日志和追踪的查询，用户仍需要能够查询时间序列数据并构建仪表板！正如前面提到的，这是通过选择查询类型为TimeSeries或Table来支持的，这将呈现适当的构建器。

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

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

记住，如果以上任何方式都不起作用，您始终可以使用经典的SQL！最后，所有这些新功能都可以作为Grafana仪表板中的面板组装起来。

展望未来

注意到上述内容忽略了用例的一个重要组成部分：指标。如我们的博客文章所述，指标是基于SQL的可观测性的三个支柱中最不成熟的一个。主要是因为ClickHouse缺乏Prometheus摄入接口和使用PromQL进行查询的手段，比如rate...。目前:)，对于此支柱的任何构建器都感觉像是：提供了一个次优的解决方案来正确解决问题。敬请关注更新！

在接下来的几个月里，我们看到了提升插件的许多其他机会。实时日志跟踪是一个，我们知道许多用户需要实时诊断问题的功能。此外，我们对将AI服务整合到插件中的潜力感到兴奋。借鉴我们在Cloud控制台中使用AI驱动的SQL查询辅助所取得的成功，我们现在正在探索将相同功能整合到插件中的可能性，目的是允许用户使用自然语言查询其日志和追踪。

我们应该强调：当前插件处于Beta版。这主要是为了收集反馈，考虑到这个变化的重要性。作为我们的用户和社区，您的声音很重要，我们希望听到这些变化是否合理，以及您还希望看到什么其他内容。

结论

在本文中，我们探讨了新版ClickHouse Grafana插件如何将可观测性置于其新的设计理念的核心位置，并如何大大简化了日志和追踪的查询，同时保留了查询其他数据类型，如时间序列的灵活性。

征稿启示

面向社区长期正文，文章内容包括但不限于关于 ClickHouse 的技术研究、项目实践和创新做法等。建议行文风格干货输出&图文并茂。质量合格的文章将会发布在本公众号，优秀者也有机会推荐到 ClickHouse 官网。请将文章稿件的 WORD 版本发邮件至：Tracy.Wang@clickhouse.com