WAS虎の巻(運用管理編): 第1回「定常運用」

WAS虎の巻では、WebSphere Application Server(WAS)の概要や構成についてご紹介しています。今回から開始するWASの虎の巻(運用管理編)では、WASを利用したWebシステム基盤の運用管理について取り上げていきます。

運用管理編 第1回は「定常運用」です。Webシステム基盤の定常的な運用作業について、「起動・停止」、「ログ・メンテナンス」、「障害監視」、「性能監視」の4項目に分けてご説明します。

オリジナル文章公開日：2011年12月
オリジナル文章作者：橋本裕樹, 日本アイ・ビー・エム システムズ・エンジニアリング（株）

1 起動・停止

Webシステムは複数のシステムやミドルウェアが連携してサービスを提供していますので、ミドルウェアの起動・停止を行う際には、タイミングや順序についての考慮が必要になります。

この章ではWAS基盤環境におけるミドルウェアの起動・停止について、以下をご説明します。

• IBM HTTP Server(IHS)、WASの起動順序・停止順序
• IHS、WASの起動方法・停止方法

1-1 起動順序・停止順序

ミドルウェアの起動順序・停止順序は、ミドルウェア間やプロセス間の依存関係に基づいて決定します。連携している一連のミドルウェアの起動作業は、バックエンド・システムから実施することが一般的です。ミドルウェアの停止作業はその逆となり、フロントエンド・システムから実施することが一般的です。

例えば、WASからDB2やWebSphere MQを参照している場合、起動順序はDB2やWebSphere MQを起動した上でIHSとWASを起動する流れにし、停止順序はIHSとWASを停止した上でDB2やWebSphere MQを停止する流れにします。

上記ではIHSとWASを一括りにしましたが、IHS、WASは以下のような複数のプロセスで構成されており、これらのプロセスの起動順序・停止順序についても考慮が必要になります。

• IHSプロセス
• (IHS管理サーバー・プロセス)
• アプリケーション・サーバー・プロセス
• デプロイメント・マネージャー・プロセス
• ノード・エージェント・プロセス

図：IHS、WASを構成するプロセス

IHS、WASを構成するプロセスの起動は、管理する側から管理される側という順序で実施することが一般的です。停止はその逆となり、管理される側から管理する側という順序で実施することが一般的です。

IHS、WASの起動

1. デプロイメント・マネージャー・プロセス
2. ノード・エージェント・プロセス
3. アプリケーション・サーバー・プロセス
4. (IHS管理サーバー・プロセス)
5. IHSプロセス

IHS、WASの停止

1. IHSプロセス
2. (IHS管理サーバー・プロセス)
3. アプリケーション・サーバー・プロセス
4. ノード・エージェント・プロセス
5. デプロイメント・マネージャー・プロセス

なお、ノード・エージェント・プロセスはアプリケーション・サーバー・プロセスより先に起動していなければならないという、製品仕様上の制約がありますのでご注意ください。これはアプリケーション・サーバーの起動時に、ノード・エージェントのロケーション・サービス・デーモンが使用できる必要があるためです。

1-2 IHSプロセスの起動・停止

IHSの主なプロセスには、IHSプロセス、IHS管理サーバー・プロセスがあります。

IHSプロセスの起動・停止には、UNIX/Linux環境ではapachectlコマンド、Windows環境ではhttpd.exeコマンド(Windowsサービス)を使用します。IHSをデプロイメント・マネージャーの管理対象にしている場合は、WAS管理コンソールからIHSプロセスの起動・停止を行うことも可能です。

IHSプロセス：

IHS管理サーバーは、IHSをデプロイメント・マネージャーの管理対象として統合する構成において、IHSをノード・エージェント経由で管理しない場合に必要になります。主にIHSとWASを共存させない構成で使用します。
IHS管理サーバー・プロセスの起動・停止には、UNIX/Linux環境ではadminctlコマンド、Windows環境ではhttpd.exeコマンド(Windowsサービス)を使用します。

IHS管理サーバー・プロセス：

1-3 WASプロセスの起動・停止

WASの主なプロセスには、デプロイメント・マネージャー・プロセス、ノード・エージェント・プロセス、アプリケーション・サーバー・プロセスがあります。各プロセスの起動・停止にはWASコマンド行ツールを使用します。なお、管理セキュリティー機能を有効化している環境では、各プロセスを停止する際に認証のための管理ユーザー名とパスワードが必要になります。

デプロイメント・マネージャー・プロセスとノード・エージェント・プロセスが起動している状態であれば、WAS管理コンソールからアプリケーション・サーバー・プロセスの起動・停止を行うことも可能です。

デプロイメント・マネージャー・プロセス：

ノード・エージェント・プロセス：

アプリケーション・サーバー・プロセス：

Windows環境では、Windowsサービスを使用してデプロイメント・マネージャー・プロセスの起動・停止、ノード・エージェント・プロセスの起動・停止を行うように設定することも可能です。Windowsサービスへの登録にはWASService.exeコマンドを使用します。WASService.exeコマンドの詳細は下記の製品ドキュメントをご参照ください。

• WAS V7.0 Information Center - WASServiceコマンド（リンク切れ）
• WAS V8.0 Information Center - WASServiceコマンド（リング切れ → WAS V8.5 Documentation）

2 ログ・メンテナンス

Webシステムを構成するミドルウェアからは様々な種類のログが出力されます。どのようなログが出力されるかを理解し、業務要件や運用方針に照らし合わせて、それぞれのメンテナンス方法やメンテナンス・タイミング、必要な保管世代数を検討する必要があります。

この章ではWAS基盤環境におけるミドルウェア・ログのメンテナンスについて、以下をご説明します。

図：IHS、Webサーバー・プラグイン、WASから出力される主なログ

2-1 ログのメンテナンス方法

ログ・ファイルのメンテナンスには、ログ・ローテーションと保管世代管理という2つの作業があります。

ログ・ローテーション
ログ・ローテーションとは、一定の条件でログの出力先ファイルを新しいファイルへ切り替えることです。これにより、ファイルが肥大化することを防ぎ、ログの参照や管理を容易にします。新しいファイルへ切り替える条件には主に時間基準とファイル・サイズ基準があり、日次で切り替える、あるサイズに達したら切り替える、といった条件を設定します。

保管世代管理
保管世代管理とは、ログ・ローテーションで作成されたファイルを一定の条件で削除や退避し、管理することです。削除や退避する条件には主に時間基準とファイル数基準があり、3ヶ月間経過したものは削除する、直近の5ファイルのみ保持する、といった条件を設定します。

ミドルウェアが出力するログ・ファイルのすべてに対して、このようなログ・メンテナンス機能が提供されているわけではありませんので、独自にシェル・スクリプト等で実現する必要が生じる場合もあります。また、あえてミドルウェアが提供するログ・メンテナンス機能を無効化し、独自のシェル・スクリプトを使用して一斉にログ・メンテナンスを行っているというようなケースもあります。

2-2 IHSログのメンテナンス

IHSが出力する主なログには、アクセス・ログとエラー・ログがあります。
アクセス・ログにはIHSプロセスが処理したすべてのリクエストに関する情報が記録されます。エラー・ログにはIHSプロセスで発生したエラーに関する情報が記録されます。
アクセス・ログはアクセス量に比例してサイズが大きくなりますので、注意が必要です。アクセス量が多いシステムでは、1日のアクセス・ログが数GBものサイズになることもあります。

アクセス・ログとエラー・ログ：

デフォルト設定では、アクセス・ログとエラー・ログ、どちらもファイル・サイズに制限がなく、単一ファイルに出力され続けます。製品機能でログ・ローテーションを行う場合は、以下のようにIHS構成ファイル(httpd.conf)でrotatelogsプログラムを使用する設定を行います。

例：rotatelogsプログラムを使用して、日次でアクセス・ログとエラー・ログのログ・ローテーションを行う設定

# アクセス・ログの日次ログ・ローテーション設定
CustomLog "| /usr/IBM/HTTPServer/bin/rotatelogs -l
 /usr/IBM/HTTPServer/logs/access_log.%Y%m%d%H%M%S 86400" common
# エラー・ログの日次ログ・ローテーション設定
ErrorLog "| /usr/IBM/HTTPServer/bin/rotatelogs -l
 /usr/IBM/HTTPServer/logs/error_log.%Y%m%d%H%M%S 86400"

ただし、rotatelogsプログラムには保管世代管理の機能がありませんので、ログ・ローテーションで作成された古いファイルの退避や削除はシェル・スクリプト等で独自に行う必要があります。

例：rotatelogsプログラムを使用している環境で、最終更新日から30日が経過したアクセス・ログを退避、エラー・ログを削除するコマンド (UNIX/Linux環境)

# アクセス・ログ、エラー・ログの出力ディレクトリーへ移動
cd /usr/IBM/HTTPServer/logs
# 最終更新日から30日が経過したアクセス・ログを"/archive/access_log"ディレクトリーへ移動
find . -name "access_log.*" -mtime +30 -exec mv {} /archive/access_log \;
# 最終更新日から30日が経過したエラー・ログを削除
find . -name "error_log.*" -mtime +30 -exec rm -f {} \;

rotatelogs プログラムの詳細は下記の製品ドキュメントをご参照ください。

• rotatelogs - Piped logging program to rotate Apache logs

2-3 プラグイン・ログのメンテナンス

Web サーバー・プラグインが出力するログには、プラグイン・ログがあります。

プラグイン・ログには、Webサーバー・プラグインとアプリケーション・サーバー間での通信エラーなど、プラグイン・モジュールに関連するエラーの情報が記録されます。
デフォルトのログ・レベルは「エラー」に設定されており、正常時にログの出力はあまりありません。問題分析のために「トレース」といった詳細なレベルに設定すると、リクエスト毎に大量の情報が出力され、急速にファイル・サイズが大きくなる場合があります。

プラグイン・ログ：

プラグイン・ログにはログ・ローテーションや保管世代管理の機能がありませんので、必要に応じてシェル・スクリプト等で独自に行います。

例：手動でプラグイン・ログのログ・ローテーションを行い、最終更新日から30日が経過した保管ファイルを削除するコマンド (UNIX/Linux環境)

# プラグイン・ログの出力ディレクトリーへ移動
cd /usr/IBM/WebSphere/Plugins/logs/webserver1
# プラグイン・ログを保管用ファイルにコピー
cp -p http_plugin.log http_plugin.log.`date +%Y%m%d%H%M%S`
# プラグイン・ログのファイルの中身を消去
cat /dev/null > http_plugin.log
# 最終更新日から30日が経過した保管用ファイルを削除
find . -name "http_plugin.log.*" -mtime +30 -exec rm -f {} \;

2-4 WASログのメンテナンス

WASが出力する主なログには、JVMログ、プロセス・ログ、診断トレース・ログ、IBM保守ログ(アクティビティー・ログ)、初期障害データ・キャプチャー(FFDC)ログがあります。IBM保守ログ以外のログはJVMプロセス単位、つまり、デプロイメント・マネージャー、ノード・エージェント、アプリケーション・サーバーの単位で出力されます。

JVMログ
JVMログはSystem.outログとSystem.errログで構成されており、それぞれJVMのSystem.outストリームとSystem.errストリームが記録されます。

JVMログ：

デフォルト設定では、System.outログとSystem.errログ、どちらも1MBでログ・ローテーションが行われ、直近の5ファイルが保持されます。

例：JVMログのログ・ローテーションと保管世代管理に関する設定画面 (WAS V8.0環境)

ログ・ローテーションが行われると、それまでのJVMログは以下のような日時の付いたファイル名に変更されます。

ログ・ローテーション後のJVMログ：

プロセス・ログ
プロセス・ログは標準出力ログと標準エラー出力ログで構成されており、それぞれプロセスの標準出力ストリームと標準エラー出力ストリームが記録されます。
デフォルト設定では、正常時にログの出力はほとんどなく、プロセスの起動時に環境に関する情報が出力される程度です。ただし、冗長ガーベッジ・コレクション(GC)を有効化している場合は、GC毎の詳細情報(GCログ)がプロセス・ログに出力されます。具体的な出力先は、AIX、Linux、Windows環境では標準エラー出力ログとなり、Solaris、HP-UX環境では標準出力ログとなります。

プロセス・ログ：

プロセス・ログにはログ・ローテーションや保管世代管理の機能がありませんので、必要に応じてシェル・スクリプト等で独自に行います。

例：手動で標準エラー出力ログのログ・ローテーションを行い、最終更新日から30日が経過した保管ファイルを削除するコマンド (UNIX/Linux環境)

# プロセス・ログの出力ディレクトリーへ移動
cd /usr/IBM/WebSphere/AppServer/profiles/Custom01/logs/server1
# 標準エラー出力ログを保管用ファイルにコピー
cp -p native_stderr.log native_stderr.log.`date +%Y%m%d%H%M%S`
# 標準エラー出力ログのファイルの中身を消去
cat /dev/null > native_stderr.log
# 最終更新日から30日が経過した保管用ファイルを削除
find . -name "native_stderr.log.*" -mtime +30 -exec rm -f {} \;

診断トレース・ログ
診断トレース・ログには、製品コンポーネントの内部処理に関する詳細情報が記録されます。
デフォルト設定ではトレース・レベルが「*=info」に設定されており、基本的にログの出力はありません。問題分析のためにより詳細なレベルに設定すると、短時間に大量の情報が出力される場合があります。

診断トレース・ログ：

デフォルト設定では20MBでログ・ローテーションが行われ、直近の5ファイルが保持されます。

例：診断トレース・ログのログ・ローテーションと保管世代管理に関する設定画面 (WAS V8.0環境)

IBM保守ログ(アクティビティー・ログ)
IBM保守ログ(アクティビティー・ログ)には、JVMログに記録されるWAS関連メッセージと問題分析のための情報が記録されます。このログはノード上のJVMプロセス間で共用されており、1つのファイルに合わせて出力されます。
バイナリー・フォーマットのファイルであるため、内容の参照には専用のツールを使用します。主にIBMのサポート・センターや開発部門が問題分析を行う際に使用するログです。

IBM保守ログ：

IBM保守ログは指定されたサイズの単一ファイル内に循環出力されますので、ユーザーがログ・ローテーションや保管世代管理を行う必要はありません。WAS V7.0ではデフォルト設定で最大2MBのファイルが出力されますが、WAS V8.0ではデフォルト設定で無効化されており、ファイル自体が出力されません。

例：IBM保守ログの循環出力に関する設定画面 (WAS V8.0環境)

初期障害データ・キャプチャー(FFDC)ログ
初期障害データ・キャプチャー(FFDC)ログには、製品コンポーネントの内部処理で障害が発生した際に、関連するイベントやエラーの情報が自動収集され、記録されます。
主にIBMのサポート・センターや開発部門が問題分析を行う際に使用するログです。

初期障害データ・キャプチャー(FFDC)ログ：

デフォルト設定では出力から7日間経過したファイルは自動削除されますので、ユーザーがログ・ローテーションや保管世代管理を行う必要はありません。

3 障害監視

Webシステムに限らず、情報システムは様々な原因によって障害が発生する恐れがあります。重大な障害が発生しても適切に検知できるよう、発生し得る障害と影響を洗い出し、監視すべき対象と検知方法を検討する必要があります。

この章ではWAS基盤環境におけるミドルウェア障害の監視について、以下をご説明します。

• 障害監視の概要
• IHS、WASの主な監視対象プロセス
• IHS、WASの主な監視対象ログと検知条件例

3-1 障害の監視方法

基本的な障害監視の方法には、プロセス監視、ログ監視、サービス正常性(疎通)監視があります。

プロセス監視
プロセス監視では、監視対象のプロセスが存在するか、プロセスが使用するTCPポートがリッスンされているかを確認します。独自にシェル・スクリプト等で監視する場合は、OSの標準コマンドである、psコマンドやtasklistコマンド、netstatコマンドを定期的に呼び出して確認するような実装にします。

プロセスの監視方法：

ログ監視
ログ監視では、監視対象のログ・ファイルに予期しないエラーや例外が出力されていないかを確認します。ログ監視を行う場合は、ログ監視機能を提供する監視ソリューション製品を使用することが一般的です。独自にシェル・スクリプト等で監視する場合は、ログ・ファイルの更新内容をtailコマンドで常時取得し、検知条件に合致するメッセージの有無を確認するように実装します。

サービス正常性(疎通)監視
サービス正常性(疎通)監視では、実際にサービスが正常に提供されているかを確認します。アプリケーションそのものにダミーのリクエストを送るという方法や、正常性を確認するためのサーブレットを用意してリクエストを送るという方法で確認します。実際にリクエストを送ることで、プロセス監視やログ監視では検知が難しい、プロセス・ハングや全スレッド・ハングを検知できるようになります。

例：一定時間以内に正常なステータス・コードが返るかを確認するPerlスクリプト

#!/usr/bin/perl
use LWP::UserAgent;
# サービス正常性監視用URLとタイムアウト値を設定
my $url = 'http://localhost:9080/snoop';
my $tmout = 10;
# 設定されたサービス正常性監視用URLにアクセス
my $ua = LWP::UserAgent->new;
$ua->timeout($tmout);
my $res = $ua->get($url);
# 正常時：0、異常時：1のリターン・コードを返す
exit($res->is_success ? 0 : 1);

3-2 IHSプロセスの監視

IHSプロセスの監視を行う場合、UNIX/Linux環境ではhttpd、Windows環境ではhttpd.exeを監視対象にします。また、TCPポートのリッスン状況を監視する場合は、IHS構成ファイル(httpd.conf)のListenディレクティブで設定しているポート番号を対象にします。
Windows環境において、Windowsサービス経由でIHSを起動している場合は、scコマンドでサービスの状態を確認するという方法もあります。

IHSプロセスの監視：

なお、UNIX/Linux 環境でmod_cgidモジュール、mod_mpmstatsモジュールを使用している場合は、それぞれのモジュールに対して別途httpdプロセス(子プロセス)が作成されます。プロセス数を基準に監視を行う場合はご留意ください。

例：IHSプロセス数、80番ポートのリッスン状況を確認するコマンド (UNIX/Linux環境)

# IHSプロセス数を確認(IHS管理サーバーを除外)
ps -ef | grep -v 'grep' |grep -v 'admin.conf' | grep -c 'httpd'
# 80番ポートのリッスン状況を確認
netstat -an | awk '/LISTEN *$/ {print $4}' | grep -c '[^0-9]80$'

例：IHSのWindowsサービスの状態、80番ポートのリッスン状況を確認するコマンド (Windows環境)

REM IHS Windowsサービスの状態を確認
sc query "IBMHTTPServerV8.0"
REM 80番ポートのリッスン状況を確認
netstat -an | findstr /r /c:"TCP .*:80 .* LISTENING"

3-3 WASプロセスの監視

デプロイメント・マネージャー・プロセス、ノード・エージェント・プロセス、アプリケーション・サーバー・プロセスの監視を行う場合、UNIX/Linux環境ではjava、Windows環境ではjava.exeを監視対象にします。また、TCPポートのリッスン状況を監視する場合は、Webコンテナー・トランスポート・チェーンで設定しているWCInboundDefault、WCInboundDefaultSecureのポート番号を対象にします。

WASプロセスの監視：

デプロイメント・マネージャー・プロセス、ノード・エージェント・プロセス、アプリケーション・サーバー・プロセスは、いずれもJVMプロセスであるため、それぞれを区別するにはプロセスのコマンドライン引数を確認する必要があります。デプロイメント・マネージャー・プロセスにはdmgr、ノード・エージェント・プロセスにはnodeagent、アプリケーション・サーバー・プロセスにはアプリケーション・サーバー名がコマンドライン引数に入ります。

なお、tasklistコマンドではコマンドライン引数が出力されませんので、Windows環境ではwmicコマンドの使用をご検討ください。

例：WASプロセスの存在、9080番ポートのリッスン状況を確認するコマンド (UNIX/Linux環境)

# WASのserver1プロセスの存在を確認
ps -ef | grep -v 'grep' | grep 'java' | grep -w 'WsServer' | grep -c 'server1'
# 9080番ポートのリッスン状況を確認
netstat -an | awk '/LISTEN *$/ {print $4}' | grep -c '[^0-9]9080$'

例：WASプロセスの存在、9080番ポートのリッスン状況を確認するコマンド (Windows環境)

REM WASのserver1プロセスの存在を確認
wmic process where "name='java.exe' and commandline like '%WsServer %server1%'"
 get processid
REM 9080番ポートのリッスン状況を確認
netstat -an | findstr /r /c:"TCP .*:9080 .* LISTENING"

その他に、WASコマンド行ツールのserverStatusコマンドを使用して、デプロイメント・マネージャー、ノード・エージェント、アプリケーション・サーバーの起動状態を確認するという方法もあります。ただし、serverStatusコマンドでは実行毎にJVMプロセスが起動されますので、psコマンドに比べると使用リソースが大きく、短い間隔での連続実行には適しません。

例：serverStatus コマンドを使用してサーバーの起動状態確認を行うコマンド (UNIX/Linux環境)

# WASコマンド行ツールの配置ディレクトリーへ移動
cd /usr/IBM/WebSphere/AppServer/profiles/Custom01/bin
# serverStatusコマンドでserver1の起動状態を確認
./serverStatus.sh server1

3-4 IHSログの監視

IHSのログ監視では、主にエラー・ログを監視対象とし、検知条件としてログ・レベルが一定以上のメッセージを設定します。

IHSログの監視：

なお、ユーザーが存在しないファイルをリクエストした際にもエラー・レベルのメッセージが出力されますので、検知条件に"[error]"を含める場合は"File does not exist"という文字列が含まれるメッセージを除外するなど、工夫が必要になります。また、rotatelogsプログラムを使用している場合は、監視対象ログのファイル名が固定ではなくなりますので注意が必要です。

アクセス・ログを監視対象とする場合は、500番台のステータス・コードを検知するという方法が考えられます。

3-5 プラグイン・ログの監視

Web サーバー・プラグインのログ監視では、プラグイン・ログを監視対象とし、検知条件としてログ・レベルが一定以上のメッセージを設定します。プラグイン・ログには、Webサーバー・プラグインがアプリケーション・サーバーの異常を検知した際のエラー情報も記録されますので、プラグイン・ログの監視によってアプリケーション・サーバーの障害を早期に検知できる場合があります。

プラグイン・ログの監視：

なお、レスポンスが返る前にユーザーがWebブラウザーを閉じた際に、接続が切断されたことによるエラー・レベルのメッセージが出力されることがあります。このようなサービスに影響がないメッセージは適宜除外する必要があります。

3-6 WASログの監視

WASのログ監視では、主にJVMログ(System.outログ)を監視対象とし、検知条件としてイベント・タイプが一定以上のメッセージを設定します。また、一定時間以上アクティブな状態のスレッドが存在した場合に出力されるメッセージのメッセージIDを検知条件に含めることで、スレッド・ハング発生の可能性を検知するということも可能です。

WASログの監視：

JVMログ監視の妨げとならないよう、アプリケーション・ログはJVMログに出力しないようにすることが望ましいです。

4 性能監視

Webシステムのリソースやパフォーマンスに関する情報は多岐にわたります。性能監視を検討する際には、どのような目的でモニタリングするのかを明確にしておくことが重要になります。また、同じ情報を複数の方法で取得できる場合も多いため、それぞれの方法の特徴や出力形式を理解し、最適な方法を選択ください。

この章ではWAS基盤環境におけるシステム性能の監視について、以下をご説明します。

• ハードウェアの主なモニタリング項目と取得方法
• IHS、WASの主なモニタリング項目と取得方法

4-1 ハードウェア性能情報のモニタリング

ハードウェアのモニタリングでは、主にプロセッサー、メモリー、ディスクに関する使用率や使用量を取得します。これらの情報はOS標準のコマンドやツールを使用して取得することが可能です。
独自にシェル・スクリプト等でモニタリングする場合は、定期的にコマンドを呼び出し、整形してファイル等へ出力するような実装にします。

ハードウェアの主なモニタリング項目と取得方法：

4-2 IHS性能情報のモニタリング

IHSのモニタリングでは、主にスレッド処理状況、スループット、リクエスト処理時間を取得します。

IHSの主なモニタリング項目と取得方法：

スレッド処理状況を取得するには、mod_statusモジュールを使用する方法とmod_mpmstatsモジュールを使用する方法があり、どちらもIHS構成ファイル(httpd.conf)で設定を行います。
mod_statusモジュールではHTTPでサーバーに直接アクセスして情報を取得する必要があることに対し、mod_mpmstatsモジュールでは一定間隔でエラー・ログに情報が記録されます。スレッドの処理状況を常時取得する目的であれば、mod_mpmstatsモジュールの使用をご検討ください。

例：mod_statusモジュールによるスレッド処理状況出力

例：mod_mpmstats モジュールによるスレッド処理状況出力

[Sat Dec 03 22:45:06 2011] [notice] mpmstats: rdy 61 bsy 64 rd 1 wr 4 ka 0 log 0
 dns 0 cls 59
[Sat Dec 03 22:45:06 2011] [notice] mpmstats: bsy: 4 in mod_was_ap22_http.c
[Sat Dec 03 22:55:06 2011] [notice] mpmstats: rdy 154 bsy 171 rd 71 wr 23 ka 0 log 0
 dns 0 cls 77
[Sat Dec 03 22:55:06 2011] [notice] mpmstats: bsy: 22 in mod_was_ap22_http.c

mod_statusモジュール、mod_mpmstatsモジュールの詳細は下記の製品ドキュメントをご参照ください。

• mod_status
• mod_mpmstats

アクセス・ログにはリクエストを受け付けた日時が記録されますので、単位時間あたりのログ出力行数からスループット(HTTPトランザクション数/秒)を算出できます。
リクエスト処理時間はデフォルト設定ではアクセス・ログに記録されません。必要に応じて、リクエスト処理時間が記録されるようにLogFormatディレクティブで設定を行います。

例：LogFormatディレクティブにリクエスト処理時間(マイクロ秒)を意味する"%D"を追加

LogFormat "%h %l %u %t \"%r\" %>s %b %D" common

例：アクセス・ログに記録されたリクエストの処理時間(マイクロ秒)

192.168.0.1 - - [04/Dec/2011:00:26:14 +0900] "GET /images/notes.gif HTTP/1.1" 200 170 5754 
192.168.0.1 - - [04/Dec/2011:00:26:14 +0900] "GET /images/support.gif HTTP/1.1" 200 150 10404 
192.168.0.1 - - [04/Dec/2011:00:26:14 +0900] "GET /images/background.gif HTTP/1.1" 200 183099 38375 
192.168.0.1 - - [04/Dec/2011:00:26:14 +0900] "GET /images/foreground.gif HTTP/1.1" 200 53680 39095

LogFormatディレクティブの詳細は下記の製品ドキュメントをご参照ください。

• mod_log_config

4-3 WAS性能情報のモニタリング

WASのモニタリングでは、主に各スレッド・プールの使用状況、コネクション・プールの使用状況、アクティブなHTTPセッション数、Javaヒープの使用状況、ガーベッジ・コレクション(GC)の状況を取得します。

WASの主なモニタリング項目と取得方法：

WASの各種コンポーネントの性能情報は、Performance Monitoring Infrastructure(PMI)と呼ばれるモニタリング用インターフェースを経由して取得することができます。取得対象とする項目はPMIの設定画面にて、「基本」、「拡張」、「全て」、「カスタム」の統計セットから選択します。

Tivoli Performance Viewer(TPV)は、このPMIを使用して性能情報を表示、収集するためのツールです。TPVはWAS管理コンソールに統合されていますので、Webブラウザーで管理コンソールを参照できる環境があれば使用できます。また、TPVはリアルタイムの性能情報を表示するだけではなく、ファイルに記録する機能も提供しています。

例：PMIで取得対象とする項目の設定画面 (WAS V8.0環境) (WAS管理コンソール：[モニターおよびチューニング]>[Performance Monitoring Infrastructure (PMI)]> [<サーバー名>]>[カスタム])

例：TPVによる性能情報のモニタリング画面 (WAS V8.0環境) (WAS管理コンソール：[モニターおよびチューニング]>[Performance Viewer]>[現行アクティビティー]>[<サーバー名>])

WAS虎の巻(運用管理編) 第1回では「定常運用」についてご説明しました。次回は「不定期運用」についてご説明します。

→ この連載の他の回へ