如何做好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/