一、为什么“只做 Ping 监控”一定不够？

在很多环境里，监控体系往往止步于一句话：

“Ping 通就算正常。”

但你一定遇到过这些情况：

• 服务器 Ping 通，但 Web 访问 502

• 数据库主机在线，但 3306 端口拒绝连接

• 防火墙没掉，但某个 UDP 服务已经失效

• Ping 正常，业务用户却集体报障

原因只有一个：

Ping 只能证明“网络层连通”，不能证明“服务层可用”。

而真正决定业务是否可用的，是 端口。

二、端口监控的本质：TCP 和 UDP 完全不是一回事

在 Zabbix 里，监控 TCP 端口和 UDP 端口，逻辑完全不同。

TCP 端口的本质

• 有三次握手

• 有连接成功 / 失败的明确结果

• “连得上 ≈ 服务活着”

UDP 端口的本质

• 无连接

• 不保证响应

• “没回包 ≠ 服务一定有问题”

👉 这意味着：
TCP 可以直接监控，UDP 必须“换思路”。

三、Zabbix 监控 TCP 端口

1️⃣ 核心监控项：net.tcp.service

这是 Zabbix 官方、推荐、最稳定的 TCP 端口监控方式。

示例：监控 MySQL（3306）

net.tcp.service[tcp,,3306]

含义：

• Zabbix Server / Proxy

• 尝试与目标主机的 TCP 3306 建立连接

• 成功返回 1，失败返回 0

2️⃣ 常见 TCP 服务示例

3️⃣ TCP 端口触发器（生产推荐）

服务不可达（2 分钟才报警）

max(/<HOST>/net.tcp.service[tcp,,3306],2m)=0

解释：

• 最近 2 分钟

• 一次都没连上

• 过滤瞬时抖动、重启瞬间

四、TCP 端口监控的常见误区（非常重要）

❌ 误区 1：只要端口通就代表业务正常

端口通 ≠ 应用可用
（Web 500、数据库锁表、线程耗尽，端口都可能还在）

👉 端口监控是“最基础可用性”，不是最终状态

❌ 误区 2：在 Server 不可达的网络强行监控

如果 Server / Proxy 无法访问业务网段：

• TCP 端口监控会全部失败

• 告警没有任何判责价值

👉 必须结合 Proxy，就地监控

五、Zabbix 监控 UDP 端口（最容易被误解）

先给结论（很重要）

Zabbix 没有“真正意义上的 UDP 端口可达性监控”。

因为：

• UDP 无连接

• 没有统一的“成功”标准

六、那 UDP 端口还能不能监控？能，但要换方式

方案一：net.udp.service（仅限少数协议）

Zabbix 支持部分 有标准响应的 UDP 协议，例如：

• DNS（53）

• NTP（123）

示例：DNS

net.udp.service[dns,,53]

⚠️ 只对有协议响应的 UDP 服务有效
⚠️ 对“自定义 UDP 服务”基本无效

方案二（推荐）：Agent 本地执行探测（生产级）

这是真正可靠的 UDP 监控方式。

思路

• 由被监控主机本地

• 使用 nc / ss / 应用自检命令

• 返回明确结果给 Zabbix

示例：UDP 端口是否在监听

ss -lun | grep ':514 '

结合 UserParameter：

UserParameter=udp.listen[514],ss -lun | grep -q ':514 ' && echo 1 || echo 0

方案三：用 TCP 间接监控 UDP 服务（工程实践常用）

很多 UDP 服务都有：

• 管理端口（TCP）

• 控制接口（HTTP / TCP）

例如：

• DNS：UDP 53 + TCP 53

• 日志服务：UDP 514 + 管理 TCP

• 游戏服务：UDP 端口 + 控制 TCP

👉 监控 TCP 管理端口，反而更稳定

七、TCP / UDP 端口监控的推荐组合策略

八、端口监控 + Ping 的“正确搭配方式”

这是很多成熟运维团队的标准做法：

1️⃣ Ping：判断“设备 / 链路是否在线”
2️⃣ TCP 端口：判断“服务是否在监听”
3️⃣ 应用指标：判断“业务是否真的可用”

三者缺一不可。

九、可以直接写进方案的一句话总结

Zabbix 中 TCP 端口监控可通过 net.tcp.service 实现稳定的服务可达性检测，而 UDP 端口因协议特性需结合协议响应或本地探测方式进行监控，二者应与 Ping 监控协同使用，构建完整的连通性与服务可用性监控体系。

十、详细操作举例

10.1、创建主机

可以基于端口类型或者应用系统创建主机，此处要添加主机接口，用于做端口探测的主机服务器

10.2、创建监控项

可以基于agent进行监听

也可以基于服务端的简单检查进行监听，骑着net.tcp.service的参数需要填写service，因此智能识别zabbix预定的服务类型，不适合随机端口的监听，不是只连端口，而是会做简单协议校验，比 tcp 更“懂业务一点”。

最常用的服务

协议级别的常见服务

可以看到获取了最新的数据

然后进一步创建图形即可

建议对HTTP的监控直接选择-简单检查-性能监控，不仅兼顾了服务的可用性，而且显示实际访问的延迟

图形建议选择正常-绘图风格梯度线，对比更直观

同理创建UDP的监控项

注意主机接口要是实际地址，不能是bridge地址，因此本机其的agent监控NTP服务是不可用的，其他主机用宿主机地址是可以的。

10.3、创建触发器

结尾

真正成熟的监控体系，从来不是“一个指标解决所有问题”。
Ping 告诉你“还活着”，端口告诉你“还能不能接活”，应用指标告诉你“活得好不好”。

把 TCP / UDP 端口监控补齐，你的 Zabbix 才算真正从“在线监控”，走向“可用性监控”。