1. 为什么DB监控告警总是做不好做数据库监控这些年我见过太多团队在告警配置上栽跟头。明明用了Prometheus、Zabbix这些专业工具告警规则也设了可总是陷入两种极端要么频繁误报把运维人员折腾成狼来了的放羊娃要么关键故障时安静如鸡直到业务崩盘。上周又有个朋友吐槽他们MySQL主从延迟告警设了3秒阈值结果每天收上百条报警真正需要处理的不到5%。1.1 监控数据的三重失真数据库指标采集本身就有三个天然陷阱采样失真Prometheus默认15秒抓取一次瞬时尖峰可能被漏检。有次OOM故障就发生在两次采集间隙聚合失真avg()函数会平滑掉突发流量我后来改用histogram_quantile(0.95, rate(...[5m]))才捕捉到真实峰值单位失真同样1%的CPU使用率在2核和32核机器上根本不是同等级问题经验关键指标必须配置多时间窗口检测。比如CPU既要看1分钟均值也要配5分钟峰值告警1.2 告警规则的七宗罪这些是我在真实事故后整理的典型反模式绝对值陷阱设置连接数1000报警却不区分8核和32核的机器静态阈值双11期间还沿用日常流量阈值单点检测只监控主库忽略从库延迟无状态判断不区分首次触发和持续异常告警风暴一个磁盘满触发几十条关联告警无分级处理把OOM和慢查询都设为P0无收敛设计重复告警不停轰炸2. 专业级DB监控体系搭建2.1 指标采集的黄金组合经过多次迭代我现在固定用这套组合拳# Prometheus配置示例 scrape_configs: - job_name: mysql static_configs: - targets: [10.0.0.1:9104] metrics_path: /metrics params: collect[]: - engine_innodb - global_status - info_schema.processlist必须包含的四类核心指标资源层CPU/Memory/Disk/IOWait连接层Threads_connected/Threads_running查询层Slow_queries/Select_scan复制层Seconds_behind_master2.2 动态阈值算法实践对于波动大的指标我开发了这套自适应算法# 基于历史数据的动态阈值计算 def calculate_threshold(metric_name): history_data get_7days_history(metric_name) weekday datetime.now().weekday() hour datetime.now().hour # 取同时间段历史值的P95作为基线 baseline np.percentile( [x.value for x in history_data if x.weekday weekday and x.hour hour], 95 ) return baseline * 1.5 # 允许50%浮动空间2.3 告警路由的智能分级这是我们的告警路由矩阵指标类型检测频率持续时间告警级别接收组主库不可用10s1次P0DBA研发总监从库延迟30s30s持续3次P1DBA组慢查询突增200%1m同比上周P2值班人员连接数使用率80%5m环比昨日P3自动工单3. 避坑指南血泪换来的经验3.1 必须配置的五个冷门指标Innodb_row_lock_time_avg500ms预示严重锁竞争Handler_commit比率突然下降可能是事务提交异常Binlog_cache_disk_use频繁落盘影响TPSSelect_full_join没有索引的暴力扫描Table_open_cache_misses表缓存命中率低下3.2 告警疲劳破解方案我们团队通过这三步降低无效告警70%告警压缩相同主机相同告警10分钟内不重复发送值班日历非工作时间只发短信不打电话自动恢复检测触发告警后自动执行简易检查脚本3.3 可视化仪表盘配置这是Grafana中最有用的三个面板数据库健康度雷达图六个维度综合评分查询性能热力图按时间段显示慢查询分布资源预测趋势图基于时序预测磁盘耗尽时间-- 预测磁盘空间耗尽时间的PromQL predict_linear(mysql_global_status_innodb_data_fs_free_bytes[7d], 3600*24*3)4. 真实故障排查实录去年处理过的一个典型案例某电商凌晨订单失败率飙升但所有监控指标都显示正常。最终发现是应用连接池设置了testOnBorrow导致高频执行SELECT 1监控漏掉了COM_PING计数网络闪断导致连接池疯狂重建现在的监控方案增加了每个实例的每秒新建连接数连接池活跃数/空闲数比值网络往返延迟百分位监控关键点数据库监控不能只看数据库本身要关联上下游指标最后分享我的监控配置检查清单[ ] 是否覆盖了所有实例类型主/从/代理[ ] 是否有动态阈值机制[ ] 是否设置合理的告警静默期[ ] 是否定期测试告警通道[ ] 是否建立告警根本原因知识库这套体系上线后我们的有效告警识别率从23%提升到了89%夜间告警量减少了82%。最核心的心得是监控不是技术活而是对业务理解的深度考验。比如同样看到CPU飙升知道大促预案的DBA和只会看监控的新手做出的反应完全不同。