1. 背景与核心概念：为什么选择 Zabbix 监控 Nginx
在业务系统上线以后，监控是保证服务稳定性的关键手段之一。很多同学在做监控方案时，会优先想到把 Nginx 的日志接入 ELK，或者通过 Prometheus 采集指标，但在实际的企业内网环境中，Zabbix 依然占据着非常重要的位置。原因也很直接：Zabbix 提供了从主机发现、指标采集、告警触发到可视化展示的完整闭环，尤其适合已经有 Zabbix 基础设施的团队。
当我们讨论“Zabbix 监控 Nginx”时，首先要区分两个层面的监控：
| 监控层面 | 采集内容 | 常见手段 |
|---|---|---|
| 存活监控 | 进程是否存在、端口是否监听、HTTP 是否返回 200 | 简单检查、Agent Ping、Web 检测 |
| 性能与状态监控 | 活跃连接数、请求总数、接受连接数、读写字节数 | Nginx stub_status、nginx-module-vts、第三方 Exporter |
本文重点围绕第二种，也就是基于 Nginx 自带的stub_status模块，把 Nginx 的运行状态指标采集到 Zabbix Server，再通过模板绘制出可视化图形。
这里要强调一个概念：Nginx 本身默认编译时不一定带stub_status模块，需要确认当前的 Nginx 是否开启了该模块。判断方法很简单，执行：
nginx -V 2>&1 | grep -o 'http_stub_status_module'如果输出为http_stub_status_module，说明已经支持；如果没有任何输出，也没有报错，说明当前 Nginx 缺少该模块，需要重新编译或改用 OSS 版本的 Nginx 镜像。
Zabbix 监控 Nginx 的基本链路如下：
Nginx（开启 stub_status） ↓ Zabbix Agent（读取 status 页面或 curl 拉取） ↓ Zabbix Server（根据 Item 配置定时采集） ↓ 模板 → 图形 → 触发器 → 告警通知很多初学者会问：为什么不直接通过 Zabbix 内置的 Web 监控去检查 Nginx？Zabbix Web 监控确实可以检查页面返回码，但它只能反映“服务是否活着”，无法感知连接数暴涨、请求速率异常、带宽耗尽这类生产问题。要掌握 Nginx 的实时负载情况，必须采集stub_status输出的数据。这也是本文要解决的核心问题。
2. 环境准备与版本说明
本文以一套基础实验环境为例展开，整个方案的验证需要准备以下环境。版本信息请根据你的实际情况调整，重点演示配置思路和完整链路。
| 组件 | 推荐版本/环境 | 说明 |
|---|---|---|
| Zabbix Server | 6.0 LTS / 7.0 LTS | 6.0 和 7.0 在模板导入上兼容性较好 |
| Zabbix Agent | 6.0 / 7.0，与被监控端架构匹配 | 需要安装在被监控的 Nginx 主机上 |
| Nginx | 1.20+ 或 1.24+ | 必须编译了http_stub_status_module |
| Nginx 主机操作系统 | CentOS 7 / Rocky Linux / Ubuntu 22.04 | 以下命令以 CentOS/Rocky 为主 |
| Zabbix Server 数据库 | MySQL 8.0 / PostgreSQL | 不影响本文配置思路 |
| Web 浏览器 | Chrome / Edge | 用于导入模板、查看图形 |
如果是生产环境，建议在正式操作前先在测试机完整走一遍流程，避免直接改动生产 Nginx 引发业务抖动。
本文默认你已经完成了以下前置工作：
- Zabbix Server 已安装并正常运行。
- Zabbix Agent 已安装到 Nginx 所在主机，并且 Agent 与 Server 能正常通信。
- 可以在 Zabbix Web 界面看到被监控主机的“已监控”状态。
如果还没有完成 Zabbix 的安装部署，可以参考 Zabbix 官方文档或之前的部署教程，先把基础环境搭建好，再回到本文继续。
3. 核心原理：Nginx stub_status 的指标含义
在配置 Zabbix 采集之前，必须先理解stub_status的输出格式。这个模块是 Nginx 官方提供的状态页模块，配置非常简单，在 Nginx 配置文件的server {}块中增加一个location即可。
3.1 开启 Nginx stub_status
修改 Nginx 配置文件，例如/etc/nginx/conf.d/status.conf：
server { listen 80; server_name 127.0.0.1; location /nginx_status { stub_status on; access_log off; allow 127.0.0.1; deny all; } }这里注意几点：
stub_status on;是开启状态页的关键指令。allow 127.0.0.1;和deny all;用于限制访问来源，避免状态页暴露到公网，这一点在生产环境非常重要。access_log off避免状态页请求刷满访问日志。
检查配置并重载 Nginx：
nginx -t systemctl reload nginx然后在 Nginx 本机访问状态页：
curl http://127.0.0.1/nginx_status正常情况下会输出类似下面的内容：
Active connections: 12 server accepts handled requests 34529 34529 52681 Reading: 0 Writing: 2 Waiting: 103.2 每个指标的含义
| 指标 | 含义 | 监控价值 |
|---|---|---|
| Active connections | 当前活跃连接数，包括 Waiting 连接 | 反映 Nginx 当前并发处理情况 |
| accepts | 累计接受的客户端连接数 | 用于计算连接速率 |
| handled | 累计成功处理的连接数 | 如果与 accepts 差值增大，说明有连接被丢弃 |
| requests | 累计客户端请求数 | 用于计算 QPS 请求速率 |
| Reading | 正在读取请求头的连接数 | 数值过高说明读取请求慢 |
| Writing | 正在写响应的连接数 | 数值过高说明响应输出压力大 |
| Waiting | 空闲且等待请求的连接数（keep-alive） | 通常与活跃连接相关，等待数多说明长连接正常 |
很多监控教程只教你配置不教你解读，导致图形出来了却不知道指标含义。这里特别强调两个容易忽略的统计维度：
第一个是accepts与handled的关系。正常情况下两者应该非常接近，因为 Nginx 几乎能处理所有接受的连接。如果handled明显小于accepts，说明可能存在 worker_connections 配置不足、系统文件句柄限制或后端超时导致连接被关闭。
第二个是requests与accepts的比值。这个比值可以理解为每个连接平均发起的请求数。在 keep-alive 开启的情况下，一个连接可以承载多个请求，所以比值会大于 1。如果比值接近 1，说明客户端几乎没有使用长连接，每次请求都在重新建立 TCP 连接，这会增加握手开销。在生产调优时，这个比值具有一定的参考意义，但需要结合具体应用场景判断，不能一概而论。
3.3 Zabbix Agent 自定义监控键
Zabbix Agent 默认提供了一些内置键，比如net.tcp.service、net.tcp.port、proc.num等，但这些键无法直接解析 Nginx 状态页的文本内容。因此我们需要通过 Zabbix 的“用户自定义参数”来实现。
用户自定义参数的原理很简单：
Zabbix Server 请求 Agent 的某个 Key ↓ Agent 读取配置文件中的 UserParameter 定义 ↓ 执行对应命令，获取输出文本 ↓ Agent 将输出结果返回给 Server对于 Nginx 监控，最常规的做法是：Agent 通过curl获取stub_status页面内容，再利用sed、awk、grep等文本处理工具提取对应数值，每个指标对应一个 Key。
这里有一个细节值得展开说明。Zabbix 有两种监控数据获取模式：被动模式和主动模式。被动模式下 Server 每隔一段时间来 Agent 拉取一次数据；主动模式下 Agent 自己定时收集数据并上报给 Server。使用主动模式时，Agent 执行自定义脚本的节奏由 Agent 端控制，能减轻 Server 压力，适合主机量大或网络分区复杂的场景。不过本文默认使用被动模式，配置相对直观。
3.4 为什么一定要先手动验证命令
在实际配置过程中，最常见的失败原因并不是 Zabbix 配置错误，而是手动执行命令时输出正常，但配置到UserParameter后却取不到数据。原因通常是：
- Agent 运行用户（默认
zabbix）没有执行curl的权限。 curl命令不在 Agent 的 PATH 环境变量中。- 状态页访问地址写的是 localhost，但 Agent 环境解析不到。
- 自定命令存在转义问题。
所以接下来的所有脚本和命令，我都会先提供手动执行版本，并要求你在zabbix用户下验证。这是整个监控配置中最容易踩坑的地方。
4. 完整实战：Zabbix 监控 Nginx 配置全过程
下面进入完整的实战环节。整个流程分为五个部分：确认 Agent 环境、编写监控脚本、配置用户自定义参数、导入模板、验证结果。
4.1 确认 Agent 环境与 curl 可用性
先切换到zabbix用户，验证能否正常读取状态页：
su - zabbix -s /bin/bash curl -s http://127.0.0.1/nginx_status如果这里报错，先排查 Nginx 状态页配置以及防火墙。如果输出正常，再确认curl的完整路径：
which curl常见的输出是/usr/bin/curl。记住这个路径，后面配置 UserParameter 时建议使用绝对路径。
4.2 编写提取监控指标的命令
在配置UserParameter之前，先手动测试提取逻辑。以下每条命令都应当能得到一个纯数字输出。
提取当前活跃连接数：
curl -s http://127.0.0.1/nginx_status | grep 'Active' | awk '{print $3}'提取 accepts 连接数：
curl -s http://127.0.0.1/nginx_status | grep 'server accepts handled requests' | awk '{print $1}'提取 handled 连接数：
curl -s http://127.0.0.1/nginx_status | grep 'server accepts handled requests' | awk '{print $2}'提取 requests 请求数：
curl -s http://127.0.0.1/nginx_status | grep 'server accepts handled requests' | awk '{print $3}'提取 Reading 连接数：
curl -s http://127.0.0.1/nginx_status | tail -n 1 | awk '{print $2}'提取 Writing 连接数：
curl -s http://127.0.0.1/nginx_status | tail -n 1 | awk '{print $4}'提取 Waiting 连接数：
curl -s http://127.0.0.1/nginx_status | tail -n 1 | awk '{print $6}'有的资料会建议一次请求状态页后保存到临时文件，再多次 grep，减少对 Nginx 的请求次数。如果状态页访问频率很高，这种做法有一定意义；但在常见监控场景下，Agent 的采集频率不会太高，多次 curl 的开销可以接受。保持脚本简单更利于排错。
4.3 配置 Zabbix Agent 用户自定义参数
找到 Agent 的配置文件，通常位于：
/etc/zabbix/zabbix_agentd.conf或者：
/etc/zabbix/zabbix_agent2.conf在配置文件末尾追加用户自定义参数。为了便于管理，建议单独创建文件：
vim /etc/zabbix/zabbix_agentd.d/nginx_status.conf写入以下内容：
UserParameter=nginx.active,curl -s http://127.0.0.1/nginx_status | grep 'Active' | awk '{print $$3}' UserParameter=nginx.accepts,curl -s http://127.0.0.1/nginx_status | grep 'server accepts handled requests' | awk '{print $$1}' UserParameter=nginx.handled,curl -s http://127.0.0.1/nginx_status | grep 'server accepts handled requests' | awk '{print $$2}' UserParameter=nginx.requests,curl -s http://127.0.0.1/nginx_status | grep 'server accepts handled requests' | awk '{print $$3}' UserParameter=nginx.reading,curl -s http://127.0.0.1/nginx_status | tail -n 1 | awk '{print $$2}' UserParameter=nginx.writing,curl -s http://127.0.0.1/nginx_status | tail -n 1 | awk '{print $$4}' UserParameter=nginx.waiting,curl -s http://127.0.0.1/nginx_status | tail -n 1 | awk '{print $$6}'这里有一个非常重要的细节：在UserParameter配置文件中，awk的字段引用符$1、$2必须写成$$1、$$2。因为 Zabbix Agent 在解析 UserParameter 时会把$当作特殊字符处理，只有用$$才能保留为 shell 中的$。如果你直接写$3，取到的数据往往是空值或者异常值。
这是新手配置 Zabbix 自定义监控项时最频繁踩的坑。
修改完成后，重启 Agent 使配置生效：
systemctl restart zabbix-agent # 或 systemctl restart zabbix-agent2查看 Agent 日志确认没有报错：
tail -n 50 /var/log/zabbix/zabbix_agentd.log4.4 在 Zabbix Server 端验证监控键
在 Zabbix Server 上手动验证 Agent 配置是否生效。注意：如果你在生产环境中无法直接登录 Zabbix Server，也可以通过 Web 界面的“测试”功能验证，这里说明命令方式。
在 Zabbix Server 上执行：
zabbix_get -s 192.168.1.100 -k nginx.active其中192.168.1.100换成你 Nginx 主机的 IP。
如果返回一个数字，比如：
12说明 Agent 自定义参数已经生效。如果返回：
ZBX_NOTSUPPORTED说明 Agent 端执行命令出错，或者 Key 没有加载成功。此时需要回到 Agent 主机排查，重点检查：
zabbix_agentd -t nginx.active这个命令可以在 Agent 本机测试 Key 是否能正常返回，而且会输出详细的报错信息，是排查利器。
如果使用的是 Zabbix Agent 2，测试命令是：
zabbix_agent2 -t nginx.active下面展示一个典型场景：假设你在UserParameter配置文件中写了awk '{print $3}'而不是$$3，那么在zabbix_agentd -t nginx.active的输出中，你会看到$3被 Zabbix 解析成了空，最终返回空值或ZBX_NOTSUPPORTED。这时候把$3改成$$3再重启 Agent，问题就解决了。
4.5 导入 Nginx 监控模板
现在我们已经有了 7 个可用的监控键。接下来需要在 Zabbix Web 界面创建监控模板。有两种思路：
第一种是手动创建模板，逐个添加 Item、Graph、Trigger，优点是灵活，缺点是比较繁琐。第二种是直接使用社区现成的模板 XML 文件，导入后修改键名称即可。
这里我推荐手动创建，因为手动创建能让你理解每个配置项的含义，后续排查问题会更有方向。如果只是为了快速上线，也可以先用社区模板，再根据实际情况调整采集项。
在 Zabbix Web 界面操作流程：
进入“配置 → 模板”，点击右上角“创建模板”：
- 模板名称：Nginx by Zabbix agent - custom
- 可见名称：Nginx 自定义监控
- 群组：Templates/Applications
创建完成后，在模板中创建应用程序（Applications）。应用程序可以理解为监控项的分组，例如“Nginx Status”。这样在图形和最新数据页面中筛选更方便。
然后为模板添加监控项（Items）。以“活跃连接数”为例，配置如下：
| 配置项 | 值 |
|---|---|
| 名称 | Nginx Active Connections |
| 类型 | Zabbix agent（被动） |
| 键值 | nginx.active |
| 信息类型 | 数值（无符号） |
| 更新间隔 | 30秒 |
| 历史数据保留 | 7天 |
| 趋势数据保留 | 30天 |
其他监控项类似，下面汇总成一张配置表：
| 监控项名称 | 键值 | 信息类型 |
|---|---|---|
| Nginx Active Connections | nginx.active | 数值（无符号） |
| Nginx Accepts | nginx.accepts | 数值（无符号） |
| Nginx Handled | nginx.handled | 数值（无符号） |
| Nginx Requests | nginx.requests | 数值（无符号） |
| Nginx Reading | nginx.reading | 数值（无符号） |
| Nginx Writing | nginx.writing | 数值（无符号） |
| Nginx Waiting | nginx.waiting | 数值（无符号） |
这里特意说明：nginx.active的取值建议使用“更新间隔 30 秒”，这个频率既能及时反映连接数变化，又不会对 Nginx 和 Zabbix Server 造成压力。nginx.reading、nginx.writing、nginx.waiting这三个值变化相对平缓，可以设置 60 秒，减少无效采集。
监控项创建完成后，模板中创建图形。添加图形时选择刚才创建的监控项，图形类型选择“线图”。对于 accepts、handled、requests 这类不断增加的数字，显示的是累计值曲线。如果你希望看到速率变化，可以在监控项的“预处理”步骤中将数据转为变化率。在 Zabbix 6.0 及以上版本，进入监控项编辑页面，在“预处理”中添加“变化率”即可。
4.6 将模板关联到主机
模板配置完成后，回到“配置 → 主机”，找到运行 Nginx 的那台主机，在“模板”栏点击“选择”，添加刚才创建的模板，然后点击“更新”。
此时主机的监控项会自动创建。等待几秒钟，进入“监测 → 最新数据”，筛选该主机，就可以看到监控项开始有数据了。
如果持续显示“不支持”，不要着急，优先使用zabbix_get和zabbix_agentd -t定位是关键所在。绝大多数问题出在 Agent 端，而不是 Server 端。
5. 测试监控统计：生产环境下的验证方法
配置完成后，我们需要验证监控项的准确性。这里提供一套可操作的测试思路。在 Nginx 本机或局域网内模拟请求流量，然后去 Zabbix 最新数据里观察指标变化。
5.1 使用 ab 工具模拟并发请求
ApacheBench（ab）是一个常见的 HTTP 性能测试工具。如果系统没有安装，可以通过 yum 安装：
yum install -y httpd-tools然后模拟并发请求：
ab -n 10000 -c 100 http://127.0.0.1/这条命令表示总共发送 10000 个请求，每次并发 100 个。运行期间，观察 Zabbix 最新数据中的nginx.active应该会明显升高。
5.2 观察 Requests 累计值变化
nginx.requests是一个累计值，所以在测试前先记下当前值，测试结束后再看增量。你可以连续执行两次：
curl -s http://127.0.0.1/nginx_status第一次记录 requests 数值，第二次在压测结束后记录，差值大约等于压测产生的请求数。不过由于系统本身可能有其他访问，完全精确对比并不现实，我们只需要确认数值在增长即可。
5.3 观察 Reading、Writing、Waiting
- 压测时
Reading和Writing会明显波动，尤其是Writing，因为 Nginx 正在向客户端输出响应。 - 压测结束后，
Writing会回落。 Waiting与 keep-alive 连接有关。如果客户端支持长连接，压测结束后仍可能有部分连接处于Waiting状态。
5.4 验证告警触发器
除了查看图形数据，还可以创建一个简单的触发器来验证告警链路。例如：
当活跃连接数持续 3 分钟超过 1000 时触发告警。
进入“配置 → 模板 → 你的模板 → 触发器”，创建触发器：
- 名称：Nginx Active Connections is too high
- 严重性：警告
- 表达式：
last(/Nginx by Zabbix agent - custom/nginx.active)>1000
这里看到表达式的格式是 Zabbix 5.0 以上版本的新写法，旧版本可能写成{模板:键值.last()} > 1000。如果你使用的是 6.0 或 7.0，建议使用新格式。表达式中last(/模板名/键值)的含义是：获取指定模板下某个监控项最近一次的值。
设置好触发器后，再次用ab压测，观察是否触发告警。如果告警没有触发，检查触发器的表达式是否写错，或者监控项名称是否被修改。
6. 结果详解：如何从 Zabbix 图形中判断 Nginx 健康状态
监控数据采集上来之后，很多人不知道如何从图形中判断问题。下面结合几个典型的图形特征做解读。
6.1 活跃连接数突然飙升
如果nginx.active在短时间内快速上升并持续不回落，通常有几种可能：
- 有爬虫或攻击流量进入。
- 后端接口响应变慢，连接堆积。
- 某个活动页面上线，用户访问量骤增。
- 负载均衡策略导致流量集中到个别节点。
此时应结合 Nginx 访问日志和ss -s命令查看 TCP 连接情况，判断是正常流量还是异常流量。
6.2 Writing 持续偏高
Writing表示正在向客户端写响应的连接数。如果这个值持续偏高，说明 Nginx 响应输出压力大。可能的原因包括：后端服务响应慢导致超时重试、客户端网络带宽有限导致发送阻塞、Nginx 缓存未开启导致频繁读取磁盘。
排查思路：先看后端响应时间，再看 Nginx 是否配置了代理缓存，最后检查客户端带宽。
6.3 Accepts 与 Handled 差值增大
正常情况下accepts和handled应该几乎一样。如果差值持续扩大，说明有一些连接没有被 Nginx 成功处理。常见原因：
worker_connections设置太小。- 系统
ulimit文件句柄限制过低。 - 后端主动断开连接。
查看 Nginx 错误日志：
tail -n 100 /var/log/nginx/error.log如果看到worker_connections are not enough，说明需要调大worker_connections，或者增加 worker 进程数。
6.4 Waiting 为 0 时需要注意什么
Waiting为 0 意味着没有空闲的 keep-alive 连接。在高并发短连接场景下，这并不一定是坏事，但如果业务本身大量使用 HTTP 长连接，Waiting长期为 0 可能说明 keep-alive 配置没生效，例如客户端没有发送Connection: keep-alive头，或者 Nginx 的keepalive_timeout设置过短。
7. 常见问题与排查思路
下面汇总一份高频问题排查表：
| 问题现象 | 常见原因 | 解决思路 |
|---|---|---|
zabbix_get返回ZBX_NOTSUPPORTED | Agent 端 Key 未加载或命令执行失败 | 在 Agent 端使用zabbix_agentd -t 键值测试 |
| 监控项一直显示“不支持” | curl 命令路径问题或状态页访问受限 | 使用绝对路径/usr/bin/curl，确认状态页可访问 |
awk取值为空 | $符号未被转义 | 将$3改为$$3 |
| 图形全是一条直线 | 更新间隔过长或监控项类型错误 | 确认数据类型为“数值（无符号）”，缩短更新间隔 |
| 数字增长速度异常 | 监控的是累计值而不是速率 | 添加预处理步骤，转为变化率 |
| Nginx 状态页无法访问 | 防火墙或 allow/deny 配置问题 | 检查防火墙规则和 Nginx location 配置 |
| Agent 重启失败 | 配置文件语法错误 | 执行zabbix_agentd -t或systemctl status查看详细报错 |
这里再展开一个非常典型的问题：Zabbix Agent 2 与 Agent 1 的配置差异。Zabbix Agent 2 是 Agent 1 的替代版本，配置文件路径通常是/etc/zabbix/zabbix_agent2.conf，自定义参数的用法类似，但测试命令是zabbix_agent2 -t 键值。如果你用的 Zabbix 7.0 搭配 Agent 2，不要还按 Agent 1 的命令去测试。
另外，很多同学在配置UserParameter时喜欢把 curl 命令直接写到参数里，但一旦命令中包含了管道符、引号、特殊字符，解析就会变得非常脆弱。更稳妥的做法是把取值逻辑写成一个 shell 脚本，UserParameter只调用脚本：
UserParameter=nginx.active,/usr/local/scripts/nginx_status.sh active脚本内容如下：
#!/bin/bash # 文件位置：/usr/local/scripts/nginx_status.sh STATUS_URL="http://127.0.0.1/nginx_status" case $1 in active) curl -s "$STATUS_URL" | grep 'Active' | awk '{print $3}' ;; accepts) curl -s "$STATUS_URL" | grep 'server accepts handled requests' | awk '{print $1}' ;; handled) curl -s "$STATUS_URL" | grep 'server accepts handled requests' | awk '{print $2}' ;; requests) curl -s "$STATUS_URL" | grep 'server accepts handled requests' | awk '{print $3}' ;; reading) curl -s "$STATUS_URL" | tail -n 1 | awk '{print $2}' ;; writing) curl -s "$STATUS_URL" | tail -n 1 | awk '{print $4}' ;; waiting) curl -s "$STATUS_URL" | tail -n 1 | awk '{print $6}' ;; *) echo "Usage: $0 {active|accepts|handled|requests|reading|writing|waiting}" exit 1 ;; esac给脚本添加执行权限：
chmod +x /usr/local/scripts/nginx_status.sh然后 UserParameter 配置改为：
UserParameter=nginx.active,/usr/local/scripts/nginx_status.sh active UserParameter=nginx.accepts,/usr/local/scripts/nginx_status.sh accepts UserParameter=nginx.handled,/usr/local/scripts/nginx_status.sh handled UserParameter=nginx.requests,/usr/local/scripts/nginx_status.sh requests UserParameter=nginx.reading,/usr/local/scripts/nginx_status.sh reading UserParameter=nginx.writing,/usr/local/scripts/nginx_status.sh writing UserParameter=nginx.waiting,/usr/local/scripts/nginx_status.sh waiting这种方式的好处是：脚本逻辑独立，方便维护和扩展；以后要加监控指标，只需要在脚本中增加一个 case 分支即可，不需要改动 Zabbix 配置。
8. 最佳实践与工程建议
到这里，整套 Zabbix 监控 Nginx 的链路已经通了。但实际生产环境的工程要求远不止“能出图”这么简单。下面总结几条核心建议，供你在项目落地时参考。
8.1 安全边界：状态页绝不能暴露公网
stub_status页面包含连接数、请求数等内部指标，如果暴露到公网，会被恶意探测利用。生产环境中，建议将状态页监听在 127.0.0.1 上，只允许 Zabbix Agent 本机访问，或者通过内网网段限制。前面已经演示了allow/deny的写法，这是底线要求。
如果 Nginx 部署在 Docker 容器中，状态页同样应该监听 127.0.0.1，但容器内的 127.0.0.1 与宿主机不同。此时需要根据 Docker 网络模式调整访问地址，或者将状态页监听在内网 IP 加防火墙限制，最终目的是让“只有被允许的主机能访问”。
8.2 采集频率与性能平衡
Zabbix 采集频率过高会带来不必要的系统开销，尤其是 Nginx 作为高并发入口时，状态页访问本身就有一点开销。大多数场景下 30 秒采集一次已经足够。如果需要对瞬时流量做精细化监控，可以缩短到 10 秒，但不建议低于 5 秒。
8.3 使用 Zabbix 预处理能力
Zabbix 6.0 以上版本自带数据预处理功能，可以把累计值转换成速率、单位、自定义倍数。比如将nginx.requests的变化率作为“每秒请求数”来监控，这样比看累计值更直观，也更适合设置告警阈值。在监控项编辑页面的“预处理”中，添加一步“变化率”即可。
8.4 告警阈值要结合历史基线
不要拍脑袋设置告警阈值。合理做法是：先让监控跑 1 到 2 周，积累一定历史数据后，再根据业务周期设置基线。例如某系统平时活跃连接数稳定在 100 左右，大促时可到 2000，那么阈值设为 1500 并持续 5 分钟触发告警，就比较合理。如果业务本身就存在周期性波动，还可以配合时间段触发器，区分业务高峰与低谷。
8.5 关注 Zabbix 版本兼容性
Zabbix 7.0 和 6.0 在模板格式上没有本质差异，但从 5.0 到 6.0 过程中，触发器表达式语法有过调整。如果你是从旧版本升级上来的，建议逐个确认模板中的表达式格式。另外，Zabbix Agent 与 Server 的版本最好保持大版本一致，跨大版本使用虽然多数情况下兼容，但某些新键值可能不可用。
8.6 日志与排错体系
Zabbix Agent 日志默认路径为/var/log/zabbix/，调试时可以把日志级别临时调高，但生产环境不建议长期开启 Debug 级别，会大量占用磁盘。排错完成后及时恢复日志级别。
同时，建议将 Nginx 状态采集与其他监控维度联动，比如系统 CPU、内存、磁盘、网络、后端服务健康状态。单一的 Nginx 活跃连接数并不能准确反映业务稳定性，关联分析才能更快定位问题。
9. 总结与下一步学习方向
本文从 Zabbix 监控 Nginx 的核心需求出发，完整介绍了 Nginxstub_status指标含义、Zabbix Agent 用户自定义参数的配置方法、模板创建流程、压测验证方式以及结果解读思路。你现在应该能够独立完成从状态页开启、Agent 配置、Server 验证到图形展示的全过程。
整个过程中最核心也最容易出问题的地方有三个：第一，UserParameter中awk的$$转义；第二，Agent 端手动测试命令与 Server 端zabbix_get核对；第三，模板关联后耐心等待数据采集并鉴别“不支持”状态的根因。把这三个点掌握了，Zabbix 自定义监控的基本功也就打牢了。
如果继续深入学习，可以重点关注这几个方向：一是 Zabbix 主动模式与被动模式的选择与批量部署，二是通过 Zabbix 模板导入导出来规范化管理监控项，三是结合 Grafana 做更美观的 Nginx 可视化面板，四是探索nginx-module-vts或 Prometheus Exporter 这类更丰富的 Nginx 指标方案。不同方案之间并不是互斥的，完全可以根据业务场景混合使用。
希望这篇教程对你有所帮助。如果你在实际配置中遇到了文中没有覆盖到的报错或者奇怪的阈值表现，欢迎在评论区把相关日志和你使用的版本发出来，通常结合具体版本和环境能更快定位问题。收藏本文备查，下次配置 Zabbix 监控 Nginx 时直接对照操作，可以节省不少排查时间。
