先聊点实际的。上个月我接手了一台总是半夜告警的数据库服务器CPU、内存指标看起来都没问题Zabbix主机层面一切都是绿的可业务方就是反馈查询慢、页面转圈。后来一查问题全在MariaDB自身的连接数被打满、慢查询堆积上。主机活着和数据库活着完全是两回事。这件事让我下了决心把Zabbix监控MariaDB服务这件事从头到尾捋清楚包括选哪些指标、怎么配置模板、触发器阈值怎么定、告警怎么通知以及那些一踩一个准的坑。今天就把这套实践完整写出来希望对正在用Zabbix、又恰好守着MariaDB实例的朋友有点帮助。1. 先搞清楚Zabbix监控MariaDB到底要盯哪些东西1.1 主机监控与数据库监控的差距很多人上手Zabbix监控MariaDB第一反应是“装个agent再套一个MySQL模板就行了”。实际远没有这么简单。Zabbix自带的系统监控只能告诉你CPU、内存、磁盘、网络这些基础设施层面的状态但数据库是一个状态极其复杂的应用它内部有连接池、缓存、锁、复制链路、慢查询队列等等。这些内部状态出了问题主机层指标往往是正常的甚至因为数据库在反复重试CPU还会莫名偏高。我做监控的第一条经验就是先分清监控分层。主机监控解决“机器死没死”的问题数据库监控解决“数据库还能不能好好服务”的问题。两者缺一不可。如果你手里这套MariaDB还有主从复制那就更需要单独盯Seconds_Behind_Master、Slave_SQL_Running_State这类复制专属指标否则主库写满了、从库同步中断业务端可能要过很久才能感知到。1.2 必须关注的核心指标清单我不喜欢一上来就堆几十个指标这样既浪费agent资源告警阈值也很难调。实际观察下来真正值得放进Zabbix的MariaDB监控指标大致可以分为下面几类分类核心指标说明连接状态Threads_connected、Max_connections、Aborted_connects判断连接数是否逼近上限有没有异常中断查询压力Questions、Queries、Slow_queries、Com_select/insert/update/delete看整体负载和慢查询增长趋势缓存效率Innodb_buffer_pool_read_requests、Innodb_buffer_pool_reads计算InnoDB缓冲池命中率临时文件Created_tmp_disk_tables、Created_tmp_tables判断是否存在大量磁盘临时表复制同步Slave_IO_Running、Slave_SQL_Running、Seconds_Behind_Master主从架构下必须盯这组指标锁等待Innodb_row_lock_current_waits、Innodb_row_lock_time定位行锁竞争这里特别提醒Zabbix官方提供的MySQL模板默认从MYSQL.M这个宏里读取密码如果你的MariaDB版本较新密码认证方式可能是caching_sha2_password那就需要在模板宏里把认证方式对应的配置一并处理好。否则agent会一直报“Access denied”让你误以为模板坏了。2. 搭建监控环境agent、模板和监控账号2.1 用官方模板还是自定义模板Zabbix自带的DB MySQL模板理论上可以兼容MariaDB因为MariaDB和MySQL的SHOW GLOBAL STATUS输出大部分字段一致。不过官方模板的设计思路比较中规中矩它提供的触发器和图表只能覆盖基础面比如连接数、查询数、慢查询数。如果你的MariaDB实例跑着大量InnoDB引擎、开了半同步复制那官方模板就明显不够用了。我建议的策略是“官方模板做底自定义监控项做补充”。具体操作上先用官方模板把基础指标跑起来确认agent连接通道正常再根据自己的业务场景补充专用监控项。比如我之前为某个业务补充过Threads_running的监控这个指标看似只是当前正在执行的线程数但很多时候连接数还没爆Threads_running已经先飙升到几百了用它来做“数据库卡顿”的早期信号非常灵敏。2.2 创建专用的监控账号与最小权限授权这一步很多人会偷懒直接用root账号让Zabbix连数据库。一般我劝都劝不住因为root能跑通一切问题是万一Zabbix前端被攻破数据库就跟着裸奔了。正确做法是新建一个只读账号CREATE USER zbx_monitor127.0.0.1 IDENTIFIED BY YourStrongPassword; GRANT REPLICATION CLIENT ON *.* TO zbx_monitor127.0.0.1; GRANT PROCESS ON *.* TO zbx_monitor127.0.0.1; GRANT SELECT ON performance_schema.* TO zbx_monitor127.0.0.1; FLUSH PRIVILEGES;如果你的Zabbix agent跑在数据库本机上建议源地址只写127.0.0.1。如果agent在另一台机器再改成对应的内网IP不要把授权放开到整个网段。REPLICATION CLIENT权限是为了读取SHOW MASTER STATUS和SHOW SLAVE STATUSPROCESS权限是为了读取线程相关的状态信息。没有这两个权限模板里一部分监控项会拿不到数据。2.3 agent客户端配置与模板关联Zabbix监控MariaDB通常有两种方式一种是agent被动检查由Zabbix Server周期性发起查询另一种是agent主动上报适合大批量监控。个人维护的机器不多被动检查足够用了。在MariaDB所在主机的Zabbix agent配置里需要启用Server和ServerActive指向Zabbix Server地址并在配置文件里引入UserParameter。如果使用Zabbix官方MySQL模板它会调用一个名为mysql.status[param]的UserParameter你需要在agent的自定义配置目录下增加一个文件cat /etc/zabbix/zabbix_agentd.d/userparameter_mysql.conf EOF UserParametermysql.status[*],/usr/local/bin/mysql_status.sh $1 $2 $3 UserParametermysql.ping,HOSTNAME$(hostname); mysqladmin -uzbx_monitor -p$(cat /etc/zabbix/.my.cnf) ping 2/dev/null | grep -q alive echo 1 || echo 0 EOF这里有一个非常关键的细节不要把密码写死在脚本命令行里比如不要写mysql -pYourPassword因为agent在执行命令时ps输出会直接暴露密码。比较稳妥的做法是用/etc/zabbix/.my.cnf给该文件设置600权限并在mysql命令行客户端里通过~/.my.cnf自动读取凭据[client] userzbx_monitor passwordYourStrongPassword host127.0.0.1然后把.my.cnf的属主改为zabbix用户chown zabbix:zabbix /etc/zabbix/.my.cnf chmod 600 /etc/zabbix/.my.cnf完成之后记得重启agent并手动执行一次监控项脚本验证输出。这一步能提前过滤掉90%的配置问题。3. 核心指标实测与触发器阈值设计3.1 连接数指标的表现与触发器写法连接数是最容易出现“拖垮全库”的指标。MariaDB的默认max_connections通常是151业务一增长连接数超过100就开始有风险了。我用Zabbix模板里的Threads_connected指标一般把触发器设置为连续5分钟超过max_connections的80%就告警。Zabbix官方模板的触发器表达式通常是这样last(/DB MySQL/Threads_connected[*]){$MYSQL.MAX_CONNECTIONS}*0.8但这里有个坑触发器里用的{$MYSQL.MAX_CONNECTIONS}宏默认值是100。如果你的MariaDB配置过max_connections500不修改宏的话连接数到达80就会告警准没错但每天都会被无关痛痒的告警轰炸。正确做法是在模板宏里把{$MYSQL.MAX_CONNECTIONS}改成实例的真实上限。另外Threads_running这个指标也应该配上触发器。很多数据库连接数还没到100Threads_running已经到20甚至50了说明有大量查询正在并发执行这往往意味着某些慢查询在挤占CPU。我习惯把Threads_running的阈值设为last(/MariaDB/Threads_running)50当然这个阈值要看机器核数4核机器跑到50基本就是灾难现场32核机器则可以放宽到100。3.2 慢查询和缓存命中率的联动判断慢查询是数据库性能问题的直接表现但它不是根因。我见过很多团队只盯着Slow_queries这个计数器结果它只是持续累加看不出任何规律。更好的做法是监控Slow_queries的变化率Zabbix可以用last和prev函数计算差值last(/MariaDB/Slow_queries)-last(/MariaDB/Slow_queries,#2) 20这个表达式含义是当前采集到的慢查询总数比上一次采集时增加了20条以上说明在这一个采集周期内出现了慢查询激增。单独一个Slow_queries绝对值告警往往没有意义因为不同业务量级下慢查询的总量差异非常大。InnoDB缓冲池命中率的计算公式通常是(1 - Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests) * 100%在Zabbix里面我通常是写一个计算型监控项使用last()函数去做除法。命中率建议不要低于98%一旦发现命中率持续低于95%基本可以断定是缓冲池远小于工作集。这种问题调整起来可能需要改innodb_buffer_pool_size配置监控起到的作用是帮你尽早发现趋势而不是等你手动登录数据库才知道。3.3 主从复制状态的监控如果MariaDB跑了主从复制Zabbix要监控的指标相对固定Slave_IO_Running是否为YesSlave_SQL_Running是否为YesSeconds_Behind_Master延迟时间Slave_IO_Running和Slave_SQL_Running在MariaDB里返回的字符串不是严格意义上的数字所以在自定义监控项时要用脚本做一次转换。下面这段脚本可以输出1或0#!/bin/bash mysql --defaults-extra-file/etc/zabbix/.my.cnf -e SHOW SLAVE STATUS\G 2/dev/null | grep -E Slave_IO_Running:|Slave_SQL_Running: | awk {print $2} | grep -q Yes echo 1 || echo 0然后建立一个文本类型监控项或者直接返回整数。触发器表达式如下last(/MariaDB/Slave_IO_Running)0提示Seconds_Behind_Master偶尔出现短暂跳变是正常的建议触发器里加max(/MariaDB/Seconds_Behind_Master,5m)60意思是在5分钟内最大值超过60秒才告警避免因为网络抖动导致误报。4. 告警通知与可视化面板的差异化配置4.1 告警媒介与升级策略Zabbix默认自带Email媒介但实际用起来很多人抱怨收不到告警原因通常是邮箱配置、垃圾箱拦截、或者SMTP认证问题。我个人倾向于在Zabbix里配置脚本媒介把消息推送到一个统一接收消息的机器人接口这样既不依赖邮箱也能在手机端快速响应。告警级别建议分三级级别典型场景响应方式Disaster数据库无法连接、复制中断电话或短信通知值班人员立即处理High连接数超过阈值、慢查询激增消息通知10分钟内确认Average缓存命中率下降、临时表增长消息通知24小时内处理Zabbix的动作Actions里可以配置多个条件比如触发器级别等于High且触发器名称包含“Slow query”时发送到某群组。这个分级配置一开始会有些繁琐但长期看省了无数精力。不要把所有的告警都一股脑发给所有人不然告警疲劳很快会让真正重要的消息石沉大海。4.2 Dashboard可视化组织Zabbix自带的模板图表通常只有一个简单的“Database status”示意图。个人推荐在Dashboard上自己组合几个关键组件一个Graph组件展示连接数趋势叠加Max_connections参考线一个Graph组件展示QPS/TPS趋势就是Questions和Com_commit Com_rollback一个单独组件展示复制延迟如果有主从架构的话一个数值组件用Recent data展示当前Threads_running和Slow_queries图形化界面最大的价值不是炫技而是让你快速建立“这数据库今天有没有异常”的第一印象。比如一个页面能看到连接数曲线在晚上10点突然爬坡、慢查询同步上升你就能判断是定时任务引起的而不用再登录数据库翻日志。5. 我从零搭建到收尾的排错清单5.1 最常见模板导入后无数据每次给别人排这个问题十有八九是userparameter_mysql.conf没有生效。Zabbix agent加载自定义UserParameter之后直接用zabbix_get测试最直观zabbix_get -s 127.0.0.1 -k mysql.status[Uptime]如果没有返回数据先确认agent配置文件是否真的包含了Include目录即/etc/zabbix/zabbix_agentd.conf里的Include/etc/zabbix/zabbix_agentd.d/*.conf这一行有没有被注释。很多发行版默认是注释掉的光把配置文件丢进目录里根本不会生效。另一个常见问题是没有重启agent。Zabbix agent不像服务进程会自动重载配置文件改了UserParameter后必须systemctl restart zabbix-agent重启之后再执行一次zabbix_get基本上问题就能定位。5.2 权限与认证问题如果zabbix_get返回“Access denied”或者Zabbix前端有“Login failed”类报错多半是监控账号认证出问题。MariaDB从10.x开始用户认证方式可能是unix_socket或ed25519等而你的Zabbix agent在远程执行mysql命令时用的是TCP连接可能无法匹配socket认证。这种场景下最稳妥的方案就是只创建一个zbx_monitor127.0.0.1账号并显式用mysql_native_password认证方式创建CREATE USER zbx_monitor127.0.0.1 IDENTIFIED VIA mysql_native_password USING *密文的PASSWORD;如果你的MariaDB版本高这个语法可能不太一样可以用更直接的写法ALTER USER zbx_monitor127.0.0.1 IDENTIFIED VIA mysql_native_password USING PASSWORD(YourStrongPassword);另外也遇到过一种情况.my.cnf里设置了host127.0.0.1但数据库用户授权是zbx_monitorlocalhost这会导致TCP连接匹配不到账号。不要看到localhost就想当然先用命令行手动验证mysql --defaults-extra-file/etc/zabbix/.my.cnf -e SELECT 1;能正常返回1说明凭据没问题。然后再用zabbix_get测试两步一分就清楚问题在哪了。5.3 宏变量与时间戳问题Zabbix官方模板里的宏比较多比如{$MYSQL.DIR}、{$MYSQL.PASSWORD}等。如果你用的模板没有按环境调整宏监控项会被禁用或返回错误。尤其要注意宏的默认值比如官方模板里的{$MYSQL.DIR}可能指向/var/run/mysqld/mysqld.sock而MariaDB套件安装后的socket路径往往是/run/mysqld/mysqld.sock一个字符不匹配就可能导致连接失败。时间戳的问题比较隐蔽。Uptime这个指标返回的是秒数如果你不小心把它的信息类型配置成“数字无正负”Zabbix前端会显示一个巨大的数看着都知道不对。凡是Uptime、Threads_connected这类计数型指标信息类型必须是“数字无正负”Slave_IO_Running这种字符串型指标则要配置成“字符”否则触发器表达式根本无法匹配。我自己吃过大亏当年把Threads_connected配成了“浮点数”前端显示一切正常触发器却一直不生效排查到半夜才发现是字段类型错了。5.4 历史数据保留策略最后顺便说一个大多数人不会立刻注意到的点Zabbix默认的历史数据保留周期和时间序列数据保留周期设置。MariaDB监控项每分钟采一次数据如果你保留策略太短比如只有7天那么等你发现数据库性能下降想回看半个月前的趋势时数据早就没了。我通常把数据库监控项的历史数据保留至少30天趋势数据保留一年。代价是数据库表会稍微大一点但比起事后查无此数据的尴尬这点磁盘开销完全值。这些坑我都是实际踩过的。第一次搭建Zabbix监控MariaDB时光是让模板从“不支持”变成“正常”就花了整个下午原因不过是一个.my.cnf权限设成了644。从那以后我养成了习惯每新增一个监控项先手动跑一遍底层命令确认输出正确再上Zabbix。自动化监控是帮你看远处风险的前提是你得先一步一步地走通眼前的路。