特集：システム管理の鉄則（後編）

NagiosでWebサーバを頑丈にする方法

2004/4/2
鳴滝光二

症状監視の設計

　症状監視でまず考えるのはネットワークレベルでの到達性の監視です。このため、まずは以下に対してpingによる到達性の監視を行います。

• サーバA
• サーバB
• ファイアウォール
• ルータ
• DMZ用スイッチ
• 社内用スイッチ

　ここで気を付けなければならないことは、監視ツールがDMZのセグメントに設置してあるため、ルータ、社内用スイッチはファイアウォール越しにpingによる到達性チェックをすることになります。従って、ファイアウォールの設定で、これらのパケットに対するフィルタを開けるようにしなければ正しく監視できないので注意してください。

　もし、ファイアウォールの仕様上、どうしてもpingによる到達性チェックができない場合は、監視方法をSNMPによるポーリング監視に切り替えるなどの方法が考えられます。

　Nagiosではホストに親子関係が指定でき、子のホストへの到達性がなくなった場合、親のホストへの到達性をチェックして、到達できない理由が、子のホストが停止したのか、それとも子のホストのあるネットワークへの到達性がなくなったのかを判断してくれます。

　モデルシステムの場合、監視ツールは社内のセグメントに設置されているので、監視ツールが設置されているマシンから見て、ホストごとの依存関係は次のようなツリーになります。

図2‐5 監視対象ホストの依存関係ツリー

　この設定を行うことで監視ツールから送信される障害の通知を劇的に減らすことができます。

　例えばファイアウォールが落ちた場合、Nagiosからは以下のホストへの到達性が失われます。

• ルータ
• サーバA
• サーバB
• DMZ用スイッチ

　この設定がない場合、管理者には上のすべてのホストに対する障害とファイアウォール自体の障害の検知が通知され、対応する管理者にとって「余計な」情報が伝達されることになり、障害対応の妨げになりかねません。

　次にサーバA、サーバBに対しての症状監視ですが、これらのホストのリモートアクセス環境がSSHで提供されていることを前提に、SSHのサービス稼働監視を行います。

　この設定には2つ意味があります。

1. SSHの稼働監視と外形監視の監視の状況の組み合わせによって発生した障害 がプロセスレベルなのか、OSレベルなのか判断する。
2. SSHの稼働監視をすることにより、障害対応にSSHによるリモートからのアクセスが可能かどうか障害発生時に知ることができる。

　同一サーバ上の関連しない複数のプロセスを監視すれば、片方に障害が発生した場合は落ちたプロセスの障害であると判断できますし、両方に障害が発生した場合は、大抵の場合OS上の問題であると判断できます。

　また、SSHは障害対応作業をするためのリモートアクセスを提供するサービスですから、これに障害が発生していた場合、OSが動いていてpingには反応したからといって、この時点でリモートからの障害対応が難しいことを意味することには変わりありません。

　症状監視としてこれだけ監視しておけば、とりあえず、

• ネットワーク機器の障害を依存関係を踏まえて監視
• サーバの障害に対し、プロセス・OSレベルの切り分けが障害発生時にある程度可能

　という監視ができますので、これらの設定をNagiosの設定ファイルに落としたものを例示します。

【hosts.cfg の例】

# テンプレート define host{         name                            generic-host   ; テンプレート名         notifications_enabled           1       ; 通知有         event_handler_enabled           1       ; イベントハンドラの有         process_perf_data               1       ; パフォーマンス情報を保存         retain_status_information       1       ; ステータス情報を保存         retain_nonstatus_information    1       ; ステータス情報以外を保存         max_check_attempts              20      ; ホストチェックの最大Retry回数         notification_interval           60      ; 障害発生から60分したら再通知         notification_period             24x7    ; 24x7で通知         notification_options            d,r     ; Down, Recover時に通知         register                        0       ; この設定がテンプレートであることを指定         } define host{         use                        generic-host         host_name                  router1         alias                      Router #1         address                    172.16.0.1         parents                    firewall1         check_command              check-host-alive         } define host{         use                        generic-host         host_name                  serverA         alias                      Server A         address                    172.16.0.9         parents                    switch1         check_command              check-host-alive         } define host{         use                        generic-host         host_name                  serverB         alias                      Server B         address                    172.16.0.10         parents                    switch1         check_command              check-host-alive         } define host{         use                        generic-host         host_name                  switch1         alias                      Switch #1         address                    172.16.0.15         check_command              check-host-alive         } define host{         use                        generic-host         host_name                  firewall1         alias                      Firewall #1         address                    192.168.0.2         parents                    switch2         check_command              check-host-alive         } define host{         use                        generic-host         host_name                  switch2         alias                      Switch #2         address                    192.168.0.3         check_command              check-host-alive         }

【hostgroups.cfg の例】

define hostgroup{   hostgroup_name  default   alias           DefaultGroup   contact_groups  admin-contactgroup   members         router1,serverA,serverB,switch1,switch2,firewall1   }

【contacts.cfg の例】

define contact {         name                            generic-contact         service_notification_period     24x7         host_notification_period        24x7         service_notification_options    w,u,c,r         host_notification_options       d,r         service_notification_commands   notify-by-email         host_notification_commands      host-notify-by-email         register                        0 } define contact {         use                             generic-contact         contact_name                    admin         alias                           Server Admin         email                           jji@atmarkit.co.jp         }

【contactgroups.cfg の例】

define contactgroup{         contactgroup_name       admin-contactgroup         alias                   admin-contactgroup         members                 admin         }

【services.cfg の例】

define service{         name                            generic-service        ; テンプレート名         notifications_enabled           1       ; 通知有         event_handler_enabled           1       ; イベントハンドラの有         process_perf_data               1       ; パフォーマンス情報を保存         retain_status_information       1       ; ステータス情報を保存         retain_nonstatus_information    1       ; ステータス情報以外を保存         is_volatile                     0       ; 通常サービスチェック         max_check_attempts              3       ; リトライ回数         normal_check_interval           5       ; 5分間隔でチェック         retry_check_interval            1       ; リトライ間隔         check_period                    24x7    ; 24x7でチェック           notification_interval           240     ; 障害発生から240分したら再通知          notification_period             24x7    ; 24x7で通知         notification_options            w,c,r   ; Warning, Critical, Recover時に通知         contact_groups                  admin-contactgroup         register                        0       ; この設定がテンプレートであることを指定 } # Service definition define service{         use                             generic-service         host_name                       router1         service_description             PING         check_command                   check_ping!100.0,20%!500.0,60%         } define service{          use                             generic-service         host_name                       switch1         service_description             PING         check_command                   check_ping!100.0,20%!500.0,60%         } define service{         use                             generic-service         host_name                       switch2         service_description             PING         check_command                   check_ping!100.0,20%!500.0,60%         } define service{         use                             generic-service         host_name                       firewall1         service_description             PING         check_command                   check_ping!100.0,20%!500.0,60%         } define service{         use                             generic-service         host_name                       serverA         service_description             HTTP         check_command                   check_http         } define service{         use                             generic-service         host_name                       serverA         service_description             SSH         check_command                   check_ssh         } define service{         use                             generic-service         host_name                       serverA         service_description             PING         check_command                   check_ping!100.0,20%!500.0,60%         } define service{         use                             generic-service         host_name                       serverB         service_description             POP         check_command                   check_pop         } define service{         use                             generic-service         host_name                       serverB         service_description             SMTP         check_command                   check_smtp         } define service{         use                             generic-service         host_name                       serverB         service_description             DNS         check_command                   check_dns         } define service{         use                             generic-service         host_name                       serverB         service_description             SSH         check_command                   check_ssh         } define service{         use                             generic-service         host_name                       serverB         service_description             PING         check_command                   check_ping!100.0,20%!500.0,60%         }

さらに詳細な監視と運用

　また、実際に設定可能かどうかは皆さんのシステムに依存するため、ここではアイデアだけを提示しますが、Nagiosが提供するHTTPのサービス稼働監視では、オプションで監視の対象とするURIとサーバからの応答に、一定の文字列が含まれているかどうかをチェック可能なため、テスト用のCGIなどを用意するなどで、監視ツールの一般的な利用ではできないような特殊な監視も実装可能です。

　例として、以下のPerlスクリプトによるCGIを挙げます。

【disktest.cgi】

#!/usr/bin/perl # # Disk test CGI Script my $msg  = "FAIL" ; my $test = "/var/log/test.txt"; if(open(TST,  "> ${test}")){         for(my $i = 0;$i < 64;$i++){             print TST "1234567890123456789012345678901234567890\n";         }         $msg = "SUCC"; } print "Content-type: text/plain\n\n"; print $msg . "\n";

　このスクリプトは非常に単純ですが、サーバのファイルシステムへの書き込みのみを明示的に行っているため、このスクリプトへの監視を、その応答へのチェック付きで行うことにより、簡単なディスク監視を実装できます。

　実はディスクへの監視は意外と難しく、通常はログ監視で、OSのエラーメッセージ中のディスクのエラーのパターンを検出するよう設定するのですが、ディスクのエラーはその性格上、一端で出すと大量にログを吐きます。このためログ監視で監視をすると大量に障害が検知してしまうため障害対応の妨げになりかねません。

　もちろん上のスクリプト例は完全ではありませんし、ディスク監視に限らず、このような監視を実装するためにはある程度の開発が必要になるため、すべてのケースで有効だとは思えませんが、効率の良い症状監視の例として挙げてみました。

　最後に、監視設計におけるもう1つの重要なポイントを挙げておきます。経験上どんなに詳細な監視を行ったとしても、監視では検知できない障害という最悪の状態は起こり得ます。このため、いったん監視ツールに設定を行った場合も、実際に起こった障害の経験や、システムへの変更などを踏まえて監視設計を再考して、より効率の良い監視運用に努めることが、当たり前の話ですがシステム監視の最も重要なポイントである点を忘れずに日々の運用に励んでください。

外形監視へ

2/2

Index　システム管理の鉄則
前編　Webサーバ周辺、これだけおさえれば、落ちても大丈夫？
後編　NagiosでWebサーバを頑丈にする方法
	外形監視の設計 　モデルシステムについて 　監視ツールについて 　どこから外形監視をするのか？ 　外形監視の設計
	症状監視の設計 　さらに詳細な監視と運用 　症状監視の設計

関連記事
	連載：監視を自動化するSNMP ネットワークを管理するプロトコル 連載：24×365のシステム管理 運用管理に必須のツール／コマンド群 書評：SNMPを使ったネットワーク管理に役立つ3冊

「Master of IP Network総合インデックス」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）