DNS 反向解析超时导致 Zabbix trapper busy 升高

环境： Zabbix 5.0.26，Linux
最终结果： 将 DNS 从 114.114.114.114 恢复为原配置 61.139.2.69 后，trapper busy 降至 5% 以下。

一、故障现象

• busy trapper processes, in % 从长期低于 5% 突然升至约 90%，出现大量监控告警，但对应业务程序运行正常。
• Zabbix 网页提示：Zabbix server is not running, the information displayed may not be current。
• 其他进程 busy 较低，缓存剩余空间充足，当天未新增监控项。
• 重启 Zabbix server、MySQL 后，问题未解决。
• 将 StartTrappers 从 5 增加至 20 后，busy 有所下降，但后续仍在约 40%，未恢复至历史水平。

二、处理与排查经过

1. 发现正向解析异常，临时更换 DNS

告警发生时，测试发现百度、微信的部分域名无法正常解析。因此，将服务器 DNS 从原来的 61.139.2.69 修改为 114.114.114.114，已知域名的正向解析恢复正常。

当时只验证了“域名 → IP”，未验证“IP → 主机名”的反向解析。 后续发现，部分 IP 通过新 DNS 反向解析时存在超时。

2. 重启服务及增加 trapper，未消除故障

重启 Zabbix server 和 MySQL 是为尝试恢复监控而执行的排障操作。其中，MySQL 重启前后均检查过，未发现数据库异常告警，不能将此次人工重启作为故障起因。

增加 trapper 数量能够缓解繁忙度，但未消除请求中的等待。

3. 从进程等待定位到 DNS

检查发现，多数 trapper CPU 使用率很低，处于等待状态，部分请求处理耗时约 10 秒。

使用 strace 跟踪 trapper，发现其向 114.114.114.114:53 发起 DNS 查询，随后等待约 5 秒超时，并再次等待。DNS 抓包进一步发现：大量查询为 PTR 反向查询，部分查询约 5 秒后重发，未见及时响应。

4. 用异常地址与正常地址对照验证

被反查 IP	指定 114.114.114.114 的查询结果	系统解析结果
192.168.15.147	2 秒内未响应，超时	getent hosts 耗时约 10.030 秒
133.x.x.67	2 秒内未响应，超时	getent hosts 耗时约 10.025 秒
133.x.x.226	24 毫秒返回 PTR	正常对照

这些结果与 trapper 的约 10 秒请求耗时相吻合，表明问题是部分 IP 的反向解析超时，而非 DNS 整体不可达。

5. 恢复原 DNS，验证恢复

将 DNS 恢复为 61.139.2.69 后，trapper busy 降至 5% 以下，确认反向解析超时是此前 trapper 持续繁忙的原因。

三、原因与影响

本次已验证的故障链路为：

部分域名正向解析异常
→ 临时更换 DNS，正向解析恢复
→ 部分 IP 的反向解析出现超时
→ trapper 处理请求时长时间等待 DNS
→ 可及时处理请求的进程减少，busy 持续偏高
→ 恢复原 DNS 后，busy 降至 5% 以下

trapper busy 高不等于 CPU 使用率高。 请求处理期间等待 DNS，也会占用 trapper，因此可以出现 CPU 较低、缓存充足，但 trapper 繁忙的现象。

需保留的判断边界：上述证据确认了更换 DNS 后持续存在的反向解析阻塞；尚不能据此将更换 DNS 前最初出现的全部告警，也归为同一原因。但根据总体的现象判断大概率原有电信DNS本身也存在反向解析异常的情况，导致产生大量告警。

四、可复用的诊断方法

在故障服务器上，分别测试指定 DNS 与系统实际解析路径，并选择异常地址和正常地址对照：

# 查看 DNS 和系统解析顺序
cat /etc/resolv.conf
grep '^hosts:' /etc/nsswitch.conf

# 对比不同 DNS 对同一 IP 的反向解析
dig @114.114.114.114 -x 192.168.15.147 +time=2 +tries=1
dig @61.139.2.69 -x 192.168.15.147 +time=2 +tries=1

# 检查系统实际解析耗时
time getent hosts 192.168.15.147

# 短时抓包，观察查询、响应及重试
timeout 30s tcpdump -ni any -nn -tttt -vv -s 0 'port 53'

必要时短时跟踪一个异常 trapper，确认耗时是否发生在 DNS 等待中，避免仅凭进程繁忙度判断瓶颈。

五、运维经验

• 更换 DNS 必须双向验证： 不仅检查业务域名能否正向解析，还要检查监控相关 IP 的反向解析结果与耗时。
• “能解析部分域名”不等于 DNS 满足全部业务需求： 本次更换 DNS 解决了已知正向解析问题，却引入了部分反向查询超时。
• 扩容不是根因修复： 增加 StartTrappers 只能缓解并发占用，不能消除 DNS 等待。
• 按时间线判断因果： 区分故障发生、DNS 修改、服务重启等事件，不能将后续人工排障操作误判为起因。
• 恢复应形成闭环： 同时验证解析耗时、trapper busy、监控数据时效和相关告警。此次已确认 busy 恢复至 5% 以下，最初的百度、微信部分域名解析均已恢复。