Web管理界面中Zabbix自动发现功能失效是运维场景里特别常见的小问题，很多人刚碰到的时候会慌神，不知道从哪下手查，其实只要按部就班走流程，很快就能搞定。
一、先搞懂Zabbix自动发现的核心作用
很多人用Zabbix的时候，都是自己手动一个个加主机，要是机房里新增十几二十台服务器，手动加不仅慢，还容易漏。自动发现就是干这个的：你设置一个要扫的IP段，Zabbix会自动去扫这个段里的在线设备，然后把符合条件的设备自动添加到Zabbix的监控里，还给对应设备绑定好监控模板，不用你手动配置。这个功能特别适合服务器数量多、更新快的场景，能省好多重复的力气。不过它也有自己的小毛病，要是配置得不对，反而会出问题，这就是我们要排查的失效情况。
1.1 自动发现的常见应用场景
比如公司新租了一个机柜，放了20台新的Linux服务器，你要一个个加的话，得打开Web界面，输入主机名、IP地址、选模板、点保存，一台得花2分钟，20台就是40分钟，还容易写错IP。用自动发现的话，你只需要把新的IP段填到发现规则里，设置好要探测的端口，剩下的交给Zabbix，10分钟之内就能搞定，还不会出错。还有的时候是公司的服务器IP会动态变化，比如测试环境的服务器，每次开机IP都不一样，自动发现也能自动抓新的IP，不用你手动更新。
二、Zabbix自动发现失效的典型排查步骤
碰到失效的时候，别乱翻Web界面，先按顺序查四个地方：发现规则、发现动作、通信链路、日志，每个地方都有对应的排查方法，还有现成的工具可以用。
2.1 先查“发现规则”本身有没有问题
发现规则就是你告诉Zabbix要扫哪个IP段、用什么方式扫的配置，最容易出问题的就是网段写错，或者探测的端口不对。比如你要扫192.168.3.0/24的IP，结果写成了192.168.1.0/24，那Zabbix扫了半天都是空的，自然不会发现任何主机。这时候你可以用我写的这个Shell脚本，模拟Zabbix的探测逻辑，扫一遍你设置的IP段，看看有没有存活的主机，要是没扫到，那肯定是规则里的网段错了或者端口不对。
#!/bin/bash
# 功能：扫描指定网段内响应Zabbix Agent的主机，用于排查自动发现失效问题
# 这里要改成你Zabbix里发现规则用的IP段前缀，比如你扫192.168.3开头的，就写成192.168.3.
TARGET_NET="192.168.3."
# Zabbix Agent默认的端口是10050，要是你改了端口，这里也要对应改
TARGET_PORT="10050"
# 循环扫描1到254的IP，覆盖整个子网
for i in {1..254}
do
# ping 1个包，等1秒超时，减少等待时间，判断主机是否在线
ping -c1 -W1 ${TARGET_NET}$i > /dev/null 2>&1
if [ $? -eq 0 ]; then
# 在线的话，测Zabbix Agent端口是否开放，用nc工具
nc -zv ${TARGET_NET}$i ${TARGET_PORT} > /dev/null 2>&1
if [ $? -eq 0 ]; then
echo "找到了：${TARGET_NET}$i，Zabbix Agent正常运行"
else
echo "在线但端口不对：${TARGET_NET}$i，${TARGET_PORT}没开"
fi
else
echo "不在线：${TARGET_NET}$i"
fi
done
这个脚本是单一的Shell技术栈，不用其他工具，只要你的机器装了ping和nc命令就行。运行之后，要是你发现应该在线的主机都显示“不在线”，那就是网段错了；要是显示“在线但端口不对”，那就是Agent的端口没开。我上周帮公司的运维同事解决这个问题，就是他把网段写成了192.168.1.0，实际用的是192.168.3.0，脚本扫了之后一眼就看出来了，改了规则之后，第二天就自动发现了22台新服务器。
2.2 再查“发现动作”有没有启用
很多人只做了发现规则，但是忘了配发现动作，这就导致即使扫到了主机，也不会自动添加到Zabbix里。发现动作就是发现主机之后要做的事，比如自动添加主机到某个主机组，绑定对应的监控模板，发送通知之类的。要是这个动作没启用，那发现就等于白做。你可以用下面的Shell命令，查Zabbix的MySQL数据库，看所有启用的发现动作有没有配置对：
#!/bin/bash
# 功能：检查Zabbix Server中已启用的发现动作，排查发现后未执行操作的问题
# 这里的zabbix是Zabbix的数据库用户名，zabbix123是密码，要改成你自己的
mysql -uzabbix -pzabbix123 zabbix -e "SELECT name, status FROM actions WHERE event_source=3 AND status=0;"
解释一下，Zabbix的发现事件源ID是3，status=0是启用状态，status=1是禁用状态。要是你运行这个命令之后，发现没有任何输出，那就是没有启用的发现动作，你需要到Zabbix的Web界面里，找到对应的发现规则，编辑它，在“操作”标签页里，勾选对应的动作，保存之后启用就行。
2.3 检查Zabbix Server和Agent的通信链路
就算规则和动作都对，要是Zabbix Server和被发现的服务器之间不通，也会发现失效。最常见的就是Agent的配置错了，或者防火墙挡了端口。Agent的配置文件里有个Server参数，必须填Zabbix Server的实际IP，不能填127.0.0.1，不然Agent只接受本地的连接，Zabbix Server扫的时候就会被拒绝。你可以用这个命令看Agent的配置对不对：
# 查看Zabbix Agent的核心配置，重点看Server和ServerActive参数
cat /etc/zabbix/zabbix_agentd.conf | grep -E '^Server=|^ServerActive='
正常的输出应该是类似： Server=192.168.1.100 ServerActive=192.168.1.100 要是这里填了127.0.0.1，改成Zabbix Server的IP之后，还要重启Agent服务，让配置生效。还有，被发现的服务器的防火墙要开放10050端口，不然Zabbix Server扫不到，CentOS7的话，可以用这个命令开端口：
# 临时开放Zabbix Agent端口，重启防火墙后失效
firewall-cmd --add-port=10050/tcp
# 永久开放，需要重新加载防火墙
firewall-cmd --add-port=10050/tcp --permanent
firewall-cmd --reload
2.4 最后看Zabbix Server的日志找线索
要是上面的都查了还是没找到问题，那就要看Zabbix Server的日志了，日志里会写发现过程中的错误，比如“无法连接到主机”“规则参数错误”之类的。日志路径一般是/var/log/zabbix/zabbix_server.log，用这个命令看最近的发现相关日志：
# 查看Zabbix Server最新的100条日志，过滤发现相关的内容
tail -n 100 /var/log/zabbix/zabbix_server.log | grep -i "discover"
比如日志里有“[warning] cannot connect to host 192.168.3.10:10050”，那就是端口没开；要是有“[error] invalid discover rule network range”，那就是网段格式错了，比如写成了192.168.3.0/32，而不是/24。
三、常见失效场景的具体解决办法
刚才的排查步骤对应了几个最常见的场景，我再把它们整理得更清楚一点，方便大家碰到的时候直接用。
3.1 场景1：发现规则的网段填写错误
这个是我碰到最多的情况，很多人复制粘贴的时候写错了数字，比如把3写成了1，或者把子网掩码写错。解决办法就是用我写的那个Shell脚本扫一遍，要是脚本扫不到你应该发现的主机，就去Zabbix的Web界面里改发现规则的网段，和实际的IP段完全一致。
3.2 场景2：Zabbix Agent的端口被防火墙阻止
这个也很常见，服务器装了防火墙，默认会拒绝外部连接，Agent的10050端口没开，Zabbix Server扫不到。解决办法就是在Agent的服务器上开放10050端口，刚才的firewall-cmd命令就行，要是是阿里云、腾讯云的服务器，还要在云服务商的安全组里开放10050端口，这个很多新手容易忘。
3.3 场景3：发现动作未启用
就是发现规则的操作没开，扫到主机也不会加。解决办法是用那个MySQL命令查，要是没有启用的动作，就去Web界面里，找到对应规则的操作，勾选“启用”，保存就行。
3.4 场景4：Agent的Server参数配置错误
很多人装Agent的时候，直接用了默认的配置，Server填了127.0.0.1，导致只有本地能连接，Zabbix Server扫不到。解决办法是修改Agent的配置文件，把Server改成Zabbix Server的实际IP，然后重启Agent服务。
四、Zabbix自动发现的优缺点
讲完排查，再说说这个功能的好坏，让大家心里有数，以后用好它的长处，避开短处。
优点很明显，就是批量处理，省人力，比如要加几十台服务器，手动加要半小时，自动发现只要10分钟，还不会出错，适合大规模运维，尤其是服务器数量多的公司。另外，它支持多种发现方式，比如用ICMP ping扫、SNMP扫网络设备、Agent扫服务器，适配不同的设备，很灵活。
缺点也有，就是配置复杂，要是规则写得太宽泛，会扫到不该扫的设备，比如打印机、网络摄像头，把这些加到监控里反而会增加工作量；要是规则写得太严格，会漏扫正常的设备，比如某个主机的端口改了，规则里没改，就扫不到。还有，排查失效的时候要查好几个环节，对新手不友好，容易找不到问题点。
五、注意事项
最后说几个要注意的地方，避免以后再出同类问题：
- 发现规则的网段要和实际完全一致，包括子网掩码，比如要扫192.168.3.0/24，就不能写成192.168.3.0/25；
- 被发现的设备的防火墙和云安全组要开放对应的端口，不仅要开Agent的10050，要是用SNMP的话，还要开161端口；
- 发现动作要和对应的主机组、监控模板绑定，不然即使发现了主机，也不会配置监控，等于白发现；
- Zabbix Server和Agent的时间要同步，不然会因为时间差导致探测失败，比如Agent的时间比Server慢了1小时，Zabbix会认为连接是过期的，拒绝连接；
- 定期查看Zabbix Server的日志，每周看一次发现相关的日志，及时发现异常，不用等失效了才查。
六、总结
Zabbix自动发现失效不是什么严重的问题，只要按“先查规则，再查动作，再查通信，最后查日志”的步骤一步步来，90%以上的问题都能解决。新手碰到的时候别慌，先开个终端跑一下我给的Shell脚本，把问题缩小到具体的环节，再对应修改配置，很快就能恢复功能。用好自动发现这个工具，能帮运维省很多时间，把精力放在更重要的事情上。
Comments