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

　エンタープライズ・モニタリングのつぼ（前編）では、ITインフラストラクチャーの屋台骨であるネットワークのモニタリングについて解説しました。中編では、「リソースとサーバ・ハードウェアリソースのモニタリング」を解説しました。

　前回、モニタリングの対象リソースを『ハードウェア』と『ソフトウェア』に分類し、サーバの「ハードウェアリソース」として、CPU、メモリ、ハードディスクなど、サーバに搭載されたハードウェアリソースを監視する技術と、RAIDやUPSなどの機構をオペレーティングシステムの状態に依存せずに独立して監視する技術を解説しました。

　後編ではさらに、サーバの「ソフトウェアリソース」として、サーバ上で稼働するアプリケーションの監視技術について解説します。

　サーバ上のプロセス監視に始まり、あたかもクライアントがサーバを使用しているかのようなシミュレートを行い監視する技法まで、多種多様な監視技術について実例を挙げてご紹介します。最後に、ご紹介したモニタリング技術を監視製品が実装するときの付加機能、すなわち、システム監視として運用する観点で、利便性を上げる機能やシステム品質を向上させるための機能について特徴を解説します。

サーバ・ソフトウェアリソースのモニタリング

　オペレーティングシステム、ミドルウェア、アプリケーションは、サーバのソフトウェアリソースです。ソフトウェアリソースのモニタリングは、サーバ機上で検知処理を実行する方法と、クライアントからのアクセスをシミュレートする方法に大別されます。

　以下にソフトウェアリソースの代表的なモニタリング手法をまとめます。

オペレーティングシステムのモニタリング

　オペレーティングシステムは、UNIX／Linuxのsyslog、Windowsのイベントログにさまざまな情報を記録します。

Jan 9 11:42:57 betatmr 
su: from root to nobody at /dev/pts/2
Jan 9 11:43:07 betatmr su: BAD SU from nobody to root at /dev/pts/2
Jan 9 12:22:50 betatmr sendmail[6968]: My unqualified host name (betatmr) 
unknown; sleeping for retry
Jan 9 12:23:12 betatmr no[8354]: Network option tcp_keepcnt was set 
to the value 0
Jan 9 12:23:12 betatmr syslog: /usr/sbin/ifconfig -l
Jan 9 12:23:50 betatmr sendmail[6968]: unable to qualify my own domain 
name (betatmr) -- using short name
Jan 9 12:23:51 betatmr sendmail[6968]: starting daemon (AIX5.2/8.11.0): 
SMTP+queueing@00:30:00
Jan 9 12:23:59 betatmr syslog: pts/0: failed login attempt for root 
from 9.170.15.163 

画面1　Windows2000 イベントログの例

　ハードウェアリソースのモニタリングでも紹介しましたが、syslogやWindowsのイベントログには、システム構成が変更されたことを通知するメッセージや、アプリケーション処理の成功や失敗、UNIX/Linux環境でのCOREダンプ、Windowsのアクセス保護違反など、オペレーティングシステムが検知したプログラム障害情報なども記録されます。これらのメッセージは、オペレーティングシステムのモニタリング対象として検討するべきものになります。

ミドルウェアのモニタリング

　昨今、ミドルウェアの定義は一様ではありませんが、ITアプリケーションを支えるミドルウェアとしては、RDBMS（リレーショナル・データベース管理システム）やTP（トランザクション処理）／MQ（メッセージキューイング）などがあります。さらにWebサーバやグループウェアもミドルウェアとして位置付ける場合があります。

　ミドルウェアは一般に、それぞれが独立したアプリケーションです。それらがマルチプラットフォーム環境で稼働し、ユーザーアプリケーションの開発／稼働の前提ソフトウェアとして汎用的に利用されるようになったことで、ミドルウェアに対するモニタリング技法も汎用的な方法が定着してきているといえます。

　ミドルウェアのモニタリングは、ミドルウェアが提供する機能が正常に稼働していることをチェックし、障害の予兆を検知することが目的です。例えばRDBMSであれば、テーブルやバッファプール使用率やインスタンス情報、デッドロック情報など、データベースの稼働状況を一定の数値の範囲＝閾（しきい）値で判別します。

　TPやMQ、Webサーバなどの場合は、トランザクション数、キューの長さ、HIT数など、リクエスト数とその増減傾向を計測する方法に加え、一定の応答時間基準を満たしていることを確認する方法が取られることがあります。サーバ内部のレスポンスを計測するために、サーバに計測専用のエージェントを入れたり、サーバログからレスポンスを計測するためのツールを開発したりすることもあります。

　ブラウザベースのアプリケーションの場合、ユーザーの応答時間という観点で、ネットワーク経由でブラウザアクセスをシミュレートするようなツールを利用することもあります。どのモニタリング手法についても、障害やパフォーマンス劣化を未然に検知するため、一定のインターバルで検知処理を実行し、障害になる前に問題を取り除くことを第1の目的としています。

アプリケーションのモニタリング

図4　プロセスとログファイルを監視する
※ 黄色の記号図はプロセスやログファイルを表しています

　アプリケーションのモニタリングにはプロセス監視とログファイル監視という２つの伝統的手法があります。

●コマンドによる監視

　プロセス監視と呼ばれる手法は、UNIX/Linuxの場合、psコマンドに相当する方法でプロセスの死活を監視します。Windowsの場合、“net start”コマンド相当で確認することができるWindowsサービスの死活を監視します。プロセス監視は、常駐するべきものがダウンしたことを検知させる目的のほか、例外時だけ使われるプロセスの起動検知、同じプロセス名のプロセス数監視、あるいは特定プロセスが使用するCPUやメモリの使用率監視など、アプリケーション特性によりいくつかの代表的な監視技法があります。

●ログファイルでの監視

　もう1つはアプリケーションのログファイル監視です。ログファイルに特定の状況を表すメッセージが書き込まれたら、それを検出する技法です。検出のキーとなるパターンは、エラーIDや特定の文字列です。モニタリングを実装する際には、あらかじめアプリケーション担当者にこれらの「通知するべきメッセージ」を洗い出していただき、ログに書き込まれるフォーマットをバイト単位で寸分なく提示していただくことが重要です。

●クライアントのシミュレート

　さらに、各アプリケーションが間違いなく稼働しているかを確かめるためには、ネットワーク、オペレーティングシステム、ミドルウェア、アプリケーションすべてが関係する処理を実際のクライアントアクセスをシミュレートした形で実行させる方法が有効です。例えばWebベースの受発注システムで、疑似アカウントを作成し、クライアントPCから実際の受発注取引を繰り返し実行するような方法があります。

　この方法は、クライアントPC側にブラウザアクセスをシミュレートするプログラムを導入し、それを利用して一連のブラウザ操作を記憶させ、シナリオに従ってそれを実行させる技法を使います。これによりアカウントの認証、システムへのリクエスト投入、トランザクション生成、受発注データによるデータベース更新の成否を確認することができ、さらに一連の処理の応答時間まで計測することができます。

図5　擬似クライアントアクセスで関連する一連の処理状況をチェック
※ 黄色の記号図はプロセスやログファイルを表しています

セキュリティのモニタリング

　インターネットと接続されたシステムでは、一定のセキュリティ基準が守られていることを監視する必要があります。今回のテーマからは若干それますが、統合的なモニタリングシステムを構築する観点でセキュリティ監視は避けては通れないテーマのため、どのようなものを対象にモニタリングするべきかを簡単に説明します。

　リソースという切り口でいうと、監視するべきセキュリティリソースはお客さま固有です。ユーザーID情報、ウイルス侵入予防、不正アクセス予防など、セキュリティ監視の目的によりリソースが異なります。これらは一般に、ネットワークセキュリティ管理、ユーザー管理、リソースアクセス制御、ウイルス対策といった手法により、一定のセキュリティ基準をシステム的に制定し、その基準に違反する事象を検知できるようにしています。