NSCA パッシブ古くなった --> 複数のハングした nrpe プロセス?

NSCA パッシブ古くなった --> 複数のハングした nrpe プロセス?
  • 神拳 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)によって保持されます

関連情報