大家在做 Zabbix 监控建设时Web 服务器和反向代理的监控往往是刚需。Nginx 作为目前使用率极高的 Web 服务软件承担了静态资源托管、反向代理、负载均衡、SSL 终止等关键职责一旦它出现连接数飙高、请求积压或主动健康检查失败前端业务会立刻感知到。如果我们只在故障发生时被动排查效率太低更合理的做法是把 Nginx 的关键运行指标纳入 Zabbix 监控体系通过自定义监控项采集状态页数据再配合图形和触发器实现主动告警。本文将基于一套完整的实验流程从 Nginx 状态页开启、Zabbix Agent 自定义监控项配置到数据采集、图形展示、触发器告警逐步演示如何用 Zabbix 监控 Nginx并详细解读测试后的监控统计结果。文章既覆盖概念原理也包含可复制的命令和配置适合正在做 Zabbix 监控落地的运维新手也适合需要完善 Web 监控维度的进阶读者。1. Nginx 监控指标与 Zabbix 监控架构1.1 Nginx 需要监控哪些指标Nginx 的运行状态可以从三个维度观察连接数、请求数、连接状态。连接数方面我们需要关注当前正在处理的活动连接数以及 Nginx 接受的连接总数、握手成功次数和请求总数。这些数据反映了 Nginx 的连接处理能力和压力情况。请求数是最直接的流量指标。通过观察每秒请求数QPS即 Queries Per Second的曲线可以判断业务流量的波峰波谷也可以对比发布前后流量变化是否异常。连接状态则分为几类readingNginx 正在读取请求头。writingNginx 正在读取请求体、处理请求或向客户端发送响应。waiting保持连接模式下请求处理完成但连接尚未关闭此时连接处于空闲等待状态。当 reading 和 writing 数值持续偏高时通常说明后端响应慢或客户端请求处理不过来当 waiting 数值很高时说明 Keepalive 连接较多这是正常现象但也要结合连接超时参数观察。1.2 Zabbix 监控 Nginx 的两种常见方式目前主流的监控方式有两种。第一种是使用 Zabbix 官方或社区提供的 Nginx 监控模板。官方模板通常依赖 Zabbix Agent 主动采集并且要求被监控主机上安装了相应的采集脚本或模块。这种方式配置简单但灵活性一般。第二种是使用自定义 UserParameter 监控项。我们手动编写脚本或直接通过 shell 命令解析 Nginx 状态页输出再通过 Zabbix Agent 暴露给 Zabbix Server。这种方式可以精确控制监控项名称、数据单位和采集频率也方便后期扩展是本文重点演示的方式。无论采用哪种方式前提都是 Nginx 必须开启 stub_status 状态页模块并配置对应的 location 访问规则。1.3 整体采集链路整个采集链路的逻辑如下Nginx 开启 stub_status通过 HTTP 访问 /nginx_status 返回纯文本状态信息。Zabbix Agent 调用自定义监控项命令用 curl 获取状态页内容。通过 sed、awk 等文本处理命令提取对应指标数值。Zabbix Server 周期性向 Agent 拉取数据或由 Agent 主动上报。数据入库后在 Zabbix 前端配置图形、触发器实现可视化和告警。这里的关键点是Zabbix Agent 所在主机必须能够访问 Nginx 状态页地址。如果是本机采集直接使用 127.0.0.1 即可如果跨主机采集则需要保证网络策略放通。2. 环境准备与版本说明本文实验环境如下表所示实际部署时可以按自己的环境调整。组件版本 / 配置说明操作系统CentOS 7.9 / Ubuntu 22.04 均可本文以 CentOS 7.9 为例Nginx1.20.x 或 1.24.x需要支持 stub_status 模块Zabbix Server6.0 LTS需要数据库和前端服务正常Zabbix Agent6.0.x与被监控主机同机部署浏览器Chrome / Edge访问 Zabbix 前端需要说明的是不同 Linux 发行版的软件包管理方式不同本文中的命令以 CentOS/RHEL 系为主。如果你使用的是 Ubuntu需要把yum换成apt同时注意 Zabbix 仓库地址的差异。Nginx 的stub_status模块在官方 RPM 包中通常已经编译进去。你可以执行下面的命令确认nginx -V 21 | grep -o stub_status如果输出中包含stub_status说明当前 Nginx 已支持该模块直接配置状态页 location 即可。如果没有任何输出说明 Nginx 编译时未包含该模块需要使用--with-http_stub_status_module重新编译或者安装带该模块的发行版 Nginx 包。3. 开启 Nginx 状态页并验证输出3.1 修改 Nginx 配置文件编辑 Nginx 配置文件在 server 块中添加一个 location用于暴露状态页。以nginx.conf中server { ... }为例server { listen 80; server_name localhost; location /nginx_status { stub_status on; access_log off; allow 127.0.0.1; deny all; } }关键配置说明stub_status on开启状态页模块这是 Nginx 提供状态输出的开关。access_log off关闭该 location 的访问日志避免健康检查或频繁采集刷满日志。allow 127.0.0.1; deny all;仅允许本机访问状态页其他来源一律拒绝。这是一个非常重要的安全设置。为什么不建议直接允许所有 IP 访问因为/nginx_status页面会暴露当前连接数、请求数等运行细节在公网环境下属于敏感信息限制来源是基本的安全底线。生产环境中Zabbix Agent 与 Nginx 同机部署时使用本机回环地址采集完全不需要开放外网访问。3.2 检查配置并重载 Nginx修改完成后先测试配置文件语法nginx -t输出一般为nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful确认无误后重载配置nginx -s reload或者使用 systemdsystemctl reload nginx重载不会中断现有连接比 restart 更平滑适合配置变更场景。3.3 验证状态页输出在本机执行 curlcurl http://127.0.0.1/nginx_status正常输出如下Active connections: 1 server accepts handled requests 10 10 20 Reading: 0 Writing: 1 Waiting: 0各字段含义如下第一行Active connections当前活动连接数包括正在处理的和空闲等待的。第二行和第三行分别是 Nginx 启动以来接受的连接总数、成功握手总数和处理的请求总数。第四行Reading正在读取请求头的连接数。第四行Writing正在读取请求体、处理请求或写响应的连接数。第四行Waiting空闲 Keepalive 连接数。需要注意accepts、handled、requests是累计值从 Nginx 启动开始累加不会自动清零。我们在 Zabbix 中看到的数值会越来越大这是符合预期的如果要观察速率变化Zabbix 可以使用delta或speed per second的预处理方式来计算增量。这一点在后文中会详细说明。4. Zabbix Agent 自定义监控项配置4.1 安装 Zabbix Agent如果被监控主机上还没有安装 Zabbix Agent需要先安装并配置。以 CentOS 7 为例rpm -Uvh https://repo.zabbix.com/zabbix/6.0/rhel/7/x86_64/zabbix-release-6.0-4.el7.noarch.rpm yum clean all yum install -y zabbix-agent如果是 Ubuntu 系统仓库配置方式略有不同但 Agent 安装包名称是一致的。安装完成后编辑 Agent 配置文件/etc/zabbix/zabbix_agentd.confServer192.168.10.10 ServerActive192.168.10.10 Hostnamenginx-web-01其中Server允许哪些 Zabbix Server 或 Proxy 主动拉取数据。ServerActiveAgent 主动上报时连接的 Server 地址。HostnameAgent 主机名必须与 Zabbix 前端添加主机时配置的主机名称一致否则数据会显示为不可达。重启 Agent 服务systemctl restart zabbix-agent systemctl enable zabbix-agent4.2 创建自定义监控项配置文件Zabbix Agent 支持在/etc/zabbix/zabbix_agentd.d/目录下创建扩展配置文件。我们新建一个专门用于 Nginx 监控的配置文件vim /etc/zabbix/zabbix_agentd.d/nginx_status.conf写入以下内容UserParameternginx.accepts,/usr/bin/curl -s http://127.0.0.1/nginx_status | awk /server accepts handled requests/{getline; print $1} UserParameternginx.handled,/usr/bin/curl -s http://127.0.0.1/nginx_status | awk /server accepts handled requests/{getline; print $2} UserParameternginx.requests,/usr/bin/curl -s http://127.0.0.1/nginx_status | awk /server accepts handled requests/{getline; print $3} UserParameternginx.active,/usr/bin/curl -s http://127.0.0.1/nginx_status | awk /Active connections/{print $3} UserParameternginx.reading,/usr/bin/curl -s http://127.0.0.1/nginx_status | awk /Reading:/{print $2} UserParameternginx.writing,/usr/bin/curl -s http://127.0.0.1/nginx_status | awk /Writing:/{print $4} UserParameternginx.waiting,/usr/bin/curl -s http://127.0.0.1/nginx_status | awk /Waiting:/{print $6}每条配置的含义是定义了一个 Zabbix 监控项的 key例如nginx.activeAgent 收到这个 key 的采集请求后会执行右侧的 shell 命令返回对应指标的数值。这里要特别说明awk的用法。以nginx.accepts为例curl -s http://127.0.0.1/nginx_status | awk /server accepts handled requests/{getline; print $1}流程是curl获取状态页文本。awk查找包含server accepts handled requests的行。匹配后执行getline读取下一行。输出下一行的第 1 列即accepts累计值。类似地nginx.writing和nginx.waiting通过定位Reading:所在行再分别取第 4 列和第 6 列。如果你的服务器上curl安装路径不是/usr/bin/curl可以用which curl确认。Zabbix Agent 执行命令时使用的 PATH 环境变量可能比较精简写绝对路径是最稳妥的。4.3 重启 Agent 并验证监控项配置文件修改完成后重启 Zabbix Agentsystemctl restart zabbix-agent然后可以用官方提供的zabbix_get工具在 Zabbix Server 端测试也可以在被监控主机上用zabbix_agentd -t测试。先在 Agent 本机验证 key 是否有效zabbix_agentd -t nginx.active预期输出类似nginx.active [t|1]表示 key 有效当前值为 1。如果输出[m|ZBX_NOTSUPPORTED]说明 key 未识别或命令执行异常。在 Zabbix Server 端安装zabbix-get后也可以远程验证yum install -y zabbix-get zabbix_get -s 192.168.10.20 -k nginx.active其中192.168.10.20是被监控主机 IP。如果返回数字说明 Agent 与 Server 之间的通信链路正常自定义监控项已经生效。5. Zabbix 前端创建主机与监控项5.1 创建主机登录 Zabbix Web 前端按照以下路径操作数据采集 → 主机 → 创建主机配置示例主机名称nginx-web-01模板暂不关联 Nginx 模板我们手动创建监控项群组Web Servers接口AgentIP 地址填被监控主机 IP端口默认 10050填写完成后点击“添加”。这里需要注意主机名称必须和 Agent 配置文件中的Hostname一致否则 Agent 主动上报的数据无法关联到主机。如果使用被动模式采集主机名称不一致可能不直接影响数据接收但为了后续维护方便建议保持统一。5.2 创建监控项在主机详情页进入监控项 → 创建监控项。下面以nginx.active为例说明关键字段的配置名称Nginx Active Connections类型Zabbix 客户端被动采集键值nginx.active信息类型数字无正负主机接口Agent更新间隔30s历史数据保留期7d趋势数据保留期30d如果要在图形中直观地看到请求速率、连接数变化可以利用 Zabbix 的预处理功能。例如“每秒请求数”不应该直接使用nginx.requests的累计值而是需要计算差值。在监控项配置中添加预处理步骤自定义 multiplier参数勾选Change per second或使用 Zabbix 提供的Change预处理类型以 Zabbix 6.0 为例我们可以在预处理步骤中选择Change per second这样 Zabbix 会自动计算最近两次采集值的差值再除以时间间隔得到每秒速率。同样的方式为其他指标创建监控项监控项名称键值信息类型Nginx Acceptsnginx.accepts数字无正负Nginx Handlednginx.handled数字无正负Nginx Requestsnginx.requests数字无正负Nginx Active Connectionsnginx.active数字无正负Nginx Readingnginx.reading数字无正负Nginx Writingnginx.writing数字无正负Nginx Waitingnginx.waiting数字无正负手动创建七个监控项确实有点繁琐但这有助于理解监控项的构成。在企业批量部署中更推荐的方式是导出模板 XML批量导入后直接关联。本文为了讲解原理先采用手动方式。5.3 创建图形监控项创建完成后下一步是创建图形方便观察趋势。路径为主机 → 图形 → 创建图形配置两个图形第一个图形Nginx Connections添加nginx.active、nginx.reading、nginx.writing、nginx.waiting四个监控项。第二个图形Nginx Requests Summary添加nginx.accepts、nginx.handled、nginx.requests三个监控项。图形类型建议使用“正常”折线图数据展示更清晰。如果希望看到堆叠效果可以在图形属性中调整绘制风格。5.4 创建触发器图形用于事后查看触发器用于实时告警。我们创建几个有实际意义的触发器。第一个触发器Nginx 活动连接数过高。配置参数如下名称Nginx Active Connections Too High on {HOST.NAME}严重性警告表达式last(/nginx-web-01/nginx.active)500这里的 500 是一个示例阈值实际应该根据业务规模和机器性能调整。为了避免偶发尖峰触发告警可以改成连续 N 次超过阈值min(/nginx-web-01/nginx.active,5m)500表示最近 5 分钟内的最小活动连接数大于 500 才告警。取最小值而不是最大值是为了过滤短时间内的瞬时波动。第二个触发器Nginx 请求数异常下降。这个触发器可以用于发现服务挂掉或流量骤降的场景。表达式max(/nginx-web-01/nginx.requests,10m) 0如果最近 10 分钟请求数为 0说明没有请求进入 Nginx需要立刻检查服务状态。不过要注意非业务时段本来就没有请求这种触发器适合配置在流量不间断的业务上或者结合时间段调度使用。第三个触发器Nginx 状态页不可访问。可以通过监控nginx.active无法获取数据来间接判断状态页故障。但 Zabbix 对“不支持”的监控项默认会显示告警也可以单独配置nodata(/nginx-web-01/nginx.active,3m)1表示nginx.active在 3 分钟内没有数据触发器进入告警状态。6. 测试监控统计与结果解读6.1 模拟访问流量配置完成后我们需要实际制造一些请求验证监控项是否能够正常采集数据并观察图形变化。在 Nginx 本机或者任意能访问 Nginx 的机器上循环执行 curlfor i in $(seq 1 1000); do curl -s -o /dev/null http://127.0.0.1/nginx_status sleep 0.1 done上面的命令会连续请求状态页 1000 次每次间隔 0.1 秒。这样做的目的有两个一是产生真实的 Nginx 请求记录二是让requests累计值明显增长。如果想模拟更高的并发连接可以使用abApache Bench工具ab -n 5000 -c 50 http://127.0.0.1/这条命令表示总共发送 5000 个请求并发 50 个。如果你的测试机没有安装ab执行yum install -y httpd-tools6.2 在 Zabbix 前端查看最新数据进入监测 → 主机 → 最新数据筛选nginx-web-01主机。正常情况下可以看到刚才创建的七个监控项且“最后检查时间”会不断更新。点击“图形”按钮可以查看每个指标的历史曲线。以nginx.active为例在ab压测期间活动连接数会明显冲高。压测结束后数值回落到低位甚至接近 0。如果这个曲线没有变化说明采集链路有问题优先检查 Agent 配置和网络连通性。6.3 解读监控统计结果这里我们重点分析几类指标的变化规律。首先是accepts、handled、requests三个累计值。正常情况下handled约等于accepts如果两者差距持续扩大说明部分连接没有被 Nginx 成功处理可能存在 worker 进程异常或 accept 锁问题。requests通常大于accepts因为一个连接可以发起多个请求Keepalive 连接复用时尤其明显。其次是Reading、Writing、Waiting三个状态值。如果Writing长期很高说明 Nginx 正在大量发送响应数据可能网络带宽成为瓶颈或者客户端接收速度很慢如果Reading很高说明请求体很大或并发上传很多需要检查客户端上传行为如果Waiting占据绝大部分连接数说明 Keepalive 空闲连接很多这时可以通过调整keepalive_timeout参数来限制空闲连接时长。最后要强调一点Zabbix 图形中的requests默认展示的是累计值曲线看起来会是一条一直向上的斜线。如果我们要看 QPS必须基于累计值做差值计算。Zabbix 的 6.0 版本中可以在监控项预处理里选择Change per second或者在图形中临时选择“以每秒变化率显示”。如果使用的是较低版本就需要在自定义脚本中直接输出增量值或者使用 Zabbix 的delta数据收集类型。6.4 验证触发器告警为了测试触发器可以把活动连接数阈值临时调低。例如将nginx.active触发器表达式从大于 500 改成大于 5然后重新执行一次并发请求ab -n 200 -c 20 http://127.0.0.1/等待 1 到 2 个采集周期后进入监测 → 问题应该可以看到该触发器进入告警状态。确认告警生效后记得把阈值修改回合理值避免误报刷屏。如果配置了邮件或企业微信等告警媒介此时还会收到对应通知。关于告警媒介的具体配置属于 Zabbix 管理层面的内容本文不展开但思路是先配置用户和媒介再在动作中关联触发器和用户群组。7. 常见问题与排查思路在实际配置过程中下面几个问题出现的频率很高。问题现象常见原因解决思路zabbix_get返回 ZBX_NOTSUPPORTEDkey 拼写错误或 UserParameter 文件权限不对用zabbix_agentd -t key在 Agent 本机测试检查配置文件路径监控项有数据但长期为 0命令执行返回了非数字内容或 curl 访问状态页超时手动在 Agent 本机执行完整命令确认输出是否正常curl访问/nginx_status返回 403配置了allow和deny规则当前访问 IP 不在白名单检查allow 127.0.0.1是否生效生产环境保持白名单策略Nginx 状态页中 Waiting 一直为 0配置了keepalive但未生效或客户端使用短连接确认配置了keepalive_timeout且客户端支持 KeepaliveZabbix 图形不显示数据监控项未关联主机、采集间隔未到、历史数据保留期已过检查“最新数据”中是否有数据再检查图形配置是否选择了正确主机触发器持续抖动告警阈值设置不合理或使用了累计值直接比较合理使用min/max/avg聚合函数或改为基于增量速率计算这里重点讲一个排查思路先确认 Nginx 状态页本身能访问再确认 Agent 命令能手动执行最后确认 Zabbix 前端能收到数据。三步逐层定位绝大多数问题都能在短时间内解决。另外在配置 UserParameter 时配置文件里的命令如果包含特殊字符或管道符Zabbix Agent 默认会通过 shell 解释执行所以管道符|、重定向符号等都可以正常使用。但如果命令中包含逗号或空格建议用引号把整个命令包起来。8. 最佳实践与生产环境建议8.1 使用模板管理监控项手动创建监控项适合学习原理但生产环境强烈建议使用模板。将本文中的七个 UserParameter key 整合到一套自定义模板中导出 XML 后新增 Nginx 主机时直接关联模板即可。模板中包含监控项、图形、触发器后续统一修改阈值也只需修改模板不用逐台主机调整。8.2 合理设置采集频率Nginx 连接数和请求数属于高频变化指标但并不意味着采集间隔越短越好。一般建议连接数、Reading、Writing、Waiting30 秒到 1 分钟。请求累计值30 秒采集一次用于计算速率。过高的采集频率会占用 Agent 进程资源也会给 Zabbix Server 的数据库写入带来压力。对于几千台主机的大规模环境建议使用 Zabbix Proxy 分担采集压力或者延长采集间隔。8.3 安全最小化配置状态页 location 中保留allow 127.0.0.1; deny all;是最基本的底线。如果 Zabbix Server 和被监控主机不在同一台机器也不要直接放开网段访问建议通过 Zabbix Agent 所在内网网络的运维跳板机访问或者使用防火墙规则限制来源 IP。此外UserParameter 配置文件中尽量不要使用过于复杂的 shell 脚本。命令越简单故障面越小。如果确实需要复杂逻辑建议写成独立脚本放在/etc/zabbix/scripts/目录下并确保执行用户对脚本有读权限和执行权限。8.4 关注趋势数据而非单点值监控系统最大的价值在于趋势分析。单次看到active500很难判断是否异常但如果图形显示过去一周的活动连接数通常在 100 到 150 之间今天突然飙升到 500就可以快速定位到流量异常或发布变更。因此配置监控项时一定要重视趋势数据保留期。默认 30 天的趋势保留期是不够长的建议至少保留 90 天或更长方便做容量规划。8.5 触发器报警要避免重复轰炸生产环境的告警必须要有抑制策略。常见的做法使用min/max/avg函数避免瞬时抖动触发告警。设置恢复表达式让告警在指标恢复后自动关闭。结合业务时段例如凌晨低峰期不发送请求数下降告警。8.6 定期巡检监控项状态Zabbix 中经常出现“监控项不支持”或“数据长时间不更新”的静默故障尤其是当 Nginx 配置变更、Agent 升级、系统重启后自定义命令可能失效。建议每季度巡检一次监控项健康状态重点关注不可达、不支持、无数据三类异常。另外要注意 Nginx 状态页本身没有访问鉴权机制。即使配置了 IP 白名单也建议在 Nginx 上层额外加一层防火墙策略防止状态页被内部其他主机非法访问。如果你使用的是 Nginx Plus官方提供了更丰富的监控指标和 JSON 接口采集方式会更灵活。9. 总结与进阶方向通过本文的实操我们完成了 Nginx stub_status 状态页的开启配置了 Zabbix Agent 的自定义监控项然后在 Zabbix 前端创建主机、监控项、图形和触发器并用请求工具制造访问流量验证了监控数据从采集到展示再到告警的完整链路。同时我们详细解读了 Nginx 状态页各字段的含义以及如何通过 Zabbix 的预处理功能将累计值转换为每秒速率。这套自定义监控方案的优点是灵活、可控、不依赖外部模板也方便扩展其他指标。如果你想要更标准化的做法可以去 Zabbix 官方模板库下载现成的 Nginx by HTTP 或 Nginx template 模板导入后直接关联主机省去手动创建监控项的步骤。下一步可以继续深入的方向包括将 Nginx 日志接入 Zabbix通过日志关键字监控 4xx、5xx 状态码数量。结合 Zabbix 的自动发现规则批量监控多台 Nginx 实例。扩展监控维度例如在后端 upstream 配置健康检查结合 Zabbix 检测后端节点故障。通过 Grafana 接入 Zabbix 数据源制作更美观的业务看板。监控建设的核心是持续迭代。不要期望一套配置永久适用随着业务规模变化阈值、采集频率、告警策略都需要不断调整。建议先从本文的最小配置入手运行一段时间摸清基线数据再逐步丰富监控项和告警规则。