序文
Nagiosネットワークサービス、リソースの分散監視環境を設定することができます。 ここではその方法について簡潔に説明してみます・・・
目的
ここで記述する分散監視環境の目的の一つは"中央"サーバから1つ以上の"分散された"サーバ でサービスチェックを行うことで(CPU使用率などの)オーバーヘッドを軽減させることにあります。 ほとんどの小・中規模の環境ではこのような設定を行う必要が実際には無いでしょう。 しかし、100または1000のホスト(と多くのサービス)をNagiosで監視しようと思うと、 分散監視はとても重要になってきます。
参考図
下の図はNagiosでどのようにして分散監視を行うかの一般的な考え方を示しています。 この図中の絵を使いながら説明していきます・・・。
中央サーバ vs. 分散サーバ
Nagiosで分散監視環境を設定する際は、中央サーバと分散サーバは異なる方法で設定します。 これからどのように双方のタイプのサーバを設定するのか、その設定が監視全体に どのような変化をもたらすのかについて説明します。 まず始めに、異なるタイプのサーバの目的について記述します。
分散サーバの機能は定義したホストの"クラスタ"の全サービスをアクティブチェックすることです。 ここで使う"クラスタ"の意味は広義に使用しています - 基本的にはネットワーク上の任意のホストのグループを示しています。 ネットワーク環境に依存しますが、1つの場所にいくつかのクラスタがあるでしょう。 また、それらのクラスタはWANやファイアウォールなどで分割されているかもしれません。 (任意に定義した)それぞれのクラスタホストで覚えておくべき重要なことは、そのクラスタ内でNagiosを稼働し、 ホストのサービスを監視している分散サーバは1つであるということです。 1つの分散サーバは通常Nagiosのベアボーンのみインストールします。 分散サーバは望まない限り、ウェブインタフェイスをインストールする必要もなく、 通知やイベントハンドラも必要なく、どんなサービスチェックもする必要がありません。 分散サーバ設定のより詳しい説明は後で行います・・・。
中央サーバの役割は、1つ以上の分散サーバからのサービスチェックの 結果を単純にリスンすることです。 サービスはときどき中央サーバからアクティブチェックされますが、 このアクティブチェックは緊急時にのみ行われるもので、殆どはパッシブチェックを受けるだけです。 中央サーバは1つ以上の分散サーバからのパッシブサービスチェック の結果を受け付けるので、中央サーバは全監視ロジックの焦点となります。 (通知、イベントハンドラスクリプトの起動、ホスト状態の決定、 ウェブインタフェイスを提供する、等々)
分散監視サーバからのサービスチェック情報の受信
それでは、どのようにして分散サーバから中央サーバへサービスチェックの結果を 送っているのか知るために設定の詳細へ進みましょう。 すでにNagiosが稼働しているホストでどのようにしてパッシブチェックの結果を受け取るかに ついては説明しています(パッシブチェックドキュメントを 参照してください)。 しかし、他のホストからのパッシブチェックを受け取る方法については情報を提供していません。
パッシブチェックの結果をリモートホストへ送るために、 私はnscaアドオンを書きました。 このアドオンには2つのプログラムで構成されています。 一つは、リモートホストで動き、他のサーバへサービスチェックの結果を送信する クライアントプログラム(send_ncsa)。 2つ目はスタンドアロンデーモンまたはinetd経由で動きクライアントプログラムからの コネクションを待つncsaデーモン(nsca)です。 クライアントからサービスチェック情報を受け取ることで、 デーモンはPROCESS_SVC_CHECK_RESULTコマンドにて(中央サーバの)Nagiosの 外部コマンドファイルにチェック情報を登録します。 次にNagiosが外部コマンドをチェックした際に、 分散サーバが処理し、送信したパッシブサービスチェックの情報を拾うでしょう。簡単でしょ?
分散サーバの設定
じゃぁ実際の分散サーバのNagiosの設定は? 基本的にはベアボーンインストールです。 ウェブインタフェイスや通知は必要ありません。これらの機能はは中央サーバに持たせます。
設定の変更ポイント:
すべてを共に正しく稼働させるためには、分散サーバはすべてのサービスチェックを Nagiosに送ることを期待します。イベントハンドラを使えば 状態の変化をレポートすることが出来ますが、それだと中断できません。 強制的に分散サーバにすべてのサービスチェックの結果を送信させるには、 メイン設定ファイルのobsess_over_servicesを有効にし、 サービスチェックの後に毎回 ocsp_command を実行させなくてはならりません。 中央サーバへ全サービスチェックの結果を送るために(上で記述した) send_nscaクライアントと nscaデーモンを使ったocspコマンドを使用します。
設定を完了するために、以下のようなocspコマンドを定義する必要があります:
ocsp_command=submit_check_result
The command definition for the submit_check_result command looks something like this:
define command{
command_name submit_check_result
command_line /usr/local/nagios/libexec/eventhandlers/submit_check_result $HOSTNAME$ '$SERVICEDESC$' $SERVICESTATEID$ '$SERVICEOUTPUT$'
}
submit_check_resultシェルスクリプトは次のような感じにします (central_server部分を実際の中央サーバのIPアドレスに置き換えてください):
#!/bin/sh # Arguments: # $1 = host_name (Short name of host that the service is # associated with) # $2 = svc_description (Description of the service) # $3 = state_string (A string representing the status of # the given service - "OK", "WARNING", "CRITICAL" # or "UNKNOWN") # $4 = plugin_output (A text string that should be used # as the plugin output for the service checks) # # Convert the state string to the corresponding return code return_code=-1 case "$3" in OK) return_code=0 ;; WARNING) return_code=1 ;; CRITICAL) return_code=2 ;; UNKNOWN) return_code=-1 ;; esac # pipe the service check info into the send_nsca program, which # in turn transmits the data to the nsca daemon on the central # monitoring server /bin/printf "%s\t%s\t%s\t%s\n" "$1" "$2" "$return_code" "$4" | /usr/local/nagios/bin/send_nsca central_server -c /usr/local/nagios/etc/send_nsca.cfg
上のスクリプトではsend_nscaプログラムと設定ファイル(send_nsca.cfg)はそれぞれ /usr/local/nagios/bin/と/usr/local/nagios/etc/ にある物と想定しています。
以上です これでリモートホストで稼働しているNagiosを分散監視サーバとして設定できました。では実際に分散サーバの挙動とどのようにNagiosへサービスチェックの結果を送っているのか見てみましょう(下の順番の番号は上のダイヤグラムの番号と連携しています)。
中央サーバの設定
ここまでで分散サーバの設定を見てきました。次に中央サーバに移りましょう。集中させるためには、中央サーバーは通常設定するようなスタンドアロンサーバのような設定を行います。 その設定方法は次のようになります:
中央サーバを構成するにあたって気にとめておかなければならない3つの重要な事項があります:
プログラムワイドに全サービスをもしくは分散サーバが監視するサービスにはenable_active_checksオプションでサービスチェックを無効にすることは重要です。これはアクティブサービスチェックが通常の状況で絶対実行されないようにする設定です。そのサービスは通常のチェック間隔(3分毎、5分毎など・・)で再スケジュールされ続けますが、実際には実行されません。この再スケジュールのループはNagiosが稼働している間単に続けられると言うだけです。なぜかと言うことに関しては少しだけ説明しましょう・・・
以上です!簡単でしょ?
パッシブチェックの諸問題
すべての集中監視のために中央サーバはパッシブチェックに頼っていると言えます。完全に監視をパッシブチェックに頼るということの主な問題点はNagiosは監視情報を他の何かから提供されることに頼らなければ鳴らないという事実です。万が一パッシブチェックの結果を送ってくるリモートホストがダウンやunreachableになったらどうしたらいいでしょう?もしNagiosがそのホストのサービスにアクティブチェックを行っていない場合、どうやってその問題を検知すればいいでしょう?
幸い、これらの問題を解決する方法があります・・・。
フレッシュネスチェック
Nagiosはサービスチェックの結果を"フレッシュネス"チェックする機能があります。フレッシュネスチェックのより詳しい情報はこちらにあります。この機能はリモートホストが中央サーバへパッシブチェックの結果を送ってこなくなったと言う状況から保護します。"フレッシュネス"チェックのその目的は分散サーバから送られるパッシブサービスチェックと中央サーバ上の通常のアクティブチェックの結果を"確実に"することです。もし分散サーバからのサービスチェックの結果が"期限切れ"状態であったら、Nagiosは中央監視サーバから強制的にそのサービスをアクティブチェックするよう設定します。
さて、これをどうやってやるか?ですが、分散サーバで監視をするサービスに中央サーバ上で次のように設定します・・・。
Nagiosはフレッシュネスチェックが有効になっている全サービスの結果を定期的に"フレッシュ"かどうかチェックします。それぞれのサービス定義のfreshness_thresholdの値がサービスチェックの結果が"フレッシュ"かどうか判断する基準になります。例えば、あるサービスのこの値を300に設定したとしたら、Nagiosはサービスチェックの結果が3分(300秒)より古ければそれは"期限切れ"と考えます。freshness_thresholdオプションの値を設定しない場合、Nagiosはnormal_check_intervalもしくはretry_check_intervalオプションのどちらかから自動的に"フレッシュ"かどうか計算します(計算値はそのサービスがどんなステートタイプかに依存します)。もしそのサービスチェックの結果が"期限切れ"であったならば、Nagiosはそのサービスのサービス定義のcheck_commandオプションで指定したサービスチェックを実行します。
中央サーバからそのステータスをアクティブチェックできるようにサービス定義の check_commandオプションを指定しなくてはならないことを覚えておいてください。通常、このチェックコマンドは実行されることはありません(なぜならそのサービスはプログラムワイドもしくはその特定のサービスでアクティブチェックが無効にしているから)。フレッシュネスチェックが有効の際は、Nagiosはもしプログラムワイドおよびその特定のサービスでアクティブチェックが無効になっていたとしてもそのサービスのステータスをこのコマンドでアクティブチェックします。
もし、中央監視サーバからのアクティブチェックコマンドを定義できない場合 (もしくは設定することが困難だと判明した場合)、全サービスの check_commandオプションに 単純に警告ステータスを返すダミースクリプトを設定します。 ここにサンプルスクリプトを掲載します。定義するコマンド名を 'service-is-stale'として サービス定義のcheck_commandに設定することを想定しています。 定義は次のような感じです・・・
define command{
command_name service-is-stale
command_line /usr/local/nagios/libexec/staleservice.sh
}
次のようなstaleservice.shスクリプトを/usr/local/nagios/libexecに起きます。
#!/bin/sh /bin/echo "CRITICAL: Service results are stale!" exit 2 |
Nagiosがそのサービス結果が期限切れを検知したら、service-is-staleコマンドである/usr/local/nagios/libexec/staleservice.shを実行し、そのサービスを警告状態にします。これにより通知が送信され、担当者は問題を認知するしょう。
ホストチェックの実行
ここまでで分散サーバからパッシブサービスチェックを行う方法を学びました。これは中央サーバは実際にはアクティブサービスチェックを行わないことを意味しています。しかし、ホストチェックに関してはどうでしょう? ホストチェックも当然必要ですがどうするのでしょう?
ホストチェックは監視活動の中では通常妥協できる点(絶対に必要というわけでなければ)ですので中央サーバからのアクティブチェックで良いかと思います。 つまり、つまり分散サーバで行っているのと同じように(非分散監視環境の時と同じように)中央サーバにもホストチェックの設定をします。
パッシブホストチェックも可能です(ここを見てください) 。 分散監視設定で使えますが、少し問題があります。
分散監視サーバから中央監視サーバへパッシブチェックを送信したければ、次の事を確実に行ってください:
ochpコマンドはホストチェック結果を処理するのに使用し、サービスチェック結果を 処理するocspコマンドと同じように使います(上述のドキュメントを見て下さい)。 パッシブホストチェック結果が確実に最新になるようにする為、ホストの freshness checkingを有効にする必要があります (サービスについて上述されているものと方法は同じです)。