今日关键词数据库巡检、Prometheus、Grafana、告警阈值、故障预测、运维体系大家好我是数据库小学妹 有段时间我天天在救火。一个月里凌晨3点被电话叫醒了4次。磁盘满了两次连接爆了一次还有一次主从断了我不知道第二天才发现。白天也不消停。开发找我说查询慢运维找我说要重启。我每天到工位第一件事是看有没有新的告警邮件。后来实在受不了花了两周搭了一套巡检体系。现在问题发生前就能收到告警终于不用半夜被电话吵醒了。今天把这套方案整理出来。为什么需要巡检我一开始觉得有告警就行了。结果告警只在问题爆发时响响的时候已经晚了。数据库问题大多是慢慢积累的。表空间涨、慢查询多、复制延迟变大这些事情一点点发生。等你察觉的时候业务已经受影响了。巡检就是在问题发生前收到预警提前处理。巡检指标设计我一开始以为关注慢查询就够了。后来连接爆了一次磁盘满了一次才发现这两件事跟慢查询一点关系都没有。巡检指标要从五个维度来看。连接相关看当前连接数和活跃连接数。连接数超过最大值的80%就该告警。活跃连接长期高说明有慢查询或者锁等待。查询相关看慢查询数量和QPS。慢查询突然变多说明有性能问题。全表扫描比例高的话索引设计可能有问题。锁相关看锁等待数量和死锁次数。有锁等待说明有并发冲突锁等待时间长会影响业务响应。复制相关看主从延迟和复制状态。延迟超过几秒就要关注复制断了要立即处理。存储相关看表空间使用率和碎片率。表空间超过80%就该告警碎片太多影响查询性能。Prometheus mysqld_exporter 实战方案选的Prometheus Grafana。mysqld_exporter采集指标Prometheus存储和告警Grafana做展示。我第一次装mysqld_exporter的时候踩了个坑。下载的是最新版结果跟服务器上的MySQL 5.7不兼容采集直接报错。后来换了v0.15.0才搞定。安装步骤# 下载注意版本兼容性wgethttps://github.com/prometheus/mysqld_exporter/releases/download/v0.15.0/mysqld_exporter-0.15.0.linux-amd64.tar.gz# 解压tarxvf mysqld_exporter-0.15.0.linux-amd64.tar.gz# 配置数据库连接exportDATA_SOURCE_NAMEexporter:password(localhost:3306)/# 启动./mysqld_exportermysqld_exporter默认采集的指标已经很全了。连接数、查询数、锁等待、复制延迟都有。需要自定义的话可以加.my.cnf配置。Prometheus配置抓取目标scrape_configs:-job_name:mysqlstatic_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%以上。这个方向挺值得跟进的。你们的巡检是怎么做的有没有踩过什么坑评论区聊聊 我是数据库小学妹咱们下篇见