API、データベース、ログにおけるタイムスタンプ

本番デバッグは、HTTP トレース、DB 行、3 つのログファイル — それぞれ独自の時刻表現 — を揃えることから始まることが多い。

相関ワークフロー

1. 参照 instant を選ぶ — 例: ユーザー報告時刻または request ID タイムスタンプ
2. すべてを UTC epoch ms（あれば ns）に正規化
3. クロックスキュー許容 — ノート PC とコンテナはずれる; 緩いシステムでは ±2 分は一般的
4. 隣接ウィンドウでフィルタ — 深い grep の前に reference ± 5 分
5. ソース単位をメモ（nginx: sec、app: ISO UTC、db: timestamptz）

API

REST JSON は次を公開しうる:

{ "createdAt": 1700000000000, "updatedAt": "2023-11-14T22:13:20.000Z" }

1 payload 内の型混在はサービス進化で起きる。各フィールドを独自の条件でパース。

GraphQL と protobuf スキーマは通常スカラー型を文書化 — クライアント比較を書く前に読む。

データベース

• PostgreSQL TIMESTAMPTZ は内部 UTC — 良いデフォルト
• BIGINT epoch 列は秒 vs ms を永遠に覚える必要
• タイムゾーンなし DATETIME（MySQL レガシー）は「与えられた壁時計」を保存 — グローバルアプリでは危険

アプリログと SQL を結合するとき、先に両側を同じ instant 表現に変換。

分散ログ

trace ID にタイムスタンプを埋め込むか付随させる。壁時計文字列しかなければ、既知イベント（デプロイマーカー、ハートビート）で各サービスからサンプル行を変換しスキューを推定。

要点

サービス間デバッグは正規化 + ウィンドウ検索であり、ローカル時計の推測ではない。先に変換、次に比較、3 番目にウィンドウを広げる。