通知

導入 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$マクロはそれを正確に確認する行を含みます。以下のテーブルに、マクロに設定可能な値とそれらの説明をリストします:

値	説明
PROBLEM	サービス又はホストに問題が発生しました(又は依然として問題が発生し続けています)。サービス通知の場合は、該当のサービスがWARNING・UNKNOWNまたはCRITICALのいずれかに当たることを示します。ホスト通知の場合は、該当のホストがDOWNまたはUNREACHABLEステータスであることを示します。
RECOVERY	サービス又はホストは、復旧しました。サービス通知の場合は、該当サービスがOKになったことを示し、ホスト通知の場合は該当ホストがUP状態に戻ったことを示します。
ACKNOWLEDGEMENT	この通知は、ホスト又はサービスの問題を承認するものです。webインタフェースから特定のホスト又はサービスへアクセスすることで開始されます。
FLAPPINGSTART	ホスト又はサービスは、フラッピングを開始しました。
FLAPPINGSTOP	ホスト又はサービスは、フラッピングを停止しました。
FLAPPINGDISABLED	ホスト又はサービスは、フラッピングが使用不可能になったためフラッピングを停止しました。
DOWNTIMESTART	ホスト又はサービスは、予定されたダウンタイムへ入りました。今後の通知は抑止されます。
DOWNTIMESTOP	ホスト又はサービスは、予定されたダウンタイムを抜けました。今後は通知が再開されます。
DOWNTIMECANCELLED	ホスト又はサービスの予定されたダウンタイムは、キャンセルされました。今後も通知は行われます。

使用できるリソース Helpful Resources

Nagiosが通知を出すようにするには多くの方法があり、あなたはそのうちのどの方法を使用するか決定できます。通知方法を決定したら、必要なソフトウェアをインストールし、設定ファイルに通知コマンドを設定しなければなりません。2、3の考えられる方法は以下の通りです：

• Eメール
• ポケベル
• 電話(SMS)
• ポップアップウィンドウ
• Yahoo・ICQやMSNのインスタントメッセージ
• アラーム音
• など...

基本的に、コマンドラインから実行できるものは、通知コマンドに合わせて変更できます。

もし、ポケベルか携帯電話に通知を送るためにEメールに代わるものを探しているなら、以下のパッケージをチェックしてください。問題が発生した時に Nagiosと連動してメッセージを送ることが簡単です。あなたは通知を出すのにEメールに頼る必要はありません(しかしネットワークに問題があればうまく働かない可能性はあります)。私自身はこのパッケージを実際に試したわけではありませんが、他の人がこれらを利用してうまくいっていると報告をくれました...

• Gnokii (GSMネットワークを利用しノキアの電話へ連絡を入れるためのSMSソフト)
• QuickPage (英数字ポケベルソフト)
• Sendpage (ページングソフト)
• SMS Client (ポケベルと携帯電話へメッセージを送るためのコマンドラインユーティリティ)

通知に伝統的"でない"方法を利用したい場合は、アラーム音について色々設定したくなるかも知れません。アラーム音を監視サーバから発したい場合は、Festivalをチェックしてください。もし監視サーバ以外からアラーム音を発生させたい場合は、Network Audio System (NAS)とrplayプロジェクトをチェックしてください。