「ホストチェック」の版間の差分

2010年9月4日 (土) 21:53時点における最新版

導入 Introduction

ホストチェックの基本的な働きをここでは記述していきます。

いつホストチェックは行われるの？ When Are Host Checks Performed?

ホストは、Nagiosのデーモンによってチェックされます。

• 通常のチェック間隔は、あなた自身のホスト定義に記載できるオプションであるcheckアクションの実行を繰り返す時間間隔 と接続を再試行する時間間隔によって定義されています
• 利用者の需要に応じて、ホストの状態の変化とサービスを結び付けて見張ります。
• 利用者は、ホストへの到達可能性を見張る役割も必要とされています。
• 利用者は、ホストへの依存から予測するチェックを必要としています。

通常のホストチェックのスケジュールは任意で決めることが出来ます。もしあなたが、check_interval(checkアクションの実行を繰り返す時間間隔)を設定でゼロに設定したならば、 Nagiosは基本的なホストチェックすら出来なくなるでしょう。しかしながら、利用者はホストに対する自らの望みに沿ったチェックを、監視ロジックの一部としてと必要とします。

オンデマンド・チェックはホストの状態の変化とサービスを関連付けて考えます。なぜなら、Nagiosはホストの状態が変化しているかどうかを知る為のソフトだからです。状態がよく変化するものには、ホストの状態が変化しているかどうかだけを見る指標を用いたサービスチェックもあります。例えば、もしNagiosがホストのHTTPサービスがCRITICAL(クリティカル状態・重大な異常を示す)からOK(正常状態)へと変化したことを検知したならば、恐らくそのホストがリブートから復旧したことやバックアップシステムが動き出したことを指し示すでしょう。

ホストのオンデマンド・チェックはホストへの到達可能性を調べる方法を利用して作られています。 Nagiosは、ネットワークの供給停止を出来るだけ素早く検知するように設計されています。そして、ホストの状態が、DOWN(ホストダウン)なのかUNREACHABLE(ホストまでpingが届いていない)状態のいずれかを識別します。それら2つはとても異なる状態なので、識別できることによって、ネットワーク管理者がネットワークの供給停止の原因を素早く突き止める手助けとなるのです。

オンデマンド・チェックは、predictive host dependency check(ホストへの依存から予測するチェック)の仕組みを利用して行われています。それらのチェックは、出来るだけ的確で依存性のある仕組みによって確実なものへと裏付けられています。

キャッシュされたホストチェック Cached Host Checks

オンデマンド・ホストチェックの実行はキャッシュされたチェックを手助けに利用すれば、著しく向上させることが出来ます。 Nagiosにホストチェックの実行を無視することを許し、もし関係性のあるチェックの結果の代わりになるものを決めればさらに向上させることも出来まする。キャッシュを利用したチェックについてより知りたければ、ここのページを見てください。

依存性とチェック Dependencies and Checks

host execution dependencies(ホスト毎の実行に関する依存)を定義することが出来ます。それによって、Nagiosが、一つ、あるいは他の複数のホストの状態に依存したホストの状態(ステータス)のチェックするのを妨げることになります。依存性に関してより深く知りたい場合は、ここを見ると良いです。

ホストチェックの並列処理 Parallelization of Host Checks

定期的なホストチェックは並列処理されます。 Nagiosがスケジューリングされたホストチェックを実行する際は、スケジュールされたホストチェックを始め、その後、一旦手を止めていた他の作業(実行中のサービスチェックなど)に戻ります。ホストチェックは、Nagiosのデーモンから分岐した子プロセスとして実施されます。ホストチェックが完了したら、子プロセスはNagiosの親プロセスにチェックの結果を伝えます。 Nagiosの主な処理は、チェック結果に対し適切な処理を下し解決を行うことです。(イベントハンドラの実行や障害の通知など)

オンデマンド・ホストチェックも必要があるのならば、並列処理を行うことも出来ます。先述したように、Nagiosは比較的新しいホストチェックからのキャッシュされた結果として利用されるなら、オンデマンド・ホストチェックの実際の実行をとめることも出来ます。

Nagiosが、スケジュールされたホストチェックや、オンデマンド・ホストチェックを実行する際に、他のホストのチェックも始めるかもしれないです。それらのチェックは、predictive dependency checks(依存性から予測したチェック)や、ホストが使う、network reachability(ネットワークの利用の可能性) の仕組みに対する決定に影響を与えるような、以上の2つの要因によって始められます。 2番目のチェックは、たいていは並列処理で実行されます。しかし、予期せぬ大きな例外事項が起きた際には、それによってパフォーマンスに悪い影響を与えられることもあるのです。

Note ホストの max_check_attempts(サービスチェックがOK以外の状態を返した時に何度Nagiosが再試行するかの回数) 数を 1 に設定したら、パフォーマンスには深刻な影響が出ます。その理由は何だって？もしNagiosが network reachability(ネットワークの到達可能性)の仕組み(DOWNやUNREACHABLE等の状態が見える状態)を利用して真の値を決定する必要があるのならば、親プロセスに近いすべてのホストの serial(連続番号) を調べる必要があるのです。だからこそ、常に max_check_attempts(サービスチェックがOK以外の状態を返した時に何度Nagiosが再試行するかの回数) を1より大きな値にすれば、並列処理の時よりも高いパフォーマンスを得ることが出来るのです。

ホストの状態 Host States

チェックされるホストは3つの異なった状態の一つに分類される：

• 正常
• ホストダウン
• ホストまで未到達

ホストの状態の決定 Host State Determination

ホストチェックは、 plugins(プラグイン)によって実行されます。プラグインは、OK、WARNING、UNKNOWN、またはCRITICALの状態を返すことが可能です。では、どのようにしてNagiosは、プラグインの返す値をUPやDOWNやUNREACHABLEといったホストの状態へと変換するのでしょうか。それはですね・・・

下記の表は、プラグインが返す値と一つ前のホストの状態がどのようなものなのかを示す表です。いくつかの後処理(後に述べる)がなされると、ホストの最終的な状態が変化するものもあります。

WARNING は大抵はホストがUP状態であることを意味します。しかし、use_aggressive_host_checking(アグレッシブホストチェック→このオプションを無効にするとNagiosは、チェックをより早く行おうとする。有効にした場合、ホストチェックに多く時間を使うが、確実性は少し上昇する。Nagiosホストの復旧をあまり検知しない問題がある場合を除いて、このオプションは無効にすることをお勧めします。) のオプションを有効にしているのならば、 WARNING という結果が ホストの DOWN を意味することもあります。

もし一つ前のホストの状態が DOWN ならば、Nagiosは本当にホストが DOWN しているのかや UNREACHABLE なのかを確認しようと試みます。ホストの、DOWN と UNREACHABLE の間の状態の区別は、管理者がネットワークの供給停止の原因の根本を素早く確定するための手助けになるので重要です。下記の表は、Nagiosの親ホストの最終状態の決定がどのようにして決められるのかを示しています。

ホストの状態変化 Host State Changes

恐らくお分かりでしょうが、ホストはずっと同じ状態では留まってはいません。物理的な故障、パッチの適用、必要不可欠なサーバのリブートなどがあるのです。 Nagiosはホストの状態をチェックする時、 UP と DOWN と UNREACHABLE の状態の間のホストの変化を検出し、適切な処理をすることができるのです。これらの状態変化の結果は、異なった state types(状態の種類)（HARDやSOFT）があり、これを引き金として、 event handlers(イベントハンドラ) の実行、 notifications(通知) を行います。状態の変化を検出し、対応することは、Nagiosの行っていることの全てです。

ホストがあまりに頻繁に状態を変化させることを、"flapping(バタバタしている状態、バタツキ)"であると考えられます。 flapping しているホストの良い例の一つに、「OSが読み込まれた際すぐに、自発的にリブートし続けようとするサーバーのようなものである」というものがあります。この例は、詳細を語る上でよく使われる面白い例です。 Nagiosはサービスがいつ flapping (バタツキ)を始めたかを検出できます。そして、バタツキが止まって、サービスの状態が安定するまで、通知を止めることができます。もし詳しくバタツキを検出する仕組みが知りたいならば、 ここを見ると良いです。