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