我刚刚开始使用Nagios监视一组广播发射机。每个发射机都被定义为一个主机，而我希望监控的发射机的每个方面(射频转发、射频反射、电源电压等)都被定义为一个服务。这样，如果这些方面中的任何一个超出容忍范围，我就可以得到警报，并且可以使用性能数据绘制每个方面的图形(在本例中使用pnp4nagios)。
为了检查发射机的遥测数据，我编写了一些脚本，其中一个用于解决所涉及的每个品牌/型号的发射机的独特设施。按照我所看到的其他Nagios检查的工作方式，脚本的参数允许您选择要报告的方面。
起初我对此很满意。它的工作方式与我遇到的任何更传统的Nagios一样。但后来我遇到了一个障碍。
因为每个服务检查都是单独安排的，所以诊断警报条件可能会很棘手，因为不同的服务并不是同时被检查的——因此我正在查看的一组值不太可能是时间一致的。如果所有服务检查值都来自同一时刻，则更容易检测相关性(因为值集本质上是快照)。
我的第一个想法是通过运行单个命令的单个实例来处理这个问题，它将返回多个服务的值。这似乎也比打开尽可能多的连接实例要检查的服务要有效得多。从脚本的角度来看，这很容易做到。但是从Nagios配置的角度来看，我不知道如何(或者是否?)您会这样做。
我知道我还可以将数据收集从Nagios检查中分离出来，定期缓存所有遥测值，并从缓存中提供Nagios值。但是，如果可以的话，我不想增加额外的延误。
想法吗?
我的第一个想法是通过运行单个命令的单个实例来处理这个问题，它将返回多个服务的值。这似乎也比打开尽可能多的连接实例要检查的服务要有效得多。从脚本的角度来看，这很容易做到。但是从Nagios配置的角度来看，我不知道如何(或者是否?)您会这样做。
从Nagios的角度来看，这没什么奇怪的，因为你实际上是在编写自己的插件，插件可以像你想要的那样通用或特定。
在编写自己的插件时，最好记住:
- 你的脚本负责所有的失败，所以确保你处理垃圾响应，失败的连接和任何其他错误，你预测可能发生在插件本身，并退出适当的错误级别。
- 因为你可能会遇到你没有预料到的错误，它可能是有意义的，让插件写什么它正在做一个日志文件，以及它得到的响应。
- 插件必须使用退出码来正确地提醒Nagios。如果需要性能数据，则需要以正确的语法提供。参见开发指南。
我正在考虑被动提交业务数据。它会解决我提到的所有问题。但是它会创建一些小的新进程——现在有外部进程保持运行，并且它有点超出主流的做事方式(可能会让未来的管理员通过一点痛苦来弄清楚它是如何工作的)。
我不认为这是一个比编写自己的插件更好的解决方案，除非数据来自节点主动推送。
例如，在IoT上下文中，您正在监视的节点实际上可能直接向Nagios实例发送被动检查结果。在这种情况下，被动检查是有意义的，因为你只想接受别人给你的任何东西，并在没有结果的情况下采取行动(新鲜度)。
在您的情况下，似乎编写自己的脚本可以同时处理时间问题和脚本中需要的任何其他附加逻辑，并且就Nagios而言，它应该只按照计划运行它并观察退出代码，然后在失败时按照配置执行。