构建查询洞察UI

我们最近发布了查询洞察的初始实现，它为 ClickHouse Cloud 用户提供了一种现成的查看和解释查询日志的方法。此功能适用于所有 ClickHouse Cloud 用户，本文将讨论它的作用以及我们的构建方式。

ClickHouse 实例中的 system.query_log 表包含有价值的数据，可以帮助用户了解以下内容：

• 查询性能和异常；
• 错误和相关启发式方法（异常代码、消息、设置、概要事件等）；以及
• 时间序列查询指标（随时间推移的读写吞吐量、量和延迟）

但是，收集这些信息会带来一个问题——system.query_log 目前包含 70 多个字段（完整列表此处），并且每个查询都会生成两个或多个记录。因此，解释查询日志数据可能很困难，尤其是对于不太熟悉 ClickHouse 的用户来说。

为了说明这一点，让我们看一下 CLI 中简单select * from system.query_log 的输出

ClickHouse Cloud 中的 SQL 控制台略微改进了这一点（至少从视觉上看），但除非您已经确切地知道要查找的信息，否则体验仍然不是很直观

添加更多复杂性，每个 ClickHouse Cloud 服务至少包含两个副本，每个副本都有自己的副本特定版本的查询日志，这意味着仅仅运行select * from system.query_log 只能返回分配给此查询的副本的结果。因此，每次 ClickHouse Cloud 用户（或更广泛地说，任何运行多副本部署的 ClickHouse 用户）想要检查查询日志时，都需要使用clusterAllReplicas() 函数，对于经验不足的用户来说，此函数同样不直观。这让我们得出查询日志 UI 的第一个（也是最明显的）顶级目标

• 目标 #1 — 使查询日志数据更易于理解和访问

如前所述，查询日志是查询优化、调试以及监控整个集群健康状况和性能的关键信息来源。除了简单地提高查询日志数据的可访问性之外，考虑查询日志的用途（以及何时有用）为我们为这项新功能设定的其他顶级目标提供了依据

• 目标 #2 — 公开重要的顶级查询指标
• 目标 #3 — 简化使用查询日志的查询调试和优化工作流程
• 目标 #4 — 从查询日志公开基于上下文的“智能”建议和见解，进一步简化查询调试和优化

在我们开始确定这项功能的工作范围时，我们发现上面提到的前两个目标可以在相当短的时间内完成，并且可以解决我们用户面临的重大摩擦点。另一方面，后两个目标仍然是模糊的，需要额外的研究以及对何时以及如何使用不同的查询日志指标/指标进行更深入的了解。因此，我们决定尽快发布初始版本，以解决目标 #1 和 #2，并为逐步改进目标 #3 和 #4 打下基础。重要的是，未来的迭代工作将以用户反馈为前提。如果您正在阅读本文，请尝试一下我们新的查询洞察 UI 并给我们反馈！

选择服务后，左侧边栏中的监控导航项应展开以显示一个新的“查询洞察”子项。单击此选项会打开新的查询洞察页面

顶部的统计框代表选定时间段内的一些基本的顶级查询指标。在它下方，我们公开了三个时间序列图表，它们表示查询量、延迟和错误率，这些图表按查询类型（select、insert、other）细分，跨越选定的时间窗口。延迟图表可以进一步调整以显示 p50、p90 和 p99 延迟

在顶级指标下方，表格显示选定时间窗口内查询日志条目（按规范化的查询哈希值和用户分组）

最近的查询可以按任何可用字段进行筛选和排序，并且可以配置表格以显示/隐藏其他字段（表格、p90 和 p99 延迟）。

从最近的查询表格中选择一个查询将打开一个弹出窗口，其中包含特定于所选查询的指标和信息

从弹出窗口中可以看出，此特定查询在过去 24 小时内已运行超过 3000 次。'查询信息' 选项卡中的所有指标都是聚合的，但我们也可以通过选择'查询历史记录' 选项卡来查看单个运行的指标

查询洞察是我在 2 月下旬加入 ClickHouse 后有机会参与的第一个真正项目。我花了前几周时间完成一些小型任务和错误修复，以便熟悉代码库和流程，然后被要求开发此功能。这体现了我团队对我的信任和信心，以及我们招聘流程的优势——严格的招聘标准让我们能够知道，被聘用的人员能够胜任他们所承担的工作，并且能够快速上手。

该功能及其应达成的目标已得到相当充分的规范和设计，但细节和实现留给了我。我是在一个 Figma 设计的基础上工作的，该设计显示了一个相当通用的图表以及用于显示不同类型数据（如所有查询、错误和慢速查询）的功能。实现主要包括将查询与可视化代码分离，并提供一些定义明确的接口。这些接口允许传递给查询的数据（例如时间范围以及我们是否查询延迟或错误）发生变化，而不会影响图表渲染代码。

到目前为止在我的职业生涯中，我已经了解到，模拟一个功能和实际运行它完全是两回事，而且我们对软件需求的集体理解会随着时间的推移而发生变化。考虑到这一点，我在开发这个项目时力求让初始草案尽可能地范围狭窄（但仍然可用），然后向各种内部和外部用户演示该功能——这是一种开发 Web 应用程序的相当标准的方法。这使得任何即将发生的更改都非常容易实现。我之前提到了慢速查询；经过一些早期利益相关者的使用后，我们决定慢速查询的想法不太合理，因此我们取消了它，并用 p99、p90 和 p50 延迟代替了它。我们还意识到，单击表格时显示的弹出窗口效果不太好，因此几乎完全重新设计了它。这些都没有什么大不了的，因为它是以预期会发生变化为前提开发的，因此在开发过程中设置了抽象和接口，以使这些更改能够无痛地进行。

此功能现已面向所有现有的 ClickHouse Cloud 用户提供，位于监控 >> 查询洞察下。如果您尚未使用 ClickHouse Cloud，您可以通过注册 30 天试用并获得 300 美元的免费积分来立即尝试此处。