数据库巡检体系搭建实战：指标设计与Prometheus落地

📌 今日关键词：数据库巡检、Prometheus、Grafana、告警阈值、故障预测、运维体系

大家好，我是数据库小学妹 👋

有段时间，我天天在救火。一个月里，凌晨3点被电话叫醒了4次。磁盘满了两次，连接爆了一次，还有一次主从断了我不知道，第二天才发现。

白天也不消停。开发找我说查询慢，运维找我说要重启。我每天到工位第一件事，是看有没有新的告警邮件。

后来实在受不了，花了两周搭了一套巡检体系。现在问题发生前就能收到告警，终于不用半夜被电话吵醒了。

今天把这套方案整理出来。

为什么需要巡检

我一开始觉得，有告警就行了。结果告警只在问题爆发时响，响的时候已经晚了。

数据库问题大多是慢慢积累的。表空间涨、慢查询多、复制延迟变大，这些事情一点点发生。等你察觉的时候，业务已经受影响了。

巡检就是在问题发生前收到预警，提前处理。

巡检指标设计

我一开始以为关注慢查询就够了。后来连接爆了一次，磁盘满了一次，才发现这两件事跟慢查询一点关系都没有。

巡检指标要从五个维度来看。

连接相关：看当前连接数和活跃连接数。连接数超过最大值的80%就该告警。活跃连接长期高，说明有慢查询或者锁等待。

查询相关：看慢查询数量和QPS。慢查询突然变多，说明有性能问题。全表扫描比例高的话，索引设计可能有问题。

锁相关：看锁等待数量和死锁次数。有锁等待说明有并发冲突，锁等待时间长会影响业务响应。

复制相关：看主从延迟和复制状态。延迟超过几秒就要关注，复制断了要立即处理。

存储相关：看表空间使用率和碎片率。表空间超过80%就该告警，碎片太多影响查询性能。

Prometheus + mysqld_exporter 实战

方案选的Prometheus + Grafana。mysqld_exporter采集指标，Prometheus存储和告警，Grafana做展示。

我第一次装mysqld_exporter的时候，踩了个坑。下载的是最新版，结果跟服务器上的MySQL 5.7不兼容，采集直接报错。后来换了v0.15.0才搞定。

安装步骤：

# 下载（注意版本兼容性）
wget https://github.com/prometheus/mysqld_exporter/releases/download/v0.15.0/mysqld_exporter-0.15.0.linux-amd64.tar.gz

# 解压
tar xvf mysqld_exporter-0.15.0.linux-amd64.tar.gz

# 配置数据库连接
export DATA_SOURCE_NAME="exporter:password@(localhost:3306)/"

# 启动
./mysqld_exporter

mysqld_exporter默认采集的指标已经很全了。连接数、查询数、锁等待、复制延迟都有。需要自定义的话可以加.my.cnf配置。

Prometheus配置抓取目标：

scrape_configs:
  - job_name: 'mysql'
    static_configs:
      - targets: ['localhost:9104']

告警阈值怎么设

这部分我走过弯路。

一开始我把阈值设得很紧，连接数超过50%就告警。结果三天收到200多条通知，我直接麻木了。真出问题的时候，告警淹在里面根本没看到。

后来调整策略，分两层设。

静态阈值是硬指标，超过就必须告警。连接数超过最大值的80%，表空间超过80%，主从延迟超过10秒，慢查询每分钟超过100个。

动态基线是和过去7天同时段对比。QPS突增突降超过50%告警，响应时间突增超过100%告警。动态基线能捕捉业务异常，比如某个时段突然有大量请求。

有些数据库自带诊断工具，比如金仓的KDDM可以基于性能快照自动分析瓶颈，还能给出优化建议。如果你们用的是这类数据库，不妨先看看它自带的监控能力，可能比自己搭Prometheus省不少事。

Grafana 巡检看板

看板我设计了三个视图，每个对应一个使用场景。

日常巡检视图：连接数、QPS、慢查询趋势、主从延迟、复制状态、表空间使用率。每天早上到工位扫一眼，心里有数。

故障排查视图：锁等待详情、慢查询TOP10、等待事件分布。出问题的时候用这个视图定位，比一条条跑SQL快多了。

容量规划视图：表空间增长趋势、连接数增长趋势、QPS变化趋势。用来做容量预估，提前跟领导申请扩容资源。

故障预测

巡检做得好，真的能预测故障。

说个真实案例。有天我看容量规划视图，发现表空间每周涨10%。当时心想"应该还好吧"，随手算了一下——两个月后磁盘就满了。幸亏多看了一眼，提前把半年前的日志表归档清理掉。

还有一次更险。连接数每天高峰期都在涨，我以为是业务增长的正常现象。后来画了条趋势线，月底就会碰到max_connections上限。赶紧调整连接池配置，优化了长连接释放。

主从延迟那个案例，排查过程不太顺利。延迟从0.5秒涨到2秒，我一开始以为是主库写入太快。查了半天发现是从库磁盘IO扛不住，加了块SSD才解决。

避坑清单

告警别设太紧，分级很重要。 我刚搭完的时候，所有告警都走同一个通道，全发到钉钉群。结果群里一天几十条告警，大家直接屏蔽了。后来改成严重问题打电话，一般问题发消息，才恢复正常。巡检频率也是，太频繁浪费资源，太稀疏发现不了问题。我现在是每5分钟采集一次，每天汇总一次报告。

看板别搞太多，三个视图足够。 我见过有团队搞了十几个看板，结果谁都不看。日常巡检、故障排查、容量规划，该有的都有了。

告警通道别只配一个。 这是我最惨的一次教训。我把告警发到公司邮箱，有次出差三天没看邮件。回来发现从库复制断了两天没人知道。现在告警分两个通道：邮件留底，IM群实时推送，严重的直接打电话。

趋势判断

巡检体系不会一直停在Prometheus + Grafana这个阶段。

我觉得接下来有两个方向值得关注。

一个是智能基线。现在动态基线还是我手动调的规则，未来应该能用机器学习自动学习业务模式。比如周末和工作日的QPS曲线不一样，系统自己就能识别出来。

另一个是自动修复。告警之后自动执行一些操作——连接满了自动杀空闲查询，磁盘快满了自动清理临时文件。简单场景已经有了，复杂场景还在摸索。

AIOps概念很大，说的是把日志、指标、变更记录关联分析。现阶段落地的不多，但方向是对的。目前国产数据库中，金仓已经在做"的卢"运维智能体，能自动发现异常、自动分析并触发告警，故障预警准确率据说能到98%以上。这个方向挺值得跟进的。

你们的巡检是怎么做的？有没有踩过什么坑？评论区聊聊 👇

我是数据库小学妹，咱们下篇见 👋