Webサーバの24×365監視を実現する　〜その2 - URL監視用のツールをインストールする〜：24×365のシステム管理（5）

　前回（「その1 - 何を監視すればいいのか？」）では、Webサーバの稼働を確認するために、何を監視するべきかを解説した。今回はその際に記述した概要を踏まえた上で、より具体的な監視方法について解説する。

■監視項目と監視ツールの策定

　この連載で何度も記述したように、システムの監視にはさまざまな監視項目が存在する。それぞれに意味のある監視ではあるが、その監視を実現するツールを検討する段階で、実現可能な監視項目が限定されてくる。システムの運用を専門にしている企業や、大規模なシステムを運用しなければならない企業／団体であれば、コストをかけて大規模な監視ツールを導入することができる。しかし、小規模なシステムの監視目的に高価な監視ツールを購入したり、専用の監視ツールを開発することは困難である。そこで、本連載では「フリーの監視ツール」ということを前提に解説する。当然フリー監視ツールである以上、可能な監視項目に制限ができる。それでも可能な限り有効な監視を設定できるように努力してみるつもりである。

　正直に告白すると、筆者はシステム運用を専門にする企業に所属している手前、フリーの監視ツールに触ることはほとんどない。そのため本連載で触れるフリーの監視ツールの多くは、はじめて接するものばかりである。読者の方の中に、より充実した機能を持った監視ツールをご存じの方がいらっしゃるようであれば、私の方がご教授願いたいというのが本音である。とはいえ「何を監視するか」と「何を検知したいのか」という監視の目的と監視対象を明らかにした上で、その目的を達成できるツールを策定することは可能である。要するに目的さえ達成できれば、その手段は何でも構わないということだ。

●監視対象と監視項目

　Webサーバの監視で最も重要なのは「Webサービスの稼働を確認する」ことである。この観点から最も確実な方法は、実際に特定の≪URL（Uniform

Resource Locator）≫を参照してみることである。つまり、インターネット経由で特定のURLを参照することによって、監視対象となるWebサーバの正常な稼働を確認するのである。この監視によって、以下の状態が検知できる。

　よくアクセスするWebサイトでも、時折「いつもよりアクセスに時間がかかる」あるいは「まったくアクセスできない」という状態になることがある。これらが上記(2)、または(3)に相当する。ユーザーとして感じる“いつもと違う”という状態を、監視ツールは定期的な監視により素早く検知して、管理者に通知することができる。

　監視以外の複雑な解説を省略するため、今回監視対象とするWebサーバは比較的単純な構成を想定したい。Webサーバは単独で立ち上げられ（Apacheを使用）、ロードバランサやクラスタリングなどによる負荷分散や冗長性を考慮したシステム構成がとられていないものとする。このWebサーバを監視対象として、このWebサーバ内にある特定URLを定期的に参照して、Webサービスの稼働を監視する。

●使用する監視ツール〜Nagios

　Webサービスの稼働監視を実行するツールとして、今回は「Nagios」を使用することにする。Nagiosは少し前まで「NetSaint」と呼ばれており、本連載でも以前に紹介したことがあるフリーの監視ツールである。Nagiosを実行するプラットフォームとして、Red

Hat 7.3をインストールしたPCを1台用意した。これが今回の監視サーバである。ちなみに、ネットワーク越しに監視を実行するため、監視用のサーバとして用意する機材には、1つ以上のTCP/IPのネットワーク・インターフェイスを持たせていることが最低限のハードウェア要件である。

　Nagiosは、ネットワーク接続されたホストや、ホスト上で動作しているサービスの動作状況を監視し、指定された監視タイミングでステータスを収集する。監視対象に問題を発見すると、あらかじめ指定された連絡先へ、指定された方法（メール、ページャなど）で通知する。また、Webブラウザ経由で、監視対象のステータスや監視ログ、レポートを参照することもできる。

　まず、Nagiosの最新バージョンをNagiosの公式サイトから入手する。Core Distributionとして、9月15日に最新の1.0b6バージョンがリリースされているので、今回はこれを入手した。各種プラグイン、アドオンソフトもあるので、説明文を読んで興味があるものを一緒にインストールすることをお勧めする。今回はまず、Core Distributionのみをインストールする。

　Nagiosのインストールには、動作可能なLinux OSと、Cコンパイラが必要となる。また、Core Distributionに含まれているCGIプログラムを使用する場合、インストールするサーバ上でApacheなどのWebサーバプログラムと、Thomas Boutellのgdライブラリのバージョン1.6.3以上が必要になる。WebサーバプログラムはWebブラウザ経由での操作に、gdライブラリはステータスマップやトレンド情報の表示に使用する。なお、gdライブラリのインストールには、さらにzlibおよびlibpngをインストールする必要であるので注意してほしい。

■監視基準の策定

　監視対象と監視項目は決まったが、実際に監視を実行するためには、さらに詳細に監視基準を作成する必要がある。策定しなければならない監視基準は以下のような事柄である。

• どこから監視するか
• 監視サーバから監視対象までのネットワーク到達性の確保
• 参照するURL
• 障害発生時のアラート通知先
• 障害発生後の対応方法

●どこから監視するか

　監視サーバは、監視対象となるサーバとは別のネットワークセグメント上にあることが望ましい。これは、同じネットワークセグメント上に監視サーバを設置した場合、いくつかのネットワークセグメントを経由してWebサーバに到達するユーザーと比較してネットワーク経路上の問題に遭遇しにくく、単純にWebサーバプロセスが動いていれば、そのURLのウェブページを参照できるという程度の監視となってしまうためである。しかし、さまざまなな制約から、同じネットワークセグメント上に監視サーバを設置しなければならないケースが発生してしまうかもしれない。その場合には、監視サーバが検知しきれないネットワーク的な障害が発生する可能性が常にあることを、管理者は忘れないようにしなければならない。

●監視サーバから監視対象までの経路の確保（ネットワーク到達性）

　Webサービスの稼働監視は、通常インターネット経由で実行する。この場合に必須となるのは、監視サーバからインターネットへの到達性である。監視サーバから監視対象となるWebサーバに到達できなければ、監視ができないのは自明の理である。なお、参照するURLがユーザー認証を必要とするページである場合には、監視ツールに認証情報を持たせる必要がある。監視ツールによっては認証する機能を持っていない場合もあるので、監視ツールの策定には注意すべきである。

　ちなみに、今回は解説しないが、監視対象サーバ上のプロセスやログを監視する場合、監視に使用するプロトコルにもよるが、インターネットを経由して監視することは、セキュリティ上好ましくない。そのため、これらの監視を実行する場合、監視サーバ群へ直接アクセスできる監視専用ネットワーク（専用線やダイヤルアップ回線など）を構築し、“裏”から監視対象サーバの情報を取得するようにすることが多い。

●参照するURLの決定

　監視のために実際に参照するURLは、常に固定のものを参照すべきである。また、監視の精度をより向上させたいのであれば、参照するURLの数を増やすことになる。サービスのトップページとして利用しているURLのほか、より多くのアクセスが予想されるページ、あるいはあまりアクセスが多くないページを同時に参照すると、それらの数値の比較によって障害の切り分けに役立つこともある。

●監視間隔と障害と判断する“しきい値”の決定

　監視サーバがURLを参照する間隔と、監視ツールが取得した監視対象のステータスから障害と判断するための“しきい値”を決定する。定期的に指定されたURLを確認して、特定の時間内（タイムアウト値として設定）に指定URLのデータをすべて参照できない状態を検知した場合、監視ツールはWebサーバの障害としてアラートを通知する。また、常に参照する場合のレスポンスタイムを計測し、このレスポンスタイムが規定値を上回った場合に、警告として監視システムからアラートを通知するように設定してもいい。

●アラート通知先の決定

　監視システムが障害を検知した場合、アラートをどこに通知するかを決定する。監視対象サーバの管理者はもちろん必要であるが、1人だけにアラートを通知すると、その1人にだけ負荷が掛かる。「確かに、システムの管理者とはそういうものだ」とあきらめてしまうのは簡単だが、24時間365日稼働するシステムの運用に担当者が1人というのは、あまりにも無理がある。やはり最低でも3人以上の管理者を決めて、アラートも複数人に通知するようにしたいものである。管理者の肉体的／精神的な拘束感を和らげることは、よりよいシステムの設計へ管理者の能力を使うことにもなるだろう。

●アラートが発生した場合の対処〜障害対応フロー／手順の決定

　アラートを複数人へ通知すると、当然技術スキルにも差が出てしまう。このスキルのバラつきを、障害対応においてできる限り平坦にするために、障害対応フローと手順の策定が必要となる。障害が発生した場合にそれを切り分ける方法については、すでにこの連載中で述べている。これらを障害対応フロー／手順として確立して、アラートの通知を受けたスタッフの全員が理解できるレベルで記述しておく。つまり、対応するスタッフのうちで、一番スキルの低い人に合わせて手順を作成するのである。

　障害対応フローと障害対応手順書は、アラートが発生してから問題が解決するまでのすべての手順を明確に示したものであることが望ましく、判断すべき個所においては、なるべくあいまいな判断基準を載せないほうがよい。例えば、あるファイルの大きさが“いつもと違う”という記述では、対応するスタッフによって判断基準が異なり、もしかするとそれが重大な影響を及ぼすかもしれない。ファイル容量が最新のファイルと比較して10％の変化を超えない場合など、できる限りデジタルで明確な判断基準を盛り込んでおくと、対応するスタッフが変わった場合でも、手順書はそのまま生かすことができる。

　これらの資料の作成は非常に手間が掛かるため、結局作成されないまま特定の管理者に負担がかかっていることが多い。しかし、これらの資料はシステム運用に役立つだけではなく、今後の管理者を教育するための資料としても非常に有効に活用できることも多い。やはり、監視開始初期に労力を惜しまないことをお勧めする。

■NagiosのインストールNagiosのインストール

　Nagiosをインストールする前に、Nagiosを実行するユーザーアカウントとグループを作成する。もちろん任意のユーザー名とグループ名で作成して構わないが、今回はユーザー名、グループ名ともに、「nagios」という名前にした。

　さて、いよいよインストールである。ダウンロードしたファイルを適当なディレクトリに置いて展開する。展開すると、「nagios-1.0b6」というディレクトリが作成される。

gzip -d ./nagios-1.0b6.tar.gz
tar xvf nagios-1.0b6.tar

　次に、Nagiosの実行ファイルがインストールされるディレクトリを作成する。ここでは、/usr/local の下にnagios ディレクトリを作成するが、ほかのディレクトリを使用しても問題ない。

mkdir /usr/local/nagios

　Nagiosを展開したディレクトリ（nagios-1.0b6）へ移動する。たくさんあるファイルの中に、configureファイルがあることが分かる。これをオプションつきで実行する。

./configure --prefix=/usr/local/nagios 
--with-cgiurl=/nagios/cgi-bin \
--with-htmlurl=/nagios/ --with-nagios-user=nagios --with-nagios-grp=nagios

それぞれのオプションの意味は、以下のとおりである。

　configureスクリプトが問題なく実行され、コンフィグレーションのサマリが表示される。これらの内容を確認して問題なければコンパイルする。

make all

　コンパイル終了後、できあがった実行ファイルとHTMLファイルをインストールする。

make install

　次に、initスクリプトをインストールする。initスクリプトはサンプルの起動スクリプトで、「/etc/rc.d/init.d」の下にnagiosというファイル名で作成される。内容を確認して、必要であれば適切なパスなどを設定する。

make install-init

　まだこの状態では、コンフィグファイルのサンプルがインストールされていない。やはり最初は、サンプルファイルからコンフィグを作成する方が楽である。サンプルのコンフィグファイルは、次のコマンドでインストールできる。

make install-config

　ここまででCore Distributionのインストールは完了した。次に、プラグインモジュールをインストールする。Core Distributionと同じディレクトリにダウンロードしたファイルを移動して展開する。

gzip -d nagiosplug-1.3-beta1.tar.gz
tar xvf nagiosplug-1.3-beta1.tar

　次に、nagiosユーザーにスイッチして、新たに作成されたディレクトリに移動する。ここにconfigureファイルがあるので、オプションを付与して実行する。

cd nagiosplug-1.3-beta1
./configure --prefix=/usr/local/nagios --with-nagios-user=nagios 
\
--with-nagios-group=nagios --with-cgiurl=/cgi-bin/nagios

　それぞれのオプションの意味は、次のとおりである。Nagios pluginのインストールでは、Core Distributionをインストールしたディレクトリやユーザーを指定すること。

　configure実行後にコンパイルする。

make all

　コンパイル終了後、作成されたモジュールをインストールする。

make install

　これで、Nagiosが取り合えず利用できる環境をインストールした。Nagiosをインストールした「/usr/local/nagios」ディレクトリを参照すると、次のようになっているはずである。

画面1　Nagiosの基本画面。基本的に、NagiosはWebブラウザから操作することになる（画面をクリックすると拡大表示します）

　次回は、インストールした監視ツールに対して、監視項目／監視間隔／しきい値／アラート通知先などを設定する予定である。