网站搭建 主机推荐,北京好用的h5建站,深圳网站建设总部,哪些网站有友情链接本文字数#xff1a;2631#xff1b;估计阅读时间#xff1a;7 分钟 作者#xff1a;Bucky Schwarz 本文在公众号【ClickHouseInc】首发 我们最近发布了 Query Insights 的初步实现#xff0c;为 ClickHouse Cloud 用户提供了一种便捷的方法来查看和解释查询日志。该功能对… 本文字数2631估计阅读时间7 分钟 作者Bucky Schwarz 本文在公众号【ClickHouseInc】首发 我们最近发布了 Query Insights 的初步实现为 ClickHouse Cloud 用户提供了一种便捷的方法来查看和解释查询日志。该功能对所有 ClickHouse Cloud 用户开放本篇文章将讨论其功能和构建过程。 为什么要构建查询日志 UI
ClickHouse 实例中的 system.query_log 表包含大量有价值的数据可以帮助用户了解 查询性能和异常 错误及其相关信息异常代码、消息、设置、配置文件事件等 以及 时间序列查询指标读取/写入吞吐量、数据量和延迟的变化。
然而收集这些信息也带来了挑战——system.query_log 目前包含超过 70 个字段完整列表请见此处https://clickhouse.com/docs/en/operations/system-tables/query_log并且每个查询会生成两个或更多记录。因此解释查询日志数据可能会很困难特别是对于不太熟悉 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 并给我们反馈 查询洞察 V1
选择服务后左侧边栏的监控导航项会展开显示一个新的“查询洞察”子项。点击此选项将打开新的查询洞察页面 顶级指标
页面顶部的统计框显示了所选时间段内的一些基本查询指标。下面展示了三个时间序列图分别代表查询量、延迟和错误率这些图按查询类型选择、插入、其他在所选时间窗口内分解显示。延迟图可以进一步调整以显示 p50、p90 和 p99 延迟 最近的查询
在顶级指标下方有一个表格显示了所选时间窗口内按标准化查询哈希和用户分组的查询日志条目 最近的查询可以按任何可用字段进行过滤和排序表格也可以配置以显示或隐藏附加字段如表格、p90 和 p99 延迟。
查询详情
在最近的查询表格中选择一个查询会打开一个包含该查询特定指标和信息的侧边栏 从侧边栏可以看到这个特定查询在过去 24 小时内已运行超过 3000 次。“查询信息”选项卡显示的是汇总指标但我们也可以通过选择“查询历史”选项卡查看单次运行的指标 幕后揭秘
查询洞察是我在二月底加入 ClickHouse 后参与的第一个重要项目。在开始这个功能开发之前我花了几周时间做一些小任务和修复错误以熟悉代码库和工作流程。这反映了团队对我的信任和信心以及我们招聘流程的高标准——高标准的招聘让我们确信被录用的人有能力完成工作并能迅速上手。
这个功能的目标和设计已经相当明确但细节和实施由我负责。我从一个 Figma 设计开始该设计展示了一个通用的图表和显示不同类型数据如所有查询、错误和慢查询的功能。实现过程中主要是将查询逻辑与可视化代码分离并定义了清晰的接口。这些接口允许我们在不影响图表渲染代码的情况下更改传递给查询的数据例如时间范围以及查询的是延迟还是错误。
在我的职业生涯中我已经学到功能的草拟与实际运行是两回事并且我们对软件需求的理解会随着时间而变化。因此我在接手这个项目时尝试让初始版本范围尽可能狭窄但仍可用然后将功能展示给各种内部和外部用户——这是开发 Web 应用程序的标准方法。这样任何未来的更改都可以相对容易地实施。我前面提到的慢查询经过早期用户使用后我们认为其概念不太合理于是取消了它并用 p99、p90 和 p50 延迟替代。我们还意识到点击表格时显示的侧边栏效果不好因此几乎完全重新设计了它。这些都不是大问题因为我们在开发时预见到了可能的更改并设置了相应的抽象和接口以便轻松实现这些更改。 征稿启示 面向社区长期正文文章内容包括但不限于关于 ClickHouse 的技术研究、项目实践和创新做法等。建议行文风格干货输出图文并茂。质量合格的文章将会发布在本公众号优秀者也有机会推荐到 ClickHouse 官网。请将文章稿件的 WORD 版本发邮件至Tracy.Wangclickhouse.com 联系我们 手机号13910395701 邮箱Tracy.Wangclickhouse.com 满足您所有的在线分析列式数据库管理需求
