Webサーバの24×365監視を実現する 〜その1 - 何を監視すればいいのか？〜：24×365のシステム管理（4）
昨今のインターネット時代、企業活動におけるWebサイトの重要性は、もはやこの場で説明するまでもないでしょう。そこでは、Webサーバの24時間365日稼働の実現が求められています。今回から数回にわたり、Webサーバ監視におけるポイントを紹介していきます。まずは、Webサーバで監視すべき項目や、監視の前に必要な事項をリストアップすることからはじめていきましょう。（編集局）
「Webサーバを監視しなければらない」と言われて、Webサーバの何を監視すればいいのか即座に思い浮かべられるだろうか。連載の第2回「Webサーバの障害をいかに切り分けるか」では、“Webサーバに障害が発生した場合”の原因を特定する方法を中心に解説したが、定常的な監視（作業の自動化）については、概要のみにとどまってしまった。そこで、今回はWebサービスの障害を自動で検知するため、定常的な監視設定に主眼をおいて解説する。
■Webサーバに設定する監視項目
Webサービスを提供しているサーバを定常的に監視するためには、次のような項目を監視する必要がある。
- 特定のURLでコンテンツへアクセス
- ネットワーク・トラフィックの監視
- アクセス・ログの監視
- エラー・ログの監視
- ディスク容量の監視
これらの監視を適切なタイミングで実行し、その監視結果を適切な閾（しきい）値と比較することによって、次のようなシステム・トラブルを検知することができる。
- サービス・ダウン
- パフォーマンスの低下
- エラーの増大
このように常にシステム全体の状態を把握し、システム・トラブルのおおよその原因が分かっているのであれば、素早いトラブルの検知と対応が可能になる。トラブル検出後の障害の切り分けに関しては、連載の第2回「Webサーバの障害をいかに切り分けるか」を参照してほしい。
■実際にコンテンツにアクセスする
Webサーバを管理するにあたって最も重要なことは、Webのサービスが正常に稼働しているか確認することである。Webサービスの正常な稼働とは、そのWebサーバで提供しているすべてのコンテンツが正しく表示されることを意味する。サービスの稼働を検査するには、実際に監視対象となるコンテンツにアクセス（HTTPで情報をGET）することからはじまる。
コンテンツにアクセスして確認することは、次の内容である。
- 目的のコンテンツに到達できるか
- 目的のコンテンツに到達するのにどの程度の時間がかかるか
- コンテンツをすべて読み出すのにどの程度の時間がかかるか
- コンテンツの内容は正しいか
●サービスの稼働
最初に確認するのは、指定したURLで目的のコンテンツに到達できるかどうかである。もし目的のコンテンツに到達できない場合、「指定したURLが間違っている」「名前解決ができない」「対象となるWebサーバの存在を確認できない」などの理由が想定できる。
もちろん、実際にすべてのサービスを利用（特定のコンテンツにアクセス）して確認するのが理想だが、監視システムや監視対象のサーバなどにかかる負担が大きい場合、特に重要なページのみをチェックするように設定することになるだろう。検査するコンテンツの数が多ければ、その分だけ検査の精度は向上する。
●パフォーマンス
次に、目的のコンテンツに到達するのに要した時間および、内容をすべて読み出すのに要した時間を確認する。これらの時間は途中経路による外的要因に大きく左右されるが、それでも極端なパフォーマンスの変動には注意が必要である。必要以上にパフォーマンスが低下した場合はもちろん、極端にパフォーマンスが“向上”した場合にも確認すべきだろう。機材やインフラの整備など明確な理由がないにもかかわらず、極端にパフォーマンスが向上するということは、何らかの理由でそのサービスが利用されていないということを意味している。つまり、どこかで障害が発生している可能性を示唆しているのである。
コンテンツへのアクセスのトータル・タイムは、時間帯によって変動する。定期的にトータル・タイムを計測し、その値を24時間でグラフ化すると、監視の基本となる「ベースライン」ができる。連続して1週間ほど計測し、それぞれの時間帯での標準値を割り出すと、より信頼性の高いベースラインができる。このベースラインを基本にして、それぞれの時間ごとに、監視ツールがアラートを通知するための閾値を変動させると、非常に有用な監視ができる。問題はベースラインによる監視に対応した監視ツールが、ほとんどといっていいほど存在しないことである。筆者が知る限り、Agilent
Technologiesの「Firehunter」がベースライン監視に対応している。残念ながら、ベースライン監視機能を搭載したフリーの監視ツールは見たことがない。もし読者の中でこれらの機能を搭載したほかのツールをご存じの方がいたら、ぜひ教えていただきたい。
●内容の正確性
利用するコンテンツと同じデータと比較することで、監視対象のコンテンツの内容が正しいかを検査することもできる。コンテンツのデータ改ざんは、さまざまな問題を引き起こす深刻な攻撃である。もちろん、セキュリティを強化してこれらの攻撃を防ぐ必要はあるが、それでもすべての攻撃を防ぎきれる保障はどこにもない。そこで、定期的にすべての（あるいは一部の）コンテンツにアクセスして、それらの内容が改ざんされていない正しいデータであることを確認する必要がある。これらのチェックには、単純なリンク・ミスなどによって意図しないデータの表示を検出する効果もある。
また、動的なコンテンツの場合には、処理が正しく実行されているかも検査する必要があるだろう。ただし、動的な処理のあるコンテンツの改ざんや動作がチェックできる監視ツールは極めて少なく、自分自身で専用のスクリプトなどを作成することになる。そのため、動的なコンテンツを抱える多くのサイトでは、これらのコンテンツの動作や改ざんを監視せずに運用している。
■ネットワーク・トラフィックを監視する
Webサーバのネットワーク・トラフィック監視では、Webサーバのネットワーク・インターフェイスのパケット流量を監視する。ネットワーク・トラフィックを監視する主な目的は、ネットワークの状態からシステム・パフォーマンスを判断するためであるが、同時にシステムの障害の検知や障害の切り分けに重要な情報となる。
ネットワーク・トラフィック監視では、主に次のような情報を収集する。
- ネットワーク・インターフェイスへのI/O
- 破棄パケット
- エラー・パケット
これらの情報を常に収集し、通常想定される以上のトラフィックが発生した場合に、監視ツールによってアラートを通知する。また、想定されるトラフィックの値を大きく下回る場合にも、同様にアラートを通知すべきである。システムやインフラの変更などの明確な理由がないにもかかわらず、極端にパケット流量が減少するということは、途中の経路に障害が発生している可能性を示唆している。このように、パケット流量に大きな変化を検知した場合、その原因を究明するためにアクセス・ログやエラー・ログを確認する。
アラートを通知する基準となる閾値は、普段のトラフィックの状態から想定する必要がある。トラフィックの流量は時間帯によって変化する。コンテンツ・アクセスのトータル・タイムの監視についての部分でも述べたように、ネットワーク・トラフィックの監視でもベースラインによる閾値の設定が理想である。
ネットワーク・トラフィックの監視は、監視対象となるシステムに監視エージェントを導入し、SNMPなどによって監視システムに情報を通知する方法が一般的である。
■ログを監視する
サービスの稼働監視で重要になるのは、「アクセス・ログ」と「エラー・ログ」の2種類である。アクセス・ログはその名前の示すとおりサービスへのアクセスを記録したログ・ファイルであり、エラー・ログはシステム内で発生したエラーを記録したログである。
ログの監視には、単純にログ・ファイルのサイズをチェックするログ容量の監視と、ログの内容を常に参照して特定の文字列を検知した場合にアラートを通知する監視の2種類がある。定常的な監視ではログ容量だけを監視し、一定時間に想定される以上の（あるいは想定されるよりも著しく下回る）ログが記録された場合にアラートを通知する監視を行えば、十分対応できるだろう。ただし、特定のエラーを常に気にしなければならない場合は、エラー・ログから特定のエラー文字列を検出した際にアラートを通知するように設定することになる。
どちらの監視を設定するかは、監視運用のポリシーを策定するタイミングで決定する。どちらの監視を設定しても常にログ・ファイルを監視しなければならないため、監視対象のシステムに監視エージェントを導入し、SNMPなどで監視システムに通知する方法が一般的である。
■ディスク容量を監視する
CPUやメモリの使用率と異なり、ディスクは明示的にデータを削除しない限り、消費され続けてしまうリソースである。そのため、システムリソースの中でもディスク容量は非常に重要な監視項目である。
フォームなどを経由してユーザーからデータを収集したりするようなコンテンツであれば、ディスクの容量は常に監視する必要がある。また、データ収集などの処理を実行していない場合でも、大量のアクセス・ログやエラー・ログでディスクを圧迫してしまう可能性がある。これらの問題を回避するためには、ディスクの容量を常に監視し、収集したデータのバックアップなど、運用ポリシーを明確に策定しておかなければならない。
■監視運用ポリシーの策定／監視項目の決定
実際に監視運用ポリシーを策定するにあたって、どのような事柄を検討すればいいのだろうか。何を監視しなければならないかは、提供するサービスのクオリティなどに大きく左右される。また、システム的に許容できる“監視することによる負荷”は、コンテンツの内容の複雑さや、現状のシステム・リソースから想定するしかない。それらを考慮して次のような項目を検討する。
●どのコンテンツにアクセスするか
実際に監視対象として検討している各コンテンツへ手動でアクセスし、概算で構わないので所要時間（トータル・タイム）を調べる。さらにネットワークの帯域やWebサーバのシステム構成などをあわせて検討し、実際にアクセスするコンテンツを決定する。
さらに、内容の改ざんなどコンテンツの比較を実行する場合には、監視システムが許容できるかをテストしてから設定しなければならない。監視システムがどの程度の処理を許容できるかは、実際に負荷実験を実行しなければ正確な値は分からないので、最初から多くの監視項目を設定するのは避けた方がいいだろう。
●パフォーマンス監視の閾値の設定
コンテンツ・アクセスのトータル・タイムやネットワーク・トラフィックなどのパフォーマンスを監視する場合には、現状のパフォーマンスを1週間程度計測し、その結果を平均して策定する。これらのパフォーマンス監視は、ベースラインによる閾値の設定が望ましいことは繰り返し述べたが、実際に対応した監視ツールはほとんど存在しない。そのため、監視ツールの仕様が許すのであれば、1つの監視対象を複数の監視項目として設定し、監視タイミングを時刻によって調整するという方法が考えられる。また、閾値を「〜以上かつ、〜以下」のように範囲指定できるツールを選択したい。
●ログの確認
コンテンツへのアクセスや、パフォーマンス監視などが充実しているのであれば、無理にログ・ファイルを定常的に監視する必要はない。ログが非常に重要な役割を果たすのは、障害発生時に原因を特定する場合である。しかし、システムがダウンする前に異常なアクセスの増大やエラーの続発などをリアルタイムで確認できれば、致命的な障害に発展する前に対応することができる可能性もある。これらを考慮して、監視運用しなければならないWebサーバで、どの程度ログ監視が必要なのかを検討する。
■監視運用手順の確立
監視する項目、閾値、監視間隔が決定すれば、次にアラートが発生した場合の対処について検討する必要がある。設定するアラートのレベルが“障害発生”であれば、障害対応手順を決定し、障害対応マニュアルや、障害対応ログのフォーマットなどを作成する。また、障害発生の前に“警告”レベルのアラートを設定するのであれば、警告アラートの通知を受けてから、システムの何を注意して監視しなければならないのかを明確にしておかなければならない。
これらの監視運用手順の策定をおざなりにすると、どれだけシステム監視を詳細に設定しても安定稼働はおぼつかない。最初から詳細に手順を策定することが難しいのであれば、障害対応の記録だけでも必ず毎回詳細に残しておくようにする。障害が発生するたびにログを残すことで障害対応のノウハウが蓄積され、有効で無理のない監視手順や、障害対応マニュアルを作成できるようになる。もちろんそのためには、障害が発生するたびに問題点を検討して、次回につなげていくという姿勢が重要である。
次回は、HTTPのサービス稼働監視、ネットワーク・トラフィック監視、ディスク使用率の監視を、実際のフリーの監視ツールで監視する設定について解説する予定である。
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。