症状監視でまず考えるのはネットワークレベルでの到達性の監視です。このため、まずは以下に対してpingによる到達性の監視を行います。
ここで気を付けなければならないことは、監視ツールがDMZのセグメントに設置してあるため、ルータ、社内用スイッチはファイアウォール越しにpingによる到達性チェックをすることになります。従って、ファイアウォールの設定で、これらのパケットに対するフィルタを開けるようにしなければ正しく監視できないので注意してください。
もし、ファイアウォールの仕様上、どうしてもpingによる到達性チェックができない場合は、監視方法をSNMPによるポーリング監視に切り替えるなどの方法が考えられます。
Nagiosではホストに親子関係が指定でき、子のホストへの到達性がなくなった場合、親のホストへの到達性をチェックして、到達できない理由が、子のホストが停止したのか、それとも子のホストのあるネットワークへの到達性がなくなったのかを判断してくれます。
モデルシステムの場合、監視ツールは社内のセグメントに設置されているので、監視ツールが設置されているマシンから見て、ホストごとの依存関係は次のようなツリーになります。
この設定を行うことで監視ツールから送信される障害の通知を劇的に減らすことができます。
例えばファイアウォールが落ちた場合、Nagiosからは以下のホストへの到達性が失われます。
この設定がない場合、管理者には上のすべてのホストに対する障害とファイアウォール自体の障害の検知が通知され、対応する管理者にとって「余計な」情報が伝達されることになり、障害対応の妨げになりかねません。
次にサーバA、サーバBに対しての症状監視ですが、これらのホストのリモートアクセス環境がSSHで提供されていることを前提に、SSHのサービス稼働監視を行います。
この設定には2つ意味があります。
同一サーバ上の関連しない複数のプロセスを監視すれば、片方に障害が発生した場合は落ちたプロセスの障害であると判断できますし、両方に障害が発生した場合は、大抵の場合OS上の問題であると判断できます。
また、SSHは障害対応作業をするためのリモートアクセスを提供するサービスですから、これに障害が発生していた場合、OSが動いていてpingには反応したからといって、この時点でリモートからの障害対応が難しいことを意味することには変わりありません。
症状監視としてこれだけ監視しておけば、とりあえず、
という監視ができますので、これらの設定を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 }
define hostgroup{ hostgroup_name default alias DefaultGroup contact_groups admin-contactgroup members router1,serverA,serverB,switch1,switch2,firewall1 }
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 }
define contactgroup{ contactgroup_name admin-contactgroup alias admin-contactgroup members admin }
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を挙げます。
#!/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";
このスクリプトは非常に単純ですが、サーバのファイルシステムへの書き込みのみを明示的に行っているため、このスクリプトへの監視を、その応答へのチェック付きで行うことにより、簡単なディスク監視を実装できます。
実はディスクへの監視は意外と難しく、通常はログ監視で、OSのエラーメッセージ中のディスクのエラーのパターンを検出するよう設定するのですが、ディスクのエラーはその性格上、一端で出すと大量にログを吐きます。このためログ監視で監視をすると大量に障害が検知してしまうため障害対応の妨げになりかねません。
もちろん上のスクリプト例は完全ではありませんし、ディスク監視に限らず、このような監視を実装するためにはある程度の開発が必要になるため、すべてのケースで有効だとは思えませんが、効率の良い症状監視の例として挙げてみました。
最後に、監視設計におけるもう1つの重要なポイントを挙げておきます。経験上どんなに詳細な監視を行ったとしても、監視では検知できない障害という最悪の状態は起こり得ます。このため、いったん監視ツールに設定を行った場合も、実際に起こった障害の経験や、システムへの変更などを踏まえて監視設計を再考して、より効率の良い監視運用に努めることが、当たり前の話ですがシステム監視の最も重要なポイントである点を忘れずに日々の運用に励んでください。
Copyright © ITmedia, Inc. All Rights Reserved.