我们使用nsca来执行被动检查。
define service { name salt-service register 0 active_checks_enabled 0 passive_checks_enabled 1 check_freshness 1 freshness_threshold 600 max_check_attempts 2 check_interval 5 retry_interval 3 } define service { use salt-service service_description syncthing_procs-2 host_name x check_command check_nrpe!syncthing_procs!10 display_name Syncthing Procs } 虽然freshness_threshold是10分钟，但是被动检查是陈旧的情况：
Oct 6 09:52:36 x shinken：[Tue Oct 6 09:52:35 2015]警告：主机'x'上服务'syncthing_procs-2'的结果是陈旧的0d 0h 10m 16s（threshold = 16714d 9h 42m 35秒）。 我强迫立即检查服务。
噢，在configuration文件中设置为10分钟， threshold=16714d 9h 42m 35s来自哪里？ 当然，Shinken虚拟机和主机“x”上的系统时间是一样的。
有很多服务是这样陈旧。 正如你所看到的，在被动检查失效之后，我们使用check_nrpe来执行一个主动检查。 而现在的问题是我们有这么多的nrpe进程似乎悬而未决：
nagios 31404 1 0 Sep18 ? 00:00:00 /usr/sbin/nrpe -c /etc/nagios/nrpe.cfg -d nagios 31727 1 0 Oct01 ? 00:00:00 /usr/sbin/nrpe -c /etc/nagios/nrpe.cfg -d nagios 31732 1 0 Oct01 ? 00:00:00 /usr/sbin/nrpe -c /etc/nagios/nrpe.cfg -d nagios 32148 1 0 Sep30 ? 00:00:00 /usr/sbin/nrpe -c /etc/nagios/nrpe.cfg -d nagios 32157 1 0 Sep30 ? 00:00:00 /usr/sbin/nrpe -c /etc/nagios/nrpe.cfg -d
我只是贴几个。 实际上，有200多个进程。
所以，除了错误的门槛之外，我还有另外一个问题：为什么之后有那么多的nrpe进程呢？ 我知道当执行一个主动检查时，一个新的进程将被分叉。 但检查完成后应该消失，对吗？
啊，我知道第一个问题的答案。
噢，在configuration文件中设置为10分钟，阈值= 16714d 9h 42m 35s来自哪里？
看起来像Shinken和Nagios稍有不同。 这是大纪元时间（天/小时/分钟/秒）。
expr $(date +%s) / 3600 / 24 16714
你不可能知道你的情况到底出了什么问题。 所以这里有一些想法：
我们使用nsca来执行被动检查。 为什么之后有那么多的nrpe进程呢？ 我知道当执行一个主动检查时，一个新的进程将被分叉。 但检查完成后应该消失，对
这似乎nsca不能正常工作，然后进行主动检查。 确保nsca正常工作。
虽然freshness_threshold是10分钟，但是被动检查是陈旧的
或nsca没有configuration发送被动结果shinken
我知道当执行一个主动检查时，一个新的进程将被分叉。 但检查完成后应该消失，对
也许这些支票没有做，连接被对方保留（shinken）