SourceForge.JP: Open Source Software

　この記事は、新刊『Building a Monitoring Infrastructure with Nagios』(Prentice Hall Professional, Copyright 2007 Pearson Education, Inc. All rights reserved.)からの抜粋です。

　最初のシナリオでは、B社がパブリックなMXに到達する不要な電子メールをブロックするために、信頼性の低いフィルタを組み合わせて使用している。問題は、このフィルタが同社の業務提携先であるA社をなんらかの理由で目の敵にして、A社からの電子メールを完全にブロックする事態が数週間おきに発生することである。この問題を解決するために協議が重ねられたが、フィルタの組み合わせが複雑すぎるのとB社の組織が大きすぎることから、容易に原因を絞り切れないでいた。解決できたと思うたびに問題が再発するのである。さらに悪いことに、B社のフィルタはメールを拒否するのではなく「250 not OK」と返答して床にただ投げ捨てるので、問題が発覚するまで丸一日がたってしまうのだ（セキュリティのコンサルタントが、そうするのが一番いいとアドバイスしたからである）。

　せめて問題を早期に検出したいと、A社のシステム管理者はB社のメールサーバとSMTPハンドシェイクを定期的に実行するcheck_smtpプラグインを使ってコマンドを定義した。

define command{
   command_name   check_spam_block
   command_line   $USER1$/check_smtp -H $HOSTADDRESS$ \
                  -C 'hello companyA.com' –R '250 OK' \
                  –C 'mail from: <alice@companya.com>'\
                  –R '250 OK' \
                  –C 'rcpt to: <bob@companyb.com>' \
                  –R '250 OK'
   }

　これは有効だった。B社がハンドシェイクに対して「250 OK」以外で応答すると、A社の管理者にすぐに通知が来る。しかも、必要ならこの定義を拡張してSMTP通信のデータ部を含めることも可能だ。

　一言付け加えておくと、このようなことを行う前には承諾を得る必要がある。所有下にないものを監視するのだから、面倒なことにならないとも限らない。それに、監視対象のサービスと実際に通信するサービスチェックがログや接続統計に影響を与えることも忘れてはならない。データ部を監視に含めると、B社の管理者が実際に電子メールメッセージを受け取ることになる。一般に、人間に直接影響が及ぶことは敬遠するのが望ましい。一方で、できの悪いデーモンを使うと接続が不意に切断されてサービスチェックに支障が出る可能性がある。また、相手側の管理者がこちらの監視ツールのトラフィックを悪性のものと判断し、フィルタでブロックすることもありうる。監視の対象とするものにはよくよくの注意を払う必要がある。自分の会社やグループに属さないものを監視する場合はなおさらだ。

　次の例は、ある中規模のヘルスケア企業でシステム管理者を勤めるT氏のケースだ。この会社で彼は、少しうさん臭いPKIベンダ、VeriSure社からSSL証明書を取得する立場にある。また、新しいドメイン名を登録する仕事もあるが、これにはVeriSure社を使わないのが同社の決定である。最近、T氏のメールボックスはVeriSure社からのメールで溢れかえるようになった。ほとんどはセールスのメールで、料金を割り引くからドメインの登録をVeriSure社に移管して欲しいというものだ。複数のドメインとSSL証明書を所有していることから、こういったメールが毎日20通も届く。T氏はジレンマに陥った。VeriSure社からのメールをすべて/dev/nullに放り込みたいが、SSLの有効期限切れの連絡は受け取る必要がある。そこで、こんなコマンドを使うことにした。

define command{
   command_name   check_ssl
   command_line   $USER1$/check_http $ARG1$ -C 10
   }

　check_httpは、あらゆる便利なことができる優れたプラグインである。-Cスイッチによって、指定したWebサイトのSSL証明書の有効期限がチェックされる。Webサイトの証明書が指定の日数（この例では10日）以内に期限切れになる場合、check_httpから致命的エラーが生成される。このコマンドにより、T氏の問題は解決した。恐らくVeriSure社からの通知より少しばかり信頼性も高いだろう。

　この定義では、1つ目の例と違って$HOSTADDRESS$マクロを使用しない。理由は、サーバアドレスではなくURLを指定するからだ。このURLは、ARGマクロを通して渡される。

define service{
   host_name              webServer
   service_description    check_ssl
   check_command          check_ssl!www.myweb.org
   notification_options   c,w,r
   use                    chapter6template
   }

　面白いことに、$HOSTADDRESS$マクロは通常はプラグインを実行するホストを決めるマクロなので、このマクロを使用しないときはservice定義のhost_nameディレクティブには何を指定してもかまわない。つまり、上記のコードのhost_nameに無関係の会計データベースサーバを指定しても、チェックは正常に実行される。$HOSTADDRESS$マクロがコマンド定義に含まれない場合にhost_nameディレクティブが使用されるのは、WebのUIだけである。このとき、check_sslサービスはhost_nameによって参照されるものに所属するとして表示される。

NewsForge.com 原文