第3章：ログ・メトリクス・トレースの当たり方（最低限）

この章で学ぶこと

• 観測の入口を決める（ログ/メトリクス/トレース）
• request-id 等で点を線にする
• 複数ログ源を相関する前に時刻同期と時計ずれを確認する
• “正常との差分”で見る

成果物（または判断基準）

• 観測点（何を見るか）のメモ
• 切り分けに使う証跡（ログ抜粋等）

本文

最低限は“どの層で破綻しているか”を特定すること。アプリケーション/DB/外部依存のいずれかに切り分ける。

注: “正常との差分”を見るために、比較対象（直近の正常期間、同時間帯、同リージョン等）を先に決める。

当たり方（例）

• メトリクス: エラー率、レイテンシ、飽和（接続数/CPU）
• ログ: エラー種類、request-id、直近変更の影響
• トレース: どこで詰まっているか（外部呼び出し等）

観測結果はタイムラインに記録し、判断の根拠として残す。

複数ログ源の時刻整合性

タイムゾーンと表記形式が同じでも、ホストの時計がずれていれば事象の順序を誤る。アプリケーション、DB、ロードバランサーなど複数のログ源を相関する前に、次を確認してタイムラインへ記録する。

• 各ログ源の時刻同期状態（同期済み / 未同期 / 不明）、共通タイムソース、確認日時、確認方法
• インシデント対象期間に近い時点で基準時刻と比較した時計ずれ（clock skew）の幅と方向
• 補正の有無。補正する場合は対象ログ源、補正幅・方向、根拠、補正後時刻

原ログの時刻は上書きせず証跡として保全する。分析用タイムラインで補正する場合は、原時刻と補正後時刻を併記する。同期状態やずれが確認できないログ源は「不明」と記録し、時刻だけで前後関係を確定しない。

この確認はログ基盤の構築手順ではなく、相関結果の信頼性を示す最小メタデータである。NIST SP 800-92 は、logging host の時計を共通タイムソースへ同期し、ログ設定やプロセスの異常を記録・報告する高水準のログ管理ガイダンスを示している。

具体例（場当たり→再現性）

悪い例（場当たり）

ログを `grep` で眺めるだけ
メトリクスもトレースも見ない
どの層が原因かが特定できない

良い例（再現性）

メトリクス: レイテンシ上昇と DB 接続待ち増加を確認
ログ: request-id でエラーとクエリ遅延をひも付け
トレース: 外部依存は正常、DB 呼び出しがボトルネック
時刻整合性: アプリと DB の同期状態、共通タイムソース、確認日時を記録
時計ずれ: DB が基準より 2.4 秒進んでいた。原時刻を保全し、分析用タイムラインでは -2.4 秒の補正を併記
記録: 根拠（グラフ/ログ抜粋）を保存

チェックリスト

• 入口（どの観測を優先するか）が決まっている
• 正常との差分で見ている
• 複数ログ源の同期状態、共通タイムソース、時計ずれを確認した
• 原時刻を保全し、補正した場合は対象、幅・方向、根拠、補正後時刻を記録した
• 証跡（グラフ/ログ抜粋）が残っている

まとめ

• 観測の入口（ログ/メトリクス/トレース）を決め、層を切り分ける
• request-id 等で関連するログをひも付け、点ではなく線で追う
• 複数ログ源の同期状態と時計ずれを確認し、原時刻と補正を区別して記録する
• 正常時との差分を前提にし、根拠（グラフ/ログ抜粋）を記録する

次章への接続

• 次章: 第4章