NagiosでWebサーバを頑丈にする方法特集:システム管理の鉄則(後編)(2/2 ページ)

» 2004年04月02日 00時00分 公開
[鳴滝光二@IT]
前のページへ 1|2       

症状監視の設計

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# テンプレート 
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
        } 
【hosts.cfg の例】
define hostgroup{
  hostgroup_name  default
  alias           DefaultGroup
  contact_groups  admin-contactgroup
  members         router1,serverA,serverB,switch1,switch2,firewall1
  } 
【hostgroups.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
        } 
【contacts.cfg の例】
define contactgroup{
        contactgroup_name       admin-contactgroup
        alias                   admin-contactgroup
        members                 admin
        } 
【contactgroups.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%
        } 
【services.cfg の例】

さらに詳細な監視と運用

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

 例として、以下のPerlスクリプトによる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 
            print TST "1234567890123456789012345678901234567890\n";
        }
        $msg = "SUCC";
}
print "Content-type: text/plain\n\n";
print $msg . "\n"; 
【disktest.cgi】

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

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

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

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

前のページへ 1|2       

Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

AI for エンジニアリング
「サプライチェーン攻撃」対策
1P情シスのための脆弱性管理/対策の現実解
OSSのサプライチェーン管理、取るべきアクションとは
Microsoft & Windows最前線2024
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。