通知

導入 Introduction

通知が正確に働く方法に関して、多くの質問がありました。ここでは、ホストとサービス通知がいつ、どのように出されるかと、それが受け取られる方法について、できる限り正確に説明します。

通知のエスカレーションについてはこちらです。

通知はいつ発生する？ When Do Notifications Occur?

通知を出すという決定は、サービスチェックとホストチェックロジックでなされます。ホストとサービス通知は、以下のような場合に発生します...

• ステータスがハード状態になった時。ステータスのタイプと状態についてのより詳しい情報はこちらです。
• ホストまたはサービスが、最後に通知が出されてから指定された<通知間隔>が経過してもOK以外のステータスだった時(指定されたホストまたはサービスのみ)。

誰に通知される？ Who Gets Notified?

各々のホストとサービス定義には、どの通知先グループがそのホストまたはサービスについての通知を受け取るかを指定する<contact_groups>オプションがあります。通知先グループは、1つ以上の個々のコンタクトを含むことができます。

Nagiosがホストまたはサービス通知を出す場合は、ホストまたはサービス定義の<contactgroups>オプションで指定されている全ての通知先グループの個々を宛先とします。Nagiosは、コンタクトは複数の通知先グループに属しているかもしれないと考え、通知の前に重複するコンタクト情報を除外します。

通知を送るために通らなければならないフィルタとは？ What Filters Must Be Passed In Order For Notifications To Be Sent?

ホストまたはサービス通知を出す必要があるからといって、全ての通知が出されるわけではありません。通知を決定する前に、'潜在的'通知が通過するべきいくつかのフィルタが存在します。フィルタで通知が許可されなければ、ある種の通知はされないかもしれません。ではフィルタの詳細へ進みます…

プログラム全体のフィルタ: Program-Wide Filter:

通知がまず通過しなければならないフィルタは、プログラム全体で通知が有効かどうかです。これはメイン設定ファイルのenable_notificationsディレクティブで指定されますが、実行中にWebインタフェイスから変更されるかもしれません。通知がプログラム全体で無効になっている場合は、ホストまたはサービス通知を出すことはできません。プログラム全体で通知が有効になっていれば、更に合格すべきテストがあります…

サービスとホストのフィルタ: Service and Host Filters:

ホスト又はサービス通知の最初のチェックは、予定されたダウンタイム期間かどうかです。もし予定されたダウンタイムの期間内なら、通知は行われません。ダウンタイム期間外なら、次のフィルタへ渡され更なるチェックを受けます。傍注:ダウンタイム期間中のホストに関連するサービス通知は抑制されます。

第2のフィルタは、ホスト又はサービスがフラッピング状態かどうか (フラップ検知を有効にしている場合)です。もしサービス又はホストがフラッピング状態なら、通知は行われません。そうでなければ、更に次のフィルタへ渡されます。

第3のフィルタは、ホスト又はサービス固有のオプションです。各々のサービス定義は、ワーニング状態、クリティカル状態とリカバリ状態に通知を出すかどうか決定できるオプションを持っています。同じように、各々のホスト定義は、ホストがダウンした時、到達不可能になった時、回復した時に、通知を出すかどうか決定できるオプションを持っています。ホスト又はサービス通知がこれらのオプションに当てはまれば、通知は行われません。もし当てはまらなければ、通知は次のフィルタに渡されます... 注: 固有の問題が原因で発生した通知は、ホスト又はサービスの回復時のみ送られます。検知していない問題に対する回復通知は意味をなしません。

4つめのフィルタは通知の発生した時間帯です。各ホスト又はサービス定義には、通知を受け取る時間帯を指定する<notification_period> オプションがあります。通知の発生が指定時間外なら、通知は行われません。指定時間内なら、通知は次のフィルタに渡されます... 注:このフィルタをパスしなかった(つまり通知が行われなかった)場合、Nagiosは次の指定時間帯にホスト又はサービス通知をスケジュールします(もしOK以外のステータスだった場合)。これにより、次の指定時間帯には指定された通知先へ速やかに障害通知が送られます。

最後のフィルタは次の2つからなります: (1)ホスト又はサービスについて、過去に何度か同じ問題で通知を出している。(2)このホスト又はサービスのステータスは、前回の通知時から変化していない。この2つの基準を満たした時、Nagiosは前回の通知から経過した時間がホスト又はサービス定義の<notification_interval>オプションの値を上回っているかチェックします。もし前回の通知からの経過時間が短かった場合には、通知は行われません。前回の通知から十分な時間が経つか、このフィルタの2つの基準を満たした場合に、通知が行われます。しかしこれが実際に通知先へ送られるかどうかは、もう1セットのフィルタ次第です...

通知フィルタ:Notification Methods

ここにきて、通知はプログラムモードフィルタと全てのホスト又はサービスに渡され、Nagiosは通知されるべき人々に通知を始めます。各々の通知先は通知を受け取ることになるでしょうか？残念！各通知先にも、受け取られる前に通知が通るべき独自のフィルタセットがあります。注:通知フィルタは、各々の通知先に特有なので、他の通知先には影響を与えません。

通知先毎で通過すべき最初のフィルタは、通知オプションです。各々の通知先定義は、ワーニング状態、クリティカル状態とリカバリ状態にサービス通知を出すかどうか決定できるオプションを持っています。また、ホストがダウンした時、到達不可能になった時、回復した時に、ホスト通知を出すかどうか決定できるオプションも持っています。ホスト又はサービス通知がこれらのオプションに当てはまれば、通知は行われません。もし当てはまらなければ、通知は次のフィルタに渡されます... 注: 固有の問題が原因で発生した通知は、ホスト又はサービスの回復時のみ送られます。検知していない問題に対する回復通知は意味をなしません。

通知先毎で通過すべきの最後のフィルタは、通知時間帯です。各通知先定義には通知を受け取る時間帯を指定する<notification_period> オプションがあります。通知の発生が指定時間外なら、通知は行われません。指定時間内なら、通知が行われます！

通知方法 Notification Methods

きちんと指定すれば、問題と回復については大抵の方法で通知できます:ポケベル、携帯電話、Eメール、インスタントメッセージ、警告音、電気的振動など。通知方法は、オブジェクト定義ファイルの通知コマンドに依存します。

:もしクイックスタートガイドに従ってNagiosをインストールしているなら、通知はEメールで送られるようにするべきです。以下のファイルでEメール通知コマンドを見ることができます: /usr/local/nagios/etc/objects/commands.cfg.

特定の通知方法(ページングなど)は、Nagiosに直接取り込まれません。Nagiosの"コア"は、オールインワンアプリケーションではないからです。サービスチェックがNagiosのコアに埋め込まれているなら、ユーザが新しいチェック方法を追加したり既存のチェック方法を修正することは非常に難しくなるでしょう。通知も似たようなものです。既に1000以上の通知方法があり、その多くはパッケージ化されているのに、わざわざ最初から作成しなおす必要があるでしょうか？それは外部実体(即ち単純なスクリプトまたは完全なメッセージシステム)をはるかに乱雑にしてしまうでしょう。ポケベルと携帯電話のための通知を扱えるパッケージは、リソースセクション以下にリストされます。

通知タイプマクロ Notification Type Macro

通知コマンドを作成する場合には、発生している通知のタイプを考慮する必要があります。$NOTIFICATIONTYPE$マクロはそれを正確に確認する行を含みます。以下のテーブルに、マクロに設定可能な値とそれらの説明をリストします: