フランス拠点の障害対応、タイムゾーン混在ログをUTCに寄せず突き合わせた手順

フランス拠点のアプリログと、日本の監視基盤が集めたログを突き合わせる必要が出たとき、片方は Europe/Paris、片方は JST で、しかも一部のミドルウェアだけ UTC で出ていました。件数は1障害あたりおよそ12万行、時間窓は3時間ぶん。最初は全部 UTC に変換しようとして、変換スクリプトの適用範囲を間違え、二重変換で30分ずらしたまま2時間溶かしました。

以降は変換せず、各ログの出所ごとに「元のタイムゾーン」を固定して並べる方式に変えました。まずファイル単位でどれがどのTZかを判別します。

for f in app-*.log mw-*.log; do
  printf '%s\t' "$f"
  head -n 1 "$f" | grep -oE '(CET|CEST|UTC|JST|[+-][0-9]{4})' | head -n 1
done

その結果を1行の対応表にして、突き合わせは date で都度変換しながら行います。

TZ=Europe/Paris date -d '2024-03-10 02:30:00' '+%s %Z'
TZ=Asia/Tokyo    date -d '2024-03-10 10:30:00' '+%s %Z'

エポック秒に落として比較するので、夏時間の切り替えを含む窓でも順序が壊れません。2024-03-31 の 02:00-03:00 は Europe/Paris に存在しない時刻なので、その時間帯のログは「欠落」ではなく「その時刻が無い」と記録するようにしました。

この方式の代价は、閲覧時に毎回変換が入るぶん脳の負荷が上がることです。UTC に正規化したファイルを1本作っておけば読むのは楽ですが、作った時点の変換ミスが全員に伝染します。今回は原因究明を優先し、変換は表示時のみに限定しました。

効かないのは、ログにタイムゾーン表記が無く、しかもホストの設定が履歴で変わっている場合です。この場合はファイルの mtime とホスト設定の変更履歴を突き合わせるしかなく、完全な復元は諦めました。あと、Cron で回しているバッチのログはアプリ側が現地時刻で出していて、TZ を変えても出力が変わらないものがありました。これはアプリの設定ファイル側を見ないと直りません。

同じように夏時間をまたぐ窓で、ログの時刻を「元のまま」扱っている人がいたら、どの時点でエポックに落としているか教えてほしいです。