OTR_LogAnalysis

ログ分析

• TOP > 使い方 > ログ分析

概要

Open 棟梁が出力した運用ログ（ACCESS / SQLTRACE など）を読んで、エラーと性能の問題を見つけ、対応を決める方法。

• ログの出力（設定・書式）はログ出力方式 (log4net)を参照。ここは出たログを分析する側。
• 分析の結果は「証跡（ログ行）→ 原因の推定 → 対処案」の形で、重大度順に纏める。推測は証跡とセットで示す。

詳細

ログの種類

日付でローリングする（名前.YYYY-MM-DD.log）。_WS 付きは 3 層のサービス・インターフェイス側の同種ログ。

ロガー	内容	主に見るもの
ACCESS	各層の入り／出のトレースと例外	ERROR / FATAL 行、実行時間、レイヤの矢印
SQLTRACE	実行した SQL と時間	実行時間・CPU 時間、多発する SQL
OPERATION	業務操作（書式はプロジェクトの決め事）	業務イベントの追跡
SERVICE-IF	サービス・インターフェイスの開始／終了	Web サービスの異常終了

行の読み方

共通の先頭は [日時],[LEVEL],[thread],<message>。

• ACCESS：,ユーザ名,IP,レイヤ矢印,画面名,処理名,,実行時間,CPU時間,エラーメッセージID,エラーメッセージ
  • 出る側（<----- / <<-----）の行の数値が、実行時間・CPU 時間。
  • ERROR 行の直後の複数行がスタックトレース。
• SQLTRACE：実行時間,CPU時間,[commandText]:〈SQL〉 [commandParameter]:〈パラメタ〉

エラー分析

1. ERROR / FATAL の行を抽出し、エラーメッセージ ID と、スタックトレースの先頭の例外型で分類する。
2. 例外型で対応が変わる。

例外型	意味	対応の方向
FrameworkException（例：セッション・タイムアウト）	フレームワークが検知した事象。多くは仕様どおり	多発するならタイムアウト値や UX を見直す
BusinessSystemException	業務を停止したシステム例外	メッセージ ID から原因を特定する
その他の例外	未ハンドルの例外	例外の振替（業務例外・システム例外へ）や入力チェックの追加を検討する

• 業務例外は正常系の戻り値で返るので、ACCESS の ERROR には出ない（ワーニングとして出る）。

3. スタックトレースの「場所 …:行」で、発生した層とクラスを特定する。

性能分析

絶対値ではなく、分布（外れ値）で見る。

兆候	疑うこと
SQLTRACE の実行時間が突出、または同じ SQL が多発	暗黙の型変換によるインデックス不使用、N+1、ページングの欠如
ACCESS の B 層の時間は長いが SQL は短い	業務ロジック、外部呼び出し
実行時間と CPU 時間の差が大きい	待ち（I/O、ロック、外部サービス）

コーディング・エージェントに任せる場合

• スキル opentouryo-log-analysis を使わせる。ログの読み取りと集計はエージェントに向いた作業である。
• 対処の実施（コード修正）は、原因が確認できてから別の作業として行わせる。

参考

• ログ出力方式 (log4net)
• 例外処理方式
• 性能設計

---

Tags: 再構築