序論
他の多くのモニタリングツールとは似ていないのですが、Nagiosはサービスやホストなどの状態に対してチェックを行うための内部的メカニズムを含んでいません。代わりにNagiosは、全部の裏方の仕事をプラグインと呼ばれる外部プログラム(プラグインと呼ばれます)に頼っています。モニターすべきサービスかホストをチェックする必要がある場合は、常にNagiosはpluginを実行します。プラグインは、チェックをするために (一般的な意味での)何か を実行し、単にNagiosに対して結果を返します。Nagiosは、プラグインから受け取る結果を処理し、必要な処置は何でも(例えば、
下記のイメージは、Nagiosのコアプログラム理論からプラグインがどのように分離されているかを示すものです。
Nagiosは、いくつかのタイプのローカルまたは、リモートのリソース資源、またはサービスチェックするプラグインを実行します。
プラグインがリソースやサービスをチェックし終えた際に、単に処理するためNagiosへチェック結果を返します。
プラグインがどのように働くのかについての、さらに複雑なダイアグラムは パッシブサービスチェックに関するドキュメントで見ることができます。
表側
プラグイン構造に関しての優れた部分は、あなたが考えうるものすべてを監視できるということです。何かあるものをチェックする過程を自動化できれば、Nagiosでそれを監視することができます。プロセス、ロードアベレージ、ディスク使用状況、pingの(応答)割合など、基礎的なリソース資源を監視するため、すでにたくさんのプラグインが開発されています。他の何か別のプラグインが欲しいのなら、writing pluginsのドキュメントをみて、自分で開発してみてください。意外と簡単かもよ!
裏側
プラグイン構造でできる最低限のことは、Nagiosは絶対的に監視しているものが何なのか絶対に分からないということです。
ネットワークトラフィック統計、データエラー割合、室内温度、CPUヴォルテージ、ファンスピード、プロセスロード、ディスクスペース、また、空想的な話ですが、"スーパー"トースターが朝パンをちょうどいい焦げ目にする・・・ということまでもを監視できます。
そのため、Nagiosは、何時間にわたって監視しているリソース資源の正確な値への変更のグラフを作り出すことができません。
単に、それらのリソース資源の状態の変化を追跡することはできます。プラグインだけが自分自身が何をモニターしていて、どのようにチェックを行うのか、正確に知っています。しかしながら、プラグインはステータス情報に沿った、オプションの
サービスチェックの為にプラグインを使う
プラグインとサービスチェック間の相関性はかなり明白に違いありません。Nagiosは、定義した特別のサービスのステータスをチェックする必要がある時、サービス定義の中で話されている<check_command>中で指定したプラグインを実行します。プラグインは、指定したサービスやリソース資源の状態をチェックし、Nagiosへの結果を返します。
ホストチェックに対してのプラグイン使用
ホストの状態をチェックする為にプラグインを使用することは、少し理解に苦しむかもしれません。 各ホスト定義では、プラグインを指定する話の中で出てきた <host_check_command>を使用して、ホストのステータスをチェックするために実行されるべきプラグインを指定します。 ホスト・チェックは定期的には、実行されません・・・すなわち、ホストチェックは必要とされるときにのみ、通常、ホストに関係している1つ以上のサービスに関する問題がある場合にだけ実行されます。
ホスト・チェックはサービス・チェックと同じプラグインを使用することができます。唯一の違いは、プラグインが返す結果の重要性です。 ホスト・チェック用に使用されるプラグインがnon-OKのステータスを返答してきたなら、Nagiosはホストはダウン状態にあると信じます。
ほとんどの状況で、pingが返って来るかどうかをチェックするプラグインを使用したいでしょう、この方法がホストがアップしているかどうかを伝える最も一般的な方法です。しかしながら、もし、(先ほど述べた)空想的なトースターをモニターしていたならば、発熱要素が、ハンドルがいつ押し下げられた時、回転するかどうかチェックするプラグインを使用したいと思うかもしれません。それはトースターが「生きていた」かどうかに関して適正な表示を与えるでしょう。