Zabbix监控MariaDB服务最大的误区就是“模板一挂万事大吉”。我见过太多环境只监控了3306端口和进程存活结果数据库连接打满、主从复制断了、慢查询突然飙升Zabbix面板还是一片安静。真正可用的监控不只是“它活着”而是能提前告诉你“它快撑不住了”“复制已经开始堆积”“某个指标正在偏离基线”。这篇内容围绕Zabbix监控MariaDB服务展开从采集链路、账号权限、Agent 2插件、自定义Key、触发器设计到告警收敛完整讲一套可落地的方案。适合运维、DBA、SRE以及正在搭监控体系的朋友参考。下面按我实际踩坑后的思路拆开讲尽量把每个参数和选择理由都说明白。1. 监控目标拆解与整体方案设计1.1 先分清服务存活、实例状态、业务健康三层很多人一说“监控MariaDB”第一反应就是加一个TCP端口检测。这个做法不能算错但只覆盖了最外层。端口通只代表MariaDB进程还在监听不代表它能正常执行查询连接数没满也不代表慢查询没有拖垮InnoDB主从线程显示Yes也不代表延迟没有持续扩大。所以我一般把MariaDB监控拆成三层第一层是服务存活包括端口、进程、systemd单元、ping查询第二层是实例状态包括连接数、线程、QPS、TPS、缓冲池、临时表、锁等待第三层是业务健康包括慢查询、复制延迟、Galera集群状态、磁盘空间增长趋势。三层分开之后采集方式、告警级别和排查路径都会清晰很多。Zabbix在这里的优势是采集、存储、触发器、告警闭环都比较完整。MariaDB本身又兼容MySQL协议所以Zabbix Agent 2的MySQL插件可以直接拿来用。但要注意MariaDB有一些自己的状态变量比如Galera相关的wsrep_*还有一些变量名在不同版本里有差异。因此我通常采用“内置插件打底自定义脚本补盲区”的组合不把全部希望押在一个模板上。这样即使升级MariaDB版本也能快速调整。1.2 采集方式选型Agent 2内置插件、自定义脚本还是远端SQL采集方式我对比过几种最后稳定下来的组合是标准状态变量走Zabbix Agent 2的MySQL插件MariaDB特有指标和复杂计算走自定义脚本。为什么不全部用自定义脚本因为Agent 2插件已经封装了连接管理、JSON输出和部分发现规则维护成本低。为什么不全部用内置插件因为MariaDB的某些变量、复制状态和Galera指标内置模板不一定覆盖而且阈值和触发器逻辑各家差异很大。下面这张表是我在实际环境里做选型时的判断依据采集方式适合场景优点缺点Zabbix Agent 2 MySQL插件全局状态、进程存活、库大小、复制基础状态配置简单JSON输出方便做依赖项需要Agent 2连接信息在配置文件中自定义脚本加UserParameterMariaDB特有变量、复杂计算、白名单控制灵活可控制权限和输出格式需要维护脚本和权限Zabbix Server远端执行SQL没有Agent或跨网络采集不依赖本机Agent凭据暴露风险高网络和权限难控外部脚本加定时任务推送特殊采集或离线环境不受Zabbix采集周期限制数据链路不统一排查麻烦我的建议很直接优先用Agent 2插件补不齐的指标再用自定义脚本。远端SQL和定时任务推送只作为兜底不作为主链路。1.3 指标优先级与采集频率基线监控项不是越多越好采集频率也不是越密越好。MariaDB的状态变量大多是累计值采集太频繁会增加Agent和数据库开销采集太慢又会让告警滞后。我一般按“故障影响面”和“变化速度”来定频率。服务存活和复制状态变化快30秒到1分钟连接数、线程数、QPS、TPS1分钟InnoDB、临时表、慢查询趋势3到5分钟磁盘空间、库大小5到15分钟。下面是我常用的基线表具体数值可以根据业务峰值调整。指标类别典型指标建议频率告警级别服务存活mysql.ping、端口、进程30秒到1分钟灾难连接与线程Threads_connected、Threads_running1分钟严重吞吐Questions、Com_commit、Com_rollback1分钟警告到严重复制Seconds_Behind_Master、IO/SQL线程30秒到1分钟严重到灾难InnoDB缓冲池命中率、脏页、行锁等待3到5分钟警告临时表与慢查询Created_tmp_disk_tables、Slow_queries3到5分钟警告容量数据目录磁盘、库大小5到15分钟严重这里有个经验Seconds_Behind_Master不要只看瞬时值要结合持续时间和复制线程状态。从库SQL线程空闲时这个值可能为0也可能为NULL网络抖动时可能瞬间跳高。触发器必须加持续时间否则告警会炸。QPS和TPS也一样要看突增突降而不是单点绝对值。2. 数据库侧准备与Agent采集链路搭建2.1 创建最小权限只读监控账号监控账号的第一原则是“只读、最小权限、只能本机登录”。不要用root也不要用业务账号。MariaDB里创建监控账号的SQL大致如下CREATE USER zbx_monitor127.0.0.1 IDENTIFIED BY 替换为强密码; GRANT PROCESS, REPLICATION CLIENT ON *.* TO zbx_monitor127.0.0.1; GRANT SELECT ON performance_schema.* TO zbx_monitor127.0.0.1; FLUSH PRIVILEGES;PROCESS用于查看线程和状态REPLICATION CLIENT用于查看主从状态performance_schema的查询权限用于部分性能指标。如果还要监控所有库的大小Agent 2的mysql.db.size可能需要读取information_schema这时通常要评估是否授予更宽的SELECT权限。我的做法是如果平台对库表信息敏感就不开全库SELECT只监控实例级指标如果必须监控库大小就单独授权并记录原因。密码文件建议放在/etc/zabbix/.my.cnf权限600属主为zabbix用户。内容示例[client] host127.0.0.1 port3306 userzbx_monitor password替换为强密码 default-character-setutf8mb4然后执行chown zabbix:zabbix /etc/zabbix/.my.cnf chmod 600 /etc/zabbix/.my.cnf注意监控账号不要开SUPER不要开GRANT不要允许从任意主机登录。密码文件权限一旦放开等于把数据库凭据送出去。2.2 配置Zabbix Agent 2的MariaDB连接Zabbix Agent 2使用MySQL插件连接MariaDB配置目录通常在/etc/zabbix/zabbix_agent2.d/plugins.d/。新建一个mariadb.confPlugins.Mysql.Sessions.mariadb.Uritcp://zbx_monitor:替换为强密码127.0.0.1:3306/这里的mariadb是会话名后面在监控项Key里会用到比如mysql.ping[mariadb]。如果密码里包含、:、/等特殊字符需要做URL编码否则连接串会被解析错。配置文件权限也要收紧chown zabbix:zabbix /etc/zabbix/zabbix_agent2.d/plugins.d/mariadb.conf chmod 600 /etc/zabbix/zabbix_agent2.d/plugins.d/mariadb.conf systemctl restart zabbix-agent2重启后先用Agent自带的测试参数验证zabbix_agent2 -t mysql.ping[mariadb] zabbix_agent2 -t mysql.get_status_variables[mariadb]正常情况mysql.ping返回1mysql.get_status_variables返回一段JSON。如果返回ZBX_NOTSUPPORTED优先看Agent日志和连接串。这里有个小坑不同Zabbix版本的插件Key和配置项可能有差异尤其是6.0和6.4之后。我一般会用zabbix_agent2 -t先验证再往模板里填不凭记忆硬写。2.3 主机绑定与模板关联在Zabbix Web端创建或选择对应主机把MariaDB模板链接上去。主机接口可以是Agent接口端口10050。如果Zabbix Server和Agent之间是主动模式还要确认ServerActive配置正确。模板关联后主机宏里通常会放阈值比如连接数使用率、复制延迟、磁盘剩余空间。我的习惯是把阈值做成主机宏而不是写死在触发器里。这样同一套模板可以给不同规格的数据库用比如核心库连接数告警85%报表库可以放到90%。关联完成后去“最新数据”里看几个核心指标有没有值。mysql.ping、Threads_connected、Questions、Seconds_Behind_Master至少要有数。没有数不要急着怪模板先回到Agent测试命令。链路是Zabbix Server或Proxy采集AgentAgent调用插件插件连MariaDBMariaDB返回状态。任何一层断了最新数据都会空。3. 核心监控项与自定义Key实现3.1 用内置Key快速拿到全局状态Zabbix Agent 2的MySQL插件可以拿到不少基础数据。我常用的Key包括mysql.ping[会话名]、mysql.get_status_variables[会话名]、mysql.get_global_variables[会话名]、mysql.replication.get_slave_status[会话名]。其中mysql.get_status_variables会返回SHOW GLOBAL STATUS的JSON适合做依赖项。比如先建一个主监控项再用依赖项提取Threads_connected、Threads_running、Questions、Slow_queries。这样采集一次多个监控项共享数据数据库压力小。如果模板里没有现成的依赖项也可以直接建独立监控项。独立监控项的优点是配置直观缺点是每个指标都会触发一次采集。实例少的时候无所谓实例多了就要考虑Agent和数据库的开销。我的建议是核心指标少而准用独立监控项大量状态变量用主项加依赖项。复制状态用插件返回JSON再依赖出IO线程、SQL线程、延迟和错误信息处理起来比较统一。3.2 自定义脚本补齐连接数、QPS、TPS和慢查询内置插件覆盖不到或需要白名单控制时我会写一个统一脚本。脚本放在/etc/zabbix/scripts/mariadb_status.sh由UserParameter调用。下面是一个简化但可用的版本#!/usr/bin/env bash set -euo pipefail MYSQL_CNF/etc/zabbix/.my.cnf MODE${1:-} NAME${2:-} SQL case $MODE:$NAME in status:Threads_connected|status:Threads_running|status:Questions|status:Com_commit|status:Com_rollback|status:Slow_queries|status:Innodb_buffer_pool_reads|status:Innodb_buffer_pool_read_requests|status:Created_tmp_disk_tables|status:Created_tmp_tables|status:Aborted_connects|status:Aborted_clients|status:Table_locks_waited|status:Table_locks_immediate|status:wsrep_cluster_size|status:wsrep_ready) SQLSHOW GLOBAL STATUS LIKE ${NAME} ;; variable:max_connections) SQLSHOW GLOBAL VARIABLES LIKE ${NAME} ;; slave:delay) SQLSHOW SLAVE STATUS ;; ping) mariadb --defaults-extra-file$MYSQL_CNF -N -B -e SELECT 1 /dev/null 21 echo 1 || echo 0 exit 0 ;; *) echo ZBX_NOTSUPPORTED: unsupported metric $MODE:$NAME 2 exit 1 ;; esac if [ $MODE:$NAME slave:delay ]; then val$(mariadb --defaults-extra-file$MYSQL_CNF -N -B -e $SQL | awk -F\t NR1{for(i1;iNF;i) if($iSeconds_Behind_Master) coli} NR2{print $col}) if [ -z $val ] || [ $val NULL ]; then echo -1 else echo $val fi else mariadb --defaults-extra-file$MYSQL_CNF -N -B -e $SQL | awk NR2{print $2} fiUserParameter配置UserParametermariadb.status[*],/etc/zabbix/scripts/mariadb_status.sh status $1 UserParametermariadb.variable[*],/etc/zabbix/scripts/mariadb_status.sh variable $1 UserParametermariadb.slave.delay,/etc/zabbix/scripts/mariadb_status.sh slave delay UserParametermariadb.ping,/etc/zabbix/scripts/mariadb_status.sh ping记得赋权chmod x /etc/zabbix/scripts/mariadb_status.sh chown zabbix:zabbix /etc/zabbix/scripts/mariadb_status.shQPS可以用Questions做“变化率”预处理。监控项类型选数字无符号更新间隔60秒预处理选“Change per second”。TPS可以用Com_commit和Com_rollback分别做变化率再建一个计算项相加。慢查询用Slow_queries的变化率比看累计值更有意义。连接数使用率建议用计算项100 * last(/主机/mariadb.status[Threads_connected]) / last(/主机/mariadb.variable[max_connections])触发器设为大于85持续5分钟告警大于95持续1分钟严重告警。这样不会因为一瞬间的连接突增就报警。3.3 主从复制与Galera集群状态主从复制是MariaDB监控的重头戏。Seconds_Behind_Master必须采但不能只采它。还要看Slave_IO_Running和Slave_SQL_Running。如果IO线程断了延迟可能显示NULL如果SQL线程断了延迟可能不再增长但数据已经停止同步。自定义脚本里可以把这两个状态转成1和0方便触发器判断。触发器思路是IO线程不等于Yes持续3次告警SQL线程不等于Yes立即严重告警延迟大于300秒持续5分钟告警大于900秒持续1分钟升级。last(/主机/mariadb.slave.delay) 300 and last(/主机/mariadb.slave.delay) -1如果使用Galera集群还要监控wsrep_cluster_size、wsrep_cluster_status、wsrep_ready、wsrep_connected、wsrep_flow_control_paused。集群节点数小于2通常意味着失去仲裁风险wsrep_ready为0说明节点不可写。wsrep_flow_control_paused持续大于0.1说明集群在流控写入可能被节流。这些指标对MariaDB集群非常关键普通MySQL模板往往没有需要自己补。3.4 InnoDB、临时表、锁等待指标InnoDB缓冲池命中率是判断内存是否够用的重要指标。粗略计算方式是100 * (1 - Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests)但直接用累计值算比率长期看会接近100不容易发现短期恶化。更稳的做法是分别对Innodb_buffer_pool_reads和Innodb_buffer_pool_read_requests做每秒变化率再用计算项算比率。低于95%持续10分钟可以警告低于90%持续5分钟可以严重。临时表磁盘比率可以用Created_tmp_disk_tables / Created_tmp_tables大于25%说明很多临时结果落盘要考虑优化SQL或调整tmp_table_size、max_heap_table_size。行锁等待看Innodb_row_lock_waits和Innodb_row_lock_time_avg表锁等待看Table_locks_waited与Table_locks_immediate的比值。这些指标不适合做“秒级告警”更适合做趋势和容量评估。我的经验是InnoDB命中率突然下降往往伴随大查询或数据量突增临时表磁盘比率升高通常是某个报表SQL在作怪锁等待升高可能是长事务没有提交。把这些指标和慢查询、QPS放在同一张图上看排查效率会高很多。3.5 触发器表达式设计让告警不炸也不漏触发器设计要解决两个问题一是不要因为瞬时抖动炸群二是不要在真正故障时沉默。我的原则是服务存活类触发器短周期、少次数性能类触发器长周期、看趋势复制类触发器看线程状态加延迟。比如场景表达式思路持续时间MariaDB不可用last(/主机/mariadb.ping)03次连接数过高连接使用率855分钟复制延迟高延迟300且不等于-15分钟复制线程停止IO或SQL线程非Yes3次InnoDB命中率低命中率9510分钟磁盘空间不足剩余20%5分钟告警级别也要区分。服务不可用、复制完全中断、磁盘低于5%是灾难连接数超过95%、延迟超过900秒是严重连接数超过85%、延迟超过300秒是一般InnoDB命中率下降是警告。有了级别值班同学才知道先看哪个。4. 可视化、告警收敛与批量落地4.1 仪表盘怎么摆才方便排查我习惯把MariaDB仪表盘分成四块第一块是服务概览放ping、端口、进程、运行时间第二块是连接与吞吐放连接数、活动线程、QPS、TPS第三块是复制与集群放IO/SQL线程、延迟、Galera节点状态第四块是资源与InnoDB放缓冲池命中率、临时表、锁等待、磁盘空间。这样值班时先看第一块确认服务活着再看第二块判断压力第三块看数据一致性第四块定位性能瓶颈。图表不要堆太多线。连接数和最大连接数放一张图QPS和TPS放一张图复制延迟单独一张图。磁盘空间和库大小可以放同一张图但要用不同颜色区分。我的习惯是每张图最多三条线超过就拆图。Zabbix的仪表盘支持聚合和动态项但不要为了好看加太多组件排查时加载慢反而影响效率。4.2 告警收敛分级、依赖和维护窗口告警收敛是监控体系能不能长期用下去的关键。MariaDB挂掉时连接数、QPS、复制延迟可能同时告警。如果不做依赖关系值班同学会收到几十条通知。我一般会设置依赖主机不可达时抑制该主机上所有MariaDB性能告警MariaDB服务不可用时抑制连接数、QPS、复制延迟复制IO线程断开时抑制延迟告警因为延迟可能已经无意义。维护窗口也要用起来升级、备份、大促前提前设置避免正常操作触发告警。通知渠道上灾难和严重走电话或即时消息一般和警告走群消息或邮件。同一条告警在短时间内重复触发要做收敛比如10分钟内同一触发器只发一次恢复时再发一次。这些配置不复杂但能极大降低告警疲劳。4.3 模板导出、版本管理与批量关联模板做好后不要只留在Web界面里。Zabbix支持导出XML或YAML我通常把模板导出后放进Git仓库每次修改都提交。这样升级Zabbix版本或迁移环境时可以快速恢复也方便对比触发器表达式变化。模板里的阈值尽量用宏比如{$MARIADB.CONN.USAGE.WARN}、{$MARIADB.REPL.DELAY.WARN}。宏可以在主机、模板、全局三个层级覆盖批量关联时非常省事。如果需要给几十台MariaDB批量关联模板手动点不现实。可以用Zabbix API写个小脚本读取主机列表批量链接模板并设置主机宏。脚本逻辑很简单先登录获取Token再查主机再调用host.update。这里不展开完整代码核心思路是“模板统一、宏按主机覆盖、脚本批量执行”。做一次之后后面新增实例就是加主机、设宏、关联模板三步。4.4 采集性能与安全边界采集本身也会消耗MariaDB资源。Agent 2的MySQL插件会建立连接、执行状态查询。连接数不多时没问题但如果成百上千个实例都高频采集数据库和Zabbix都会累。我的建议是核心实例1分钟采集关键指标非核心实例3到5分钟状态变量用主项加依赖项QPS、TPS用变化率不要采集毫无意义的变量。Agent 2的插件会话名和连接串要保护好配置文件权限600密码不要复用业务账号。如果环境支持可以给Agent到数据库的连接启用TLS至少保证本机回环或内网可信。还有一个容易忽略的点监控账号的登录也会产生连接。如果max_connections很小监控连接虽然不多但也要算进去。一般来说预留2到5个连接给监控和备份就够了。不要把监控账号和备份账号混在一起权限和排查都会乱。5. 常见问题与排查技巧实录5.1 Agent返回ZBX_NOTSUPPORTED怎么查ZBX_NOTSUPPORTED是Zabbix监控里最常见的报错原因通常在三处Key写错、插件没加载、数据库连不上。排查顺序我固定为先看Agent日志再手动执行Key再检查插件配置最后看数据库权限。命令可以这样tail -f /var/log/zabbix/zabbix_agent2.log zabbix_agent2 -t mysql.ping[mariadb] zabbix_agent2 -t mariadb.status[Threads_connected]如果mysql.ping失败但mariadb.status成功说明自定义脚本链路没问题问题在Agent 2插件。检查/etc/zabbix/zabbix_agent2.d/plugins.d/mariadb.conf是否存在、权限是否正确、会话名是否和Key一致。如果两个都失败优先检查.my.cnf权限和数据库账号。如果只有某个指标失败检查变量名是否在MariaDB当前版本里存在比如wsrep_*只在Galera节点上存在。5.2 权限与连接错误速查表现象可能原因处理方式Access denied账号密码错、主机限制检查账号、密码、127.0.0.1限制Cant connect to MariaDB端口、套接字、防火墙检查3306监听、bind-addressUnknown system variable变量名不存在或版本差异登录数据库执行SHOW GLOBAL STATUS LIKE ...验证ZBX_NOTSUPPORTEDKey错、插件未启用、脚本无执行权限查日志、手动执行、检查脚本权限数据为0或空累计值未变化、权限不足、SQL返回空检查监控项类型和预处理复制延迟为NULL复制线程未运行或权限不足检查SHOW SLAVE STATUS和REPLICATION CLIENT权限注意排查权限问题时最好用sudo -u zabbix切到Agent运行用户测试而不是用root测试。root能跑通不代表zabbix能跑通这是新手最容易踩的坑。5.3 主从延迟误报和QPS为0的坑主从延迟误报通常有几种情况。第一从库SQL线程空闲Seconds_Behind_Master为0或NULL如果脚本不处理NULLZabbix可能报不支持。第二网络抖动导致瞬时延迟跳高触发器没有加持续时间告警瞬间发出。第三大事务或DDL在从库执行时间长延迟持续升高但这是真实问题需要结合Relay_Log_Pos和Exec_Master_Log_Pos判断。我的做法是脚本把NULL转成-1触发器排除-1并且延迟告警加5分钟持续时间。QPS为0也常见原因可能是Questions采集失败、预处理没选“Change per second”、或者监控项类型不对。累计值直接看是一条缓慢上升的线变化率才能看出每秒请求量。5.4 模板关联后无数据、数据延迟怎么办模板关联后无数据先确认主机接口是否可用。Zabbix Server或Proxy能不能访问Agent的10050端口Agent能不能访问数据库3306端口。然后看“最新数据”里有没有采集时间。如果采集时间很旧可能是Agent队列积压、Server负载高或网络延迟。如果采集时间很新但值为空看监控项类型和预处理。如果只有部分指标有数据说明模板里部分Key在当前MariaDB版本上不支持需要调整。数据延迟还有一个常见原因是时间不同步。Zabbix Server、Proxy、Agent、数据库主机之间时间偏差太大会导致“最新数据”看起来不更新触发器窗口计算也会异常。生产环境建议统一时间同步。这个点看起来基础但实际排查中经常遇到。5.5 生产环境避坑清单监控账号只读、最小权限、只允许本机登录密码文件权限600。Agent 2插件配置和自定义脚本都用zabbix用户测试不要用root测试。连接数、复制延迟、磁盘空间这类触发器必须加持续时间避免瞬时抖动误报。Seconds_Behind_Master要为NULL做特殊处理否则容易变成不支持项。QPS、TPS、慢查询用变化率不要直接看累计值。Galera集群一定要加wsrep_*指标普通MySQL模板覆盖不了。模板和宏要版本化阈值用宏不要写死在触发器里。告警依赖和抑制要配置数据库挂了只发核心告警不要炸出几十条。采集频率按实例重要性分级核心库1分钟非核心库3到5分钟。每季度回顾一次告警记录把长期不触发和长期误报的触发器重新调阈值。我个人在实际操作中的体会是Zabbix监控MariaDB服务最难的不是装Agent也不是写SQL而是“知道哪些指标值得告警哪些指标只适合看趋势”。连接数、复制线程、磁盘空间、服务存活这四类必须告警InnoDB命中率、临时表、锁等待更适合做容量分析和排障参考。还有一个小技巧把慢查询数量、QPS、连接数放在同一张仪表盘上当慢查询升高但QPS没涨通常是某条SQL变差当连接数升高但QPS没涨通常是连接池配置或长事务问题。监控数据本身不会说话把它们放在一起看故障轮廓才会出来。
Zabbix监控MariaDB服务最大的误区就是“模板一挂万事大吉”。我见过太多环境只监控了3306端口和进程存活结果数据库连接打满、主从复制断了、慢查询突然飙升Zabbix面板还是一片安静。真正可用的监控不只是“它活着”而是能提前告诉你“它快撑不住了”“复制已经开始堆积”“某个指标正在偏离基线”。这篇内容围绕Zabbix监控MariaDB服务展开从采集链路、账号权限、Agent 2插件、自定义Key、触发器设计到告警收敛完整讲一套可落地的方案。适合运维、DBA、SRE以及正在搭监控体系的朋友参考。下面按我实际踩坑后的思路拆开讲尽量把每个参数和选择理由都说明白。1. 监控目标拆解与整体方案设计1.1 先分清服务存活、实例状态、业务健康三层很多人一说“监控MariaDB”第一反应就是加一个TCP端口检测。这个做法不能算错但只覆盖了最外层。端口通只代表MariaDB进程还在监听不代表它能正常执行查询连接数没满也不代表慢查询没有拖垮InnoDB主从线程显示Yes也不代表延迟没有持续扩大。所以我一般把MariaDB监控拆成三层第一层是服务存活包括端口、进程、systemd单元、ping查询第二层是实例状态包括连接数、线程、QPS、TPS、缓冲池、临时表、锁等待第三层是业务健康包括慢查询、复制延迟、Galera集群状态、磁盘空间增长趋势。三层分开之后采集方式、告警级别和排查路径都会清晰很多。Zabbix在这里的优势是采集、存储、触发器、告警闭环都比较完整。MariaDB本身又兼容MySQL协议所以Zabbix Agent 2的MySQL插件可以直接拿来用。但要注意MariaDB有一些自己的状态变量比如Galera相关的wsrep_*还有一些变量名在不同版本里有差异。因此我通常采用“内置插件打底自定义脚本补盲区”的组合不把全部希望押在一个模板上。这样即使升级MariaDB版本也能快速调整。1.2 采集方式选型Agent 2内置插件、自定义脚本还是远端SQL采集方式我对比过几种最后稳定下来的组合是标准状态变量走Zabbix Agent 2的MySQL插件MariaDB特有指标和复杂计算走自定义脚本。为什么不全部用自定义脚本因为Agent 2插件已经封装了连接管理、JSON输出和部分发现规则维护成本低。为什么不全部用内置插件因为MariaDB的某些变量、复制状态和Galera指标内置模板不一定覆盖而且阈值和触发器逻辑各家差异很大。下面这张表是我在实际环境里做选型时的判断依据采集方式适合场景优点缺点Zabbix Agent 2 MySQL插件全局状态、进程存活、库大小、复制基础状态配置简单JSON输出方便做依赖项需要Agent 2连接信息在配置文件中自定义脚本加UserParameterMariaDB特有变量、复杂计算、白名单控制灵活可控制权限和输出格式需要维护脚本和权限Zabbix Server远端执行SQL没有Agent或跨网络采集不依赖本机Agent凭据暴露风险高网络和权限难控外部脚本加定时任务推送特殊采集或离线环境不受Zabbix采集周期限制数据链路不统一排查麻烦我的建议很直接优先用Agent 2插件补不齐的指标再用自定义脚本。远端SQL和定时任务推送只作为兜底不作为主链路。1.3 指标优先级与采集频率基线监控项不是越多越好采集频率也不是越密越好。MariaDB的状态变量大多是累计值采集太频繁会增加Agent和数据库开销采集太慢又会让告警滞后。我一般按“故障影响面”和“变化速度”来定频率。服务存活和复制状态变化快30秒到1分钟连接数、线程数、QPS、TPS1分钟InnoDB、临时表、慢查询趋势3到5分钟磁盘空间、库大小5到15分钟。下面是我常用的基线表具体数值可以根据业务峰值调整。指标类别典型指标建议频率告警级别服务存活mysql.ping、端口、进程30秒到1分钟灾难连接与线程Threads_connected、Threads_running1分钟严重吞吐Questions、Com_commit、Com_rollback1分钟警告到严重复制Seconds_Behind_Master、IO/SQL线程30秒到1分钟严重到灾难InnoDB缓冲池命中率、脏页、行锁等待3到5分钟警告临时表与慢查询Created_tmp_disk_tables、Slow_queries3到5分钟警告容量数据目录磁盘、库大小5到15分钟严重这里有个经验Seconds_Behind_Master不要只看瞬时值要结合持续时间和复制线程状态。从库SQL线程空闲时这个值可能为0也可能为NULL网络抖动时可能瞬间跳高。触发器必须加持续时间否则告警会炸。QPS和TPS也一样要看突增突降而不是单点绝对值。2. 数据库侧准备与Agent采集链路搭建2.1 创建最小权限只读监控账号监控账号的第一原则是“只读、最小权限、只能本机登录”。不要用root也不要用业务账号。MariaDB里创建监控账号的SQL大致如下CREATE USER zbx_monitor127.0.0.1 IDENTIFIED BY 替换为强密码; GRANT PROCESS, REPLICATION CLIENT ON *.* TO zbx_monitor127.0.0.1; GRANT SELECT ON performance_schema.* TO zbx_monitor127.0.0.1; FLUSH PRIVILEGES;PROCESS用于查看线程和状态REPLICATION CLIENT用于查看主从状态performance_schema的查询权限用于部分性能指标。如果还要监控所有库的大小Agent 2的mysql.db.size可能需要读取information_schema这时通常要评估是否授予更宽的SELECT权限。我的做法是如果平台对库表信息敏感就不开全库SELECT只监控实例级指标如果必须监控库大小就单独授权并记录原因。密码文件建议放在/etc/zabbix/.my.cnf权限600属主为zabbix用户。内容示例[client] host127.0.0.1 port3306 userzbx_monitor password替换为强密码 default-character-setutf8mb4然后执行chown zabbix:zabbix /etc/zabbix/.my.cnf chmod 600 /etc/zabbix/.my.cnf注意监控账号不要开SUPER不要开GRANT不要允许从任意主机登录。密码文件权限一旦放开等于把数据库凭据送出去。2.2 配置Zabbix Agent 2的MariaDB连接Zabbix Agent 2使用MySQL插件连接MariaDB配置目录通常在/etc/zabbix/zabbix_agent2.d/plugins.d/。新建一个mariadb.confPlugins.Mysql.Sessions.mariadb.Uritcp://zbx_monitor:替换为强密码127.0.0.1:3306/这里的mariadb是会话名后面在监控项Key里会用到比如mysql.ping[mariadb]。如果密码里包含、:、/等特殊字符需要做URL编码否则连接串会被解析错。配置文件权限也要收紧chown zabbix:zabbix /etc/zabbix/zabbix_agent2.d/plugins.d/mariadb.conf chmod 600 /etc/zabbix/zabbix_agent2.d/plugins.d/mariadb.conf systemctl restart zabbix-agent2重启后先用Agent自带的测试参数验证zabbix_agent2 -t mysql.ping[mariadb] zabbix_agent2 -t mysql.get_status_variables[mariadb]正常情况mysql.ping返回1mysql.get_status_variables返回一段JSON。如果返回ZBX_NOTSUPPORTED优先看Agent日志和连接串。这里有个小坑不同Zabbix版本的插件Key和配置项可能有差异尤其是6.0和6.4之后。我一般会用zabbix_agent2 -t先验证再往模板里填不凭记忆硬写。2.3 主机绑定与模板关联在Zabbix Web端创建或选择对应主机把MariaDB模板链接上去。主机接口可以是Agent接口端口10050。如果Zabbix Server和Agent之间是主动模式还要确认ServerActive配置正确。模板关联后主机宏里通常会放阈值比如连接数使用率、复制延迟、磁盘剩余空间。我的习惯是把阈值做成主机宏而不是写死在触发器里。这样同一套模板可以给不同规格的数据库用比如核心库连接数告警85%报表库可以放到90%。关联完成后去“最新数据”里看几个核心指标有没有值。mysql.ping、Threads_connected、Questions、Seconds_Behind_Master至少要有数。没有数不要急着怪模板先回到Agent测试命令。链路是Zabbix Server或Proxy采集AgentAgent调用插件插件连MariaDBMariaDB返回状态。任何一层断了最新数据都会空。3. 核心监控项与自定义Key实现3.1 用内置Key快速拿到全局状态Zabbix Agent 2的MySQL插件可以拿到不少基础数据。我常用的Key包括mysql.ping[会话名]、mysql.get_status_variables[会话名]、mysql.get_global_variables[会话名]、mysql.replication.get_slave_status[会话名]。其中mysql.get_status_variables会返回SHOW GLOBAL STATUS的JSON适合做依赖项。比如先建一个主监控项再用依赖项提取Threads_connected、Threads_running、Questions、Slow_queries。这样采集一次多个监控项共享数据数据库压力小。如果模板里没有现成的依赖项也可以直接建独立监控项。独立监控项的优点是配置直观缺点是每个指标都会触发一次采集。实例少的时候无所谓实例多了就要考虑Agent和数据库的开销。我的建议是核心指标少而准用独立监控项大量状态变量用主项加依赖项。复制状态用插件返回JSON再依赖出IO线程、SQL线程、延迟和错误信息处理起来比较统一。3.2 自定义脚本补齐连接数、QPS、TPS和慢查询内置插件覆盖不到或需要白名单控制时我会写一个统一脚本。脚本放在/etc/zabbix/scripts/mariadb_status.sh由UserParameter调用。下面是一个简化但可用的版本#!/usr/bin/env bash set -euo pipefail MYSQL_CNF/etc/zabbix/.my.cnf MODE${1:-} NAME${2:-} SQL case $MODE:$NAME in status:Threads_connected|status:Threads_running|status:Questions|status:Com_commit|status:Com_rollback|status:Slow_queries|status:Innodb_buffer_pool_reads|status:Innodb_buffer_pool_read_requests|status:Created_tmp_disk_tables|status:Created_tmp_tables|status:Aborted_connects|status:Aborted_clients|status:Table_locks_waited|status:Table_locks_immediate|status:wsrep_cluster_size|status:wsrep_ready) SQLSHOW GLOBAL STATUS LIKE ${NAME} ;; variable:max_connections) SQLSHOW GLOBAL VARIABLES LIKE ${NAME} ;; slave:delay) SQLSHOW SLAVE STATUS ;; ping) mariadb --defaults-extra-file$MYSQL_CNF -N -B -e SELECT 1 /dev/null 21 echo 1 || echo 0 exit 0 ;; *) echo ZBX_NOTSUPPORTED: unsupported metric $MODE:$NAME 2 exit 1 ;; esac if [ $MODE:$NAME slave:delay ]; then val$(mariadb --defaults-extra-file$MYSQL_CNF -N -B -e $SQL | awk -F\t NR1{for(i1;iNF;i) if($iSeconds_Behind_Master) coli} NR2{print $col}) if [ -z $val ] || [ $val NULL ]; then echo -1 else echo $val fi else mariadb --defaults-extra-file$MYSQL_CNF -N -B -e $SQL | awk NR2{print $2} fiUserParameter配置UserParametermariadb.status[*],/etc/zabbix/scripts/mariadb_status.sh status $1 UserParametermariadb.variable[*],/etc/zabbix/scripts/mariadb_status.sh variable $1 UserParametermariadb.slave.delay,/etc/zabbix/scripts/mariadb_status.sh slave delay UserParametermariadb.ping,/etc/zabbix/scripts/mariadb_status.sh ping记得赋权chmod x /etc/zabbix/scripts/mariadb_status.sh chown zabbix:zabbix /etc/zabbix/scripts/mariadb_status.shQPS可以用Questions做“变化率”预处理。监控项类型选数字无符号更新间隔60秒预处理选“Change per second”。TPS可以用Com_commit和Com_rollback分别做变化率再建一个计算项相加。慢查询用Slow_queries的变化率比看累计值更有意义。连接数使用率建议用计算项100 * last(/主机/mariadb.status[Threads_connected]) / last(/主机/mariadb.variable[max_connections])触发器设为大于85持续5分钟告警大于95持续1分钟严重告警。这样不会因为一瞬间的连接突增就报警。3.3 主从复制与Galera集群状态主从复制是MariaDB监控的重头戏。Seconds_Behind_Master必须采但不能只采它。还要看Slave_IO_Running和Slave_SQL_Running。如果IO线程断了延迟可能显示NULL如果SQL线程断了延迟可能不再增长但数据已经停止同步。自定义脚本里可以把这两个状态转成1和0方便触发器判断。触发器思路是IO线程不等于Yes持续3次告警SQL线程不等于Yes立即严重告警延迟大于300秒持续5分钟告警大于900秒持续1分钟升级。last(/主机/mariadb.slave.delay) 300 and last(/主机/mariadb.slave.delay) -1如果使用Galera集群还要监控wsrep_cluster_size、wsrep_cluster_status、wsrep_ready、wsrep_connected、wsrep_flow_control_paused。集群节点数小于2通常意味着失去仲裁风险wsrep_ready为0说明节点不可写。wsrep_flow_control_paused持续大于0.1说明集群在流控写入可能被节流。这些指标对MariaDB集群非常关键普通MySQL模板往往没有需要自己补。3.4 InnoDB、临时表、锁等待指标InnoDB缓冲池命中率是判断内存是否够用的重要指标。粗略计算方式是100 * (1 - Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests)但直接用累计值算比率长期看会接近100不容易发现短期恶化。更稳的做法是分别对Innodb_buffer_pool_reads和Innodb_buffer_pool_read_requests做每秒变化率再用计算项算比率。低于95%持续10分钟可以警告低于90%持续5分钟可以严重。临时表磁盘比率可以用Created_tmp_disk_tables / Created_tmp_tables大于25%说明很多临时结果落盘要考虑优化SQL或调整tmp_table_size、max_heap_table_size。行锁等待看Innodb_row_lock_waits和Innodb_row_lock_time_avg表锁等待看Table_locks_waited与Table_locks_immediate的比值。这些指标不适合做“秒级告警”更适合做趋势和容量评估。我的经验是InnoDB命中率突然下降往往伴随大查询或数据量突增临时表磁盘比率升高通常是某个报表SQL在作怪锁等待升高可能是长事务没有提交。把这些指标和慢查询、QPS放在同一张图上看排查效率会高很多。3.5 触发器表达式设计让告警不炸也不漏触发器设计要解决两个问题一是不要因为瞬时抖动炸群二是不要在真正故障时沉默。我的原则是服务存活类触发器短周期、少次数性能类触发器长周期、看趋势复制类触发器看线程状态加延迟。比如场景表达式思路持续时间MariaDB不可用last(/主机/mariadb.ping)03次连接数过高连接使用率855分钟复制延迟高延迟300且不等于-15分钟复制线程停止IO或SQL线程非Yes3次InnoDB命中率低命中率9510分钟磁盘空间不足剩余20%5分钟告警级别也要区分。服务不可用、复制完全中断、磁盘低于5%是灾难连接数超过95%、延迟超过900秒是严重连接数超过85%、延迟超过300秒是一般InnoDB命中率下降是警告。有了级别值班同学才知道先看哪个。4. 可视化、告警收敛与批量落地4.1 仪表盘怎么摆才方便排查我习惯把MariaDB仪表盘分成四块第一块是服务概览放ping、端口、进程、运行时间第二块是连接与吞吐放连接数、活动线程、QPS、TPS第三块是复制与集群放IO/SQL线程、延迟、Galera节点状态第四块是资源与InnoDB放缓冲池命中率、临时表、锁等待、磁盘空间。这样值班时先看第一块确认服务活着再看第二块判断压力第三块看数据一致性第四块定位性能瓶颈。图表不要堆太多线。连接数和最大连接数放一张图QPS和TPS放一张图复制延迟单独一张图。磁盘空间和库大小可以放同一张图但要用不同颜色区分。我的习惯是每张图最多三条线超过就拆图。Zabbix的仪表盘支持聚合和动态项但不要为了好看加太多组件排查时加载慢反而影响效率。4.2 告警收敛分级、依赖和维护窗口告警收敛是监控体系能不能长期用下去的关键。MariaDB挂掉时连接数、QPS、复制延迟可能同时告警。如果不做依赖关系值班同学会收到几十条通知。我一般会设置依赖主机不可达时抑制该主机上所有MariaDB性能告警MariaDB服务不可用时抑制连接数、QPS、复制延迟复制IO线程断开时抑制延迟告警因为延迟可能已经无意义。维护窗口也要用起来升级、备份、大促前提前设置避免正常操作触发告警。通知渠道上灾难和严重走电话或即时消息一般和警告走群消息或邮件。同一条告警在短时间内重复触发要做收敛比如10分钟内同一触发器只发一次恢复时再发一次。这些配置不复杂但能极大降低告警疲劳。4.3 模板导出、版本管理与批量关联模板做好后不要只留在Web界面里。Zabbix支持导出XML或YAML我通常把模板导出后放进Git仓库每次修改都提交。这样升级Zabbix版本或迁移环境时可以快速恢复也方便对比触发器表达式变化。模板里的阈值尽量用宏比如{$MARIADB.CONN.USAGE.WARN}、{$MARIADB.REPL.DELAY.WARN}。宏可以在主机、模板、全局三个层级覆盖批量关联时非常省事。如果需要给几十台MariaDB批量关联模板手动点不现实。可以用Zabbix API写个小脚本读取主机列表批量链接模板并设置主机宏。脚本逻辑很简单先登录获取Token再查主机再调用host.update。这里不展开完整代码核心思路是“模板统一、宏按主机覆盖、脚本批量执行”。做一次之后后面新增实例就是加主机、设宏、关联模板三步。4.4 采集性能与安全边界采集本身也会消耗MariaDB资源。Agent 2的MySQL插件会建立连接、执行状态查询。连接数不多时没问题但如果成百上千个实例都高频采集数据库和Zabbix都会累。我的建议是核心实例1分钟采集关键指标非核心实例3到5分钟状态变量用主项加依赖项QPS、TPS用变化率不要采集毫无意义的变量。Agent 2的插件会话名和连接串要保护好配置文件权限600密码不要复用业务账号。如果环境支持可以给Agent到数据库的连接启用TLS至少保证本机回环或内网可信。还有一个容易忽略的点监控账号的登录也会产生连接。如果max_connections很小监控连接虽然不多但也要算进去。一般来说预留2到5个连接给监控和备份就够了。不要把监控账号和备份账号混在一起权限和排查都会乱。5. 常见问题与排查技巧实录5.1 Agent返回ZBX_NOTSUPPORTED怎么查ZBX_NOTSUPPORTED是Zabbix监控里最常见的报错原因通常在三处Key写错、插件没加载、数据库连不上。排查顺序我固定为先看Agent日志再手动执行Key再检查插件配置最后看数据库权限。命令可以这样tail -f /var/log/zabbix/zabbix_agent2.log zabbix_agent2 -t mysql.ping[mariadb] zabbix_agent2 -t mariadb.status[Threads_connected]如果mysql.ping失败但mariadb.status成功说明自定义脚本链路没问题问题在Agent 2插件。检查/etc/zabbix/zabbix_agent2.d/plugins.d/mariadb.conf是否存在、权限是否正确、会话名是否和Key一致。如果两个都失败优先检查.my.cnf权限和数据库账号。如果只有某个指标失败检查变量名是否在MariaDB当前版本里存在比如wsrep_*只在Galera节点上存在。5.2 权限与连接错误速查表现象可能原因处理方式Access denied账号密码错、主机限制检查账号、密码、127.0.0.1限制Cant connect to MariaDB端口、套接字、防火墙检查3306监听、bind-addressUnknown system variable变量名不存在或版本差异登录数据库执行SHOW GLOBAL STATUS LIKE ...验证ZBX_NOTSUPPORTEDKey错、插件未启用、脚本无执行权限查日志、手动执行、检查脚本权限数据为0或空累计值未变化、权限不足、SQL返回空检查监控项类型和预处理复制延迟为NULL复制线程未运行或权限不足检查SHOW SLAVE STATUS和REPLICATION CLIENT权限注意排查权限问题时最好用sudo -u zabbix切到Agent运行用户测试而不是用root测试。root能跑通不代表zabbix能跑通这是新手最容易踩的坑。5.3 主从延迟误报和QPS为0的坑主从延迟误报通常有几种情况。第一从库SQL线程空闲Seconds_Behind_Master为0或NULL如果脚本不处理NULLZabbix可能报不支持。第二网络抖动导致瞬时延迟跳高触发器没有加持续时间告警瞬间发出。第三大事务或DDL在从库执行时间长延迟持续升高但这是真实问题需要结合Relay_Log_Pos和Exec_Master_Log_Pos判断。我的做法是脚本把NULL转成-1触发器排除-1并且延迟告警加5分钟持续时间。QPS为0也常见原因可能是Questions采集失败、预处理没选“Change per second”、或者监控项类型不对。累计值直接看是一条缓慢上升的线变化率才能看出每秒请求量。5.4 模板关联后无数据、数据延迟怎么办模板关联后无数据先确认主机接口是否可用。Zabbix Server或Proxy能不能访问Agent的10050端口Agent能不能访问数据库3306端口。然后看“最新数据”里有没有采集时间。如果采集时间很旧可能是Agent队列积压、Server负载高或网络延迟。如果采集时间很新但值为空看监控项类型和预处理。如果只有部分指标有数据说明模板里部分Key在当前MariaDB版本上不支持需要调整。数据延迟还有一个常见原因是时间不同步。Zabbix Server、Proxy、Agent、数据库主机之间时间偏差太大会导致“最新数据”看起来不更新触发器窗口计算也会异常。生产环境建议统一时间同步。这个点看起来基础但实际排查中经常遇到。5.5 生产环境避坑清单监控账号只读、最小权限、只允许本机登录密码文件权限600。Agent 2插件配置和自定义脚本都用zabbix用户测试不要用root测试。连接数、复制延迟、磁盘空间这类触发器必须加持续时间避免瞬时抖动误报。Seconds_Behind_Master要为NULL做特殊处理否则容易变成不支持项。QPS、TPS、慢查询用变化率不要直接看累计值。Galera集群一定要加wsrep_*指标普通MySQL模板覆盖不了。模板和宏要版本化阈值用宏不要写死在触发器里。告警依赖和抑制要配置数据库挂了只发核心告警不要炸出几十条。采集频率按实例重要性分级核心库1分钟非核心库3到5分钟。每季度回顾一次告警记录把长期不触发和长期误报的触发器重新调阈值。我个人在实际操作中的体会是Zabbix监控MariaDB服务最难的不是装Agent也不是写SQL而是“知道哪些指标值得告警哪些指标只适合看趋势”。连接数、复制线程、磁盘空间、服务存活这四类必须告警InnoDB命中率、临时表、锁等待更适合做容量分析和排障参考。还有一个小技巧把慢查询数量、QPS、连接数放在同一张仪表盘上当慢查询升高但QPS没涨通常是某条SQL变差当连接数升高但QPS没涨通常是连接池配置或长事务问题。监控数据本身不会说话把它们放在一起看故障轮廓才会出来。
