Prometheus+Grafana搭建MySQL监控体系：从指标采集到告警实战

1. 为什么选择PrometheusGrafana来盯MySQL1.1 生产环境里MySQL监控到底缺什么先聊一个很现实的问题你手上的MySQL实例真的被“监控”了吗很多团队最开始的监控方式就是看几眼命令行状态、翻翻慢日志或者跑到服务器上敲一句show processlist发现不对劲再临时处理。这种事后救火的方式在面对业务高峰、连接数暴涨、慢查询堆积的时候根本来不及反应。我曾经接手过一个项目MySQL在凌晨2点突然出现大量锁等待业务侧延迟直接拉满。等早上大家上班看到告警业务已经受了影响。事后复盘发现其实监控数据早就有前兆Threads_running持续升高、InnoDB行锁等待时间涨了好几倍只是当时没有一个统一的监控平台把这些指标串起来。这就是引入PrometheusGrafana的核心价值把散落在MySQL各个状态变量里的指标变成一套自动化采集、可视化展示、规则告警的体系。Prometheus负责拉取和存储指标Grafana负责把指标画成图、配上告警规则mysqld_exporter则是连接MySQL和Prometheus之间的桥梁。三者配合基本可以覆盖一个MySQL实例从“活着”到“运行状态健康”的全部观测需求。1.2 整套监控链路的关键流转先建立整体认知数据链路是这样的MySQL实例对外暴露性能状态变量mysqld_exporter用专门的监控账号登录MySQL周期性执行查询把指标抓出来以HTTP接口按Prometheus格式暴露Prometheus通过配置的scrape_interval定期从这个HTTP接口拉取数据经过relabel处理后存入本地时序数据库Grafana作为展示层通过PromQL查询Prometheus中的数据渲染成面板和图表同时根据Alerting规则触发告警通知。这条链路里每个环节都有自己的分工不是简单堆三个组件就能完事。我见过很多部署失败的案例往往是因为某个环节没打通exporter能启动但连不上MySQL、Prometheus能拉到数据但Grafana里的查询结果全是NaN、告警规则写错导致一晚上收到几百条垃圾通知。这些问题后面会逐个拆解。1.3 核心监控指标的分类与优先级在动手搭建之前先明确“要监控什么”否则把几百个指标全展示出来只会让人眼花缭乱。按我的实践经验MySQL监控指标可以分成四层可用性层实例是否活着、端口是否可连接、主从复制是否正常。这一层最重要挂了就是事故。资源层连接数、线程数、CPU/内存/磁盘IO、网络流量。这层反映数据库的压力状况。性能层QPS/TPS、慢查询数量、缓冲池命中率、锁等待时长。这层反映SQL执行质量和引擎内部状态。业务层特定业务表的行数变化、特定查询的响应时间。这层和具体业务强相关需要二次定制。搭建监控系统的顺序也建议按这个优先级来先保证可用性和资源层能看到、能告警再逐步深入性能层最后按需做业务层的定制面板。一上来就想把几百个指标都接上反而容易忽略最核心的存活监控。2. 监控环境从零搭建实操2.1 Prometheus服务端部署与基础配置Prometheus的部署方式我建议用二进制或者容器看团队习惯。对于学习和中小规模场景直接用官方二进制包最省心没有容器环境也能跑。下载地址在Prometheus官网选择一个稳定版本比如长期支持版解压后目录结构是这样的prometheus-2.x.x.linux-amd64/ ├── prometheus ├── promtool ├── console_libraries/ ├── consoles/ └── prometheus.ymlprometheus.yml是核心配置文件下面是一个最基础的配置示例global: scrape_interval: 15s evaluation_interval: 15s external_labels: cluster: mysql-prod scrape_configs: - job_name: mysql static_configs: - targets: [localhost:9104]配置里有两个关键参数需要解释一下。scrape_interval表示Prometheus多久从exporter拉一次数据默认是15秒。对于MySQL监控来说15秒够用不需要调到5秒甚至1秒那样只会增加MySQL和exporter的负担还容易触发大量慢查询记录。evaluation_interval表示Prometheus多久评估一次告警规则同样设15秒即可。启动Prometheus很简单加一个--config.file参数指定配置文件路径就行./prometheus --config.fileprometheus.yml启动之后访问http://服务器IP:9090可以看到Prometheus自带的Web界面能查指标、看靶标状态。靶标页面Targets页是最先要检查的地方如果mysqld_exporter没有启动这里会直接显示Down排查起来很直观。提示Prometheus自身没有用户名密码认证生产环境使用务必用防火墙或反向代理限制9090端口访问范围否则监控数据等于裸奔。2.2 创建专用监控账号不占业务账号配额在部署mysqld_exporter之前先在MySQL里创建一个专用的监控账号。为什么要单开账号两个原因一是安全最小化原则监控账号只需要拉取状态数据不应该具备写权限二是区分连接来源出了问题能定位哪些请求来自监控系统。创建账号的SQL如下CREATE USER IF NOT EXISTS exporter192.168.1.% IDENTIFIED BY 这里写一个强密码; ALTER USER exporter192.168.1.% IDENTIFIED WITH mysql_native_password BY 这里写一个强密码; GRANT SELECT, REPROCESS, SHOW DATABASES, SHOW VIEW, PROCESS ON *.* TO exporter192.168.1.%; GRANT SELECT ON performance_schema.* TO exporter192.168.1.%; FLUSH PRIVILEGES;权限这块有个细节PROCESS权限是必须的因为mysqld_exporter采集连接数、线程状态的时候需要读取SHOW PROCESSLIST和SHOW ENGINE相关状态信息performance_schema的权限用于采集InnoDB相关的更细粒度指标。MySQL 8.0及以上版本的默认认证插件是caching_sha2_password而老版本的mysqld_exporter连接时可能不兼容所以上面第二句保险起见把认证协议切到了mysql_native_password。如果你用的是较新的exporter版本也可以不切换但根据我踩过的坑切一下最稳。2.3 mysqld_exporter采集端详细配置mysqld_exporter推荐直接下载官方编译好的二进制包解压后最关键的是配置数据库连接信息。可以通过环境变量或配置文件传入我习惯用配置文件的形式方便管理cat .my.cnf EOF [client] userexporter password你的强密码 host127.0.0.1 port3306 socket/var/run/mysqld/mysqld.sock EOF启动命令./mysqld_exporter \ --config.my-cnf.my.cnf \ --web.listen-address:9104 \ --collect.engine_innodb_status \ --collect.performance_schema.events_statements_summary_by_digest启动参数里--collect.engine_innodb_status和--collect.performance_schema.events_statements_summary_by_digest这两个比较关键。前者采集InnoDB引擎的详细状态比如缓冲池命中率、锁信息都要靠它后者采集SQL语句级别的执行统计用于定位慢查询和高频SQL。默认情况下这两个采集器不一定打开不加参数可能导致面板里部分图表没有数据。启动后先手动访问一下http://localhost:9104/metrics能看到一大段# HELP开头的数据就说明采集正常。继续用curl手动验证一下是否能拉到MySQL相关的指标curl -s http://localhost:9104/metrics | grep mysql_upmysql_up这个指标返回1表示exporter和MySQL之间连接正常返回0则说明连接有问题这个指标在后面的告警规则里也会作为MySQL可用性的核心判断依据。2.4 Grafana数据源接入Grafana的部署相对无脑二进制解压后直接启动默认监听3000端口浏览器打开http://服务器IP:3000进入初始化页面默认账号密码都是admin首次登录会强制要求修改。登录之后第一步要做的不是创建仪表盘而是先把Prometheus数据源加上。路径是左侧齿轮图标Configuration→ Data Sources → Add data source → 选择Prometheus。在配置页面里只需要填两处URL填Prometheus服务的地址比如http://localhost:9090如果Grafana和Prometheus不在同一台机器就填Prometheus所在服务器的IP。Scrape interval建议填15s这个值要和你Prometheus配置文件里的scrape_interval保持一致否则图表显示时间可能偏短或偏长。数据源保存之后先到Explore页面试着查询一下输入mysql_up如果能出结果说明链路从MySQL到Grafana已经全通了。至此基础设施已经就绪接下来就是核心的部分怎么读懂指标、怎么写告警规则、怎么建出真正有用而不是好看的面板。3. 核心指标解读与PromQL告警规则实战3.1 几个必须盯死的核心指标很多人把监控面板做得花里胡哨图表一大堆但真出了事还是两眼一抹黑。核心原因是没有抓住“关键指标”。我按照排障时最常用的顺序挑了几个必看的指标连接数。MySQL允许的最大连接数由max_connections控制一旦连接数打满新连接会直接报Too many connections错误这个错误对业务来说是致命的。看连接数不能只看绝对值要结合max_connections看使用率mysql_global_status_threads_connected / mysql_global_variables_max_connections * 100这条PromQL表达式返回的是连接使用率百分比建议设一个告警阈值超过80%就警告超过90%就意味着随时可能打满属于严重级别。慢查询。慢查询是SQL性能问题的直接体现关注指标是mysql_global_status_slow_queries。这个指标是累计值Prometheus在存储时会把它按时间保存所以可以直接看它的速率rate(mysql_global_status_slow_queries[5m])表示最近5分钟内每秒新增的慢查询数量。如果这个值突然从趋近于0变成持续上升一定要立刻去看慢日志通常意味着有SQL没走索引、或者锁等待导致执行时间拉长。InnoDB缓冲池命中率。数据在内存里的读取速度比磁盘快几个数量级缓冲池命中率越高说明磁盘IO压力越小。计算方式(sum(rate(mysql_global_status_innodb_buffer_pool_read_requests[5m])) - sum(rate(mysql_global_status_innodb_buffer_pool_reads[5m]))) / sum(rate(mysql_global_status_innodb_buffer_pool_read_requests[5m]))这条看起来复杂拆开看其实就两步把读请求总量减去实际落到磁盘的读次数得到命中的次数再除以总请求量就是命中率。正常应该在99%以上如果这个数字持续低于95%要么是缓冲池太小要么是查询里大量使用全表扫描把冷数据带进了内存。主从复制延迟。对于有主从架构的数据库mysql_slave_status_seconds_behind_master这个指标直接反映从库和主库的延迟秒数。需要注意如果是多级复制这个指标反映的是当前从库和它的上一级之间的延迟而不是和最终主库的延迟。延迟持续增长会导致从库查询结果陈旧对读写分离架构影响很大。线程运行数。mysql_global_status_threads_running表示当前正在执行的线程数。它和已连接数threads_connected不同前者是“正在干活”的线程后者是“连上了但可能空闲”的连接。Threads_running如果长期大于几十甚至上百说明数据库正在高负载运转要结合慢查询和锁等待一起看。3.2 PromQL语法速览够用为主PromQL看起来复杂但监控MySQL用到的语法其实就那几样。我总结成五类够用就行直接查询mysql_up返回指标当前值。raterate(counter[5m])算计数器指标在5分钟内的平均速率用于QPS、慢查询数这类累计值。数学运算a / b * 100两个指标做除法、乘法比如连接数使用率、命中率。比较运算mysql_up 0返回结果为布尔值用在告警规则里。聚合运算sum() by (instance)按标签聚合多台实例的数据。监控多台MySQL时用这个可以看集群总QPS、每台实例的各自状态。先记这五种绝大多数场景够用。更复杂的语法可以在实际查询中边查边学。3.3 告警规则编写与告警渠道告警规则放在Prometheus的配置里独立成一个文件管理比较规范。在prometheus.yml里加一行rule_files配置指定规则文件路径rule_files: - rules/mysql.yml然后在主目录下创建rules/mysql.yml写具体的告警规则groups: - name: mysql_alerts rules: - alert: MySQLInstanceDown expr: mysql_up 0 for: 1m labels: severity: critical annotations: summary: MySQL 实例 {{ $labels.instance }} 无法访问 description: Prometheus 无法从 mysqld_exporter 采集数据请检查实例存活状态。 - alert: MySQLTooManyConnections expr: mysql_global_status_threads_connected / mysql_global_variables_max_connections * 100 85 for: 5m labels: severity: warning annotations: summary: MySQL 连接数使用率超过 85% description: 当前使用率{{ $value }}%请检查应用连接池设置或慢查询占用的连接数。这里有一个容易忽视的for参数它表示条件持续多久才触发告警。设为1m或5m能有效过滤瞬时抖动。我见过有人把for设为0结果只要指标突破阈值1秒钟就告警一晚上全是噪音。合理设置for能过滤大量无意义告警。告警规则写好后重载Prometheus配置kill -HUP $(pgrep prometheus)或者通过promtool check rules先检查规则文件的语法./promtool check rules rules/mysql.ymlpromtool是Prometheus自带的规则校验工具强烈建议每次改完规则先跑一遍再reload不然一个语法错误可能导致整组规则失效。告警通知方面Prometheus自身的Alertmanager组件负责把告警分发到邮件、企业微信、钉钉、Slack等渠道。Alertmanager的配置核心是路由我贴一个简化版的邮件通知配置global: smtp_smarthost: smtp.example.com:465 smtp_from: alertexample.com smtp_auth_username: alertexample.com smtp_auth_password: 邮箱授权码 route: group_by: [alertname] group_wait: 30s group_interval: 5m repeat_interval: 4h receiver: email receivers: - name: email email_configs: - to: opsexample.com send_resolved: true每个参数都有意义。group_by表示相同告警名的多条信息合并成一条group_wait是积攒告警的时间窗口repeat_interval是同一告警重复通知的间隔设为4小时防止刷屏send_resolved设为true告警恢复后也会收到通知闭环比较完整。4. Grafana可视化面板搭建实战4.1 快速上手导入社区面板再微调Grafana生态里最省力的一种方式是直接导入现成的面板。进入Grafana官网的Dashboards页面搜索“MySQL”能找到一个非常经典的Percona MySQL Overview面板导入它的ID即可用左侧Dashboards → Import → 输入面板ID → 选择Prometheus数据源 → Import。导入后会看到一组包含连接数、QPS、缓冲池、主从复制、InnoDB状态的面板基本覆盖了大部分监控需求。这里要特别提醒社区面板依赖的指标名和你当前mysqld_exporter版本采集的指标名可能不一致。导入后如果某个图表出现No Data先检查该图表绑定的PromQL指标是否存在于你的环境中不要盲目怀疑采集链路坏了。以Percona面板为例它默认绑定的很多指标是Percona分支的mysqld_exporter特有的官方版的mysqld_exporter可能没有。解决办法是在面板设置里逐个编辑图表把PromQL里的指标名调整为官方版本对应的指标名或者切换mysqld_exporter到Percona版本。两种方式我都试过切换exporter更省事但对已有的采集体系改动比较大前期建议直接用官方exporter加自建面板。4.2 从零自建关键面板的思路如果你不想依赖社区面板或者社区面板的指标兼容性让你头疼完全可以自建。核心就是一个思路每个面板只回答一个运维问题。举个例子“MySQL是否还活着”这个面板就放一张表列出所有实例的mysql_up值1是绿色0是红色一眼就能扫出来。“连接数是否要打满了”这个面板就放一个时间序列图加一条85%的参考线mysql_global_status_threads_connected / mysql_global_variables_max_connections * 100在Grafana图表面板的Thresholds部分把85设为黄色预警线95设为红色告警线图表上就能直接看到当前值在哪个区间。“慢查询压力”面板用rate(mysql_global_status_slow_queries[5m])配合上一张InnoDB锁等待、线程运行数的图组成一个“SQL性能”区域。这几张图放在同一个Dashboard的同一行出了问题看这一行就够。面板的排版左边栏放可用性和连接数中间放QPS和慢查询右边放缓冲池和主从复制从上到下按“可用性 → 资源 → 性能 → 业务”排序。这个布局不是随便排的符合正常排障路径先确认实例活着再看连接数和压力再定位慢查询。5. 常见问题与实践避坑5.1 采集不到数据的排查清单监控栈搭完后最常遇到的就是“Grafana面板空白”。按下面这个顺序排查八成能解决第一步检查mysqld_exporter本身。访问http://exporter_IP:9104/metrics如果页面打不开或返回5xxexporter进程肯定有问题看日志。第二步检查Prometheus靶标页。打开Prometheus的Targets页面找到mysql_export的job状态是UP还是Down。Down的话检查Prometheus到exporter的端口是否通可以用telnet测一下。第三步检查数据源配置。Grafana的数据源URL要能从Grafana所在服务器访问到Prometheus。很多时候Grafana和Prometheus在不同网段网络策略没放行就会看到图表报“Bad Gateway”。第四步检查PromQL指标名。在Grafana的Explore页面输入mysql_up直接查询。没结果说明采集没成功有结果但面板空白说明面板里写的指标名不对。用Explore页看到底有哪些指标存在再回头改面板。5.2 告警风暴怎么避免刚上线告警规则的那几天告警通知多到让人直接关掉手机。原因一般有几种规则阈值设得太敏感。比如连接数使用率超过60%就告警正常业务高峰期很容易到70%以上根本不算异常。合理做法是观察一周基线数据取平时正常运行的最高值再留一点余量。for参数没设置就上线。瞬时峰值很容易触发告警但持续几秒钟就恢复了。加了for: 5m就能过滤这些抖动。同一类告警重复轰炸。这个靠Alertmanager里的repeat_interval解决同一告警在指定时间间隔内不会重复发送。我一般设4小时晚上出问题能叫醒人又不至于5分钟一条一直轰炸。还有一种是exporter自身指标不干净导致误报。比如mysql_up指标偶尔因为网络抖动掉到0持续1分钟触发“实例挂了”的严重告警但实际上MySQL活得好好的。这种情况可以把for加到2分钟或者给exporter的探活单独做一个长时间窗口的聚合判断。5.3 监控系统自身的运维经验Prometheus默认数据保留时间是15天这是官方推荐的平衡点。想要更长的历史数据就得配置远端存储比如对象存储或时序集群。如果只是本地小规模用建议至少在磁盘上留够空间按每小时约50MB的存储估算具体取决于指标数量留个100GB以上比较安心。mysqld_exporter的采集本身也会消耗MySQL资源。它每次采集要执行大量SHOW类查询和读取performance_schema在极高负载的数据库上默认15秒的采集间隔可能会增加额外压力。如果发现监控本身在拖累数据库可以把采集间隔调到30秒甚至60秒或者关掉一些非核心的采集器。还有时间同步这茬。监控系统里所有组件的时间必须同步否则你看到的时间轴是歪的告警时间也对不上。所有服务器统一配置NTP服务这是老生常谈但真的很重要。因为Prometheus在判断for时长和Alertmanager在分组时都需要依赖时间戳的一致性。最后分享一个我在实际项目中反复用到的经验监控体系建设完之后一定要做一次“故障演练”——手动停掉exporter、拔掉网络、或者制造一次连接数暴增看看告警链路是否真的能串起来。很多团队以为配好了就万事大吉结果第一次真正的故障来临时告警根本没收到原因就是某个环节的权限过期、端口策略变化等。把监控系统本身纳入日常巡检范围比任何复杂的告警规则都重要。