我刚刚开始使用Nagios监视一组广播发射器。每个发射器都被定义为一个主机,而我希望监视的发射器的每个方面(RF转发、RF反射、电源电压等)都被定义为一个服务。在这样做的时候,如果这些方面中的任何一个超出了容限,我就可以得到一个警报,并且可以使用性能数据来绘制每个方面(在本例中使用pnp4nagios )。
为了检查发射器的遥测数据,我编写了一些脚本,其中一个脚本用于解决所涉及的每个制造商/型号的发射器的独特设施。为了与我看到的其他Nagios检查的工作方式保持一致,脚本的参数允许您选择要报告的方面。
起初,我对此感到满意。它的工作原理就像我遇到的任何Nagios的传统用法一样。但是后来我遇到了一个问题。
因为每个服务检查都是单独计划的,所以诊断警报条件可能很棘手,因为不同的服务不是同时检查的-因此我正在查看的一组值不太可能是时间对齐的。如果所有服务检查值都来自同一时刻,则更容易检测相关性(因为该值集本质上是快照)。
我的第一个想法是通过运行单个命令的单个实例来处理此问题,这将返回多个服务的值。这似乎也比打开与要检查的服务一样多的连接实例效率高得多。从脚本的角度来看,这很容易做到。但是从Nagios配置的角度来看,我不知道如何(或者是否?)你会这么做的。
我知道我还可以将数据收集从Nagios检查中分离出来,定期一次缓存所有遥测值,并从缓存中提供Nagios值。但我不想引入额外的延迟,如果我可以的话。
有什么想法?
发布于 2021-03-08 04:04:24
我的第一个想法是通过运行单个命令的单个实例来处理这个问题,这将返回多个服务的值。这似乎也比打开与要检查的服务一样多的连接实例效率高得多。从脚本的角度来看,这很容易做到。但是从Nagios配置的角度来看,我不知道如何(或者是否?)你会这么做的。
从Nagios的角度来看,这并不奇怪,因为您实际上是在编写自己的插件,插件可以是通用的,也可以是特定的。
当编写你自己的插件时,记住这一点很好:
我正在考虑被动地提交服务数据。它可以解决我提到的所有问题。但它会创建一些次要的新进程-现在有外部进程可以继续运行,而且它有点脱离了主流的工作方式(可能会让未来的管理员经历一些痛苦来弄清楚它是如何工作的)。
我不认为这是一个比编写自己的插件更好的解决方案,除非数据是来自节点主动推送出来的。
例如,在IoT上下文中,您正在监视的节点实际上可能会将被动检查结果直接发送到Nagios实例。在这种情况下,被动检查是有意义的,因为你只想接受别人给你的任何东西,并在没有结果的情况下采取行动(新鲜度)。
在您的情况下,似乎编写自己的脚本会同时处理时间问题和您希望在脚本中添加的任何其他逻辑,就Nagios而言,它应该只按计划运行,并观察退出代码,然后在失败时按照配置执行。
https://stackoverflow.com/questions/66510482
复制相似问题