4. 监控体系设计
ClickHouse 作为市场数据监控的存储与分析底座，其监控体系不能只盯着“服务是否存活”。市场数据场景具有写入吞吐高、查询模式多变、数据时效敏感、容量增长快等特点，监控体系必须同时覆盖资源层、数据库层、业务层和容量层。本节围绕指标分类、采集频率、告警阈值和可视化方案四个维度，给出一套可落地的设计方法。
一、核心原理：四层指标分类模型
监控指标如果混在一起采集和告警，会导致噪声大、定位慢。建议按“资源—数据库—业务—容量”四层分类，每层关注不同的对象和判断逻辑。
- 资源层：CPU、内存、磁盘 IO、网络带宽、文件句柄、磁盘使用率。关注点是“机器是否成为瓶颈”。
- 数据库层：查询 QPS、写入行数/秒、Merge 队列长度、Part 数量、副本延迟、ZooKeeper/Keeper 会话状态、连接数。关注点是“ClickHouse 内部是否健康”。
- 业务层：行情快照写入延迟、K 线聚合任务完成时间、行情查询 P95/P99 延迟、数据缺口数量、乱序数据比例。关注点是“市场数据是否完整、及时、可查”。
- 容量层：单表日增数据量、压缩后磁盘占用、分区数量、TTL 剩余天数、未来 30 天预测容量。关注点是“还能撑多久”。
二、采集频率：按指标变化速度分层
采集频率不是越高越好。频率过高会增加 ClickHouse 自身和采集器的负担，频率过低会漏掉尖峰。建议按指标变化速度分三档：
| 频率 | 适用指标 | 采集方式 | 保留周期 |
|---|---|---|---|
| 10 秒 | CPU、内存、查询 QPS、写入行数、Merge 队列、副本延迟 | Prometheus + clickhouse-exporter | 15 天 |
| 1 分钟 | Part 数量、分区数量、磁盘使用率、连接数、Keeper 延迟 | Prometheus 或定时 SQL 采集 | 90 天 |
| 1 小时 / 1 天 | 日增数据量、压缩率、TTL 剩余天数、容量预测、数据缺口统计 | 物化视图或离线任务写入监控表 | 1 年以上 |
对于市场数据业务，写入延迟和数据缺口建议采用 10 秒级采集，因为行情中断几分钟就可能造成不可逆的数据缺失。而容量类指标变化慢，1 小时或 1 天采集一次即可。
三、告警阈值：静态基线 + 动态偏离
阈值设计最容易犯的错误是“拍脑袋定一个固定值”。市场数据有明显的高峰和低谷，固定阈值在开盘时段频繁误报，在收盘时段又过于宽松。推荐组合策略：
- 静态硬阈值：用于绝对红线，如磁盘使用率 > 85%、副本延迟 > 300 秒、Keeper 无主 > 60 秒。这类指标一旦触发必须立即处理。
- 动态基线：对查询 QPS、写入行数等周期性指标，用过去 7 天同时段均值 ± 3 倍标准差作为正常区间，偏离则告警。
- 趋势预测：对容量类指标，用线性回归预测未来 30 天磁盘占用，若预测值超过 80% 则提前告警。
- 业务 SLO 阈值：行情查询 P99 < 500ms、K 线聚合任务在开盘前 30 分钟完成、数据缺口为 0。这类阈值直接对应业务承诺。
四、可视化方案：从总览到下钻
可视化不是把 Grafana 面板堆满，而是按“总览—分层—单实例—单表”四级下钻设计。总览看红绿灯，分层看趋势，单实例看资源，单表看分区和 Part。市场数据场景建议至少包含以下面板：
- 行情写入总览：写入行数/秒、写入延迟 P99、乱序比例、缺口数量。
- 查询健康度：QPS、P95/P99 延迟、慢查询 Top 10、失败查询数。
- ClickHouse 内部状态：Merge 队列、Part 数量、副本延迟、Keeper 延迟。
- 容量趋势：日增数据量、压缩后占用、TTL 剩余天数、30 天预测曲线。
下面是一段用于采集“单表日增数据量与分区占用”的 SQL 示例，可写入监控表后由 Grafana 读取：
SELECT
table,
partition,
sum(rows) AS rows,
formatReadableSize(sum(bytes_on_disk)) AS disk_size,
max(modification_time) AS last_modify
FROM system.parts
WHERE active = 1
AND database = 'market_data'
GROUP BY table, partition
ORDER BY table, partition;该查询按表和分区聚合，能快速发现某个分区异常膨胀或长时间未更新。配合定时任务写入监控表后，即可在 Grafana 中绘制分区增长曲线。
五、案例与误区复盘
案例：某行情平台开盘后查询变慢。监控面板显示业务层查询 P99 从 200ms 升到 1.8s。按四层下钻：数据库层发现 Merge 队列从 3 涨到 47，Part 数量在 10 分钟内翻倍；资源层发现磁盘 IO util 达到 95%。根因是行情写入突增导致小 Part 过多，Merge 跟不上。处理方式是临时调大 max_insert_block_size 并增加后台 Merge 线程，同时将写入批次从 1 秒改为 3 秒。复盘结论：业务层告警必须能一键下钻到数据库层和资源层，否则定位时间会从 5 分钟拉长到 30 分钟。
常见误区：
- 只监控 ClickHouse 进程存活，不监控业务数据完整性，导致“服务正常但行情缺了 10 分钟”无人发现。
- 所有指标都用 10 秒采集，监控表自身膨胀过快，反而拖慢 ClickHouse。
- 告警阈值写死，开盘高峰频繁误报，团队逐渐关闭告警，真正故障时无人响应。
- 可视化面板只做总览，没有单表和分区下钻，容量问题无法提前发现。