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

前回「Webサーバの監視～コンフィグとICMPの設定～」は、監視ツール「Nagios」による基本的なICMP（ping）での疎通監視の設定までを解説した。そこで、今回はWebサーバ監視の最終目的である「HTTPサービスの稼働監視」の設定を解説する。

» 2003年01月06日 00時00分公開

[東原亜紀，ネットベイン]

■cgi.cfgの設定

　NagiosのWebインターフェイスはCGIを多用する。このCGIを利用するにはApacheなどのWebサーバアプリケーションと、Nagiosが用意しているCGIプログラムが必要である。さらに、CGIプログラムを実行するために、「cgi.cfg」というコンフィグファイルを設定しなければならない。再びコンフィグファイルの話でうんざりしている読者もいらっしゃると思うが、これもオープンソースコミュニティで発展するソフトウェアの宿命とあきらめてほしい。

　まず、使用するWebサーバアプリケーションにおいて、次の点が設定されるようにしてほしい。

CGIプログラムを実行するファイルへのスクリプトエイリアス設定
Webインターフェイスを提供するファイルへのエイリアス設定
CGIへアクセスするための認証設定

　CGIへアクセスするための認証設定は、ユーザー名とパスワードをNagiosのホームディレクトリにあるetc ディレクトリ以下に、Webサーバアプリケーションの指示による所定の認証用ファイル（例htpasswd.users）のファイル名で保存する。

　次にNagiosが用意しているCGIプログラムを確認する。プログラム自体は、Nagios のインストール時（Webサーバの監視?監視ツールの導入?）に同時にNagiosのホームディレクトリ以下（デフォルトでは/usr/local/nagios/sbin）へインストールされているはずである。

[nagios@nagios nagios]$ ls sbin
avail.cgi config.cgi histogram.cgi notifications.cgi showlog.cgi 
statusmap.cgi statuswrl.cgi tac.cgi
cmd.cgi extinfo.cgi history.cgi outages.cgi status.cgi statuswml.cgi 
summary.cgi trends.cgi

　cgi.cfgは、Nagios本体をインストールしたときに、サンプルがNagiosのディレクトリ以下（デフォルトでは/usr/local/nagios/etc）に保存される。サンプルのcgi.cfgファイルを開き、次のように設定する。ここでは必要最小限の設定と説明を示すので、より詳細な内容は各設定部分に記述されている英文を参照してほしい。

# MAIN CONFIGURATION FILE
Nagiosのメインファイルの絶対パスを指定する
（例）
main_config_file=/usr/local/nagios/etc/nagios.cfg

# PHYSICAL HTML PATH
Webインターフェイスに使用するHTMLファイルへのパスを指定する
（例）
physical_html_path=/usr/local/nagios/share

# URL HTML PATH
PHYSICAL HTML PATH で指定したHTMLファイルの場所に対応するURLを、Web サーバアプリケーションで設定したエイリアスと同じ値に指定する
（例）
url_html_path=/nagios

# AUTHENTICATION USAGE
認証の設定。1 は認証する、0 は認証しない。0に指定するとだれでもWeb経由で監視状況を参照できるようになる
（例）
use_authentication=1

# CONFIGURATION INFORMATION ACCESS
Nagios自身のコンフィグ情報へのアクセス権限を設定する。カンマ区切りで複数ユーザー設定可能。すべてのユーザーに許可する場合には“*”を設定。（例の「nagiosadmin」および「monmaster」はユーザー名）
（例）
authorized_for_configuration_information=nagiosadmin,monmaster

# GLOBAL HOST/SERVICE VIEW ACCESS
監視対象、サービスなどの情報を参照する権限を設定する。すべてのユーザーに許可する場合には“*”を設定
（例）
authorized_for_all_services=nagiosadmin,guestauthorized_for_all_hosts=nagiosadmin,guest

# DEFAULT STATUSMAP LAYOUT METHOD
ステータスマップの表示方法を選択する。5種類のマップが用意されており、デフォルトでは 5 に設定されている
（例）
default_statusmap_layout=5

# REFRESH RATE
ステータス、ステータスマップなどの表示をリフレッシュする間隔を、秒単位で設定する
（例）
refresh_rate=90

　WebサーバアプリケーションとNagiosの設定後、Webサーバアプリケーションを再起動して、設定したURLへアクセスする。Nagios

のトップページが認証画面とともに表示され，作成したアカウントで認証が成功すれば設定は完了である。

画面1　認証画面に作成したアカウントでログインする

■URLの監視を設定する

　では、実際のHTTPサービスの稼働監視を設定してみよう。今回の監視対象には、＠ITのトップページ「www.atmarkit.co.jp」を設定することにした。前回設定したCIMPによる稼働監視同様、監視間隔は1分、異常と判断するのは、5分間連続してトップページをGETできない場合とし、異常を検知したらNagiosの管理者へメールを送信させる。


監視対象	www.atmarkit.co.jp
監視項目	HTTPサービス稼働監視
監視間隔	1分
異常と判断する条件	5分間連続して対象のページを GET できない
通知先	Nagios 管理者のメールアドレスnagios@localhost

●services.cfgの設定

　services.cfgファイルをエディタで開き、次のような設定を追加する。host_nameには、監視対象の識別名を記述する。今回は監視対象のURLと同じに設定したが、ここは任意の文字列で構わない。check_commandには、監視に使用するコマンドを記述する。

　今回は指定URLのサービス稼働状況を監視するので、libexecディレクトリ以下の「check_http」コマンドをオプションなしで使用する。check_httpコマンドは、指定したURLの80番ポートへアクセスし、STATE_OK

を返すことを確認するコマンドである。このコマンドの詳細を確認したい場合には、check_http -hを実行すればコマンドオプションの説明が表示される。

# Service definition
define service{
use generic-service ; Name of service template to use host_name www.atmarkit.co.jp
service_description HTTP
is_volatile 0
check_period 24x7
max_check_attempts 5
normal_check_interval 5
retry_check_interval 1
contact_groups test-admins
notification_interval 0
notification_period 24x7
notification_options w,u,c,r
check_command check_http
}

●escalations.cfgの設定

　escalations.cfgファイルに、次のような設定をする。services.cfgファイルと同様に、host_nameに監視対象の識別名を記述する。contact_groupsには、異常を検知した場合にアラートを通知する先のグループを設定する。ここで設定しているtest-adminsは、前回のICMPによる疎通監視と同じ通知先である。

# Serviceescalation definition
define serviceescalation{
host_name www.atmarkit.co.jp
service_description HTTP
first_notification 5
last_notification 6
contact_groups test-admins
notification_interval 0
}

●hosts.cfgの設定

　hosts.cfgには、次のような設定を追加する。host_nameに監視対象の識別名、addressには監視対象のURLを記述する。このコンフィグファイルの設定内容から、check_httpコマンドによってwww.atmarkit.co.jpを監視することが判断できる。

# 'www.atmarkit.co.jp' host definition
define host{
use generic-host ; Name of host template to use host_name www.atmarkit.co.jp
alias Nagios Server
address www.atmarkit.co.jp
check_command check_http
max_check_attempts 10
notification_interval 0
notification_period 24x7
notification_options d,u,r
}

●hostgroups.cfgの設定

　アラート通知は前回設定した通知先と同じにしたいので、hostgroups.cfg の中の既存のグループ“test”のmembersに、今回設定する監視対象の識別名“www.atmarkit.co.jp”

を追加する。contact_groupsに設定されたグループ名“test-admins”は、すでにcontactgroups.cfgに登録されているので、hostgroups.cfgのmembersに今回の識別名を設定するだけで、前回と同じ管理者へアラートが通知されるようになる。

　もし違う管理者へ通知をしたい場合は、contacts.cfgファイルとcontactgroups.cfgファイルの設定を変更し、これまでに設定したコンフィグファイルの中のcontact_groupsの設定も変更する必要がある。

# 'test' host group definition
define hostgroup{
hostgroup_name test-servers
alias Test Servers
contact_groups test-admins
members speech,www.yahoo.co.jp,www.atmarkit.co.jp
}

●設定の確認

　ここまでで監視設定は終了しているが、監視を開始する前に-vオプションでコンフィグファイルの整合性を確かめておく必要がある。

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

　コマンド実行の結果、WarningsとErrorsがともに 0 であれば設定は終了である。

■HTTPサービスの稼働監視の開始

　設定内容に問題がなければ、早速Nagiosにコンフィグファイルをリロードさせて監視を開始する。

# /etc/rc.d/init.d/nagios reload

　監視状況をWebブラウザから確認するには、左側のメニューから「Service Detail」か「Host Detail」を選択する。今回新たに追加された「www.atmarkit.co.jp」という識別名の監視グループが確認できるはずである。ただし、最初はStatusが「PENDING」、Status Informationが「Not enough data to determine host status yet」と表示される。

　これは、実際に監視を開始してから、最初に稼働（または異常な状態）を判断するまでは、監視対象が正常に稼働していることをNagios自身が判断できないためである。監視間隔は5分の設定なので、監視の開始から5分以上経過してからブラウザをリロードすると、監視対象の現在のステータスを確認することができる。

画面2　設定した直後の Host Detail の画面（画面をクリックすると拡大表示します）

画面3　監視開始後1回目の正常を確認した後の Service Detail の画面（画面をクリックすると拡大表示します）

■Nagiosによる監視の状況確認

　Nagiosが通知したアラートの履歴などのステータスは、Webインターフェイスから確認できる。例えば画面左側のReporting欄の項目のAlert Historyをクリックすると、発生したアラートの状況やNagiosへの監視設定追加によるリスタート状況を確認できる。

画面4　アラートの履歴（画面をクリックすると拡大表示します）

　ここまでで、フリーの監視ツール「Nagios」による監視設定は終了である。多くのコンフィグファイルの設定は非常に困難で、1つの監視を設定するだけでも非常に手間が掛かる。しかし設定の煩雑さは多機能であることの証明ともいえる。

　 Nagiosは、この連載では紹介できなかった数多くの機能を実装している。ぜひNagiosに付属するドキュメントを参照して、より理解を深めていただければと思う。

■まとめ

　「最終回でやっと本題に入った」と思われた方もいらっしゃるかもしれないが、本来システムの監視・運用は、実際の監視設定よりも、セキュリティポリシーや監視・運用ポリシー策定、監視ツールの選択などの段階の方がより重要である。

　また、監視設定後は、ポリシーに従って運用されているか、あるいはポリシーに無理がないかを常に検討する必要がある。システムを24時間×365日にわたって運用するには、ただツールを導入して監視すればいいわけではなく、適切な監視と障害発生時の適切な対応の方がより重要なのだということを、この連載を機にご理解いただければ幸いである。

　最後に読者の方々に対して、おわびとお断りをさせていただきたい。この連載は当初、DNSサーバや、データベースサーバの監視・運用についても解説する予定でいた。しかし実際に連載を始めてみると「フリーの監視ツールによる監視」で解説することが非常に困難である点に気付いたため、Webサーバという非常に需要の高いサーバの監視・運用のみの解説で連載を終わらせていただくこととなった。期待されていた読者の方には大変申し訳ないことであり、この場を借りて深くおわび申し上げる。

「24×365のシステム管理」バックナンバー