Nagios

序論


ホストチェックの基本的な動作はここで説明されます…

ホストチェックはいつ実行されますか?


ホストはNagiosデーモンでチェックされます:

定期的に予定されているホストチェックはオプションです。 あなたのホスト定義における check_interval オプションに(0)をゼロを設定すると、Nagiosは定期的にホストのチェックを実行しません。 しかしながら、それでも、監視ロジックの一部としての必要性からホストのオンデマンドチェックを行います。

ホストの状態変化が起きたときオンデマンドチェックが行われます。なぜならNagiosはホストの状態が変化したかどうかを知る必要があるからです。 しばしば状態を変えるサービスは、また、ホストが状態を変えるかもしれなかったという指標です。 例えば、Nagiosがホストに関連したHTTPサービスがCRITICALからOK状態への変化をちょうど検知したら、それはホストがリブートからちょうど復旧し、元に戻って実行を開始した事を示すかもしれません。

また、ホストのオンデマンドチェックは、到達性チェックのロジックの一部として行われます。 Nagiosは、できるだけはやくネットワーク故障を検出して、DOWNとUNREACHABLEホストステータスを見分けるように設計されています。 これらは、非常に異なったステータスであり、管理者がネットワーク故障の原因の場所をすぐを見つけるのを助けます。

また、オンデマンドのチェックはまた、ホスト依存チェックロジックの一部として実行されます。 これらのチェックは、依存ロジックが出来るだけ正確に確認するのを助けます。

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


オンデマンドホストチェックの性能は、キャッシュチェックを使うことで劇的に改善できます。これはNagiosのホストチェックの実行に最近のチェック結果を使う事を許すことです。 ここでキャッシュされたチェックに関する詳しい情報を見つけることができます。

依存とチェック


Nagiosが他の1つ以上のホストの状態に依存しているホスト状態のチェックを避けるホスト実行の依存関係を定義できます。 ここで依存に関する詳しい情報を見つけることができます。

ホストチェックの並列化


計画されているホストチェックは。平行に実行されます。 Nagiosが、予定されているホストチェックを実行する必要があると、それは、ホストチェックを開始して、他の仕事(実行しているサービスチェックなど)を行うのに戻ります。 ホストチェックは子プロセスで実行します。子プロセスは親のNagiosデーモンからフォークで起動されます。 ホストチェックが知らせたとき、完成していて、子プロセスは、チェック結果について主なNagiosプロセスを知らせます(親)。 主なNagiosプロセスは、次に、チェック結果を扱って、適切な行動を取ります(通告を送っていて、イベントハンドラを実行しますなど)。

オンデマンドのホストチェックは、平行に実行されます。 先に述べたように、比較的最近のホストチェックからキャッシュされた結果を使用できるなら、Nagiosはオンデマンドのホストチェックの実際の実行をを代替できます。

Nagiosがスケジュールとオンデマンドのホストチェックの結果を処理するとき、他のホストの(セカンダリ)のチェックをスタートするかも知れません。 2つの理由でこれらのチェックが初期化されることができます: 予測依存チェックネットワーク到達性論理を使ったホストの状態を決定 普通、スタートされるセカンダリチェックは、並行処理されます。 しかしながら、意識しているべきである1つの大きい例外があります。それは、パーフォーマンスに負の効果がある事です。…

ホストの max_check_attempts の値を1にセットすると重大な問題を引き起こします。 その理由は? Nagiosが、ネットワーク到達性論理(彼らがDOWNかそれともUNREACHABLEであるかを確認する)を使用して本当の状態を決定する必要があると、ホストの直近の親すべてのシリアルチェックを開始する必要があります。 ただ、繰り返すために、それらのチェックは平行でなく順次実行されます。それゆえ、大きなパフォーマンスヒットを引き起こす場合があります。 この理由で、ホスト定義の max_check_attempts 指示にいつも1以上の値の使用を勧めます。

ホストステータス


チェックされるホストは3つの異なった状態の1つをとる事ができます:

ホストステータスの決定


ホストチェックはプラグインによって実行されます。プラグインはOK、WARNING、UNKNOWN、またはCRITICALのステータスを返すことができます)。 NagiosはどのようにUP、DOWN、またはUNREACHABLEのホストステータスをこれらプラグインからの復帰コードから解釈しますか? 見てみます。

以下のテーブルは初期のホスト状態に対応したコードをどうプラグインが返すかを示しています。 いくつかの後処理(後で説明される)が完了すると、最終のホスト状態を変える事があります。

プラグイン結果初期のホスト状態
OKUP
WARNINGUP or DOWN*
UNKNOWNDOWN
CRITICALDOWN

注意: 結果は、普通ホストがUPを意味します。 しかしながら、WARNING結果は use_aggressive_host_checking オプションが可能にな場合、ホストがDOWNと解釈されます。

最初のホスト状態が DOWNであれば、Nagiosは、ホストが本当にDOWNかUNREACHABLEかを確かめようと試みます。 DOWNとUNREACHABLEホストステータスでの区別は重要です、それは、管理者がより速くネットワーク故障の根本的原因を決定できるからです。 以下のテーブルはNagiosがどうホストの親の状態に基づいて最終的なステータスを決めるかを示しています。 ホストの親はホスト定義における親指示で定義されます。

初期のホスト状態親ホストの状態最後のホスト状態
DOWN少なくとも片方の親はUP状態です。DOWN
DOWNすべての両親は、DOWNかUNREACHABLEのどちらかです。UNREACHABLE

NagiosがDOWNとUNREACHABLE状態をどのように区別するかの詳しい情報はここにあります。

ホストステータスの変化


あなたがたぶんよく知っているように、ホストは何時も1つの状態にあるわけではありません。 破られると、パッチがあてられ、そして、サーバはリブートされる必要があります。 Nagiosがホストの状態をチェックするとき、それは、ホストがいつUP、DOWN、そしてUNREACHABLE状態の検出を可能とし、適切な動作を取ります。 これらは、出すために変化が異なったステータスのタイプ(HARDかSOFT)をもたらすと述べます。(タイプは実行されるべきイベントハンドラと通知の引き金となることができます)。 状態変更を検出して、対処するのは、Nagiosが関することです。

ホストがあまりに頻繁に状態を変えるとき、ホストは「ばたついている」と考えます。 ばたついているホストの好例は、オペレーティングシステムがロードするとすぐリブートし続けるサーバでしょう。 いつもそれは対処しなければならないおもしろいシナリオです。 Nagiosはホストがばたつき始めたかを検出し、ばたつくことが止まって、ホストの状態が安定するまで、通知を止める事ができます。 ここでバタツキ検出ロジックに関する詳しい情報を見つけることができます。

参照 参照: ネットワーク到達性, アクティブ・チェック, サービスチェック, チェックスケジューリング, 予測依存チェック

English Deutsch 日本語

目次