1. 为什么老系统上还要折腾新版监控客户端手里还有一批 CentOS 6.8 的机器在跑核心业务这事儿在不少传统行业里一点都不稀奇。业务系统跟底层运行环境绑得太死迁移成本高到没人敢轻易动于是这些老将就一直坚守在机房里。但问题来了——监控体系要升级服务端已经换到了 Zabbix 5.0客户端却还停留在 3.x 甚至 2.x 的版本数据采集口径对不上新模板用不了告警规则也没法统一管理。这个场景的核心矛盾在于操作系统版本老但监控需求新。Zabbix-agent 5.0 官方提供的二进制包主要面向 CentOS 7 及以上直接拿到 CentOS 6.8 上跑大概率会遇到 glibc 版本不兼容、systemd 脚本无法识别、依赖库缺失这一连串问题。很多人第一反应是降级用老版本 agent 算了但老版本 agent 在采集 MySQL 性能指标时键值key的命名规则和新版 server 的模板不匹配等于白装。所以这篇内容要解决的就是在 CentOS 6.8 这个老平台上把 Zabbix-agent 5.0 跑起来并且让它同时承担主机性能采集和 MySQL 数据库监控两个职责。适合谁看手里有存量老系统、又不想在监控体系上妥协的运维人员正在做监控平台统一化改造、被老机器拖后腿的工程师以及想搞清楚 Zabbix-agent 在异构环境中怎么落地的人。我前后在三批不同配置的 CentOS 6.8 机器上做过这个事踩过的坑包括但不限于编译安装时 OpenSSL 头文件找不到、agent 启动后 server 端显示ZBX_NOTSUPPORTED、MySQL 监控脚本权限不对导致采集为空。下面把这些经验完整拆开讲尽量让你一次跑通。2. 编译安装 Zabbix-agent 5.0 的完整链路2.1 源码编译是唯一靠谱的路CentOS 6.8 的 yum 源里能直接装的 zabbix-agent 版本最高也就到 3.0而且官方早就停止维护了。想上 5.0源码编译是绕不开的。有人会想去找第三方打包的 rpm我试过几个来源要么依赖链断裂要么装完 agent 启动直接报段错误排查成本比编译还高。编译之前先把基础环境补齐。CentOS 6.8 默认的 gcc 是 4.4.7编译 Zabbix 5.0 够用但需要确认几个开发库到位yum install -y gcc make pcre-devel openssl-devel zlib-devel这里有个细节openssl-devel 的版本很关键。CentOS 6.8 自带的是 OpenSSL 1.0.1eZabbix 5.0 要求的最低版本是 1.0.1刚好卡在线上。如果你之前手动升级过 OpenSSL 到 1.1.x编译时反而可能因为头文件路径混乱报错。我的建议是保持系统自带的 openssl-devel 不动除非你有明确的加密需求。下载源码包的时候注意选对版本。Zabbix 5.0 的 LTS 版本是 5.0.19 左右再往后的 5.0.x 小版本修复了一些 agent 端的内存泄漏问题建议直接上 5.0 系列最后一个稳定版。源码包解压后进入目录编译 agent 不需要编译整个 Zabbix只要 agent 子目录就够了tar -zxvf zabbix-5.0.19.tar.gz cd zabbix-5.0.19 ./configure --enable-agent --prefix/usr/local/zabbix make make install--prefix指定安装路径我习惯放在/usr/local/zabbix下方便后续管理。--enable-agent表示只编译 agent 端不编译 server 和 proxy能省不少编译时间。整个编译过程在 2 核 4G 的虚拟机上大概 3 到 5 分钟如果超过 10 分钟还没结束检查一下是不是 make 的时候 CPU 被其他进程抢占了。2.2 编译参数里容易忽略的坑./configure阶段有几个参数值得单独说。默认情况下Zabbix agent 会去检测系统里有没有 libcurl、libxml2 这些库如果有就自动启用相关功能。但在 CentOS 6.8 上这些库的版本往往比较老自动检测通过之后编译出来的 agent 可能在运行时报符号找不到的错误。我的做法是显式禁用不需要的功能./configure --enable-agent --prefix/usr/local/zabbix \ --with-libpcre \ --with-openssl \ --disable-ipv6--with-libpcre和--with-openssl是必须的前者用于正则表达式匹配后者用于 agent 和 server 之间的加密通信如果你启用了 PSK 加密的话。--disable-ipv6在纯 IPv4 环境里能避免一些奇怪的网络检测问题CentOS 6.8 的 IPv6 栈在某些内核版本上有 bug禁掉省心。还有一个隐藏坑编译时如果系统里装了多个版本的 gccconfigure 可能会选到非默认的那个。可以在 configure 之前用gcc --version确认一下如果输出不是 4.4.7要么调整 PATH要么在 configure 时加CC/usr/bin/gcc显式指定。编译完成后/usr/local/zabbix目录下会生成sbin/zabbix_agentd、bin/zabbix_get、bin/zabbix_sender这几个关键文件。zabbix_get在排查问题时特别有用后面会讲到怎么用它来验证 agent 是否正常响应。3. 让 agent 在 CentOS 6.8 上稳定跑起来3.1 配置文件的关键字段逐个拆Zabbix agent 的配置文件默认在/usr/local/zabbix/etc/zabbix_agentd.conf。这个文件里参数很多但真正影响 agent 能否正常工作的就那么几个。我习惯先把默认配置备份一份然后基于模板改cp /usr/local/zabbix/etc/zabbix_agentd.conf /usr/local/zabbix/etc/zabbix_agentd.conf.bakServer 字段指定 Zabbix server 的 IP 地址。如果你有多个 server 或者 proxy用逗号分隔。这个字段决定了 agent 接受哪些 IP 的主动连接请求。填错了会导致 server 端一直显示 agent 不可达。ServerActive 字段用于主动模式active checks。agent 会主动把采集到的数据推送到这个地址。如果你只用被动模式这个字段可以不填但如果要用主动模式采集日志或者自动发现必须填对。Hostname 字段这个值必须和 Zabbix server 上配置的主机名完全一致包括大小写。我见过好几次因为 hostname 里多了一个空格或者大小写不匹配导致 server 端一直报host not found。ListenPort默认 10050如果被占用或者有安全策略限制可以改。改完之后记得在 server 端添加主机时同步修改端口号。StartAgents被动模式下启动的 agent 进程数默认是 3。如果监控项比较多可以适当调大但不要超过 CPU 核数的两倍否则上下文切换开销反而拖慢采集速度。Timeoutagent 等待超时时间默认 3 秒。在 MySQL 监控场景下如果某些 SQL 查询比较慢3 秒可能不够建议调到 5 到 8 秒。但注意这个值不能超过 server 端的 Timeout 设置否则 server 会先超时断开。3.2 启动脚本的适配改造CentOS 6.8 用的是 SysV init不是 systemd。Zabbix 源码包里自带的启动脚本在misc/init.d/目录下有fedora、centos等几个版本。CentOS 6.8 应该用centos目录下的脚本但直接拿来用可能会报错因为脚本里引用的路径和实际安装路径不一致。我一般直接手写一个简单的启动脚本放在/etc/init.d/zabbix-agent#!/bin/bash # chkconfig: 2345 90 10 # description: Zabbix Agent AGENT/usr/local/zabbix/sbin/zabbix_agentd CONF/usr/local/zabbix/etc/zabbix_agentd.conf PIDFILE/tmp/zabbix_agentd.pid case $1 in start) echo -n Starting Zabbix Agent: $AGENT -c $CONF echo done ;; stop) echo -n Stopping Zabbix Agent: pkill -f zabbix_agentd echo done ;; restart) $0 stop sleep 2 $0 start ;; *) echo Usage: $0 {start|stop|restart} exit 1 esac exit 0给脚本加执行权限然后用chkconfig --add zabbix-agent注册服务chkconfig zabbix-agent on设置开机自启。这里有个细节PID 文件路径。Zabbix agent 默认会把 pid 写到/tmp/zabbix_agentd.pid如果你的系统对/tmp有清理策略可能导致 pid 文件被删掉stop 的时候找不到进程。可以在配置文件里用PidFile参数指定到/var/run/zabbix_agentd.pid更规范一些。启动之后用ps -ef | grep zabbix_agentd确认进程在跑然后用netstat -tlnp | grep 10050确认端口在监听。如果进程起来了但端口没监听大概率是配置文件里ListenIP绑定了错误的地址检查一下是不是写成了127.0.0.1导致只监听本地回环。3.3 用 zabbix_get 做本地自检agent 启动之后别急着去 server 端加主机先在本地用zabbix_get验证一下/usr/local/zabbix/bin/zabbix_get -s 127.0.0.1 -p 10050 -k agent.ping正常应该返回1。如果返回ZBX_NOTSUPPORTED说明这个 key 不被支持可能是 agent 版本不对或者编译时没启用对应模块。如果连接被拒绝检查 agent 是否在监听、防火墙是否放行了 10050 端口。再测一个系统性能相关的 key/usr/local/zabbix/bin/zabbix_get -s 127.0.0.1 -p 10050 -k system.cpu.load[all,avg1]这个 key 返回的是 1 分钟平均负载。如果返回的是浮点数说明 agent 的系统信息采集模块工作正常。如果返回空或者报错检查/proc文件系统是否可读——CentOS 6.8 默认是挂载的但有些加固过的系统可能会限制/proc的访问权限。提示zabbix_get的-s参数指定目标 IP-p指定端口-k指定 key。在 server 端也可以用这个命令远程测试 agent是排查连通性问题的第一手段。4. MySQL 监控的落地细节与权限设计4.1 为什么不用 agent 内置的 MySQL 监控Zabbix agent 本身并不直接支持 MySQL 监控它提供的是一个叫UserParameter的机制允许你自定义 key然后通过脚本去采集数据。Zabbix 官方模板里 MySQL 相关的监控项本质上都是调用一个 shell 脚本脚本里再用mysql命令去查数据库状态。有人会问能不能用mysqladmin的extended-status直接输出可以但那个输出格式是给人类看的解析起来麻烦。更规范的做法是写一个脚本用 SQL 查询SHOW GLOBAL STATUS和SHOW GLOBAL VARIABLES然后把结果格式化成 Zabbix 能识别的键值对。4.2 监控账号的最小权限原则在 MySQL 里创建一个专门用于监控的账号只给必要的权限CREATE USER zbx_monitorlocalhost IDENTIFIED BY YourStrongPassword; GRANT USAGE, PROCESS, REPLICATION CLIENT ON *.* TO zbx_monitorlocalhost; FLUSH PRIVILEGES;USAGE权限是登录所必需的PROCESS权限允许查看所有线程的状态SHOW PROCESSLIST需要REPLICATION CLIENT权限允许查看主从复制状态SHOW SLAVE STATUS需要。不要给 SELECT 权限监控脚本不需要读业务数据给了反而增加安全风险。密码不要明文写在脚本里。我的做法是把密码放在一个只有 root 可读的配置文件里比如/etc/zabbix/.my.cnf[client] userzbx_monitor passwordYourStrongPassword hostlocalhost然后脚本里用mysql --defaults-file/etc/zabbix/.my.cnf来调用这样密码不会出现在ps的输出里。文件权限设成600属主改成运行 agent 的用户。4.3 自定义 UserParameter 的写法在zabbix_agentd.conf里添加UserParametermysql.status[*],/usr/local/zabbix/scripts/mysql_status.sh $1 UserParametermysql.ping,/usr/local/zabbix/scripts/mysql_ping.sh UserParametermysql.version,/usr/local/zabbix/scripts/mysql_version.shmysql.status[*]里的*是通配符表示这个 key 可以接受参数。比如mysql.status[Uptime]会调用脚本并传入Uptime作为第一个参数。mysql_status.sh脚本的核心逻辑#!/bin/bash MYSQL_CMDmysql --defaults-file/etc/zabbix/.my.cnf -N -B case $1 in Uptime) $MYSQL_CMD -e SHOW GLOBAL STATUS LIKE Uptime | awk {print $2} ;; Threads_connected) $MYSQL_CMD -e SHOW GLOBAL STATUS LIKE Threads_connected | awk {print $2} ;; Questions) $MYSQL_CMD -e SHOW GLOBAL STATUS LIKE Questions | awk {print $2} ;; Slow_queries) $MYSQL_CMD -e SHOW GLOBAL STATUS LIKE Slow_queries | awk {print $2} ;; *) echo ZBX_NOTSUPPORTED ;; esac-N参数去掉列名-B参数用制表符分隔这样awk {print $2}就能直接取到值。脚本写完之后记得加执行权限并且用运行 agent 的用户身份测试一下能不能正常执行。mysql_ping.sh更简单就是检测 MySQL 是否存活#!/bin/bash mysqladmin --defaults-file/etc/zabbix/.my.cnf ping 2/dev/null | grep -q alive echo 1 || echo 0返回 1 表示存活0 表示挂了。这个 key 在触发器里用来做 MySQL 服务不可用的告警。4.4 脚本权限与 agent 运行用户的匹配这是最容易踩的坑。Zabbix agent 默认以zabbix用户运行如果你在配置文件里没改User参数的话。但zabbix用户可能没有权限读取/etc/zabbix/.my.cnf导致脚本执行失败。解决方案有两个要么把.my.cnf的属主改成zabbix要么在 agent 配置文件里把User改成root。从安全角度考虑我倾向于前者但要注意.my.cnf的权限必须是600否则 MySQL 客户端会拒绝使用这个文件。还有一个隐蔽问题SELinux。CentOS 6.8 默认 SELinux 是 enforcing 状态可能会阻止 agent 执行/usr/local/zabbix/scripts/下的脚本。如果脚本手动执行正常但通过 agent 调用就失败先检查/var/log/audit/audit.log里有没有 SELinux 拒绝记录。临时可以用setenforce 0测试但生产环境建议配置正确的 SELinux 策略或者把脚本放在允许的路径下。5. 从 server 端验证到告警配置的闭环5.1 server 端添加主机与模板关联agent 端配置好之后登录 Zabbix 5.0 的 Web 界面在配置-主机里添加新主机。关键字段主机名称必须和 agent 配置文件里的Hostname完全一致可见名称可以随便填方便识别群组选一个已有的组或者新建Agent 接口填 agent 的 IP 和端口默认 10050添加完之后关联模板。Zabbix 5.0 自带的Template OS Linux by Zabbix agent模板覆盖了 CPU、内存、磁盘、网络等基础监控项。MySQL 监控需要额外关联Template DB MySQL by Zabbix agent模板但这个模板默认的 key 可能和你的脚本不一致需要手动调整。我一般会克隆一份模板把里面的 key 改成自己脚本定义的名称这样后续维护更清晰。比如官方模板里可能用的是mysql.status[Uptime]如果你的脚本 key 是mysql.uptime就要在模板里对应修改。5.2 数据采集延迟与超时调优主机添加之后在监测-最新数据里能看到采集到的值。如果某些监控项显示不支持或者无数据按以下顺序排查在 server 端用zabbix_get远程测试 agent 的 key 是否返回正常值检查 agent 日志/tmp/zabbix_agentd.log里有没有报错确认模板里的 key 和 agent 端定义的 key 完全一致检查 MySQL 监控脚本的执行权限和.my.cnf的读取权限关于超时Zabbix 5.0 的 server 端默认Timeout是 3 秒agent 端也是 3 秒。如果 MySQL 查询偶尔比较慢建议把两端都调到 8 秒。但注意server 端的 Timeout 必须大于等于 agent 端的 Timeout否则 server 会在 agent 还没返回结果时就断开连接导致数据丢失。5.3 触发器与告警规则的设置基础监控项跑通之后配置触发器。几个关键的 MySQL 告警场景告警场景触发器表达式严重级别MySQL 服务不可用mysql.ping.last()}0灾难连接数过高mysql.status[Threads_connected].last()}200警告慢查询增长过快mysql.status[Slow_queries].change()}10警告主从复制中断mysql.replication.status.last()}0严重触发器的表达式要根据实际业务量调整阈值。比如连接数一个日活几千的小系统 200 可能就很高了但一个高并发的系统 500 都算正常。建议先采集一周数据观察基线之后再定阈值。告警媒介邮件、短信、Webhook在管理-媒介类型里配置。Zabbix 5.0 支持自定义脚本作为告警媒介可以对接企业内部的告警平台。配置完之后在用户-报警媒介里给对应用户绑定媒介然后在动作里定义什么条件下触发告警、告警发给谁。5.4 一个完整的排查案例有一次在一台 CentOS 6.8 的数据库服务器上agent 装好了主机也添加了但 MySQL 相关的监控项全部显示不支持。排查过程如下第一步在 server 端执行zabbix_get -s agent_ip -p 10050 -k mysql.ping返回ZBX_NOTSUPPORTED。说明 agent 不认识这个 key。第二步登录 agent 机器检查zabbix_agentd.conf里UserParameter是否配置正确。发现配置了但脚本路径写的是/usr/local/zabbix/scripts/mysql_ping.sh而实际脚本放在/usr/local/zabbix/script/下少了一个 s。第三步修正路径后重启 agent再次测试返回1。但 server 端仍然显示不支持。第四步检查 agent 日志发现Permission denied。原因是脚本虽然路径对了但zabbix用户没有执行权限。chmod x之后问题解决。这个案例说明agent 端的配置修改后必须重启 agent 才生效而且日志是排查问题的第一手资料不要忽略。6. 老系统上跑新 agent 的长期维护建议CentOS 6.8 已经在 2020 年底停止了官方维护这意味着系统层面的安全补丁不会再有了。在这种环境下跑 Zabbix-agent 5.0有几个长期维护的注意事项。第一agent 版本不要盲目追新。Zabbix 5.0 是 LTS 版本官方支持到 2025 年。但 6.0 及以后的版本对 glibc 的要求更高CentOS 6.8 大概率编译不过。所以锁定在 5.0 系列只跟进安全补丁级别的小版本更新不要跨大版本升级。第二监控脚本要版本化管理。我习惯把所有的UserParameter脚本放在一个 Git 仓库里每次修改都提交记录。老系统的维护窗口往往很短出问题的时候能快速回滚到上一个可用版本非常关键。第三定期检查 agent 的资源占用。Zabbix agent 本身很轻量但如果StartAgents设得太大或者 MySQL 监控脚本执行太频繁可能会导致 agent 进程堆积。用ps -ef | grep zabbix_agentd | wc -l看看进程数是否正常用top -p $(pgrep zabbix_agentd | tr \n , | sed s/,$//)观察 CPU 和内存占用。第四做好 agent 的存活监控。Zabbix server 本身有agent 不可达的告警但那个告警依赖于 server 能主动连接 agent。如果网络策略变了或者 agent 端口被封了server 端会显示不可达但不会告诉你具体原因。建议在 agent 机器上再加一个 cron 任务定期用zabbix_get自测失败时写本地日志方便事后追溯。第五MySQL 监控的采样频率要合理。Questions、Slow_queries这类累计值采集间隔太短会导致数据点过多增加 server 端存储压力间隔太长又可能漏掉突增。我的经验是核心业务库 30 秒采集一次非核心库 60 秒一次。Uptime这种变化很慢的指标可以放宽到 300 秒。第六注意 agent 和 server 之间的时间同步。Zabbix 对时间敏感如果 agent 机器的时间偏差超过 server 端的容忍范围数据可能会被丢弃。CentOS 6.8 上用ntpdate或者chrony定期同步时间确保偏差在 1 秒以内。最后分享一个我在实际运维中总结的小技巧给每台 agent 机器打上标签。在 Zabbix 5.0 里主机支持标签Tags功能。可以给 CentOS 6.8 的机器统一打上os:centos6的标签给 MySQL 服务器打上role:database的标签。这样在配置告警动作或者做数据筛选的时候可以按标签批量操作不用一台一台去选。这个功能在主机数量多的时候特别省事强烈建议用起来。
1. 为什么老系统上还要折腾新版监控客户端手里还有一批 CentOS 6.8 的机器在跑核心业务这事儿在不少传统行业里一点都不稀奇。业务系统跟底层运行环境绑得太死迁移成本高到没人敢轻易动于是这些老将就一直坚守在机房里。但问题来了——监控体系要升级服务端已经换到了 Zabbix 5.0客户端却还停留在 3.x 甚至 2.x 的版本数据采集口径对不上新模板用不了告警规则也没法统一管理。这个场景的核心矛盾在于操作系统版本老但监控需求新。Zabbix-agent 5.0 官方提供的二进制包主要面向 CentOS 7 及以上直接拿到 CentOS 6.8 上跑大概率会遇到 glibc 版本不兼容、systemd 脚本无法识别、依赖库缺失这一连串问题。很多人第一反应是降级用老版本 agent 算了但老版本 agent 在采集 MySQL 性能指标时键值key的命名规则和新版 server 的模板不匹配等于白装。所以这篇内容要解决的就是在 CentOS 6.8 这个老平台上把 Zabbix-agent 5.0 跑起来并且让它同时承担主机性能采集和 MySQL 数据库监控两个职责。适合谁看手里有存量老系统、又不想在监控体系上妥协的运维人员正在做监控平台统一化改造、被老机器拖后腿的工程师以及想搞清楚 Zabbix-agent 在异构环境中怎么落地的人。我前后在三批不同配置的 CentOS 6.8 机器上做过这个事踩过的坑包括但不限于编译安装时 OpenSSL 头文件找不到、agent 启动后 server 端显示ZBX_NOTSUPPORTED、MySQL 监控脚本权限不对导致采集为空。下面把这些经验完整拆开讲尽量让你一次跑通。2. 编译安装 Zabbix-agent 5.0 的完整链路2.1 源码编译是唯一靠谱的路CentOS 6.8 的 yum 源里能直接装的 zabbix-agent 版本最高也就到 3.0而且官方早就停止维护了。想上 5.0源码编译是绕不开的。有人会想去找第三方打包的 rpm我试过几个来源要么依赖链断裂要么装完 agent 启动直接报段错误排查成本比编译还高。编译之前先把基础环境补齐。CentOS 6.8 默认的 gcc 是 4.4.7编译 Zabbix 5.0 够用但需要确认几个开发库到位yum install -y gcc make pcre-devel openssl-devel zlib-devel这里有个细节openssl-devel 的版本很关键。CentOS 6.8 自带的是 OpenSSL 1.0.1eZabbix 5.0 要求的最低版本是 1.0.1刚好卡在线上。如果你之前手动升级过 OpenSSL 到 1.1.x编译时反而可能因为头文件路径混乱报错。我的建议是保持系统自带的 openssl-devel 不动除非你有明确的加密需求。下载源码包的时候注意选对版本。Zabbix 5.0 的 LTS 版本是 5.0.19 左右再往后的 5.0.x 小版本修复了一些 agent 端的内存泄漏问题建议直接上 5.0 系列最后一个稳定版。源码包解压后进入目录编译 agent 不需要编译整个 Zabbix只要 agent 子目录就够了tar -zxvf zabbix-5.0.19.tar.gz cd zabbix-5.0.19 ./configure --enable-agent --prefix/usr/local/zabbix make make install--prefix指定安装路径我习惯放在/usr/local/zabbix下方便后续管理。--enable-agent表示只编译 agent 端不编译 server 和 proxy能省不少编译时间。整个编译过程在 2 核 4G 的虚拟机上大概 3 到 5 分钟如果超过 10 分钟还没结束检查一下是不是 make 的时候 CPU 被其他进程抢占了。2.2 编译参数里容易忽略的坑./configure阶段有几个参数值得单独说。默认情况下Zabbix agent 会去检测系统里有没有 libcurl、libxml2 这些库如果有就自动启用相关功能。但在 CentOS 6.8 上这些库的版本往往比较老自动检测通过之后编译出来的 agent 可能在运行时报符号找不到的错误。我的做法是显式禁用不需要的功能./configure --enable-agent --prefix/usr/local/zabbix \ --with-libpcre \ --with-openssl \ --disable-ipv6--with-libpcre和--with-openssl是必须的前者用于正则表达式匹配后者用于 agent 和 server 之间的加密通信如果你启用了 PSK 加密的话。--disable-ipv6在纯 IPv4 环境里能避免一些奇怪的网络检测问题CentOS 6.8 的 IPv6 栈在某些内核版本上有 bug禁掉省心。还有一个隐藏坑编译时如果系统里装了多个版本的 gccconfigure 可能会选到非默认的那个。可以在 configure 之前用gcc --version确认一下如果输出不是 4.4.7要么调整 PATH要么在 configure 时加CC/usr/bin/gcc显式指定。编译完成后/usr/local/zabbix目录下会生成sbin/zabbix_agentd、bin/zabbix_get、bin/zabbix_sender这几个关键文件。zabbix_get在排查问题时特别有用后面会讲到怎么用它来验证 agent 是否正常响应。3. 让 agent 在 CentOS 6.8 上稳定跑起来3.1 配置文件的关键字段逐个拆Zabbix agent 的配置文件默认在/usr/local/zabbix/etc/zabbix_agentd.conf。这个文件里参数很多但真正影响 agent 能否正常工作的就那么几个。我习惯先把默认配置备份一份然后基于模板改cp /usr/local/zabbix/etc/zabbix_agentd.conf /usr/local/zabbix/etc/zabbix_agentd.conf.bakServer 字段指定 Zabbix server 的 IP 地址。如果你有多个 server 或者 proxy用逗号分隔。这个字段决定了 agent 接受哪些 IP 的主动连接请求。填错了会导致 server 端一直显示 agent 不可达。ServerActive 字段用于主动模式active checks。agent 会主动把采集到的数据推送到这个地址。如果你只用被动模式这个字段可以不填但如果要用主动模式采集日志或者自动发现必须填对。Hostname 字段这个值必须和 Zabbix server 上配置的主机名完全一致包括大小写。我见过好几次因为 hostname 里多了一个空格或者大小写不匹配导致 server 端一直报host not found。ListenPort默认 10050如果被占用或者有安全策略限制可以改。改完之后记得在 server 端添加主机时同步修改端口号。StartAgents被动模式下启动的 agent 进程数默认是 3。如果监控项比较多可以适当调大但不要超过 CPU 核数的两倍否则上下文切换开销反而拖慢采集速度。Timeoutagent 等待超时时间默认 3 秒。在 MySQL 监控场景下如果某些 SQL 查询比较慢3 秒可能不够建议调到 5 到 8 秒。但注意这个值不能超过 server 端的 Timeout 设置否则 server 会先超时断开。3.2 启动脚本的适配改造CentOS 6.8 用的是 SysV init不是 systemd。Zabbix 源码包里自带的启动脚本在misc/init.d/目录下有fedora、centos等几个版本。CentOS 6.8 应该用centos目录下的脚本但直接拿来用可能会报错因为脚本里引用的路径和实际安装路径不一致。我一般直接手写一个简单的启动脚本放在/etc/init.d/zabbix-agent#!/bin/bash # chkconfig: 2345 90 10 # description: Zabbix Agent AGENT/usr/local/zabbix/sbin/zabbix_agentd CONF/usr/local/zabbix/etc/zabbix_agentd.conf PIDFILE/tmp/zabbix_agentd.pid case $1 in start) echo -n Starting Zabbix Agent: $AGENT -c $CONF echo done ;; stop) echo -n Stopping Zabbix Agent: pkill -f zabbix_agentd echo done ;; restart) $0 stop sleep 2 $0 start ;; *) echo Usage: $0 {start|stop|restart} exit 1 esac exit 0给脚本加执行权限然后用chkconfig --add zabbix-agent注册服务chkconfig zabbix-agent on设置开机自启。这里有个细节PID 文件路径。Zabbix agent 默认会把 pid 写到/tmp/zabbix_agentd.pid如果你的系统对/tmp有清理策略可能导致 pid 文件被删掉stop 的时候找不到进程。可以在配置文件里用PidFile参数指定到/var/run/zabbix_agentd.pid更规范一些。启动之后用ps -ef | grep zabbix_agentd确认进程在跑然后用netstat -tlnp | grep 10050确认端口在监听。如果进程起来了但端口没监听大概率是配置文件里ListenIP绑定了错误的地址检查一下是不是写成了127.0.0.1导致只监听本地回环。3.3 用 zabbix_get 做本地自检agent 启动之后别急着去 server 端加主机先在本地用zabbix_get验证一下/usr/local/zabbix/bin/zabbix_get -s 127.0.0.1 -p 10050 -k agent.ping正常应该返回1。如果返回ZBX_NOTSUPPORTED说明这个 key 不被支持可能是 agent 版本不对或者编译时没启用对应模块。如果连接被拒绝检查 agent 是否在监听、防火墙是否放行了 10050 端口。再测一个系统性能相关的 key/usr/local/zabbix/bin/zabbix_get -s 127.0.0.1 -p 10050 -k system.cpu.load[all,avg1]这个 key 返回的是 1 分钟平均负载。如果返回的是浮点数说明 agent 的系统信息采集模块工作正常。如果返回空或者报错检查/proc文件系统是否可读——CentOS 6.8 默认是挂载的但有些加固过的系统可能会限制/proc的访问权限。提示zabbix_get的-s参数指定目标 IP-p指定端口-k指定 key。在 server 端也可以用这个命令远程测试 agent是排查连通性问题的第一手段。4. MySQL 监控的落地细节与权限设计4.1 为什么不用 agent 内置的 MySQL 监控Zabbix agent 本身并不直接支持 MySQL 监控它提供的是一个叫UserParameter的机制允许你自定义 key然后通过脚本去采集数据。Zabbix 官方模板里 MySQL 相关的监控项本质上都是调用一个 shell 脚本脚本里再用mysql命令去查数据库状态。有人会问能不能用mysqladmin的extended-status直接输出可以但那个输出格式是给人类看的解析起来麻烦。更规范的做法是写一个脚本用 SQL 查询SHOW GLOBAL STATUS和SHOW GLOBAL VARIABLES然后把结果格式化成 Zabbix 能识别的键值对。4.2 监控账号的最小权限原则在 MySQL 里创建一个专门用于监控的账号只给必要的权限CREATE USER zbx_monitorlocalhost IDENTIFIED BY YourStrongPassword; GRANT USAGE, PROCESS, REPLICATION CLIENT ON *.* TO zbx_monitorlocalhost; FLUSH PRIVILEGES;USAGE权限是登录所必需的PROCESS权限允许查看所有线程的状态SHOW PROCESSLIST需要REPLICATION CLIENT权限允许查看主从复制状态SHOW SLAVE STATUS需要。不要给 SELECT 权限监控脚本不需要读业务数据给了反而增加安全风险。密码不要明文写在脚本里。我的做法是把密码放在一个只有 root 可读的配置文件里比如/etc/zabbix/.my.cnf[client] userzbx_monitor passwordYourStrongPassword hostlocalhost然后脚本里用mysql --defaults-file/etc/zabbix/.my.cnf来调用这样密码不会出现在ps的输出里。文件权限设成600属主改成运行 agent 的用户。4.3 自定义 UserParameter 的写法在zabbix_agentd.conf里添加UserParametermysql.status[*],/usr/local/zabbix/scripts/mysql_status.sh $1 UserParametermysql.ping,/usr/local/zabbix/scripts/mysql_ping.sh UserParametermysql.version,/usr/local/zabbix/scripts/mysql_version.shmysql.status[*]里的*是通配符表示这个 key 可以接受参数。比如mysql.status[Uptime]会调用脚本并传入Uptime作为第一个参数。mysql_status.sh脚本的核心逻辑#!/bin/bash MYSQL_CMDmysql --defaults-file/etc/zabbix/.my.cnf -N -B case $1 in Uptime) $MYSQL_CMD -e SHOW GLOBAL STATUS LIKE Uptime | awk {print $2} ;; Threads_connected) $MYSQL_CMD -e SHOW GLOBAL STATUS LIKE Threads_connected | awk {print $2} ;; Questions) $MYSQL_CMD -e SHOW GLOBAL STATUS LIKE Questions | awk {print $2} ;; Slow_queries) $MYSQL_CMD -e SHOW GLOBAL STATUS LIKE Slow_queries | awk {print $2} ;; *) echo ZBX_NOTSUPPORTED ;; esac-N参数去掉列名-B参数用制表符分隔这样awk {print $2}就能直接取到值。脚本写完之后记得加执行权限并且用运行 agent 的用户身份测试一下能不能正常执行。mysql_ping.sh更简单就是检测 MySQL 是否存活#!/bin/bash mysqladmin --defaults-file/etc/zabbix/.my.cnf ping 2/dev/null | grep -q alive echo 1 || echo 0返回 1 表示存活0 表示挂了。这个 key 在触发器里用来做 MySQL 服务不可用的告警。4.4 脚本权限与 agent 运行用户的匹配这是最容易踩的坑。Zabbix agent 默认以zabbix用户运行如果你在配置文件里没改User参数的话。但zabbix用户可能没有权限读取/etc/zabbix/.my.cnf导致脚本执行失败。解决方案有两个要么把.my.cnf的属主改成zabbix要么在 agent 配置文件里把User改成root。从安全角度考虑我倾向于前者但要注意.my.cnf的权限必须是600否则 MySQL 客户端会拒绝使用这个文件。还有一个隐蔽问题SELinux。CentOS 6.8 默认 SELinux 是 enforcing 状态可能会阻止 agent 执行/usr/local/zabbix/scripts/下的脚本。如果脚本手动执行正常但通过 agent 调用就失败先检查/var/log/audit/audit.log里有没有 SELinux 拒绝记录。临时可以用setenforce 0测试但生产环境建议配置正确的 SELinux 策略或者把脚本放在允许的路径下。5. 从 server 端验证到告警配置的闭环5.1 server 端添加主机与模板关联agent 端配置好之后登录 Zabbix 5.0 的 Web 界面在配置-主机里添加新主机。关键字段主机名称必须和 agent 配置文件里的Hostname完全一致可见名称可以随便填方便识别群组选一个已有的组或者新建Agent 接口填 agent 的 IP 和端口默认 10050添加完之后关联模板。Zabbix 5.0 自带的Template OS Linux by Zabbix agent模板覆盖了 CPU、内存、磁盘、网络等基础监控项。MySQL 监控需要额外关联Template DB MySQL by Zabbix agent模板但这个模板默认的 key 可能和你的脚本不一致需要手动调整。我一般会克隆一份模板把里面的 key 改成自己脚本定义的名称这样后续维护更清晰。比如官方模板里可能用的是mysql.status[Uptime]如果你的脚本 key 是mysql.uptime就要在模板里对应修改。5.2 数据采集延迟与超时调优主机添加之后在监测-最新数据里能看到采集到的值。如果某些监控项显示不支持或者无数据按以下顺序排查在 server 端用zabbix_get远程测试 agent 的 key 是否返回正常值检查 agent 日志/tmp/zabbix_agentd.log里有没有报错确认模板里的 key 和 agent 端定义的 key 完全一致检查 MySQL 监控脚本的执行权限和.my.cnf的读取权限关于超时Zabbix 5.0 的 server 端默认Timeout是 3 秒agent 端也是 3 秒。如果 MySQL 查询偶尔比较慢建议把两端都调到 8 秒。但注意server 端的 Timeout 必须大于等于 agent 端的 Timeout否则 server 会在 agent 还没返回结果时就断开连接导致数据丢失。5.3 触发器与告警规则的设置基础监控项跑通之后配置触发器。几个关键的 MySQL 告警场景告警场景触发器表达式严重级别MySQL 服务不可用mysql.ping.last()}0灾难连接数过高mysql.status[Threads_connected].last()}200警告慢查询增长过快mysql.status[Slow_queries].change()}10警告主从复制中断mysql.replication.status.last()}0严重触发器的表达式要根据实际业务量调整阈值。比如连接数一个日活几千的小系统 200 可能就很高了但一个高并发的系统 500 都算正常。建议先采集一周数据观察基线之后再定阈值。告警媒介邮件、短信、Webhook在管理-媒介类型里配置。Zabbix 5.0 支持自定义脚本作为告警媒介可以对接企业内部的告警平台。配置完之后在用户-报警媒介里给对应用户绑定媒介然后在动作里定义什么条件下触发告警、告警发给谁。5.4 一个完整的排查案例有一次在一台 CentOS 6.8 的数据库服务器上agent 装好了主机也添加了但 MySQL 相关的监控项全部显示不支持。排查过程如下第一步在 server 端执行zabbix_get -s agent_ip -p 10050 -k mysql.ping返回ZBX_NOTSUPPORTED。说明 agent 不认识这个 key。第二步登录 agent 机器检查zabbix_agentd.conf里UserParameter是否配置正确。发现配置了但脚本路径写的是/usr/local/zabbix/scripts/mysql_ping.sh而实际脚本放在/usr/local/zabbix/script/下少了一个 s。第三步修正路径后重启 agent再次测试返回1。但 server 端仍然显示不支持。第四步检查 agent 日志发现Permission denied。原因是脚本虽然路径对了但zabbix用户没有执行权限。chmod x之后问题解决。这个案例说明agent 端的配置修改后必须重启 agent 才生效而且日志是排查问题的第一手资料不要忽略。6. 老系统上跑新 agent 的长期维护建议CentOS 6.8 已经在 2020 年底停止了官方维护这意味着系统层面的安全补丁不会再有了。在这种环境下跑 Zabbix-agent 5.0有几个长期维护的注意事项。第一agent 版本不要盲目追新。Zabbix 5.0 是 LTS 版本官方支持到 2025 年。但 6.0 及以后的版本对 glibc 的要求更高CentOS 6.8 大概率编译不过。所以锁定在 5.0 系列只跟进安全补丁级别的小版本更新不要跨大版本升级。第二监控脚本要版本化管理。我习惯把所有的UserParameter脚本放在一个 Git 仓库里每次修改都提交记录。老系统的维护窗口往往很短出问题的时候能快速回滚到上一个可用版本非常关键。第三定期检查 agent 的资源占用。Zabbix agent 本身很轻量但如果StartAgents设得太大或者 MySQL 监控脚本执行太频繁可能会导致 agent 进程堆积。用ps -ef | grep zabbix_agentd | wc -l看看进程数是否正常用top -p $(pgrep zabbix_agentd | tr \n , | sed s/,$//)观察 CPU 和内存占用。第四做好 agent 的存活监控。Zabbix server 本身有agent 不可达的告警但那个告警依赖于 server 能主动连接 agent。如果网络策略变了或者 agent 端口被封了server 端会显示不可达但不会告诉你具体原因。建议在 agent 机器上再加一个 cron 任务定期用zabbix_get自测失败时写本地日志方便事后追溯。第五MySQL 监控的采样频率要合理。Questions、Slow_queries这类累计值采集间隔太短会导致数据点过多增加 server 端存储压力间隔太长又可能漏掉突增。我的经验是核心业务库 30 秒采集一次非核心库 60 秒一次。Uptime这种变化很慢的指标可以放宽到 300 秒。第六注意 agent 和 server 之间的时间同步。Zabbix 对时间敏感如果 agent 机器的时间偏差超过 server 端的容忍范围数据可能会被丢弃。CentOS 6.8 上用ntpdate或者chrony定期同步时间确保偏差在 1 秒以内。最后分享一个我在实际运维中总结的小技巧给每台 agent 机器打上标签。在 Zabbix 5.0 里主机支持标签Tags功能。可以给 CentOS 6.8 的机器统一打上os:centos6的标签给 MySQL 服务器打上role:database的标签。这样在配置告警动作或者做数据筛选的时候可以按标签批量操作不用一台一台去选。这个功能在主机数量多的时候特别省事强烈建议用起来。
