背景
ClickHouse 在我们监控系统中发挥着举足轻重的作用，目前不仅承担着日志的写入，调用链、指标以及前端监控都有广泛的使用。 下面是一个异常查询导致的集群无响应的排查案例。
问题现象
从酷家乐监控系统看板来分析，17:45 cpu、负载均飙高，线程和 tcp 连接数陡增。在 16:03 对集群 重启后恢复正常； 
观察到的异常请求： 这个是测试组周期性地查询我们的日志数据，测试平台会定时查询监控数据做问题分析。从图上看集群异常时，测试组正好在大规模请求。但是这个规模的请求平时也有，应该不是他们导致的。
问题排查
重启前下载了全量 CK 日志 日志中报的基本都是网络问题，发现有耗时很高的查询 
过滤查询异常的日志，这几个耗时的确不正常，这个时刻确实发生在集群无响应的前几分钟： 
查看数据库自带的 system.query_log 表 query 日志
- 根据耗时倒序，前几个查询是 来自 即席查询 的 terms 查询，理论上不会有用户直接在即席查询查询日志监控项。输入了 message 的模糊匹配，在 distinct 当天的 hostgroup。这种查询肯定是有问题的，几乎要读取当天的所有日志数据。
- 同时查询了附近几天是否存在类似的查询，很显然并没有，这几个查询恰好发生在集群无响应之前一两分钟。
问题复现
挑选两个集群中的节点，分别执行上面的 sql 语句。根据观察，指标出现了和周五异常时刻相似的状态：
- CPU 负载飙高，磁盘读取突增，写入下降；
- 因为这个查询，需要大量读取磁盘和并解压，于是cpu飙高，cpu 飙高导致 merge 速度下降，触发磁盘写入效率下降。于是后续的写入和查询会被阻塞。
- 看到这个趋势复现后，我立即手动 kill 掉了这个查询（可以参考：clickhouse.com/docs/en/sql...），防止影响正常数据写入。
解决方案
- 在对外查询中关掉对该数据的直接查询；
- 调整 CK 集群本身处理请求的超时时间，目前配置的100s；
- 在酷家乐监控系统指标统一查询层实现 cancel query 的功能，超时时自动执行 kill 语句；