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 21 | 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 监控去检查 NginxZabbix Web 监控确实可以检查页面返回码但它只能反映“服务是否活着”无法感知连接数暴涨、请求速率异常、带宽耗尽这类生产问题。要掌握 Nginx 的实时负载情况必须采集stub_status输出的数据。这也是本文要解决的核心问题。2. 环境准备与版本说明本文以一套基础实验环境为例展开整个方案的验证需要准备以下环境。版本信息请根据你的实际情况调整重点演示配置思路和完整链路。组件推荐版本/环境说明Zabbix Server6.0 LTS / 7.0 LTS6.0 和 7.0 在模板导入上兼容性较好Zabbix Agent6.0 / 7.0与被监控端架构匹配需要安装在被监控的 Nginx 主机上Nginx1.20 或 1.24必须编译了http_stub_status_moduleNginx 主机操作系统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.confserver { 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避免状态页请求刷满访问日志。检查配置并重载 Nginxnginx -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写入以下内容UserParameternginx.active,curl -s http://127.0.0.1/nginx_status | grep Active | awk {print $$3} UserParameternginx.accepts,curl -s http://127.0.0.1/nginx_status | grep server accepts handled requests | awk {print $$1} UserParameternginx.handled,curl -s http://127.0.0.1/nginx_status | grep server accepts handled requests | awk {print $$2} UserParameternginx.requests,curl -s http://127.0.0.1/nginx_status | grep server accepts handled requests | awk {print $$3} UserParameternginx.reading,curl -s http://127.0.0.1/nginx_status | tail -n 1 | awk {print $$2} UserParameternginx.writing,curl -s http://127.0.0.1/nginx_status | tail -n 1 | awk {print $$4} UserParameternginx.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 Connectionsnginx.active数值无符号Nginx Acceptsnginx.accepts数值无符号Nginx Handlednginx.handled数值无符号Nginx Requestsnginx.requests数值无符号Nginx Readingnginx.reading数值无符号Nginx Writingnginx.writing数值无符号Nginx Waitingnginx.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 工具模拟并发请求ApacheBenchab是一个常见的 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_NOTSUPPORTEDAgent 端 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只调用脚本UserParameternginx.active,/usr/local/scripts/nginx_status.sh active脚本内容如下#!/bin/bash # 文件位置/usr/local/scripts/nginx_status.sh STATUS_URLhttp://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 配置改为UserParameternginx.active,/usr/local/scripts/nginx_status.sh active UserParameternginx.accepts,/usr/local/scripts/nginx_status.sh accepts UserParameternginx.handled,/usr/local/scripts/nginx_status.sh handled UserParameternginx.requests,/usr/local/scripts/nginx_status.sh requests UserParameternginx.reading,/usr/local/scripts/nginx_status.sh reading UserParameternginx.writing,/usr/local/scripts/nginx_status.sh writing UserParameternginx.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 时直接对照操作可以节省不少排查时间。