「WebLogicにはログが多く、どのファイルから見ればよいか分からない」
「エラーは見つけたが、アプリと基盤のどちらが原因か切り分けられない」
WebLogicを使うシステムでは、アプリケーションの実行状態、JDBC接続、スレッド、デプロイ、クラスタなど、多くの情報がログに記録されます。
ただし、ERRORという文字を検索するだけでは十分ではありません。起動時の過去エラーや、今回の事象とは関係のない警告も含まれるため、対象時刻、対象処理、実行ノードを先に絞る必要があります。
銀行システムの保守では、同じアプリケーションでも特定のManaged Serverだけで問題が起きることがあります。アクセスログとサーバログを関連付けると、ノード固有の問題を切り分けやすくなります。
この記事では、WebLogicログを調べる順番と、若手SEが押さえたい確認ポイントを解説します。
WebLogicログは「到達・実行・基盤状態」の順で確認する
まずリクエストがWebLogicへ到達したかをアクセスログで確認し、次にサーバログやアプリケーションログで処理結果を追い、最後にJDBC、スレッド、メモリなど基盤状態を確認します。
環境によってログ名や出力先、ローテーション方式が異なるため、具体的なファイル名は運用設計書とWebLogic設定で確認してください。
| ログ・情報 | 確認できること | 主な切り分け |
|---|---|---|
| アクセスログ | URL、時刻、HTTPステータス、応答時間 | WebLogicまで到達したか |
| サーバログ | 状態変化、JDBC、スレッド、デプロイ、クラスタ | 基盤側の異常があるか |
| 標準出力・標準エラー | 起動メッセージ、アプリ出力、例外 | 実行時例外があるか |
| 管理画面・監視 | サーバ状態、ヒープ、接続プール、キュー | リソース枯渇があるか |
WebLogic障害調査の4ステップ
1．対象時刻と実行ノードを特定する
利用者の操作時刻、URL、利用者ID、リクエストIDを確認し、アクセスログで該当リクエストを探します。ロードバランサ配下では、どのManaged Serverへ振り分けられたかを特定します。
サーバ間の時刻差やタイムゾーンにも注意します。ログ時刻が一致しない場合は、監視時刻や他ログとのずれを記録して補正します。
2．アクセスログで到達と応答を確認する
アクセスログに対象リクエストがなければ、Webサーバ、ロードバランサ、ネットワークなど手前で止まった可能性があります。記録があれば、HTTPステータスと応答時間を確認します。
HTTP 500はWebLogic基盤だけでなくアプリケーション例外でも発生します。ステータスだけで原因を決めず、同時刻のサーバログとアプリログへ進みます。
- 対象URLとHTTPメソッド
- HTTPステータス
- 応答時間
- 送信元・利用者を特定できる情報
- 処理したManaged Server
3．サーバログで前後の状態変化を追う
対象時刻のエラーだけでなく、その直前にあるWarning、デプロイ、接続切断、サーバ状態変化を確認します。後続の例外は、先に起きたリソース不足の結果かもしれません。
メッセージID、例外クラス、スタックトレースの最初の原因箇所を記録します。同じメッセージが他ノードでも出ているか比較します。
- JDBC接続プールの枯渇・接続失敗
- スタックスレッドやキュー滞留
- OutOfMemoryErrorやGC長時間化
- デプロイ状態・アプリ停止
- クラスタ通信・ノード離脱
4．正常ノードと比較して切り分ける
クラスタ構成では、異常ノードと正常ノードの設定、デプロイ版、接続先、起動時刻、負荷を比較します。特定ノードだけなら、アプリ共通ロジックよりノード固有設定やリソース状態を疑いやすくなります。
比較結果は、同じ項目・同じ時刻範囲で並べます。条件の違うログを比べると誤判断につながります。
【比較メモ】 対象時刻：10:14:30～10:16:00 異常ノード：ms1／HTTP 500／JDBC待機増加 正常ノード：ms2／HTTP 200／JDBC待機なし デプロイ版：同一 接続先DB：同一 直前変更：ms1のみ再起動実施
WebLogicログ調査メモのテンプレート
見つけたエラーを貼り付けるだけでなく、対象処理との関係が分かる形で残します。
【対象】 発生日時： URL・処理名： 利用者ID・リクエストID： Managed Server： 【アクセスログ】 HTTPステータス： 応答時間： 【サーバログ】 メッセージID： 例外・スタックトレース： 直前の警告・状態変化： 【比較】 他ノードの状況： 正常時との差： 仮説と未確認事項：
パスワード、トークン、個人情報などがログに含まれる場合は、共有先とマスキングルールを守ります。
よくある失敗と改善方法
| 失敗 | 起こる問題 | 改善方法 |
|---|---|---|
| ERRORだけを検索する | 前段の警告や状態変化を見落とす | 対象時刻の前後を時系列で読む |
| HTTP 500を基盤障害と断定する | アプリ例外との切り分けを誤る | サーバログとアプリログを関連付ける |
| 一つのノードだけを見る | ノード固有問題か共通問題か分からない | 正常ノードと同条件で比較する |
若手SE向けチェックリスト
- 対象時刻・URL・識別子を特定した
- アクセスログでWebLogicへの到達を確認した
- HTTPステータスと応答時間を確認した
- サーバログの前後を時系列で確認した
- JDBC・スレッド・メモリ・デプロイを確認した
- 正常ノードと異常ノードを比較した
- 機密情報をマスキングして共有した
まとめ：WebLogicログはリクエストとノードを軸に読む
WebLogicのログ調査では、すべてのログを読む必要はありません。対象時刻、対象処理、実行ノードを決め、アクセスログからサーバログへつなげます。
ログの意味や出力設定は環境差が大きいため、運用設計書と管理設定を平常時に確認しておくと、障害時の初動が速くなります。
- アクセスログで到達と応答を確認する
- サーバログはエラー直前の状態変化まで見る
- 正常ノードとの比較で切り分ける
コメント