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

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

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

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

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

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

## 为什么需要巡检

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

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

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

## 巡检指标设计

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

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

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

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

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

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

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

## Prometheus + mysqld_exporter 实战

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

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

安装步骤：

```bash
# 下载（注意版本兼容性）
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配置抓取目标：

```yaml
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%以上。这个方向挺值得跟进的。

---

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

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


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

数据库巡检体系搭建：指标设计、告警阈值与故障预测实战

讲述数据库巡检体系的搭建过程，包括巡检指标设计、Prometheus+Grafana实战、告警阈值设置、故障预测，附避坑清单

数据库

运维

人工智能

数据库巡检方案分享：通过Prometheus+Grafana搭建智能监控体系，覆盖连接数、慢查询、主从延迟等5大核心指标，设置动态告警阈值实现故障预测。包含实战安装步骤、看板设计及避坑经验，有效减少80%紧急故障，告别凌晨告警电话。

机器学习

代码解释

服务器

智能体

AIOps

2026上云采购 | AI焕新·智启新局

腾讯云BI特惠9.9元起！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

数据库巡检体系搭建：指标设计、告警阈值与故障预测实战-腾讯云开发者社区-腾讯云

数据库巡检体系搭建：指标设计、告警阈值与故障预测实战

数据库巡检体系搭建：指标设计、告警阈值与故障预测实战

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐