サーバアプリケーションのモニタリングとは：エンタープライズ・モニタリングのつぼ（後編）（2/2 ページ）

» 2004年02月24日 00時00分公開

[岩村郁雄，日本アイ・ビー・エムシステムズ・エンジニアリング ]

監視製品の実装

　これまで説明したように、リソースの監視技法を適用することで、一定のロジックに従った「検知処理」が働き、リソースに何か起きたことが分かるようになります。モニタリング機能は検知処理に加えて、実際には検知した情報を伝達するための「通知処理」が有機的に連携して実現されます。

　通知処理は、事象を検知したマシンから監視が行われているマシンまで、検知事象を表す情報が伝達され、人が理解できる形で発生した事象を表現できればよいことになります。例えば、E-mail発行やrshなどのリモートコマンド、FTP、syslogポート連携などに代表される、遠隔マシンへデータを伝達する手段とそのフォーマットが整っていれば、ユーザーが手作りで開発するレベルであっても、検知情報を通知することができます。

　検知と通知機能について、システム監視製品での特徴を紹介します。

監視製品の検知技術

　監視製品が提供する検知機能には、一般的に次のような特徴があります。

●検知のための設定とその反映を一元的に実施する

　全国に設置された数百台のサーバマシンに対し、個々に検知設定を行う手間は計り知れません。監視製品は、リソースの種別と対象となるリソースが存在するサーバを論理的に分類した設定用のインターフェイスを提供し、効率よく設定作業ができる機能を提供します。また設定の反映も、監視製品が提供するクライアント・サーバ型の通信を利用して、一括一元的に行えるようになっています。

●対象サーバのプラットフォームの違いを意識せずに検知設定する

　UNIXのコマンド1つでも、AIX、Solaris、HP-UXでオプションや出力結果は異なります。監視製品はLinux、Windowsを含め、できる限り同一レベルの検知ができるよう、これらのプラットフォームの差異を緩和する実装が施されています。

●対象サーバのソフトウェアのバージョンアップに対応した検知機能を提供する

　対象サーバのオペレーティングシステムやミドルウェアは、適宜バージョンアップされます。監視製品はこれらのバージョンアップによる差異を吸収し、検知機能の上位互換性を提供します。

●クラスタ／ハイ・アベイラビリティー構成に対応した検知機能を提供する

　サービスの停止時間を最短にする目的で適用されるクラスタ構成やハイ・アベイラビリティー構成では、サービスを提供するサーバで検知した障害事象が通知できるとは限りません。これらの構成では、一方のダウンを検知して自律的にサービスが切り替わるという特別な処理が行われるため、監視製品もその推移に合わせた切り替えができるようになっている必要があります。　

監視製品の通知技術

　監視製品の通知機能は、製品によりさまざまです。例えばRAID、UPSのモニタリングで紹介した特定ハードウェア機構の管理用サーバでは、特定ハードウェアの状況だけが通知されればよいので、それだけを監視する目的の通知インターフェイスが提供されています。

　ここでは、システム管理製品の統合監視機能として一般的に提供されている通知機能の特徴をご紹介します。

●通知結果を一元的に集約する

　いろいろなリソースで検知された事象を、一定のフォーマットに整えたり、データを分割したりして一元的に集約する機能を提供します。通知事象を随時抽出するために、RDBMSに格納する製品も数多くあります。

●共通の基準で重大度が判別できるインターフェイスを提供する

　あらかじめ設定した一定の基準に従い、検知結果が一定の重大度データ付きで通知され、表示色や表示エリア、警告音などのユーザーインターフェイスにより状況が直感的に判別できるような機能を提供します。

●通知が失敗したときのイベントロストを防ぐための機能を提供する

　通知結果を収集する監視サーバも計画停止やメンテナンスを行うことがあります。SNMPのようにプロトコル的に到達確認ができない通知方法を採用している製品は、受信されなかった通知データはロストします。これに対し、TCPやアプリケーションとしての送達確認を実装し、送出した通知データが受信されない場合にロストしないような機能−−バッファリングと再送機能を提供する製品もあります。

●通知に伴い、追加のアクションが自動実行できる

　通知データの内容により、あらかじめ設定したアクションを自動実行する機能を提供します。例えば障害が通知されたら、一時復旧用のコマンドを発行し、ポップアップウィンドウを表示するなど、自動化によってサービス停止時間を最短にする方策を講じることができるようなります。

●複数の通知データを連携し、障害の根本原因を特定するためのロジックを実装できる

　例えばNFSサーバのネットワーク障害が通知された場合、その前後に発生したNFSクライアントからの接続エラー通知の根本原因はNFSサーバのネットワーク障害であることが推測できます。このような複数の通知データの相関関係を判断させるロジックを組み込み、例えばクライアントからの接続エラー通知データに、推測原因情報を付加したり、サーバネットワーク障害通知の重大度を上げてクライアントからの接続エラー通知の重大度を下げたりすれば、障害原因の特定を迅速化させることができます。

モニタリングの先に見えてくるもの

より高度なシステム管理へ

　3回にわたりモニタリングの実装技術をご紹介しましたが、これからのITシステムの方向性にモニタリング技術は欠かせないことが分っています。コンピュータシステムを構成するリソースを必要に応じ動的に割り当てるキャパシティーオンデマンドや、ネットワーク上に散在するサーバリソースを仮想化して利用するグリッド技術などの根底には、リソースをモニタリングした結果得られたデータが利用されています。

　また、モニタリングを行うことで、そのシステムが応答時間や処理効率などの一定のサービス目標を満たした状態で正常に稼働していることを判断できます。言い換えればサービスの品質を評価する基準を設定することで、サービス目標を満たすことができない原因を洗い出し、サービスのレベルを向上していくことができるようになります。

　モニタリングの先には、ITシステムの構成要素を柔軟に伸縮して使用できるITインフラ環境とそれを実現するためのプロビジョニング、システムのサービス品質を維持・向上させるためのサービスレベル管理といった、より高度なシステム管理のテーマが見えてきています。

3回でお伝えしたエンタプライズ・モニタリングのつぼはいかがでしたでしょうか。ご意見・ご感想をお待ちしております。

「次回」へ

「エンタープライズ・モニタリングのつぼ」バックナンバー