<p>“CRITICAL - Socket timeout”报警不表示服务宕机，而是插件在规定时间内未完成TCP连接或响应接收；常见原因包括网络/防火墙阻断、服务未监听外部地址、默认10秒超时过短、SELinux限制或被监控端资源瓶颈及插件阻塞。</p>
如果您在Nagios监控中看到“CRITICAL - Socket timeout”报警，该错误并不直接表明被监控服务已挂，而是反映Nagios插件在尝试建立TCP连接或接收响应时未能在规定时间内完成通信。以下是多种可能原因及对应排查路径：
一、检查网络连通性与防火墙策略
Socket超时最常见原因是监控端无法抵达被监控端指定端口，可能受中间网络设备、安全组或本地防火墙拦截。需验证基础通信是否通畅。
1、在Nagios服务器上执行telnet命令测试目标IP和端口，例如：telnet 192.168.10.5 5666
2、若连接失败，使用traceroute确认路由可达性：traceroute 192.168.10.5
3、检查被监控主机的iptables或firewalld是否放行NRPE（默认5666）或HTTP（80/443）等对应端口。
二、验证被监控服务进程是否运行并监听正确地址
即使端口开放，若服务未启动、未绑定到预期接口或仅监听127.0.0.1，也会导致外部连接超时。
1、登录被监控主机，运行：ss -tuln | grep :5666（NRPE）或ss -tuln | grep :80（HTTP）
2、确认输出中存在*:5666或*:80而非127.0.0.1:5666；若仅显示本地回环地址，需修改服务配置绑定0.0.0.0。
3、检查NRPE服务状态：systemctl status nrpe 或 ps aux | grep nrpe
三、调整Nagios插件超时参数
默认10秒超时对高延迟链路或资源紧张的被监控主机可能过短，可通过-t参数延长等待时间，避免误报。
1、在Nagios服务定义中修改check_command行，加入-t选项，例如：-t 30
2、对于check_nrpe，更新commands.cfg中的command_line为：$USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ -t 30
3、对check_http，同样添加-t参数：-t 30，确保其不因页面加载慢而触发超时。
四、排查SELinux或AppArmor强制访问控制干扰
某些Linux发行版启用SELinux后，可能阻止nrpe或httpd进程对外建立连接或接受远程连接，导致看似“无响应”。
1、临时禁用SELinux验证影响：setenforce 0
2、若问题消失，需持久化调整策略：semanage port -a -t nrpe_port_t -p tcp 5666
3、检查audit.log中是否有avc denied日志：ausearch -m avc -ts recent | grep nrpe
五、分析被监控端系统资源与插件执行阻塞
Socket timeout也可能源于被监控主机自身负载过高、磁盘I/O卡顿或插件脚本内部hang住（如check_disk因挂载异常而长时间阻塞df命令）。
1、登录被监控主机，运行：top 和 iostat -x 1 3 查看CPU与磁盘使用率。
2、手动执行对应插件命令，例如：/usr/lib64/nagios/plugins/check_disk -w 10% -c 5% -p /，观察是否返回缓慢或无响应。
3、若发现某挂载点df卡死，可改用-p指定具体路径规避问题文件系统，或清理异常挂载。
