| ・ CMS及びDMSにおけるNetSaintの設定と起動 （１）DMS（Distributed Monitoring Server）上のNetSaintの設定 インストールのところでも書きましたが、DMS（Distributed Monitoring Server）におけるNetSaintの設定に関するキーポイントは、次の４点です。
それでは、それぞれの設定内容について見ていきましょう。 ① チェック対象となるホストやサービスを定義する。（ hosts.cfg ） DMSで監視対象となるホストやサービスをアクティブにチェックしますので、当然といえば当然ですね。 具体的な設定方法については、基本編の「 Host Configuration 」を参考にしてください。 ② スタンバイモードで起動するように設定する。（ netsaint.cfg ） netsaint.cfg のprogram_mode=s とします。 スタンバイモード（それに対するアクティブモード）については、基本編の「NetSaintの基本用語」を御覧ください。 ③ obsess over service が機能するように設定する。（ netsaint.cfg ） ④ ocspコマンドを定義しておく。（ hosts.cfg ） さて、③と④はセットとなっています。 新しい用語ですので説明しようと思うのですが、うまく日本語化できません。 netsaint.cfg の obsess over service のセクションも次のようになっているだけでした。
ちなみに、研究社の新英和中辞典で単語の意味を調べたところ、 obsess ＝ ＜悪魔・妄想などが＞．．．に取りつく。；取りついて悩ます。 obsessive ＝ 妄想的な、強迫観念の；取りつかれたような、＜恐怖など＞執拗な。 compulsive ＝ 強制的な、いやおうなしの。 と、なんともすごい訳がでてきました。(~_~;) どうやら、DMSがチェックした全ての結果をもれなくCMSに送るようにする仕組みのようです。 それでは、具体的な設定方法を見てみましょう。 まず、/usr/local/netsaint/etc/netsaint.cfg にある obsess_over_services と ocsp_command を次のように定義します。
次に、/usr/local/netsaint/etc/hosts.cfg に submit_check_result というコマンドを次のように定義します。
そして、/usr/local/netsaint/libexec/eventhandlers/submit_check_result というシェルスクリプトを次のように作成します。 （ central_server には、CMS（Central Monitoring Server）のIPアドレスを記入します。）
以上で、DMS(Distributed Monitoring Server）で稼動させるNetSaintの準備が完了しました。 最後に、CMS（Central Monitoring Server）で稼動させるNetSaintの設定を行いましょう。 （２）CMS（Central Monitoring Server）上のNetSaintの設定 これもインストールのところで書きましたが、CMS（Central Monitoring Server）におけるNetSaintの設定に関するキーポイントは、次の５点です。
これらの内容については、今までの説明で理解されていると思います。 なお、①～⑤については /usr/local/netsaint_dm/etc/netsaint.cfg の各項目を次の値にします。
これ以外に、/usr/local/netsaint_dm/etc/netsaint.cfg の次の項目も修正します。
⑥については、エクスターナルコマンドが実行された場合のログ（/usr/local/netsaint_dm/var/netsaint.log）を記録しない、という設定です。 CMS上では頻繁にエクスターナルコマンドが実行されますので、かなりのボリュームになります。 最初はログを書くようにして、動作が安定してきたならば書き込まないようにすればいいと思います。 ⑦及び⑧は、デフォルトの設定ではともに「1」となっています。 つまり、CMS上のNetSaintが終了した時点での状態を/usr/local/netsaint_dm/var/status.sav というファイルに書き込み、再起動時にはそのファイルに書き込まれた状態を読み込んでスタートする、ということです。 しかし、CMSはDMSから送られてくる情報を処理すればよいので、終了時の状態を保存し、再起動時にそれを読み込む必要はありません。 逆に、読み込むことによって不都合が生じる場合もありますので、ともに「0」とします。 （どのような場合に不都合が生じるかといいますと、DMS上のあるホストがダウンしCMSで認識した後、そのホストがリカバリーしDMSではOKとなったが、CMSがOKとなった状態を認識する前に終了した場合、CMSを再起動してもそのホストがリカバリーしたという情報が入ってこないので、CMS上ではいつまでもダウンしていると認識してしまいます。） さて、CMS上での hosts.cfg の設定ですが、これは次の２点を除きDMSで設定した内容と全く同じ内容で設定します。
その理由を今回のネットワークモデルを使って説明します。 |
|||||||||
 |
|||||||||
このモデルで、DMS上の「Host1」を次のように定義したとします。
その場合、CMS上のNetSaintでは、ホストチェックコマンドである「check-host-alive」を削除して定義します。 すなわち、
NetSaintは、定期的にホストチェックコマンドを実行するのではなく、監視するサービスに何らかの異常が発生したときに実行します。 そこで、「Host1」上のあるサービスに異常が発生した場合、その情報がNSCAを通じてCMSに送られてくると、CMSは自らのhosts.cfgに定義されているホストチェックコマンドを実行しようとします。 ところが、CMSには「192.168.0.11」というホストは接続されていませんので、ホストチェックコマンドは「UNREACHABLE」となってしまいます。 そして、「Host1」が正常に戻った場合、その情報に基づき、CMSは再度ホストチェックコマンドを実行しますが、やはり「UNREACHABLE」のままとなり、それ以降は「UNREACHABLE」状態が表示され続けてしまいます。 これを回避するために、CMS上ではホストチェックコマンドを定義しないでおくのです。 次に、DMS上のサービスを次のように定義したとします。
その場合、CMS上の定義は次のようにします。
DMS上では、/usr/local/netsaint/etc/hosts.cfg の「SERVICE CONFIGURATION」に、各サービスを監視する時間帯を本来の目的に応じた設定を行います。 この例では、２４時間３６５日監視するので「24x7」としています。 しかし、CMS上ではこれを「 none 」、すなわち「監視時間帯を定義しない」という設定にしておきます。 CMSはあくまでもパッシブサービスチェックに専念するためです。 繰り返しになりますが、CMSのhosts.cfg にDMSがサービスチェックを行うホストやサービスの定義を登録しておかないと、DMSから送られてきたデータは処理されませんので十分に注意してください。 （３）分散監視（Distributed Monitoring）の開始 以上で、「分散監視（Distributed Monitoring）」に関する設定は全て終了しました。 それでは、次の順番でNetSaint、NSCAを起動させてください。
そして、CMSのウェッブインターフェースにアクセスして見てください。 きっと感動が待っていると思います。 なお、失望が待っていた場合には、もう一度それぞれの設定内容を見直してくださいね。(^_^メ) |
 |
 |
 |