- 神拳 2.0.3
- NRPE 2.15
私たちは使用しています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
}
10 分ですがfreshness_threshold
、パッシブ チェックが古くなる場合があります。
10 月 6 日 09:52:36 x shinken: [2015 年 10 月 6 日火曜日 09:52:35] 警告: ホスト 'x' 上のサービス 'syncthing_procs-2' の結果は、0d 0h 10m 16s (しきい値 = 16714d 9h 42m 35s) までに古くなっています。サービスの即時チェックを強制しています。
ああ、threshold=16714d 9h 42m 35s
設定ファイルで 10 分に設定しているのに、これはどこから来ているのでしょうか? 確かに、Shinken VM とホスト '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 プロセスがこれほど多く存在するのでしょうか? アクティブ チェックを実行すると、新しいプロセスがフォークされることはわかっています。しかし、チェックが完了すると消えるはずですよね?
ああ、最初の質問の答えはわかっています。
ああ、設定ファイルでは 10 分に設定しているのに、threshold=16714d 9h 42m 35s はどこから来たのでしょうか?
Shinken と Nagios の間には若干の違いがあるようです。これは日/時間/分/秒単位のエポック時間です。
expr $(date +%s) / 3600 / 24
16714
答え1
あなたのケースでは何が悪かったのか正確にはわかりません。そこで、次のような考えがあります。
パッシブチェックを実行するために nsca を使用しています。その後に nrpe プロセスが多数あるのはなぜですか? アクティブチェックを実行するときに新しいプロセスがフォークされることはわかっています。しかし、チェックが完了したら消えるはずですよね?
nsca が正しく動作していないようです。アクティブ チェックが実行されました。nsca が動作することを確認してください。
freshness_thresholdは10分ですが、パッシブチェックが古い場合があります。
または、nsca が shinken にパッシブ結果を送信するように設定されていません
アクティブチェックを実行すると新しいプロセスがフォークされることはわかっています。しかし、チェックが完了したら消えるはずですよね?
おそらくチェックは行われず、接続は反対側(shinken)によって保持されます