做运维的兄弟应该都清楚MySQL一旦出问题业务那边电话能把你手机打到关机。我去年接手了一套业务系统数据库凌晨两三点磁盘满了都没人发现早上九点一开门直接全站报错那种感觉真的是“血泪教训”。后来我花了整整一个周末用Zabbix的agent方式把MySQL的监控彻底搭了起来从那以后数据库任何风吹草动告警消息比业务反馈早好几个小时。这套方案我用到了现在项目名就叫“agent监控mysql--Zabbix”。别小看这几个词它背后涉及Zabbix Agent采集原理、MySQL状态命令的解析、模板与宏的调整、触发器阈值设计一整条链路。这篇文章就把我从零到一踩过的坑、验证过的配置、还有日常维护的经验全部摊开讲适合刚接触监控的运维新人也适合已经在用Zabbix但只监控了主机CPU、内存还没把数据库纳入监控体系的同学。1. 为什么选agent方式监控MySQL而不是其他方案1.1 监控MySQL的几种常见方式对比我在一开始踩过一个误区以为监控MySQL需要什么高深莫测的东西。实际上Zabbix监控MySQL主流方式就那么几种我把他们的优缺点先列个表看完你就明白为什么我最终选了agent方式。监控方式数据获取原理优点缺点Zabbix Agent被动/主动Agent执行mysqladmin或SQL命令读取MySQL状态变量轻量、部署简单、支持自定义Key、适合绝大多数场景需要在DB服务器上装Agent理论上有一点资源开销SNMPMySQL自身不带SNMP能力通常要靠第三方脚本转换能融入已有SNMP监控体系要额外维护MIB库和转换脚本吃力不讨好ODBC方式Zabbix服务端直接通过ODBC连接MySQL查询不需要在DB服务器上装Agent需要开放数据库远程访问端口安全风险高网络抖动时容易误报外部脚本(wb_check等)Zabbix服务端调用外部脚本用SQL远程查询灵活性高脚本要自己维护远程连接还是要开端口你可能已经看出来了ODBC方式和外部脚本方式都存在一个共同的痛点要把MySQL的端口暴露给Zabbix服务端。这在生产环境里就是一个很大的安全隐患网络安全扫描一打一个准。而agent方式的逻辑是“让数据主动走出来”Zabbix服务端不直接触碰MySQL端口Agent在本地拿到数据后通过Zabbix协议传输安全性和可维护性都好了很多。1.2 agent方式的采集原理说白了是什么Zabbix Agent监控MySQL并没有用到什么魔法。Agent本质上是一个跑在被监控机器上的守护进程我配置好UserParameter之后Zabbix服务端下发一个key比如mysql.status[Uptime]Agent就在本地执行对应的命令来获取数据。以官方模板为例最核心的动作是执行mysqladmin status和mysql -e SHOW GLOBAL STATUS;。这些命令返回的都是MySQL自己维护的状态变量比如Threads_connected当前连接数、Queries累计查询次数、Slow_queries慢查询数、Innodb_buffer_pool_read_requestsInnoDB缓冲池逻辑读次数等等。Agent拿到文本输出之后再按模板里定义的格式做解析最终转换成监控项里的数值。提示这里有一个关键认知agent方式监控MySQL它的数据源是MySQL“主动暴露”的状态指标而不是Zabbix“硬抓”过来的。所以MySQL本身如果挂了Agent是无法通过mysqladmin status拿到数据的监控项会报“不支持的key”或者返回空值这一点在设计触发器时非常重要后面我会细说。1.3 一个容易混淆的概念agent不是AI agent在搜索监控方案时你可能会被“agent”这个词带到另一个坑里。最近“AI agent”、“智能体开发”这些词特别火但Zabbix里的agent跟你听说的AI agent完全不是一回事。这里的agent就是一个安装在服务器上、负责收集指标并上报给服务端的小程序没有“计划”、“推理”、“工具调用”这些概念。搞清楚这一点你就不会被各种所谓“agent项目”的技术热词带偏。Zabbix Agent就是老老实实干活的数据采集器它负责执行我指定的命令把数据库的状态变成一个个数值仅此而已。这也是很多人初次接触Zabbix时容易绕晕的地方先在脑子里把这个概念掰正后面的配置思路就顺了。2. 监控前需要准备的环境与基础部署2.1 MySQL账密准备别用root做监控先说一个我在生产环境里反复强调的原则监控账号权限能小就小绝不拿root当监控账号用。Zabbix官方模板里监控MySQL需要的最低权限大概是PROCESS、REPLICATION CLIENT、SHOW DATABASES这三个。其中PROCESS权限用来查看SHOW PROCESSLIST里的线程信息REPLICATION CLIENT用来查看主从复制状态SHOW DATABASES则允许查看有哪些库。我给监控账号的授权语句如下CREATE USER zbx_monitorlocalhost IDENTIFIED BY ZbxMonitor2025; GRANT PROCESS, REPLICATION CLIENT, SHOW DATABASES, SELECT ON *.* TO zbx_monitorlocalhost; FLUSH PRIVILEGES;注意这里用的是localhost因为Zabbix Agent就装在MySQL服务器本机上我根本不需要给监控账号开放远程登录权限。这又是一个安全细节即使Agent被攻破数据库方面也不会暴露远程登录入口。如果你是用Docker方式运行MySQL并且Zabbix Agent也运行在同一台宿主机上那么授权时可以把localhost换成你容器IP或宿主机的IP。MySQL 8.0还有一个要特别注意的地方就是默认认证插件是caching_sha2_password而Zabbix自带的监控脚本在某些版本上用mysqladmin连接时会遇到认证不兼容的问题。我用的是MySQL 8.0.28实测用caching_sha2_password也可以正常连接但如果你遇到“Authentication plugin caching_sha2_password cannot be loaded”之类的报错最简单的办法是创建用户时指定mysql_native_passwordCREATE USER zbx_monitorlocalhost IDENTIFIED WITH mysql_native_password BY ZbxMonitor2025; GRANT PROCESS, REPLICATION CLIENT, SHOW DATABASES, SELECT ON *.* TO zbx_monitorlocalhost; FLUSH PRIVILEGES;2.2 Zabbix服务端部署Docker方式最省心关于Zabbix服务端怎么部署网上教程一堆但很多人一上来就被各种依赖关系劝退了。我个人的建议是如果你是7.0及以上的版本直接用Docker Compose方式部署省时省力而且升级特别方便。我推荐Zabbix 7.0的docker部署方式主要是因为7.0在模板和监控项命名上做了一波优化而且官方容器镜像对Alpine、Ubuntu、openEuler这些系统的兼容性都做得不错。我用的docker-compose配置是这样的可以参考version: 3.5 services: zabbix-server: image: zabbix/zabbix-server-mysql:7.0-ubuntu-latest container_name: zabbix-server environment: - DB_SERVER_HOSTzabbix-db - MYSQL_DATABASEzabbix - MYSQL_USERzabbix - MYSQL_PASSWORDzabbix_password - MYSQL_ROOT_PASSWORDroot_password ports: - 10051:10051 networks: - zabbix-net zabbix-db: image: mysql:8.0 container_name: zabbix-db environment: - MYSQL_DATABASEzabbix - MYSQL_USERzabbix - MYSQL_PASSWORDzabbix_password - MYSQL_ROOT_PASSWORDroot_password volumes: - zabbix-db-data:/var/lib/mysql networks: - zabbix-net zabbix-web: image: zabbix/zabbix-web-nginx-mysql:7.0-ubuntu-latest container_name: zabbix-web environment: - ZBX_SERVER_HOSTzabbix-server - DB_SERVER_HOSTzabbix-db - MYSQL_DATABASEzabbix - MYSQL_USERzabbix - MYSQL_PASSWORDzabbix_password ports: - 8080:8080 networks: - zabbix-net volumes: zabbix-db-data: driver: local networks: zabbix-net: driver: bridge注意Zabbix 7.0对PHP版本有要求容器方式已经把这些依赖打包好了你只需要保证宿主机有Docker环境即可。如果是Ubuntu系统安装Docker后拉镜像就行如果是openEuler也可以用同样的Docker方式不用纠结yum源里没有zabbix包的问题。2.3 Zabbix Agent安装版本务必和服务端匹配Agent的安装部署关键点在于版本要匹配。Zabbix 7.0服务端配6.4的Agent协议上兼容问题不大但为了减少折腾我建议全都用7.0。Ubuntu上装Agent的命令很常规wget https://repo.zabbix.com/zabbix/7.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_7.0-2ubuntu22.04_all.deb dpkg -i zabbix-release_7.0-2ubuntu22.04_all.deb apt update apt install -y zabbix-agent安装完成后需要修改/etc/zabbix/zabbix_agentd.conf里的三个关键参数Server192.168.1.100 # Zabbix服务端IP用于被动模式 ServerActive192.168.1.100 # Zabbix服务端IP用于主动模式 Hostnamemysql-prod-01 # 这个值必须和Zabbix前端添加主机时填的“主机名称”一致然后启动Agentsystemctl restart zabbix-agent systemctl enable zabbix-agent这三个参数不出问题Agent和服务端的通信就成功了一半。Hostname不一致是最常见的报错来源很多人配置完以后Zabbix前端一直显示“主机不可达”最后查来查去就是Hostname没对上。3. 监控指标怎么选别一上来就挂全模板3.1 官方模板自带哪些监控项Zabbix安装好之后在“模板”里会自带一个Template DB MySQL。我第一次用的时候直接给主机挂上这个模板心想完了监控不就这么简单吗结果等了几分钟打开监控项一看一片红全是“不支持的key”。原因就是官方模板依赖Agent端的一些脚本和配置文件裸挂模板是不行的。后来我把思路理清了先弄清楚模板自带的监控项有哪些分类。官方模板大致覆盖了以下几个维度可用性检测mysql.ping其实就是能否连上MySQL并返回uptime。连接状态mysql.status[Threads_connected]、mysql.status[Max_used_connections]看当前连接数和历史最大连接数。查询与流量mysql.status[Queries]、mysql.status[Bytes_received]、mysql.status[Bytes_sent]判断数据库忙不忙、网络吞吐是否异常。InnoDB引擎mysql.status[Innodb_buffer_pool_read_requests]、mysql.status[Innodb_buffer_pool_write_requests]反映InnoDB缓冲池的使用效率。慢查询与复制mysql.status[Slow_queries]、mysql.replication[*]慢查询数量和主从复制延迟。性能关键指标mysql.status[Questions]、mysql.status[Uptime]分别反映实际请求量和运行时长。看清楚这些监控项之后我对模板的结构就有数了。模板只是“骨架”真正让它跑起来的是背后的采集脚本和权限配置。3.2 哪些指标值得重点盯住挂模板不等同于会监控如果你把模板里所有监控项都原样接收虽然能收集数据但真正对业务有价值的核心指标反而会被淹没在大量数据里。根据我大半年的使用经验下面这几个指标一定要单独建触发器重点盯防。首先是连接数使用率。MySQL默认max_connections是151很多业务跑着跑着连接数就爆了。我习惯在触发器里设一个“连接数超过最大连接数80%”的阈值表达式就是mysql.status[Threads_connected]除以最大连接数Zabbix里可以用last(/主机名/mysql.status[Threads_connected]) / last(/主机名/mysql.status[Max_used_connections])这类方式计算当然如果需要精确的话就得在模板宏里设置{$MYSQL.MAX_CONNECTIONS}。其次是慢查询数量。慢查询多了业务接口响应就会变慢用户体验直线下降。我一般设置成“最近5分钟慢查询数超过50”就告警用sum聚合函数可以实现。再就是主从复制延迟。这是最容易出大事的指标主库挂了从库顶上如果延迟严重数据一致性就会出问题。官方模板里有mysql.replication[Seconds_Behind_Master]这个key延迟超过30秒就应该告警延迟超过5分钟说明主从已经严重脱节需要人工介入了。最后是缓存命中率。InnoDB缓冲池命中率长期偏低说明数据库配置可能需要调优或者热点数据量超过了内存容量。这个指标不会立刻引发故障但它是数据库性能优化的重要参考。3.3 自定义监控项模板之外的需求怎么扩展模板自带的监控项再全总有些场景需要自己扩展。比如我想监控特定业务表的行数变化或者监控当前活跃事务数这些就得通过自定义UserParameter来实现。Zabbix的自定义监控项原理很简单就是在Agent端配置一个key和对应的命令服务端通过这个key来获取数据。我在/etc/zabbix/zabbix_agentd.d/下新建了一个配置文件比如userparameter_mysql_custom.conf内容如下UserParametermysql.threads_running,mysql -uzbx_monitor -p密码 -e SHOW GLOBAL STATUS LIKE Threads_running; 2/dev/null | awk NR2{print $2} UserParametermysql.active_txn,mysql -uzbx_monitor -p密码 -e SELECT COUNT(*) FROM information_schema.INNODB_TRX; 2/dev/null | sed -n 2p配置完以后重启Agentsystemctl restart zabbix-agent。然后到Zabbix前端“监测”-“最新数据”里输入这个key测试一下如果能出来数值说明自定义监控项生效了。这里有一个很重要的经验写UserParameter的时候一定要在命令最后加2/dev/null。因为mysql命令执行出错时会把错误信息输出到stderrAgent会把这部分内容也当作返回值导致监控项显示“不支持的key”。加上2/dev/null之后错误信息就被吞掉了命令只会返回最终的结果。4. 实操过程从Agent配置到前端出图一步步来4.1 Agent端环境变量与脚本准备Zabbix Agent在启动时默认的PATH环境变量是很精简的可能根本找不到mysql命令和mysqladmin命令。这是很多新手第一次配置时最容易卡住的地方我也是踩过这个坑才明白的。解决办法有两个。第一个办法是修改Agent的配置文件在/etc/zabbix/zabbix_agentd.conf里加上环境变量配置UserParametermysql.ping,mysqladmin -uzbx_monitor -p密码 ping 2/dev/null | grep -c alive UserParametermysql.status[*],mysql -uzbx_monitor -p密码 -e SHOW GLOBAL STATUS WHERE Variable_name$1; 2/dev/null | awk NR2{print $2}但这个办法会有一个问题如果MySQL路径不是标准的/usr/bin/mysql比如你用的是/usr/local/mysql/bin/mysql那还是找不到命令。所以我更推荐第二个办法在配置里使用绝对路径把mysql和mysqladmin的完整路径写进去UserParametermysql.ping,/usr/local/mysql/bin/mysqladmin -uzbx_monitor -p密码 ping 2/dev/null | grep -c alive UserParametermysql.status[*],/usr/local/mysql/bin/mysql -uzbx_monitor -p密码 -e SHOW GLOBAL STATUS WHERE Variable_name$1; 2/dev/null | awk NR2{print $2}先确认一下你的mysql命令在哪用which mysql一下就知道了。这样配置虽然看起来繁琐但一劳永逸不用再担心Agent环境变量的问题。4.2 官方模板依赖的脚本配置如果你决定用官方自带的Template DB MySQL那就需要参考官方文档把模板依赖的脚本配置好。Zabbix 7.0的MySQL模板在Agent端其实会调用一个名为mysql_status.sh的脚本老版本可能需要你手工下载新版本可能已经内置了。在基于Ubuntu的Agent中这个脚本通常会放到/usr/lib/zabbix/scripts/目录。如果没有你就得从官方GitHub库拉取脚本放进去。然后确保它具有执行权限chmod x /usr/lib/zabbix/scripts/mysql_status.sh脚本的内容大致是接收一个参数然后执行mysqladmin或mysql命令获取指标。它默认会使用~/.my.cnf文件中的账号配置所以最省事的做法是在Agent运行用户通常是zabbix用户的家目录下创建一个.my.cnf文件内容如下[client] userzbx_monitor passwordZbxMonitor2025这个文件要设置成只有zabbix用户可读chown zabbix:zabbix /var/lib/zabbix/.my.cnf chmod 600 /var/lib/zabbix/.my.cnf有了.my.cnfmysql和mysqladmin命令在无参数情况下去连接数据库就会自动读取这个文件里的账号信息脚本执行过程就非常干净命令行里也不会出现密码明文的告警。4.3 Agent端自测先证明采集端没问题配置完所有脚本和UserParameter之后别急着去前端配置主机。先在自己的终端里用zabbix_agentd自带的测试命令验证一下这样可以避免“前端连不上”的排查成本。测试命令是zabbix_agentd -t mysql.status[Uptime]如果输出类似下面这样就说明Agent能正常采集到MySQL数据mysql.status[Uptime] [s|86400]再测一下mysql.pingzabbix_agentd -t mysql.ping返回1就说明MySQL存活。如果返回ZBX_NOTSUPPORTED那说明配置有问题得回头检查脚本路径、权限、.my.cnf。我在这一步见过最多的报错是“Permission denied”基本都是.my.cnf文件权限没设置对或者zabbix用户对脚本没有执行权限。4.4 服务端zabbix_get验证证明网络链路没问题Agent端自测没问题之后再到Zabbix服务端上验证一下网络链路。在服务端执行zabbix_get -s 192.168.1.101 -p 10050 -k mysql.status[Uptime]其中192.168.1.101是被监控MySQL服务器的IP10050是Agent的监听端口。如果能正确返回秒数说明服务端和Agent之间的通信完全正常可以去前端配置了。这一步很重要它能帮你把问题快速定位到“Agent采集”还是“网络通信”还是“前端配置”。如果zabbix_get超时那就先检查防火墙和安全组确认10050端口是否放通如果返回ZBX_NOTSUPPORTED那问题在Agent端脚本或key写法上。4.5 前端添加主机与模板关联参数细节不能漏Agent和服务端之间的链路通了前端的配置就变成了“套路化”操作。但有一个细节我吃过亏强调一下“主机名称”必须和Agent配置文件里的Hostname完全一致。你填了mysql-prod-01Agent配置里也必须是mysql-prod-01一字不差。添加主机的路径是“监测”-“主机”-“创建主机”。填写主机名称、可见名称、所属群组。在“接口”配置里添加Agent接口IP填被监控服务器的IP端口默认10050。添加完主机之后在“模板”标签页里搜索MySQL关联Template DB MySQL点击“更新”。这里还有一个坑添加完模板后默认的宏不一定匹配你的MySQL实例尤其是{$MYSQL.HOST}、{$MYSQL.USER}、{$MYSQL.PASSWORD}这几个宏。如果Agent端创建的不是默认的root账号也没有按脚本默认账号配置就必须在“宏”标签页里把这三个宏改成你实际情况的值。可以在主机级别覆盖模板的宏这样不影响模板的复用。关联完成后等上1到2分钟去“监测”-“最新数据”里搜索mysql就能看到一堆监控项开始出数据了。如果没有数据优先检查配置的宏和Agent端日志/var/log/zabbix/zabbix_agentd.log。5. 常见问题与排查技巧实录5.1 高频报错速查表先会排查再谈优化我在搭建过程中遇到了不少问题也帮同事排过不少雷这里整理一张问题速查表按优先级从高到低排列覆盖了“前端一片红”时最常遇到的问题。问题现象可能原因排查方法主机不可达zabbix_get超时防火墙未放行10050端口Agent未启动端口被占用服务端执行telnet 被监控IP 10050确认Agentsystemctl status zabbix-agent监控项显示“不支持的key”UserParameter命令执行报错脚本没执行权限.my.cnf权限过大mysql命令路径不对切换到zabbix用户手动执行对应命令看能否出结果检查Agent日志mysqladmin连接失败MySQL账号密码错误账号不允许从localhost登录认证插件不兼容用命令行手动测试mysql连接确认账号host为localhost宏配置不对值全部为0{$MYSQL.USER}、{$MYSQL.PASSWORD}没覆盖默认密码不对在主机宏里覆盖模板宏并检查Agent端脚本使用的账号数据更新时间很慢默认更新间隔较长网络延迟Agent负载高在监控项中调整更新间隔比如从60s改为30sAgent日志报“no active checks on server”主动模式地址填错Hostname不一致检查ServerActive和Hostname配置是否正确5.2 权限与安全细节监控账号的三条纪律关于监控账号我总结出了三条纪律算是踩坑后形成的肌肉记忆第一条监控账号绝不使用root和业务账号。不能用root这个不用多说不推荐用业务账号是因为业务账号的数据字典、存储过程执行记录会被你自己的监控命令污染而且一旦业务侧安全审计查出来一个莫名其妙的常驻连接解释起来非常麻烦。第二条权限做到最小化。Zabbix监控MySQL真正需要的权限只有PROCESS、REPLICATION CLIENT、SHOW DATABASES最多加一个SELECT。没有SELECT权限的话某些模板里的SQL查询会失败但核心的status类指标不受影响。我建议把SELECT也加上毕竟监控需要读取一些性能相关的视图。第三条连接数限制单独控制。监控账号的连接不能不受限制但也别限制得太死一般设置成MAX_USER_CONNECTIONS 5就够了。如果设置成1当并发采集多条指标时某些查询会被拒绝反而影响监控数据完整性。ALTER USER zbx_monitorlocalhost WITH MAX_USER_CONNECTIONS 5;5.3 踩坑案例拆解MySQL 8.0认证插件不兼容我这里分享一次最典型的排障过程。有一次帮朋友搭监控他的MySQL是8.0.33Zabbix Agent用的官方模板Agent端自测zabbix_agentd -t mysql.status[Uptime]一直报“Authentication plugin caching_sha2_password cannot be loaded”。当时第一反应就是认证插件的问题。MySQL 8.0默认的caching_sha2_password和旧版客户端工具连接时确实可能出现兼容性问题。解决思路有两个第一个思路在MySQL里把监控账号的认证方式改为mysql_native_passwordALTER USER zbx_monitorlocalhost IDENTIFIED WITH mysql_native_password BY 你的密码;第二个思路升级客户端库。如果你的mysql命令行版本较旧也可以考虑装新版mysql客户端但这对运维来说风险较大一般不推荐在生产环境乱升级。我更推荐直接用第一个思路改账号认证方式对业务影响为零。还有一个特别隐蔽的问题如果你在.my.cnf里配置了密码但密码里有特殊字符比如#或;mysql命令行会把它们当注释或分隔符处理。遇到这种情况不要偷懒用.my.cnf直接改用一个专门给Agent用的MYSQL_PWD环境变量或者在UserParameter里把密码引用起来UserParametermysql.status[*],MYSQL_PWD复杂密码 mysqladmin -uzbx_monitor -e SHOW GLOBAL STATUS WHERE Variable_name$1; 2/dev/null | awk NR2{print $2}5.4 采集频率调整别把监控变成新的压力源监控本身也会消耗MySQL资源。如果你把每个监控项的间隔都设置成1秒几十个监控项叠加起来对数据库就是一笔额外负载。我在实践中的经验是常规状态变量设置成30秒到60秒采集一次就够了主从复制延迟这种关键指标可以缩短到10秒到15秒。调整方式是在前端“模板”-“监控项”里选中同类监控项批量修改“更新间隔”或在“模板”的“宏”里设置{$MYSQL.STATUS.UPDATE.INTERVAL}。批量修改时注意不要把所有监控项都改成同样间隔有些不常用的指标比如Uptime、Version5分钟一次都可以。5.5 扩展思路这套模式能迁移到其他场景吗Zabbix agent的监控模式本质上是一套“通用数据采集框架”。把MySQL换成Oracle把配置脚本换成Oracle的SQL查询思路完全一致。Zabbix官方也提供了Template DB Oracle同样是靠Agent端执行脚本或ODBC去采集只是需要额外配置Oracle客户端。再比如你想监控Windows服务器的GPU使用率Zabbix的agent在Windows上一样能工作只是采集脚本要换成PowerShell或可执行程序自定义UserParameter的思路一点没变。这也是我为什么一直建议新人把MySQL监控的整个链路吃透——你掌握的不只是一个数据库监控方案而是一整套“通过Agent采集自定义指标”的通用方法论。最后再分享一个维护技巧监控搭好只是第一步后续的维护才是细水长流。我个人有一个习惯每次MySQL版本升级、Zabbix版本升级、或者数据库迁移之后都第一时间去Zabbix前端看一眼“最新数据”确认mysql.ping、mysql.status[Uptime]、mysql.status[Threads_connected]这几个核心指标是否在正常更新。如果有一片红宁可牺牲几分钟业务时间也要马上解决绝不拖到“反正监控是辅助”这样的心态里。另外触发器的阈值不是设完就不管了。我建议每个季度根据实际运行数据做一次复盘看看哪些告警从来没有触发过哪些告警总在深夜触发但实际影响不大该放松的放松该收紧的收紧。监控是为人服务的一套“狼来了”的监控系统最终只会让所有人逐渐对它失去信任。这套方案用到现在我的直观感受就是心里踏实。数据库这种核心组件与其靠运气祈祷它不出问题不如把风险提前暴露出来。希望这篇文章能帮你少踩几个坑把MySQL监控一次性搭对、搭稳。