時間帯


別名...
"もういいかい?"


序文

時間帯はいつサービスチェックを稼働させるか、いつホストとサービスの通知を送るか、そしていつ通知を通知先が受け取るだろうということを柔軟に制御することを可能にします。この新しい機能を追加したことで後述しますがいくつかの潜在的な問題を発生させることになってしまいました。そのため私はこの時間帯機能を導入することを最初非常にためらいました。 あなたの状況で何が正しいかと言う判断はあなたに任せましょう・・・

サービスチェックでの時間帯の働き方

時間帯機能がインプリメントされていなければ、Nagiosは全サービスを24時間365日監視するでしょう。これは監視が必要なほとんどのサービスで問題のない設定ですが、あまり適していないものもあります。たとえば、通常のビジネスアワーでしか使用しないプリンタを24x365で監視する必要があるでしょうか?また、開発用のサーバで稼働している状態が望ましいが、"ミッションクリティカル"ではない場合は週末の監視は必要ないでしょう。時間帯を定義することではそのようなサービスに対していつチェックを行うのかを柔軟に制御可能になります。

個々のサービス定義の<check_period>引数にて、Nagiosにいつサービスチェックを行わせるか定義できます。Nagiosがサービスチェックを再スケジュールすると、Nagiosは次回のチェックが時間帯定義に含まれている時間内であるかどうか確認します。そうでなければ、Nagiosは次回のサービスチェック時間を時間帯設定で定義した"正しい"時間帯に行うよう調整します。このことはサービスチェックは時間帯で定義されていない時、日、週などではチェックされないと言うことを意味しています。

サービスチェックの潜在的な問題

24時間365日カバーしていない時間帯を使用している場合、特にサービス(やそのホスト)が時間帯の次の正しい時間帯までチェックの遅延が起こった時にダウンしているときに問題がでてくるかもしれません。ここにいくつかその問題について挙げてみます・・・

  1. 次回のサービスチェックが行われるまで通知先にサービスの問題が再通知されません。
  2. チェックの時間帯以外の時間にサービスが復旧した場合、通知先に復旧したことが通知されません。
  3. サービスの状態が次にチェックされるまで変更されません(ステータスログや、CGIなど)。
  4. 特定のホストの全サービスチェックは同じチェック時間帯になっている場合、ホストの問題や復旧はサービスチェックのどれかひとつが実行されるまで認識されません(そして、通知も送られません)。

サービスチェックの期間を1日24時間、1週間7日以外の設定に制限することは多数の問題を引き起こします。まあ、本当の問題というと語弊があり、迷惑というだけですが…。もし特に理由がないのであれば、個々のサービス定義の<check_period>引数は"24x7"タイプの時間帯設定にすることを強くお勧めします。

通知機能での時間帯の働き方

おそらく、通知がいつ通知先に送られるのかということを制御するために時間帯機能は最有効だと思います。通知先定義の中の<service_notification_period>と <host_notification_period>引数を使用することで、それぞれの通知先の"on call"を本格的に定義できます。ホストとサービスの通知用の異なる期間を指定することができることに注意してください。これはもし、ホスト通知が週の任意の日に送られるようにしたいが、サービス通知は平日に送りたいという感じの設定をしたい場合に有用です。この2つの通知時間帯は通知先に通知したいどんな時間でも時間帯もカバーしていることにに注目してください。以下のように特定のサービスやホストの1つ1つの通知時間を制御することができます。

ホスト定義の<notification_period>引数で、 Nagiosがそのホストの問題発生時、または復旧時に通知を行うか制御することができます。 ホスト通知がホスト通知が送られる時、Nagiosは<notification_period> 期間の有効な範囲内に現在の時間があることを確かめるでしょう。 有効な時間である場合、Nagiosはホスト障害の各通知先に通知することを試みます。 もしある通知先の <host_notification_period> にそのホスト通知がその時間に許可されていなければ、 その通知先に対して通知は行われないでしょう。

サービス定義の<notification_period>引数で、Nagiosがそのサービスの問題発生時、または復旧時に通知を行うか制御することができます。サービス通知が送られる時、Nagiosは<notification_period>期間の有効な範囲内に現在の時間があることを確かめるでしょう。有効な時間である場合、Nagiosはサービス障害の各通知先に通知することを試みます。もしある通知先の <host_notification_period>にそのサービス通知がその時間に許可されていなければ、その通知先に対して通知は行われないでしょう。 そのサービスの <notification_period>の有効な時間でなければNagiosは通知をどんな通知先にも送りません

通知機能での潜在的な問題

カスタム通知時間帯を使用することで発生するメジャーな問題はありません。しかし、サービス、ホスト障害もしくは復旧の通知がいつでも送られて通知先に通知されるわけではないという事はよく認識しておく必要があります。ホスト、サービス定義と通知先時間帯の両方が正しい設定になっていなければ、通知は送られません。 あなたのニーズに即した通知の時間制限の潜在的な問題をよく比較検討すれば、あなたの環境にマッチした設定ができるでしょう。

結論

時間帯設定はNagios監視、通知機能をいつ行うか柔軟に制御可能です。しかし、問題を引き起こすこともあります。もし、時間帯設定に関して自信が無い場合か、現在の設定に問題がある場合は、私は"24x7"(24時間365日)の時間帯指定をお勧めします。質問があるか、問題にぶつかっていたら、私に連絡をください。