简介面向运维与云计算工程师的一套普罗米修斯Prometheus监控MySQL详细文档系统梳理了从环境准备到报警通知的完整链路。内容首先讲解如何在Linux环境下的MySQL中创建专用监控账号并授予SELECT、PROCESS、SUPER等必要权限随后介绍mysql_exporter二进制包的下载、解压、.my.cnf连接配置以及通过systemd实现服务托管与开机自启再说明Prometheus添加监控目标的两种方式即静态配置和服务发现并针对容器场景给出Docker服务发现的接入说明最后讲解Alertmanager处理告警的配置方法。所有步骤均基于实际实验环境编写包含具体命令、参数和验证方法有助于读者快速部署一套可用的MySQL监控系统。资源为单个Word文档压缩包大小约6MB已有1275人学习使用。对于需要掌握Prometheus监控数据库的运维和云计算人员是一份性价比很高的参考资料。1. Prometheus监控MySQL从一条慢查询到告警通知中间隔着三层配置很多团队把Prometheus监控MySQL当成“装个exporter就完事”的活实际落地时才发现采集起来了看板上的指标读不懂、告警要么不响要么天天误报。这套方案的本质是三条链路的协作——mysqld_exporter把MySQL的status变量和performance_schema数据转成Prometheus指标格式Prometheus负责定时拉取、存储并计算告警规则最后由看板工具和告警通道把状态可视化、把异常推出去。适合正在选型或者已经装了但没跑通的运维和开发阅读。下文按数据链路、部署步骤、告警规则、避坑细节的顺序展开每个命令都标注参数含义和常见误区照着走完一遍至少能把基础监控、告警和排查路径完整搭起来。2. 先理解数据链路mysqld_exporter的采集原理与指标口径很多人配置时直接照抄网上的命令一遇到指标对不上就懵了。这一章先把链路拆开讲清楚数据从哪里来、指标名怎么读、类型为什么重要。搞懂这三件事后面配置告警和排查问题才有依据。2.1 为什么是mysqld_exporter而不是自研脚本或其它采集器Prometheus采用主动拉取模型监控目标必须暴露一个符合文本格式的/metrics HTTP端点。mysqld_exporter就是为MySQL准备这个端点的标准组件。它周期性连接MySQL执行一组预设查询把结果转换成带标签的指标再以Prometheus认识的文本格式暴露出去。自研脚本的问题在于指标类型要自己维护counter还是gauge直接决定告警表达式怎么写标签体系要自己设计采集失败要自己处理重试和超时Prometheus重启后还要考虑指标是否出现断层。mysqld_exporter把这些都封装好了而且使用官方维护的驱动实现连接协议和数据类型转换上省掉很多麻烦。另一个常见选型是pushgateway加定时脚本。这个组合临时补救可以长期会有致命问题目标挂了Prometheus仍然能从pushgateway读到旧数据mysql_up不会变成0存活性告警形同虚设。拉取模式下exporter停止响应后Prometheus会自动标记target为DOWN数据链路才完整。这也是我在选型时坚持用exporter直连的原因。要不要上更重型的数据库管理平台小规模实例或单一业务集群没必要额外的基础设施维护成本比监控本身还高。mysqld_exporter加Prometheus两个组件就能覆盖绝大多数MySQL集群的监控需求。2.2 指标从哪里来状态变量、系统表与命名规则mysqld_exporter的数据来源分两路。第一路是SHOW GLOBAL STATUS和SHOW GLOBAL VARIABLES负责全局运行状态和配置参数比如当前连接数、最大连接数、运行时长、慢查询累计计数。第二路是information_schema和performance_schema里的表提供更细粒度的进程列表、表锁、语句统计和InnoDB状态。指标命名上有明显区分mysql_global_status_开头的来自状态变量mysql_global_variables_开头的来自配置变量mysql_info_schema_和mysql_perf_schema_开头的来自对应的系统表。看到指标名就能反推数据源排查问题时路径清楚很多。collector数据来源典型指标所需权限全局状态默认SHOW GLOBAL STATUSmysql_global_status_threads_connectedSELECT全局变量默认SHOW GLOBAL VARIABLESmysql_global_variables_max_connectionsSELECTslave_statusSHOW SLAVE STATUSmysql_slave_status_slave_io_runningREPLICATION CLIENTprocesslistinformation_schema.processlistmysql_info_schema_processlist_*PROCESSeventsstatementsperformance_schema 语句汇总表mysql_perf_schema_events_statements_*SELECT这张表后面配置账号权限时也会用到。基本规则是开了哪些collector账号就补哪些权限。权限宁少勿多避免监控账号成为安全隐患。2.3 counter、gauge与指标基数决定告警写法和存储成本从使用角度讲理解数据来源的直接好处是分清指标类型。threads_connected是gauge反映当前瞬时值告警用比值加for子句就能过滤抖动。慢查询累计值slow_queries是counter必须用rate()计算速率才有意义直接对原始值设阈值这个数会随着运行时间越滚越大超过阈值后永远不恢复等于废掉这个告警。在/metrics端点里能直接看到指标类型每类指标前面有# TYPE声明counter类型通常会额外出现_total结尾的序列。写告警表达式之前先看一眼TYPE能避免把counter当gauge用、把gauge当counter算速率这类错误。还要留意指标基数。processlist和eventsstatements这类collector会产生带pid、digest、schema等标签的序列业务越复杂序列数量越多。高基数指标直接推高Prometheus存储和内存消耗。新环境上我会先跑一次exporter启动日志会列出全部可用collector及开关状态再按实例规模决定开哪些。这一步花两分钟后面排查指标缺失或存储增长时能省半小时。3. 从零部署监控账号、exporter启动参数与Prometheus抓取配置上一章讲清楚了原理这一章给出可直接照做的步骤。部署顺序建议自底向上先在MySQL侧准备账号再启动exporter然后配置Prometheus抓取最后验证。3.1 MySQL侧先准备最小权限监控账号MySQL端先建一个专用监控账号权限遵循最小化原则。常见做法是只授予SELECT、PROCESS、REPLICATION CLIENT三个权限分别对应基础查询、进程列表采集、复制状态采集。不要拿root或业务账号做监控职责分离能避免权限过大也能防止业务账号密码轮换时监控跟着断掉。CREATE USER exporter127.0.0.1 IDENTIFIED BY 这里填一个复杂密码; GRANT SELECT, PROCESS, REPLICATION CLIENT ON *.* TO exporter127.0.0.1;host部分按实际来源地址设置。exporter和应用同机时用127.0.0.1最安全exporter独立部署时改成对应IP网络层再限制来源。GRANT之后多数情况不需要FLUSH PRIVILEGES但我习惯顺手执行一次避免个别环境账号缓存导致权限不生效。再补一个细节给监控账号加上最大连接数限制。写法是在CREATE USER语句末尾加WITH MAX_USER_CONNECTIONS 3。监控账号如果出现连接泄漏反复重连可能瞬间占用大量连接栈加上这个限制能防止它把连接数打满。3.2 下载并启动mysqld_exporter凭据传递与启动参数二进制下载解压后直接就能跑。凭据传递有两种常见做法一是配置文件.my.cnf二是环境变量DATA_SOURCE_NAME。密码里有特殊字符时配置文件更省心不需要考虑转义。先写配置文件[client] userexporter password这里填密码 host127.0.0.1 port3306再启动./mysqld_exporter \ --config.my-cnf/etc/mysqld_exporter/.my.cnf \ --web.listen-address0.0.0.0:9104 \ --collect.info_schema.processlist \ --collect.perf_schema.eventsstatements \ --collect.binlog_size参数说明--config.my-cnf指定凭据文件路径--web.listen-address是exporter监听地址9104是默认端口只给本机Prometheus用就绑127.0.0.1--collect.info_schema.processlist开启进程列表采集看活跃连接数用--collect.perf_schema.eventsstatements开启语句统计慢查询分析依赖它--collect.binlog_size采集二进制日志大小预估磁盘容量用。不想写配置文件的场景用环境变量也行export DATA_SOURCE_NAMEexporter:密码tcp(127.0.0.1:3306)/ ./mysqld_exporter --web.listen-address127.0.0.1:9104生产环境建议用systemd托管重启自愈和日志管理都方便[Unit] DescriptionPrometheus MySQL Exporter Afternetwork.target [Service] Typesimple Userexporter Groupexporter ExecStart/usr/local/bin/mysqld_exporter --config.my-cnf/etc/mysqld_exporter/.my.cnf --web.listen-address0.0.0.0:9104 Restartalways [Install] WantedBymulti-user.target启动后看日志没有Access denied或连接失败的报错就说明MySQL连接正常。先curl一下确认指标能返回再做Prometheus侧配置。3.3 Prometheus抓取配置job与scrape_interval怎么设prometheus.yml里加一个jobscrape_configs: - job_name: mysql static_configs: - targets: [127.0.0.1:9104] scrape_interval: 15sjob_name用于分组一个MySQL实例集群可以拆成多个job区分环境比如mysql-prod、mysql-dev。targets填exporter的地址和端口。scrape_interval默认15s也是我推荐的起步值MySQL的指标变化粒度大多在秒级甚至分钟级15s足够捕捉连接数爬升和慢查询趋势。后续要做更细粒度的性能分析再单独下调到5s同时评估Prometheus自身负载和存储增长。如果MySQL实例很多targets可以用文件或服务发现动态维护避免每次扩容都改配置文件。小规模部署用static_configs完全够用不必提前引入复杂机制。3.4 验证采集是否真的成功三个必须检查的点第一个检查点是exporter的HTTP端点确认返回文本里有mysql_up且值为1。第二个是Prometheus的Targets页面mysql job状态显示UP。第三个是在Prometheus查询框里执行mysql_global_status_uptime能看到持续增长的数值才算真正跑通。curl -s http://127.0.0.1:9104/metrics | grep -E ^mysql_up|^mysql_global_status_uptimemysql_up等于1表示exporter到MySQL的连接正常uptime持续增长说明数据是活的不是静态缓存。三个检查点按顺序跑能快速定位是exporter问题还是Prometheus配置问题。常见情况是exporter正常但Prometheus里查不到数据这种基本是targets地址写错或抓取间隔期间服务重启过。4. 告警规则连接数、慢查询、复制状态怎么量化成触发条件监控的最终产出是告警。这一章给出我常用的五类告警表达式以及规则文件里for、labels、annotations三个字段的调优方法。4.1 核心指标组优先配哪些告警告警不是越多越好配了不响是浪费天天误报则会被业务方无视。按故障影响面排序我的底线是五个场景。故障场景推荐表达式告警级别实例不可达mysql_up 0critical连接数水位过高mysql_global_status_threads_connected / mysql_global_variables_max_connections * 100 80warning慢查询速率突增rate(mysql_global_status_slow_queries[5m]) 5warning复制线程中断mysql_slave_status_slave_io_running ! 1 or mysql_slave_status_slave_sql_running ! 1critical主从延迟过大mysql_slave_status_seconds_behind_master 30warning连接数按比例算而不是绝对值因为不同实例的max_connections差异很大绝对值阈值没法通用。慢查询速率基线需要观察一周正常业务后确定表格里的5只是起步值。复制相关的几个指标要求实例本身已经配置了主从没有主从关系的实例不要套这条规则。还有两个容易被忽略的指标mysql_global_status_aborted_connects反映连接被拒绝的次数突增说明连接数接近上限或账号权限有问题mysql_global_status_threads_running反映当前正在执行语句的线程数是判断实例真实压力的关键。4.2 规则文件写法与参数调优for、labels、annotations怎么设规则文件用YAML组织一组规则的完整写法如下groups: - name: mysql_alerts rules: - alert: MySQLConnectionHigh expr: mysql_global_status_threads_connected / mysql_global_variables_max_connections * 100 80 for: 10m labels: severity: warning annotations: summary: MySQL连接数超过80% description: 实例 {{ $labels.instance }} 当前连接占比 {{ $value | humanizePercentage }} - alert: MySQLReplicationBroken expr: (mysql_slave_status_slave_io_running 0 or mysql_slave_status_slave_sql_running 0) and mysql_up 1 for: 1m labels: severity: critical annotations: summary: MySQL主从复制中断 description: 实例 {{ $labels.instance }} 的复制线程已停止请立即检查for子句是防抖动的关键。连接数偶发冲高很快就会回落for 10m能过滤掉大部分噪音复制中断需要快速处理for 1m比较合适。labels里的severity用于告警路由分组annotations里的模板变量会在通知内容里渲染出具体实例和数值。最后那个and mysql_up 1条件很重要实例本身宕机时不叠加复制中断告警减少告警风暴。规则写完后复制到Prometheus的rules目录在配置文件里用rule_files声明然后reload。Prometheus的reload是热生效不用重启进程但每次改动前建议先做语法校验校验方法在最后一章给出。5. 避坑指南Prometheus监控MySQL最容易翻车的五个细节这一章每条都按现象、原因、解决三步展开都是我实际部署时碰到过或帮别人排查过的类型。前四条和MySQL相关最后一条其实是Prometheus自身的坑但监控MySQL时最容易暴露。5.1 现象采集超时exporter内存居高不下现象配置了很多collector之后Prometheus抓取经常超时exporter进程内存持续上涨。原因performance_schema的语句统计和表统计在大实例上扫描量很大特别是events_statements_summary_by_digest这类汇总表累积数据多时每次采集都要做聚合CPU和内存开销成倍增加。解决只保留必要的collector。我的基准配置是全局状态、slave_status、processlist三个语句统计按需开启。已经开启高消耗collector的实例定期清理汇总表数据TRUNCATE TABLE performance_schema.events_statements_summary_by_digest;清理账号需要对应权限。另外要清楚清理后慢查询统计基线会重置告警规则里的rate()在清理后短暂跳到零这是正常现象不用慌。5.2 现象连接数告警频繁误报业务方开始无视告警现象连接数告警一天响好几次排查时发现实例没有异常DBA和业务都被告警吵到疲于应对。原因直接用threads_connected绝对值设阈值忽视了实例规格差异大量sleep连接被连接池占着看起来连接数很高但实际压力不大。解决改成比例告警表达式用threads_connected除以max_connections阈值设在80%for至少拉到10分钟同时看threads_running辅助判断真实压力。threads_running才是当前正在执行语句的线程数两个指标配合才能区分“连接池占位”和“真的打满”。5.3 现象exporter在容器里连不上MySQL现象exporter日志报Access denied或dial tcp连接失败但本机直接连MySQL是通的。原因容器里用127.0.0.1访问的是容器自己的网络栈不是宿主机MySQL账号的host限制也可能不匹配。解决容器用--network host模式启动exporter让网络栈和宿主机一致或者把.my.cnf里的host改成宿主机局域网IP。账号授权也要对应修改host写成%或指定来源IP。这个坑很隐蔽因为本机测试是通的换到容器里就报错排查时不熟悉容器网络的容易卡很久。5.4 现象主从复制监控时好时坏切换后告警状态不对现象复制中断告警有时能触发有时不能主从切换后旧实例还挂着告警。原因REPLICATION CLIENT权限没给全多源复制场景下不同channel的复制状态都暴露在同一组指标里没按channel_name标签区分切换后exporter连接的还是旧实例采集到的还是老状态。解决确认监控账号有REPLICATION CLIENT权限多源复制按channel_name拆分告警或聚合判断主从切换后重启exporter或调整target配置让采集指向新的主从拓扑。切换这类动作应该纳入变更流程不能指望exporter自己发现拓扑变化。5.5 现象Prometheus数据盘被写爆现象TSDB目录增长很快磁盘使用率告警有时Prometheus直接因内存不足退出。原因默认保留时间15天很多人没配存储上限高基数指标比如进程列表和语句统计会生成大量时间序列每个pid或每个digest都是一条序列存储和内存消耗随着业务增长持续攀升。解决启动参数加上--storage.tsdb.retention.time7d和--storage.tsdb.retention.size20GB两个参数配合使用先到哪个算哪个。同时在抓取配置里用metric_relabel_configs过滤掉不需要的标签能显著降低基数。定期看Prometheus的TSDB head series数量如果持续上涨就要检查是否有新的高基数指标被纳入。6. 把监控做成体系看板组织方式与规则自检习惯6.1 看板怎么组织按使用视角分组而不是按指标罗列看板我习惯分成四层。总览页放实例存活、连接数水位、活跃线程数这类全局指标性能页放慢查询速率、InnoDB读写、缓冲池命中率复制页单独用从库视角只放复制线程状态和延迟容量页放binlog大小、磁盘占用和表数量增长。按视角分组比按指标罗列好在排障时能顺着页面从上往下定位而不是在一堆图表里找指标。6.2 用promtool做规则自检上线前必跑的命令改完规则文件不要直接reload先用promtool做语法检查promtool check rules /etc/prometheus/rules/mysql.yml没有输出错误再执行规则测试。准备一个测试文件把历史故障的指标值写进去验证告警能否按预期触发。这一步能拦住大部分表达式写错、标签引用错误、阈值设反的低级问题。rule_files: - /etc/prometheus/rules/mysql.yml evaluation_interval: 1m tests: - interval: 1m input_series: - series: mysql_global_status_threads_connected{instance127.0.0.1:9104} values: 1000x20 - series: mysql_global_variables_max_connections{instance127.0.0.1:9104} values: 1000x20 alert_rule_test: - eval_time: 5m alertname: MySQLConnectionHigh测试文件里构造两组输入序列一组连接数恒为100一组最大连接数恒为100连接占比100%超过80%阈值缓冲5分钟后告警应该处于Pending状态。promtool test rules的完整语法在不同版本略有差异以本机promtool test rules --help输出为准。我自己的习惯是每次改动规则都在配置文件注释里记录时间和原因比如“连接数告警从80%调到85%原因是业务大促时连接池水位正常偏高”。三个月后回看这些注释能避免把同一个阈值来回调。规则测试、注释记录、定期看板和指标基线这套习惯比任何单点配置都重要。希望帮到你。本文还有配套的精品资源点击获取
语法分析器实战)
