「ログが複数行・複数サーバに分かれ、同じ処理を追えない」
「スタックトレースのどこを見れば原因に近づけるのか分からない」
APサーバのアプリケーションログには、画面やAPIの受付、業務チェック、DBアクセス、外部連携、例外処理など、プログラムの流れが記録されます。
一方、複数利用者のログが同時に出力されるため、エラー文字列だけを検索すると、別リクエストのログを混ぜてしまうことがあります。
開発・保守の現場では、取引番号やリクエストIDを軸に一つの処理を時系列で追うことが、原因箇所を切り分ける近道です。正常時の同じ処理と比較できると、どの地点から差が生まれたかが分かります。
この記事では、APサーバログから処理の流れ、例外、遅延を調べる基本手順を解説します。
APサーバログは「一つの処理」を最後までつなげて読む
ログ調査では、対象時刻、処理名、利用者・取引の識別子を先に固定します。その識別子で受付から終了までを追い、欠けた区間や異常終了地点を探します。
ログ出力が不十分な場合も、推測で補わず、ソースコード、設計書、他層のログを使って未確認区間を明示します。
| 確認軸 | 役割 | 例 |
|---|---|---|
| 時刻 | 対象範囲と処理時間を絞る | 10:15:20.120～10:15:22.842 |
| 識別子 | 複数ログを一件に関連付ける | requestId、取引番号、セッションID |
| 処理名 | どの機能・メソッドかを特定する | TransferService.execute |
| ログレベル | 重要度の目安にする | INFO、WARN、ERROR |
| 終了結果 | 正常・業務エラー・システムエラーを分ける | resultCode、例外クラス |
APサーバログを追う4ステップ
1．リクエストの入口を特定する
アクセスログや受付ログから、処理開始時刻、URL・機能名、リクエストID、利用者IDを特定します。個人情報や認証情報を検索・共有するときは取り扱いルールを守ります。
入口のログがなければ、APサーバまで到達していないか、ログ出力前に失敗した可能性があります。Webサーバや基盤ログとの切り分けが必要です。
2．同じ識別子で受付から終了まで追う
同じリクエストIDや取引番号を検索し、業務チェック、DBアクセス、外部API呼び出し、終了ログの順に並べます。サーバが複数ある場合は、ノード名も記録します。
開始ログはあるのに終了ログがない場合は、その間の例外、タイムアウト、スレッド停止を確認します。
- 処理開始と処理終了
- 主要な分岐・業務チェック
- DBアクセスの開始・結果
- 外部連携の送信・応答
- 例外ハンドリング・戻り値
3．スタックトレースは原因連鎖を下へたどる
スタックトレースでは、例外名、メッセージ、Caused byの連鎖、業務ソースの最初の行を確認します。先頭のラッパー例外だけでは、根本原因が分からない場合があります。
行番号はデプロイされたソース版と一致するか確認します。別バージョンのソースを見て判断しないよう、ビルド番号やリリース版を押さえます。
確認例 1. 最上位例外：処理全体がどう失敗したか 2. Caused by：元になった例外は何か 3. 業務クラスの行：どの処理で発生したか 4. 直前ログ：入力・分岐・外部応答はどうだったか 5. 正常ログとの差：本来どのログが続くか
4．正常時と比較して欠けた処理を探す
同じ機能・似たデータ条件の正常ログと比較し、ログの順番、処理時間、分岐、外部応答の違いを確認します。異常ログだけを読むより、差分が原因候補を示してくれます。
処理が遅い場合は、全体時間だけでなく、DB、外部API、ファイルI/Oなど区間ごとの時間を比べます。
APサーバログの時系列整理テンプレート
大量のログをそのまま貼るのではなく、調査に必要な行を時系列で要約します。原本の保存場所も残します。
【対象】 発生日時： 機能・URL： requestId・取引番号： 実行ノード・リリース版： 【時系列】 時刻／処理／結果／ログ位置 【例外】 最上位例外： Caused by： 業務ソース行： 【比較】 正常時との差： 欠けている処理： 未確認事項：
ログに入力値を出しすぎると情報漏えいにつながり、少なすぎると調査できません。ログ設計の改善点が見つかったら、再発防止として検討します。
よくある失敗と改善方法
| 失敗 | 起こる問題 | 改善方法 |
|---|---|---|
| エラー行だけを抜き出す | 処理の前後関係と原因連鎖を失う | 受付から終了まで時系列で追う |
| 別リクエストのログを混ぜる | 存在しない処理経路を作ってしまう | 識別子とノードを固定する |
| 最上位例外だけを見る | ラップされた根本原因を見落とす | Caused byと直前処理を確認する |
若手SE向けチェックリスト
- 対象時刻・機能・識別子を特定した
- 実行ノードとリリース版を確認した
- 受付から終了まで同じ識別子で追った
- DB・外部連携の前後ログを確認した
- Caused byの例外連鎖を確認した
- 正常時ログと同条件で比較した
- 機密情報を適切にマスキングした
まとめ：APサーバログは識別子で一件の処理をつなぐ
APサーバログの調査では、一つのエラーを見つけることより、一つの処理がどこまで進み、どこで途切れたかを説明できることが大切です。
ログで分からない区間は未確認として残し、設計書、ソースコード、WebLogicやOracleのログと関連付けて確認しましょう。
- 時刻・処理・識別子を先に固定する
- 受付から終了までを時系列で追う
- 正常時との差と例外連鎖を確認する
コメント