フランス拠点の障害対応で使うログ、locale依存の日付書式を避けるための設定

フランス拠点のアプリから出るログで、日付が「12/03/2024」と出ていた時期があった。日本側の目には12月3日に見えるが、現地の慣習では3月12日。障害対応中にこの解釈違いで30分ほど溶かした。対象はJavaのアプリで、ロケールがfr_FRのまま出力していた。データ量は1日あたり約40万行、grepで追うには多すぎるので、まず書式を固定することにした。

やったことは単純で、ログ出力のフォーマッタに明示的なパターンを渡した。

DateTimeFormatter fmt = DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ssXXX", Locale.ROOT);
logger.info("order failed id={} at={}", orderId, fmt.format(ZonedDateTime.now(ZoneId.of("Europe/Paris"))));

設定側でも、JVMのデフォルトロケールに頼らないようにした。

-Duser.language=en -Duser.country=US -Duser.timezone=Europe/Paris

ポイントは、表示を英語にすることではなく、書式をロケールから切り離すこと。日付はISO 8601に寄せ、タイムゾーンは現地のまま残した。UTCに統一すると、現地の運用担当が「昨夜の23時」と言ったときに頭の中で変換が必要になり、会話のたびに計算が入る。現地時刻を保持しつつ、書式だけ機械可読に固定するのが、こちらでは摩擦が少なかった。

代价として、既存のログ解析スクリプトの正規表現を全部見直す必要があった。日付部分を「\d{2}/\d{2}/\d{4}」で拾っていたものは軒並み外れる。また、外部ベンダーのツールがfr_FRの書式を前提にダッシュボードを作っていた場合は、表示が崩れる。ここは事前に洗い出せず、障害対応の翌週に2つ見つかった。

この方法が効かないのは、ログを出す側を触れない場合。たとえばミドルウェアやアプライアンスのログは書式が固定で、こちらからは変えられない。そのときはパーサ側でロケールを明示して読むしかないが、fr_FRの「dd/MM/yyyy」とen_USの「MM/dd/yyyy」が混在すると、どちらの規則で読むかを人間が判断する羽目になる。結局、触れないログは別ファイルに分けて、変換テーブルを1枚だけ持つ運用に落ち着いた。

現地の運用担当とは、書式を変える前に「この形式で読めるか」を一度だけ確認した。返事は「読めるが、慣れるまで時間がかかる」だった。それでも、解釈違いで障害対応が止まるよりはよいと判断している。

同じように、fr_FRの日付書式が混ざる環境で、どのレイヤーで書式を固定しているか。アプリ側か、収集側か、閲覧側か、実際の構成を聞いてみたい。