StarRocks运维实战：构建慢查询与分桶健康度一体化监控看板

1. 为什么我们需要一个“一体化”的监控看板？

大家好，我是老张，在数据平台这行摸爬滚打十多年了，从传统数仓到现在的实时数仓都折腾过。最近几年，StarRocks 成了我们团队处理实时分析查询的绝对主力，性能确实没得说。但性能好的系统，不代表运维起来就省心。不知道你们有没有遇到过这种情况：线上突然有业务方反馈某个报表查询变慢了，以前几秒出结果，现在要等半分钟。

这时候，作为运维或者DBA，你的第一反应是什么？肯定是去查慢查询日志对吧。翻出来一看，确实找到了一条执行时间很长的SQL。你可能会开始分析它的执行计划，看看是不是缺索引、有没有全表扫描。但很多时候，你优化了SQL写法，甚至加了索引，下次查询可能还是慢。问题出在哪？

我踩过好几次坑之后才明白，慢查询往往只是“症状”，数据分布的“健康度”才是那个容易被忽略的“病根”。在StarRocks这类MPP数据库中，数据是以分桶（Tablet）为单位分布式存储和计算的。如果数据在各个分桶里分布严重不均，也就是我们常说的“数据倾斜”，那么即使你的SQL写得再完美，执行计划再优，也会因为某个节点负载过高，拖慢整个查询。这就好比一条高速公路，大部分车道空空如也，但有一条车道堵死了，整体通行速度还是上不去。

所以，单独看慢查询日志，就像医生只看病人发烧，却不去查感染源。而单独看分桶大小，又可能忽略了那些虽然数据分布均匀但SQL本身写得糟糕的查询。把慢查询分析和分桶健康度监控放到同一个看板里，就是为了让我们能一眼看清问题的全貌。在这个看板上，你左边看到的是“哪些SQL跑得慢”，右边看到的是“哪些表的数据长得歪”，两者一结合，定位瓶颈的效率能提升好几倍。接下来，我就手把手带你搭建这么一个实用的运维“驾驶舱”。

2. 搭建监控数据基石：采集慢查询与分桶信息

想把监控做起来，首先得有数据。我们需要从StarRocks里把两类关键信息捞出来：一是所有执行过的SQL的审计日志，二是每个表分桶的详细分布情况。这部分活儿干扎实了，后面的可视化就是水到渠成。

2.1 配置审计日志插件，抓取每一句SQL

StarRocks的审计日志功能非常强大，记录了谁、在什么时候、执行了什么SQL、用了多久、返回了多少行等核心信息。默认可能是关闭的，需要我们动动手开启。官方提供了审计日志插件，部署起来不算复杂。

我一般会这么操作：先去GitHub找到对应版本的插件包，下载到StarRocks的fe/lib目录下。然后修改FE的配置文件fe.conf，关键参数是audit_log_modules和audit_log_dir。我习惯把模块设置为slow_query, query，这样常规查询和慢查询都会记录。存储目录要指向一个磁盘空间充足的地方，因为日志量可能会快速增长。

这里有个我亲身踩过的坑，必须提醒你：一定要关注审计日志的滚动策略和清理机制。早期我没太在意，结果线上业务跑了一阵子，FE节点突然报错“Too many versions”，差点影响服务。后来发现是审计日志写得太频繁，产生了大量小文件。解决办法是调整插件自身的配置，比如调大max_batch_size（比如到80MB）和max_batch_interval_sec（比如到300秒），让日志批量写入，减少文件数。同时，在fe.conf里配好audit_log_roll_num和audit_log_delete_age，让旧日志自动清理。

配置完成后重启FE节点，审计日志就开始工作了。这些日志是文本格式的，为了方便用SQL分析，我们通常会用另一个小工具或脚本，定期把这些日志文件通过stream_load方式，导入到StarRocks内部的一个专用表里。这个表的结构基本和日志内容对齐，包含timestamp、user、db、queryTime、returnRows