把一台已经装好 Zabbix Agent 的虚拟机克隆成多台再让每台克隆机都用 Zabbix 监控 Nginx这个流程看起来就是改个 IP、配个模板实际上踩坑的地方不少。我最近处理的一批 Nginx 节点里有三台克隆机反复出现连接不可达、监控数据串台最后定位下来是主机名没改、agent 配置里还挂着源机的 Server 地址、Nginx 状态页根本没开启这三件事叠在一起。下面围绕克隆机、Nginx 监控、Zabbix 连接这条链路把该改的配置、该验证的命令、该看的日志按操作顺序拆开讲清楚。如果你正在做 Nginx 集群监控或者刚克隆完机器准备接入 Zabbix可以直接把它当操作清单用。1. 克隆机接入 Zabbix 之前必须处理主机名、agent 标识和网络地址1.1 克隆带来的“隐性三重复”虚拟机克隆本质上是把磁盘完整复制一份所以新机器的 /etc/hostname、/etc/hosts、Zabbix agent 配置、SSH 主机密钥、machine-id 全部和源机一样。如果只改了 IP 就急着接 Zabbix后面一定会出问题。对 Zabbix 来说最要命的是三个重复主机名重复。Zabbix Web 界面里每个主机靠 Host name 区分尤其开启 active checks 之后agent 会以配置里的 Hostname 向服务端注册。两台机器都叫 nginx-node01数据就会落到同一个主机上同一张折线图里混着两台机器的数值告警阈值完全失去意义。agent Hostname 重复。克隆机上/etc/zabbix/zabbix_agent2.conf里的Hostname还是源机的值agent 起来之后仍然以旧名字上报Zabbix Server 找不到这个名字对应的新主机数据要么丢失要么写到旧主机的历史数据里。网络地址冲突。源机如果是静态 IP克隆机需要单独改 IP、改网关、重新生成 MAC 相关配置如果用的 DHCP 也不能掉以轻心要确认拿到的确实是预设地址否则后面 zabbix_get 永远会连错机器。1.2 修改顺序和具体命令我的建议是先改系统主机名再改 agent 配置最后重启服务顺序不要乱。hostnamectl set-hostname app-nginx-02然后检查 /etc/hosts确保本机名解析正常尤其是 agent 要连接本机的时候grep -n app-nginx-02 /etc/hosts接着修改 Zabbix agent 配置。这里以 agent2 为例路径一般是/etc/zabbix/zabbix_agent2.confHostnameapp-nginx-02 Server10.0.0.10 ServerActive10.0.0.10三个参数的作用分别是Hostnameagent 注册时的名字必须和你后面在 Zabbix Web 界面创建的主机名保持一致active checks 靠这个名字认主机。Server被动检查的白名单只有列在这里的 IP 能从 agent 的 10050 端口拉数据。ServerActive主动检查的服务端地址agent 会主动连接这个地址发起 active checks。克隆机最容易漏的就是这三个参数还是源机的值。之前遇到过一台机器Server还指向旧 Zabbix Server 的 IP新服务端怎么拉都是 unreachable改掉之后立刻恢复。顺手把 SSH 主机密钥和 machine-id 也清一下rm -f /etc/ssh/ssh_host_* systemctl restart sshdZabbix 本身不在乎这两个东西但如果后面要批量管理这些克隆机不清理就会出现 SSH 登录时报 “REMOTE HOST IDENTIFICATION HAS CHANGED”排查半天才发现问题出在密钥残留。machine-id 重复则可能在 systemd 相关服务初始化时报一些奇怪错误属于卫生问题。1.3 改完怎么验证没有残留这一步别跳过直接上命令hostname cat /etc/hostname grep -E ^(Hostname|Server|ServerActive) /etc/zabbix/zabbix_agent2.conf systemctl restart zabbix-agent2 zabbix_agent2 -t agent.pingagent.ping 返回 1说明 agent 本身能正常响应本地请求。但这只是第一步后面还要看服务端能不能取到 nginx 相关数据。2. Nginx 监控数据从哪里来先把 stub_status 状态页打开2.1 两种常见监控路径Zabbix 官方对 Nginx 提供了一套模板核心思路是让 agent2 的 nginx 插件通过 HTTP 去访问 Nginx 的状态页常见模板名是 “Nginx by Zabbix agent 2”。另一条路是自己写 UserParameter让经典 agent 去 curl 状态页再解析。不管走哪条路前提都一样Nginx 必须开启stub_status状态页。状态页没开模板里所有指标都会报 not supported 或者取到 0。2.2 在 nginx.conf 里加一个受控的 location在需要监控的 server 块里加一个精确匹配的 locationserver { listen 80; server_name _; location /nginx_status { stub_status on; access_log off; allow 127.0.0.1; allow 10.0.0.10; # Zabbix Server 或 Zabbix Proxy 的地址 deny all; } }这里有几个点要解释一下location /nginx_status是精确匹配不会影响/nginx_status/这种路径也不会把业务请求误路由到这里。stub_status on;开启状态页输出。allow 127.0.0.1必须保留因为 agent 插件默认从本机取数。allow 10.0.0.10是 Zabbix Server 或 Proxy 的地址如果你用 agent2 插件它只访问 127.0.0.1这个 allow 其实可以不要但留着对排查有好处方便直接从管理机 curl 验证。deny all;确保外网不能随便访问状态页避免连接数、请求量这些信息泄露。改完先检查语法再重载nginx -t nginx -s reload如果你用的是发行版自带 Nginx也可以通过systemctl reload nginx效果一样。2.3 验证状态输出和指标含义本机先 curl 一下curl http://127.0.0.1/nginx_status正常的输出长这样Active connections: 2 server accepts handled requests 10 10 10 Reading: 0 Writing: 1 Waiting: 1每一行含义如下输出内容含义监控时怎么用Active connections当前活跃连接数快速判断当前压力accepts累计已接受连接数和 handled 对比看是否有短连接异常handled累计已处理连接数如果明显小于 accepts说明连接被过早丢弃requests累计请求数从总数做增量可以看请求速率Reading正在读取请求头的连接数偏高说明请求量在涨Writing正在写响应的连接数偏高说明响应处理慢或网络阻塞Waiting空闲长连接等待请求数keepalive 场景下观察连接复用中间那一行的三个数字第一个是 accepts第二个是 handled第三个是 requests。正常情况 accepts 和 handled 几乎相等如果长期有差值就要查 worker_connections、listen backlog 这些参数。2.4 状态页只能本机访问时agent 怎么取数如果你的 Nginx 在宿主机上直接跑agent 也在这台机器上那就让插件走 127.0.0.1完全不需要把状态页暴露给外部。如果 Nginx 跑在 Docker 容器里agent 跑在宿主机上要把容器端口映射到宿主机然后让插件指向127.0.0.1:映射端口。此时 allow 那段要加容器的网关地址或者干脆只允许本机避免容器外其他机器直连。3. Zabbix Agent 配置和模板绑定让监控项真正取到值3.1 官方模板还是自定义键值如果整个环境都是 Zabbix 6.0 以上且 agent 用的都是 agent2直接用官方模板 “Nginx by Zabbix agent 2” 最省事。官方模板通过 agent2 的 nginx 插件采集插件会访问/nginx_status页面然后按标准格式解析。如果环境中还有老版本 agent或者 Nginx 状态页在 HTTPS 后面、需要自定义路径我会直接写 UserParameter。好处是逻辑完全自己掌控curl 一下、awk 一下就能返回结果排查也直观。3.2 agent2 的 nginx 插件配置agent2 的插件配置文件一般在/etc/zabbix/zabbix_agent2.d/plugins.d/nginx.conf如果目录不存在就自己建。Plugins.Nginx.Status.Host127.0.0.1 Plugins.Nginx.Status.Port80 Plugins.Nginx.Status.Path/nginx_status Plugins.Nginx.Status.Schemehttp改完重启 agent2systemctl restart zabbix-agent2然后用 agent2 自带测试方式验证zabbix_agent2 -t nginx.status.active zabbix_agent2 -t nginx.status.accepted zabbix_agent2 -t nginx.status.handled zabbix_agent2 -t nginx.status.requests zabbix_agent2 -t nginx.status.reading zabbix_agent2 -t nginx.status.writing zabbix_agent2 -t nginx.status.waiting能返回数值说明插件、状态页、网络都通了。这里如果返回 not supported多半是路径不对或者插件没加载成功先 curl 看看状态页是否真的返回了内容。3.3 用 UserParameter 实现自定义键值没有 agent2 或者不想依赖插件的环境可以新建一个配置文件例如/etc/zabbix/zabbix_agentd.d/nginx_status.confUserParameternginx.active,curl -s http://127.0.0.1/nginx_status | awk /Active/{print $3} UserParameternginx.accepts,curl -s http://127.0.0.1/nginx_status | awk NR3{print $1} UserParameternginx.handled,curl -s http://127.0.0.1/nginx_status | awk NR3{print $2} UserParameternginx.requests,curl -s http://127.0.0.1/nginx_status | awk NR3{print $3} UserParameternginx.reading,curl -s http://127.0.0.1/nginx_status | awk /Reading/{print $2} UserParameternginx.writing,curl -s http://127.0.0.1/nginx_status | awk /Writing/{print $4} UserParameternginx.waiting,curl -s http://127.0.0.1/nginx_status | awk /Waiting/{print $6}这样写的好处是键值名完全可控后面建模板、建触发器时直接对键名。测试方式zabbix_agentd -t nginx.active zabbix_agentd -t nginx.writing如果本机能取到值但服务端取不到那就回到第 4 章的网络排查大概率是白名单或防火墙。3.4 Web 界面创建主机并绑定模板Zabbix 界面的操作路径一般是数据采集 → 主机 → 创建主机。主机名称填app-nginx-02一定要和 agent 配置里的 Hostname 一致。如果是被动检查接口类型选 Agent填克隆机的 IP 或 DNS端口默认 10050。链接模板区域搜索 “Nginx”选对应的 “Nginx by Zabbix agent 2” 模板。保存等待 1 到 2 个采集周期。到 监测 → 最新数据 里筛选主机看 nginx.* 指标是否有值。为什么主机名必须一致因为 active checks 的注册流程里agent 会把Hostname的值上报给 Zabbix ServerServer 用这个名字去找对应的主机配置。名字对不上即使网络全通数据也不知道该往哪里写。3.5 克隆机上最容易漏的两个绑定问题第一个是旧主机还挂在 Zabbix 里。如果源机之前已经监控过新克隆机接入前最好把旧主机停用或删除不然同 IP、同 Hostname 的情况下新主机数据可能和旧主机互相覆盖。第二个是 Hostname 没改数据全部落到旧主机上。这个坑最隐蔽因为 zabbix_get 也是通的Latest data 也有数值只是你盯着新主机界面看一直显示没数据。4. 连接失败时按这个顺序排查端口、白名单、防火墙、日志4.1 先确认 agent 进程和监听端口连接不通别直接改配置先看 agent 到底起没起来systemctl status zabbix-agent2 ss -lntp | grep 10050 ps -ef | grep zabbix10050 是 agent 被动检查的监听端口。如果这个端口不存在说明 agent 没起来后面所有排查都白做。常见原因是克隆机改完主机名之后没有重启或者配置文件语法错误。4.2 再确认 agent 配置里的 Server 白名单Zabbix 的被动检查逻辑是Server 主动连 agent 的 10050 端口agent 收到请求后会校验来源 IP 是否在Server列表里。不在列表里就直接丢弃agent 日志里会出现类似 “not allowed host” 的记录。所以克隆机必须检查这点Server127.0.0.1,10.0.0.10 ServerActive10.0.0.10Server是白名单ServerActive是主动连接地址。很多人只改 Hostname 不改这两个参数结果新 Zabbix Server 永远连不上。4.3 防火墙和 SELinux白名单没问题下一步查防火墙。firewall-cmd --state firewall-cmd --list-ports firewall-cmd --permanent --add-port10050/tcp firewall-cmd --reload克隆机最容易出现一个情况源机之前为了别的服务开过防火墙规则克隆之后新网络段根本不在允许列表里。如果是 Ubuntu对应的命令是 ufw如果是 Debian 系没装 ufw还要看 iptables 是否被清了。SELinux 也要考虑。可以临时关一下做对比测试setenforce 0如果关掉之后 zabbix_get 立刻通了说明是 SELinux 策略问题再把策略补上不要长期保持关闭。Zabbix 官方文档针对不同发行版都有对应的 SELinux 策略说明按版本装对应策略包即可。4.4 用 zabbix_get 判断问题在哪一侧zabbix_get 是从 Zabbix Server 侧主动拉取 agent 数据的工具没有就先装yum install zabbix-get然后分三档验证测试对象命令判断结果agent 本机取数zabbix_agent2 -t nginx.active能返回值说明插件和状态页正常服务端取数zabbix_get -s 10.0.0.11 -k nginx.active能返回值说明网络、白名单、端口全通Web 界面 item最新数据 / item 的 last error能出数说明模板和主机绑定正确如果第一档通过、第二档失败问题就集中在 Server 白名单、防火墙、端口这三件事上如果第一档也失败问题在 agent 配置或者 Nginx 状态页本身。4.5 日志怎么看每层都有日志按顺序翻/var/log/zabbix/zabbix_agent2.log或/var/log/zabbix/zabbix_agentd.log看 agent 启动、连接拒绝、插件加载失败。/var/log/zabbix/zabbix_server.log看服务端是否尝试连接、是否收到 active checks 注册。Nginx 的 error log看/nginx_status是否有 404、403、405 这类请求记录。我之前遇到过一种情形agent 日志没有任何异常zabbix_get 也能取到 nginx.active但 Web 界面 item 一直报 not supported。最后发现是模板里的键名和 plugin 返回的键名对不上版本匹配问题。这种情况只能看 item 的 last error它会明确告诉你 what key is not supported。4.6 克隆机典型现象对照表现象最可能原因先查哪里Web 界面显示 unreachable防火墙挡 10050、Server 白名单没加新 IPzabbix_get、firewall-cmd主机能看到但所有 item 没数据模板没链接、键值名不匹配最新数据、agent -tnginx 状态项报 not supported状态页没开、路径不对、插件未启用curl 状态页、agent 日志数据写到旧主机克隆机 Hostname 没改active checks 注册到旧名grep Hostnamezabbix_get 通但 web 没显示主机名不匹配或主机被分配到代理下主机配置、代理配置5. 多台克隆机批量接入 Zabbix 的配置管理思路5.1 不要一台一台手工改一次克隆三五台手工改问题不大。一旦节点上了两位数每台机器都去敲一遍 hostnamectl、sed 配置、重启服务迟早会漏掉某台的 Server 白名单。可以准备一个简单的初始化脚本克隆完成后传参执行#!/bin/bash HOSTNAME$1 NEW_SERVER_IP$2 hostnamectl set-hostname $HOSTNAME sed -i s/^Hostname.*/Hostname$HOSTNAME/ /etc/zabbix/zabbix_agent2.conf sed -i s/^Server.*/Server$NEW_SERVER_IP/ /etc/zabbix/zabbix_agent2.conf sed -i s/^ServerActive.*/ServerActive$NEW_SERVER_IP/ /etc/zabbix/zabbix_agent2.conf systemctl restart zabbix-agent2用法bash init_clone_agent.sh app-nginx-02 10.0.0.10这里我一般习惯先把一台克隆机完整跑通再把这个脚本批量套到其余机器上避免带着同一个错误复制到所有节点。5.2 维护主机名、IP、模板映射表批量接入时表格比记忆可靠。建议至少维护这些列虚拟机名IP主机名L链接模板备注nginx-clone-0110.0.0.11app-nginx-01Nginx by Zabbix agent 2权限组 Anginx-clone-0210.0.0.12app-nginx-02Nginx by Zabbix agent 2权限组 Anginx-clone-0310.0.0.13app-nginx-03Nginx by Zabbix agent 2权限组 B名字最好有规律比如app-nginx-01这样后面写脚本、批量建主机、做告警通知都很方便。5.3 批量验证连接全部接入后可以写一个循环到服务端批量验证 agent.pingfor ip in 10.0.0.11 10.0.0.12 10.0.0.13; do echo $ip zabbix_get -s $ip -k agent.ping done再把 nginx.active 也拉一遍for ip in 10.0.0.11 10.0.0.12 10.0.0.13; do echo $ip zabbix_get -s $ip -k nginx.active done有值就说明状态页、agent 取数、网络、白名单都是通的。如果某个 IP 返回空或者报错再单独回到第 4 章排查。5.4 节点数量多了考虑用 Zabbix Proxy当克隆出来的节点分布在多个网段或者单台 Zabbix Server 要管理几十上百台 agent 时建议加一层 Zabbix Proxy。Proxy 部署在靠近被监控机器的位置agent 把数据交给 ProxyProxy 再统一上报给 Server。使用 Proxy 之后的改动点Proxy 的Server和ServerActive指向 Zabbix Server。被监控节点的 agent 配置里Server和ServerActive改成指向 Proxy 的 IP。Web 界面创建主机时选择该主机由哪个 Proxy 管理。这样 Zabbix Server 不用直接连接每台克隆机的 10050 端口网络策略好开放很多。首次从单机过渡到 Proxy 时会觉得多了一层配置但节点越多收益越明显尤其是跨网段、防火墙策略严格的环境。5.5 监控项别贪多克隆机批量接入时最容易犯的错是给每台机挂一大堆模板、加几十个监控项。Nginx 监控核心就是连接数、请求数、Reading/Writing/Waiting 这几个指标足够判断容量和异常。每台机从 7 到 10 个 Nginx 指标起步跑一阵子再看要不要补比一开始就堆满更稳。更新周期也不用拉得太短。默认 1 分钟一次对大多数 Nginx 集群够用如果节点连接数高、想细化告警再单独把nginx.active的更新间隔调到 10 秒或 30 秒。更新间隔越短对 Server 的数据库写入压力越大。处理克隆机接入 Zabbix 监控 Nginx本质上就是把三件事做干净机器身份和源机分开Nginx 开一个受控的状态入口agent 的取数和通讯配置对齐。踩过几次坑之后会发现绝大多数连接问题不是 Zabbix 功能问题而是主机名残留、Server 白名单没更新、防火墙挡了端口。先把一台克隆机从改主机名到 Latest data 有数值完整走一遍再批量复制这个流程后面会省很多事。
