「ログはたくさんあるけれど、どれから見ればよいか分からない」
「エラーを見つけたが、これが原因なのか結果なのか判断できない」
開発・保守の現場では、障害調査や問い合わせ対応のたびにログを確認します。しかし、文字列を検索してエラーを一つ見つけるだけでは、原因にたどり着けないことも少なくありません。
ログは、システムで起きた出来事を時系列で残す記録です。画面、アプリケーション、WebLogic、Oracleなど複数の層をつなげて読むことで、「どこまでは正常で、どこから異常なのか」を切り分けられます。
私も銀行システムの開発・保守に25年以上関わるなかで、ログから原因を追う場面を数多く経験してきました。ログ調査で大切なのは、すべてを読むことではなく、対象時刻と処理の流れを決め、必要なログを関連付けて確認することです。
この記事では、ログ活用の基本を次の3つに分けて解説します。
- WebLogicログでリクエストと基盤側の異常を確認する
- Oracleログでデータベース側の事象を確認する
- APサーバのアプリケーションログで処理の流れを追う
ログ調査は「時刻・処理・識別子」を先に決める
ログを開く前に、調査対象を絞ります。最低限、次の情報をそろえると効率が上がります。
- 事象が発生した日時とタイムゾーン
- 対象の画面、API、バッチ、ジョブ
- 利用者ID、取引番号、リクエストIDなどの識別子
- 正常時と異常時の操作条件
「今日のエラーを全部見る」では範囲が広すぎます。「10時15分前後に利用者Aが実行した振込API」のように対象を具体化します。サーバ間で時刻差がある場合や、UTCで記録されるログがある場合は補正も必要です。
| 確認する情報 | 役割 | 例 |
|---|---|---|
| 時刻 | 確認する範囲を絞る | 10:14:30〜10:16:00 |
| 処理名 | 対象機能を絞る | 振込受付API |
| 識別子 | 複数ログを関連付ける | requestId、取引番号 |
| 結果 | 正常・異常の差を比べる | HTTP 500、ORAエラー |
1．WebLogicログで基盤側の異常を確認する
WebLogicを利用するシステムでは、サーバログ、アクセスログ、標準出力、診断ログなど複数のログが出力されます。環境ごとに出力先やローテーション設定が異なるため、平常時に一覧を確認しておくことが重要です。
サーバログではレベルだけで判断しない
WebLogicのサーバログには、起動・停止、デプロイ、JDBC、スレッド、メモリ、クラスタ通信などの情報が記録されます。ERRORやCriticalだけでなく、その直前に出ているWarningや状態変化も確認します。
- 対象サーバがRUNNING状態だったか
- アプリケーションのデプロイ状態に変化がなかったか
- JDBC接続プールの不足や接続失敗がなかったか
- スタックスレッドやOutOfMemoryErrorの兆候がなかったか
- クラスタ内の特定ノードだけで発生していないか
アクセスログでリクエストの到達を確認する
アクセスログを確認すると、対象リクエストがWebLogicまで到達したか、HTTPステータスや応答時間がどうだったかを確認できます。アプリケーションログに何も出ていない場合でも、アクセスログに記録がなければ、手前のWebサーバやネットワークで止まっている可能性があります。
複数のManaged Serverがある場合は、どのノードで処理されたかを確認します。特定ノードだけで再現するなら、そのノードの設定、デプロイ状態、接続先などへ調査範囲を絞れます。
2．Oracleログでデータベース側の事象を確認する
Oracleでは、アプリケーションが受け取ったORAエラーだけでなく、alertログやトレースファイル、リスナーログなども調査に使います。まずはアプリケーションログに出ているエラーコードと時刻を起点にします。
ORAエラーは番号と発生条件を記録する
ORAエラーは、メッセージだけでなくエラー番号、発生SQL、バインド条件、発生時刻を確認します。同じエラー番号でも、実行した処理やデータによって原因が異なる場合があります。
「10時15分23秒、取引番号12345の更新処理でORA-00001が発生。対象テーブルの一意制約に該当し、同一キーの既存データを確認中」
このように、番号と状況をセットで記録すると、データ起因かアプリケーション起因かを検討しやすくなります。
alertログとリスナーログの役割を分ける
| ログ | 主な確認内容 | 調査例 |
|---|---|---|
| alertログ | インスタンス全体の重要な事象 | 起動・停止、領域不足、内部エラー |
| トレース | 詳細な診断情報 | ORA-00600などの追加情報 |
| リスナーログ | 接続要求と接続エラー | 接続先、サービス名、TNSエラー |
| アプリ側SQLログ | 実行SQLや処理結果 | SQL、バインド値、実行時間 |
データベース側のログを参照する権限がない場合は、時刻、対象サービス、エラー番号、接続元を整理して、DBAへ確認を依頼します。「Oracleを見てください」だけでなく、調査対象を具体的に伝えることが重要です。
3．APサーバのアプリケーションログで処理を追う
アプリケーションログは、業務処理の開始・終了、入力条件、外部接続、例外などを確認する中心的な情報です。画面操作からデータベース更新まで、処理がどこまで進んだかを追います。
入口から出口へ順番に追う
- リクエストを受け付けたか
- 入力チェックを通過したか
- 業務ロジックのどこまで進んだか
- データベースや外部APIを呼び出したか
- コミットまたはロールバックされたか
- レスポンスを返したか
例外のスタックトレースは、最上段だけでなく、原因を示す「Caused by」以降も確認します。ただし、クラス名と行番号だけで原因を断定せず、ソースコードと入力条件、呼び出し元を照合します。
正常時との差分を比較する
異常時のログだけで分からない場合は、同じ処理が正常終了したログと比較します。処理順序、実行時間、接続先、SQL件数、戻り値などの違いを確認すると、分岐点を見つけやすくなります。
比較するときは、個人情報や認証情報の扱いに注意します。ログを共有するときは、社内ルールに従ってマスキングし、必要な関係者だけが参照できる場所を使用します。
ログ調査で避けたい3つの失敗
1．「ERROR」だけを検索する
エラーの前に警告や処理遅延が発生している場合があります。対象時刻の前後を含め、処理の開始から確認します。
2．最初に見つけた例外を原因と決める
例外が別の異常の結果として発生していることもあります。最初の異常、後続の例外、利用者へ返った結果を時系列で整理します。
3．調査に使った条件を残さない
対象ファイル、検索条件、時刻範囲、確認結果を残さないと、別の担当者が同じ調査を繰り返します。再実行できる形で記録しましょう。
ログ調査メモのテンプレート
【調査対象】 発生日時： 対象機能・処理： 利用者ID・取引番号・リクエストID： 【確認したログ】 ログ名・サーバ： 対象時刻： 検索条件： 【時系列】 時刻： ログの事実： 処理上の意味： 【結論】 確認できたこと： 未確認事項： 次に確認するログ・担当：
若手SE向けログ活用チェックリスト
- 発生時刻、処理名、識別子を確認した
- サーバ間の時刻差とタイムゾーンを確認した
- WebLogicのサーバログとアクセスログの役割を分けた
- Oracleのエラー番号と発生条件を記録した
- アプリケーション処理を入口から出口へ追った
- 正常時ログと異常時ログを比較した
- 個人情報や認証情報を適切に扱った
まとめ：ログは複数の層を時系列でつなげて読む
ログ調査では、膨大な情報をすべて読む必要はありません。対象時刻、処理、識別子を決め、WebLogic、Oracle、APサーバの各ログを処理の流れに沿ってつなげます。
- WebLogicログでリクエストの到達と基盤状態を確認する
- Oracleログでデータベース側のエラーと接続状況を確認する
- APサーバのログで業務処理のどこまで進んだかを追う
最初から原因を言い当てようとせず、「どこまでは正常だったか」を一つずつ確認すると、調査範囲は着実に狭くなります。
コメント