如何做好 Clickhouse 集群的监控覆盖？

前言

常言道，兵马未至，粮草先行。在 clickhouse 上生产环境之前，我们就得制定好相关的监控方案，包括指标采集、报警策略、图形化监控大盘。有了全面有效的监控，我们就仿佛拥有了千里眼顺风耳，对于线上任何风吹草动都能做到及时感知，在必要的情况下提前介入以避免线上故障。

clickhouse 监控采集方案

业界做法

业界常用的监控方案一般是基于 clickhouse-exporter(node-exporter) + prometheus + grafana 组成的监控方案。

以上为监控方案示意图，其中各组件负责功能如下

• clickhouse-server 中有 4 个系统表会记录进程内部的指标，分别是 system.metrics，system.asynchronous_metrics, system.events，system.parts 配置文件默认开启

• clickhuse-exporter 是一个用于采集 clickhouse 指标的开源组件(https://github.com/ClickHouse/clickhouse_exporter)，它会定时查询 clickhouse-server 中的系统表，转化成监控指标，并通过 HTTP 接口暴露给 prometheus.由统一采集中心替代

• node-exporter 是一个用于采集硬件和操作系统相关指标的开源组件(https://github.com/prometheus/node_exporter)。由 zabbix 监控替代

• prometheus 定时抓取 clickhouse-exporter 暴露的指标，并判断报警条件是否被触发，是则推送到 alert manager 由自研监控系统替代

hubble 监控 clickhouse 采集方案设计

如下图，利用采集中心采集 clickhouse 系统指标，就可以实现将 clickhouse-server 端监控接入 hubble 现有监控系统，后续如果需要监控其他集群，添加采集即可

clickhouse 监控指标详细说明

1 server 端

概况说明

server 端指的是 clickhouse 所在集群，监控包括 server 所在的机器情况和 server 本身的运行情况，机器情况目前通过 zabbix 就可以实现监控和报警，而 server 本身的运行情况目前是通过 granfana 直连查询 server 端的系统日志表实现的监控。目前是通过采集中心进行指标采集上报并接入 hubble 监控系统

指标列表

• 核心指标

• 分布式表、zk 相关指标

• server 运行状态指标（用于问题排查分析定位）

一些用于问题排查的指标和工具

• 查询来源以及查询热点排查：下图用于排查突增的查询请求的数据 source 和请求来源 IP，便于问题定位

• 慢查询、大查询情况：下面是按 source 统计出的慢查询和大查询情况，以及正在执行的慢查询语句情况，方便问题排查

• 一些有助于排查问题的查询 sql：

列出正在执行的慢查询

各数据库扫描行数大于 1 亿的查询数量

各数据库大于 3s 的查询数量

各数据库查询次数及来源 ip

各数据库磁盘占用大小及压缩比

• 集群机器大盘页（cpu、内存、io、磁盘容量等信息）(zabbix)

存活监控

• 通过 HTTP API 监视服务器可用性。将 HTTP GET 请求发送到/ping。如果服务器可用，它将以 200 OK 响应。

• 对于复制表集群，还需额外监控副本是否：请求/replicas_status，如果副本可用，并且不延迟在其他副本之后，则返回 200 OK。如果副本滞后，请求将返回 503 HTTP_SERVICE_UNAVAILABLE，包括滞后信息

2 client 端（包括操作 clickhouse 进行查询和写入的模块）

概况说明

这一部分主要是我们将 client 端与 clickhouse 端的交互情况进行埋点上报，配置相关大盘页，并对相关指标配置报警策略实现的。

核心指标监控大盘

写情况：

• 各集群写次数，写耗时，写失败数，内存队列堆积情况，kafka 堆积情况，失败回跑数量

读情况：

• hubble 各模块查询请求数、失败数、平均耗时、p99 耗时

后续 TODO

• 探活检测的同时实现节点故障的自动切换和恢复

参考文章

• clickhouse 集群监控：https://zhuanlan.zhihu.com/p/353594919
  

• 官方监控建议：https://clickhouse.tech/docs/en/operations/monitoring/