4

我有一个 Nagios 配置，它正在数百个节点上执行许多测试；其中之一是check_http. 它没有配置为 --enable-embedded-perl (ePN)，但我们很快就会改变它。即使启用了 ePN，我也担心每次执行 Perl HTTP+SSL 检查都将只处理一个目标的模型。

我想编写一个简单的select()（或poll() / epoll()）驱动的守护进程，它同时创建到多个目标的连接，读取结果并以 Nagios 可用的形式吐出结果，就好像它是结果一样从被动检查。

是否有关于如何实现这一目标的指南？向 Nagios 提供批量检查更新的接口或 API 是什么？

我正在考虑的一个技巧是让我的守护进程更新一个 Redis 存储（每个目标都有一个密钥，并且过期时间很短）并用check_http密钥上的本地 Redis 实例的一个非常小的、轻量级的 GET 替换（GET将获得 Nagios 的实际结果或“（nil）”响应，该响应将被视为 HTTP 连接已超时。

但是，我也对我的想法持怀疑态度，因为我认为现在有人已经有了这样的东西。

（顺便说一句：我已经准备好被说服切换到Icinga、Zabbix、Zenoss或OpenNMS之类的东西......几乎任何可以更好地扩展的东西）。

4

1 回答 1

2

至于是否让 Nagios 处理调度和检查，我将把它留给你，因为它取决于你的 Nagios 版本（较新的版本可以同时运行这些检查），以及为什么你需要一个单独的守护进程。关于 Nagios 的版本控制，版本 3 IIRC 使用并发检查，因此可以扩展到比您报告的更大的节点数。

但是，我可以回答 Redis 路由概念，因为我已经使用 Postfix 队列统计和网站的 TTFB 跟踪完成了它。

使用带有 curl 和 multiprocessing 模块的 Python 设置检查非常简单，就像将其转储到 Redis 中一样。我想说的过期时间不超过间隔将是阻止数据库增长的一个好主意。我建议 tis 值不要超过（或可能只是小于）检查间隔，以避免获取过时的检查结果。如果当前正在运行的检查尚未完成并且 Redis-to-Nagios 检查运行，则拉入上一个检查，您可能会错过失败的检查。

对于 Redis-To-Nagios 检查一个简单的 redis-cli+bash 脚本或 Python 检查来提取给定主机的数据，返回 OK 或其他取决于您的数据是相当简单的并且运行速度足够快。

我建议在 Nagios 检查服务器上运行 Redis 实例，以确保最小延迟并避免网络问题导致检查错误警报。我还建议对您的 Redis 实例和检查守护进程进行 Nagios 检查。使 check_http 替换检查依赖于正在运行的 Redis 和 http_check 守护进程。因此，您有一个依赖链，如下所示：

Redis -> http_checkd -> http_check_replacement

这将通过识别问题来防止对 http_check_replacement 的错误警报。例如，如果您的 redis_checkd 死了，您会收到警报，而不是 200 多个“失败的 http_check_replacement”。

此外，由于您在 Redis 中的数据根据​​定义是瞬态的，因此我将禁用磁盘持久性。当数据不断旋转时，无需写入磁盘。

附带说明一下，如果使用 libcurl，我建议您从 libcurl 中提取有关打开连接需要多长时间以及服务器响应多长时间（第一个字节时间 - TTFB）的统计信息，并利用 Nagios 的能力存储检查统计信息。您很可能会遇到拥有这些数据对于故障排除和性能分析非常方便的时候。

我有一个用 C 语言编写的 CLI 工具，它执行此操作并将其上传到本地 Redis 实例中。它很快——几乎比获取 URL 的时间还多。我期待它本周开源，我可以很容易地向它添加 Nagios 风格的输出。事实上，我想我会在接下来的一两周内做到这一点。

于 2013-06-09T18:36:34.807 回答