ClickHouse Grafana Plugin：我们的未来愿景，告别 SQL 痛点！

原创于 2026-06-30 09:08:06 发布 · 26 阅读

1 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#java #数据库 #运维

软件工程专栏收录该内容

176 篇文章

订阅专栏

本文字数：5729；估计阅读时间：15 分钟

作者：Alex Fedotyev

TL;DR;

我们认为 ClickHouse 和 Grafana 的结合是 ClickHouse 可观测性 (observability) 体验的核心组成部分。在本文中，我们将探讨我们对该插件的投入，以及我们使其功能更强大、使用更便捷的愿景。

ClickHouse 已成为日益增长的各项可观测性 (observability) 和实时分析 (real-time analytics) 部署的核心驱动力。各团队之所以选择它，是因为它能高效处理数十亿日志行、数百万追踪数据以及大规模时序数据，同时保持成本效益和卓越的查询性能。

我们允许用户自由选择如何使用其可观测性数据，而 Grafana 和 ClickStack 正是两个强有力的选项。ClickStack 侧重于提供丰富的探索体验，非常适合寻求原生 ClickHouse 界面的团队。Grafana 则能自然地融入现有生态系统。工程师们对其了然于心，组织也已广泛部署，它尤其擅长将来自多个来源的数据汇集于单一视图。无论是出于熟悉度、标准化要求，还是整合多源信号的需求，这种搭配在可观测性及分析用例中都广受欢迎。

随着越来越多的团队将 ClickHouse 与 Grafana 用于可观测性和分析工作，其采用率一直很高，并持续增长。

与此同时，我们也认识到当前的用户体验可能存在挑战，特别是当插件需要用户编写 SQL 语句时。在 ClickStack 中，大部分复杂性已被抽象处理，使得用户无需深入了解数据模式 (schema) 即可更轻松地探索数据。我们从这些经验中获益良多，现在的目标是将这些宝贵经验融入 Grafana 插件，使其比以往任何时候都更易于上手，并确保每位用户都能从第一天起就高效开展工作。

我们的愿景已经明确，旨在让插件比以往任何时候都更易于使用，以下是其具体实践可能呈现的面貌。

> 这些想法反映了我们目前正在探索和进行原型开发 (prototyping) 的内容，而非已确定或已承诺的路线图 (roadmap)。其中大部分工作虽已通过测试，但我们仍处于实验阶段，并积极征集反馈。这应被视为我们对插件未来发展方向的前瞻性展望，而非最终计划。

真正的原生 Grafana 体验

Grafana 为其插件提供了一系列丰富的内置功能，包括点击过滤、属性集合、日志量直方图，以及支持智能变量和注释的仪表板。

然而，这些功能只有当插件声明支持时，才能被激活并供最终用户使用。

当前，ClickStack plugin 尚未完全公开所有可用功能。因此，我们的首要任务是着手梳理并实现所有相关的接口，以便 ClickHouse plugin 能够提供真正一流、深度集成的 Grafana 体验。

那么，这在实际操作中意味着什么呢？

从日志详情中即时过滤

在事件调查中，当你查看一条日志时，可能会看到 ServiceName: payment-gateway。此时，你无需手动导航至查询构建器来添加过滤器，只需点击该字段旁边的“+”图标即可。操作完成后，查询会立即更新，数据将针对该服务进行过滤。同样，点击“-”则会排除该服务数据集。你还可以在日志正文中选择文本，然后点击“行包含过滤”，即可添加一个全文搜索。

这样一来，用户无需与用户界面（UI）“搏斗”，便能无缝地对数据进行切片和过滤，从而加速事件调查。

结构化属性显示

OpenTelemetry (OTel) 日志和 traces 都能携带超过 40 个字段，涵盖资源、日志、Span 和 Scope 属性。然而，目前它们都以一个扁平列表的形式呈现。我们正在探索引入更清晰的视觉分离方式，将属性按类别分组，以更好地反映 OTel 数据的结构。这样做的目标是让字段更易于定位，从而避免用户无休止地滚动查找，能够快速找到所需信息。

SQL 模式下的自动日志量直方图

日志量直方图目前已在查询构建器模式中提供，今后也将支持原始 SQL 查询。当配置了 OTel 列时，即使插件无法解析你的自定义 SQL，它也能自动按严重性生成日志量细分。用户无需在日志搜索的同时编写单独的聚合查询。

更智能的仪表盘变量

目前，变量编辑器仍需要通过编写原始 SQL 来填充仪表盘下拉菜单，这意味着用户必须提前了解确切的数据库、表和列名。我们的目标是引入一个引导式编辑器来改进这一体验，该编辑器将自动为用户生成 SQL 语句。

选择变量类型以动态生成查询。可选择列出数据库、表、列，或获取某一列的不同值。此外，也可以使用预定义的 OpenTelemetry (OTel) 预设，例如服务名称或日志级别。级联下拉菜单允许您无需记忆模式即可从数据库导航到特定列。选择特定列后，系统会检索其所有不同值作为变量选项，从而完成从数据库到表、列再到值的整个工作流程，无需编写任何 SQL 语句。

注解——从您的 OpenTelemetry (OTel) 数据中获取部署和 Kubernetes (K8s) 事件

Grafana 注解在时间序列面板上显示为垂直标记——这对于将变化与显示关键绩效指标 (KPI) 趋势的图表进行关联非常有用。目前，大多数团队通过持续集成/持续部署 (CI/CD) webhook 或手动应用程序编程接口 (API) 调用来设置这些注解，并从辅助数据库填充独立事件。

OpenTelemetry (OTel) 数据则使得这一切不再必需。您的跟踪 (traces) 和日志 (logs) 中已包含 ResourceAttributes['service.version'] 和 ResourceAttributes['container.image.tag'] 等信息。通过 SQL 注解查询，可以检测这些值的变化，从而将部署和回滚作为标记自动呈现在您的仪表板上，这些信息均直接来源于您的服务所发出的数据。无需任何外部集成。

同样，由 OTel 采集器摄取的 Kubernetes 事件（例如 pod 重启、内存不足 (OOM) 终止、扩缩容事件）本身就是带有时间戳的离散事件。只需通过简单的 WHERE 过滤器，即可将它们直接映射为注解。

我们正在探索在编辑器中引入注解预设的选项——用户只需选择“变更检测”或“Kubernetes (K8s) 生命周期事件”，即可获得可用的查询，无需编写 SQL 语句。对于属性变更检测，该插件可以自动处理差异：用户只需编写一个简单的 SELECT 查询以查看服务版本随时间的变化，而只有实际的版本切换才会转化为注解标记。自定义 SQL 注解功能将一如既往地正常工作。

跨数据源的过滤器保留

目前，在 Explore 中切换数据源常常会导致您丢失当前的工作上下文。那些耗时构建的过滤器、条件和精细化设置不得不从头重新创建，这不仅会拖慢问题排查的速度，还会打断您的工作流程。

理想情况下，我们希望在切换时保留上下文，以便过滤器能够自动继承，让您无需重新构建查询即可继续分析，从而使跨数据源的探索更快、更少中断。

这些功能本身并非开创性创新，它们只是用户所期望的标准行为。而这正是关键所在：用户体验应该让人感到熟悉，无需额外的学习曲线。

优先搜索，按需使用 SQL

当前的查询构建器旨在提供最大灵活性，支持任何数据库、表、列和查询类型。对于通用的 SQL 数据源而言，这确实是合适的默认设置，但它也带来了弊端。即使是执行搜索日志等简单任务，用户每次打开 Explore 时，都被迫了解或反复重新探索数据模式。

为了简化操作，我们正在尝试一种从搜索栏开始的精简查询模式。类似于 ClickStack，这种模式允许用户自然地搜索日志，无需编写 SQL，从而使初始体验更加直观，并消除了预先理解底层模式的需求。

我们当前的新搜索行为原型。

选择数据源后，将呈现一个精简的新编辑器，其中包含一个搜索栏和筛选条件标签。只需输入搜索词并按回车键即可。在底层，它将利用 ClickHouse 的 hasToken() 函数，该函数已针对索引列上的全文搜索进行优化，能够在数秒内搜索数十亿条日志。分面将以紧凑的列表形式出现，支持对列名、运算符和值进行自动完成搜索。

需要自定义排序或限制？只需点击齿轮图标。

需要查看生成的 SQL？展开预览即可。

需要完全控制？“Edit as SQL”功能将把您带入原始编辑器，并预填充当前查询。

核心理念很简单：让常见操作路径保持简单直观，同时确保更高级的工作流程触手可及。没有任何功能被隐藏，它们只是在您需要时才呈现。

基于这一理念，即使是当前在 Explore 中选择和使用数据源，也引入了不必要的繁琐。尽管一个数据源可能同时支持日志和追踪，用户仍需要在查询时明确指定其正在处理的数据类型。然而，在大多数情况下，用户搜索的都是相同类型的数据。这额外增加了一个重复步骤，减缓了探索效率。

为了简化这一过程，我们正计划推出单表数据源模式。为包含日志的表配置数据源后，在 Explore 中，您将直接进入日志搜索界面，无需模式选择器或表格选择器。只需打开 Explore，选择数据源，即可开始搜索和分析。

开箱即用仪表盘

目前，如果您部署带有 ClickHouse exporter 的 OpenTelemetry Collector，数据将存储在 ClickHouse 中，但您仍需在 Grafana 中从零开始构建仪表盘。为简化用户上手体验，我们计划为 OpenTelemetry 和 Kubernetes 可观测性场景提供开箱即用仪表盘，这些仪表盘应能与标准 schema 无缝协作。

首批仪表盘应覆盖核心可观测性工作流程：一个日志仪表盘，按严重级别显示日志量并按服务进行细分；一个 Trace 仪表盘，提供持续时间分布、服务依赖映射、基于服务的 RED 指标（请求率、错误率、持续时间）以及对顶级 Span (Span) 的可见性。这些仪表盘还将展示变量和注释 (Annotation) 的使用方法。

我们的目标是让部署 ClickHouse 以实现可观测性的团队，能够将数据摄取到可用的仪表盘，整个过程只需几分钟而非数小时。用户在配置数据源时，只需简单导入所需的仪表盘即可。

无需原始 SQL 的指标探索

ClickHouse OpenTelemetry exporter 已支持从 OTel 代理和 Kubernetes 采集 CPU 使用率、内存、网络 I/O 等指标，以及其他基础设施相关信号。

然而，目前面临的挑战是，在 Grafana 中以可视化方式探索这些数据通常需要手动编写 SQL 聚合查询语句，这并非用户对指标原生数据源所期待的使用体验。

ClickStack 提供了原生的查询构建器，使用户不必编写复杂的 SQL 查询。我们希望将同样的体验引入 Grafana。这个精简的指标构建器将允许用户选择表类型、选择指标、选择聚合方式，并添加分组维度 (group-by dimensions)。对于 ResourceAttributes 等 OTel Map 列，选择后可能会打开一个键选择器 (key picker)，允许用户深入查看 k8s.namespace.name 或 host.name 等字段，而无需编写括号表示法 (bracket notation)。

这样做的目的是，让您的基础设施和运行时指标能够像在任何以指标为中心的工具中一样轻松探索，同时无需维护一个独立的系统来查询它们。

展望未来

以上是我们计划在短期内实现的改进。更进一步，我们还在探索以下几个领域：

双向 SQL 解析

目前，查询构建器会生成 SQL，但这一过程是单向的。如果您编辑了 SQL，就无法在保留这些更改的同时切换回构建器。这揭示了一个更深层次的限制：系统无法真正理解查询本身。

通过引入一个完善的 SQL 解析器并构建完整的抽象语法树 (AST)，我们可以突破这一限制。您可以从运行手册中粘贴一个查询，让它自动转换为筛选条件 (filter pills) 和容量直方图 (volume histograms)，并在构建器和编辑器之间自由切换且不丢失任何改动，因为查询在两个方向上都得到了充分的理解。

用户查询身份识别

目前，每个 Grafana 查询都以数据源中配置的 ClickHouse 用户身份运行。这导致难以实施细粒度访问控制 (fine-grained access control)，通常迫使团队为每个项目或团队设置独立的数据源，并在此层面管理访问权限。这种方式很快就变得难以扩展和治理。

通过 JWT (JSON Web Token) 转发，每个查询都将携带 Grafana 用户的身份。这将实现完善的审计追踪 (audit trails)、按用户查询成本追踪，以及基于实际查询执行者的行级访问控制 (row-level access control)，从而使访问权限和可见性与真实用户情境 (user context) 对齐，而非依赖共享凭证。

AI 辅助查询构建

大语言模型 (LLM) 在编写 ClickHouse SQL 方面表现出色，ClickHouse 也提供了工具来帮助它们理解您的数据模型 (schema)。我们正在探索一种对话式模式，在这种模式下，用户可以描述想要查看的内容，并获得一个可用的查询，该查询会结合您的表、列和数据模型的完整上下文来生成。