我目前正在运行一个 Nagios 实例。有时，我会收到有关超时的错误警报 - 例如，它说某个服务器上的 HTTP 已关闭，但几秒钟后当我在浏览器中打开它时，它加载速度很快，并且通常没有任何错误迹象。
我该怎么做才能减少这种误报？
我猜是因为我的监控服务器出现了暂时的网络问题。我猜在另一个网络上设置另一个监控服务器会有很大帮助，但我该如何将其插入 Nagios 呢？
使用 Nagios 是否可行，还是我必须切换到另一个监控系统？我喜欢我的配置，如果可能的话，我想继续使用 Nagios 或兼容的版本（Icinga？）
答案1
提高警报阈值。例如，不要在 1 次故障后发出警报。在 3 次故障后发出警报，并在重新检查之间设置合理的间隔（1 分钟、2 分钟）。这意味着，如果服务器停机 4-5 分钟，您将收到通知，而不是在您的监控服务器上出现“瞬时网络问题”时收到通知。
答案2
提高警报阈值。事实上，您可能更愿意通过脚本进行此类监控，该脚本记录事务时间、向 Nagios 发送通知，并定期分析其最近周转时间的日志，以便仅在出现不良趋势时才发送警报。
这样您就可以将阈值设置得更高，这样它就不会对每个耗时过长的交易发出警报，但如果移动平均交易时间过长，它仍会向您发出警报。您对真正重大问题的响应会慢一点，但您不会被如此多的误报搞得精疲力竭。
无论如何，如果真正的重大问题是由您造成的（而非天灾或数据中心运营商造成的），最好通过自动重启和重新启动来处理，因为如果这些问题很容易修复，那么这是修复这些问题的最快方法。如果这些问题不容易修复，那么由较高阈值导致的几分钟延迟对您从问题中恢复的方式不会产生任何实际影响。
不要害怕尝试阈值。当您有空响应警报时，尝试降低阈值并查看结果。当您外出约会时，提高阈值，事后进行回顾，看看是否遗漏了重要信息。
答案3
首先你必须追踪http请求超时的原因。
如果您拥有超过 50 台服务器，并且每台服务器的监控值超过 5 个，那么 Nagios 本身很可能就是罪魁祸首。
它对每个监控事件生成一个请求，并产生大量的网络中断。
您可以更改 http-check-method 中的超时和重试值，而不是提高警报阈值。