フランスの現場で使うログ集約ツール、タイムゾーン設定の落とし穴

パリ郊外の小規模チーム（開発5人、運用2人）で、障害対応用のログ集約ツールを自前でホストしている。ツールはFluentd＋Elasticsearch＋Kibanaで、各サーバのタイムゾーンはEurope/Paris。先月、障害対応中にログの時刻が1時間ずれて見える現象が起きた。原因は、Fluentdの設定でtime_keyを指定していたが、パース後のタイムゾーン変換をしていなかったこと。具体的には、アプリケーションログは2024-06-10T14:30:00+02:00のようにオフセット付きで出ているのに、Fluentdのtime_formatで%Y-%m-%dT%H:%M:%S%zを指定しても、Elasticsearchに送る際にUTCに変換されず、Kibanaの表示タイムゾーン設定（Browser）と混ざって誤読を招いた。

対応として、Fluentdのfilterでrecord_transformerを使い、timeフィールドを明示的にUTCに変換するようにした。設定の抜粋は以下。

<filter **>
  @type record_transformer
  enable_ruby true
  <record>
    time_utc ${Time.parse(record['time']).utc.iso8601}
  </record>
</filter>

これでElasticsearchにはtime_utcというフィールドが追加され、Kibanaの日付フィールドにこれを指定。表示はブラウザのタイムゾーンに依存するが、元データがUTCなので混乱が減った。

なぜこの方法を選んだか。ログのタイムゾーンを現地時間のまま保存すると、夏時間の切り替えで同じ時刻が二度現れたり、他拠点のメンバーが読むときに変換が必要になる。UTCで保存し、表示時に現地時間に変換する方が、長期的にはトラブルが少ない。ただし、Kibanaの「Browser」設定はユーザーごとに異なるため、チーム内で「ログを見るときはUTCで確認する」というルールを決めた。

この方法が失效するのは、アプリケーションがタイムゾーン情報を付加していないログを出す場合。例えば2024-06-10 14:30:00のようなオフセットなしのログだと、Fluentdはサーバのローカルタイムゾーンで解釈する。サーバのタイムゾーンがEurope/Parisなら問題ないが、コンテナのタイムゾーンがUTCのままだったりすると、1時間ずれる。実際、テスト環境のDockerコンテナでこの問題が起きた。対策として、コンテナのTZ環境変数を明示的に設定するか、ログ出力側でオフセットを付けるよう修正した。

もう一つの落とし穴は、既存のログにtimeフィールドとtime_utcフィールドが混在してしまうこと。過去のログはtimeのままなので、Kibanaのインデックスパターンでtime_utcを日付フィールドに指定すると、古いログが表示されなくなる。移行期間中は両方のフィールドをサポートする必要があり、インデックステンプレートでtime_utcが存在しない場合はtimeを使うような工夫が要る。

同じようなログのタイムゾーン問題で、現地時間のまま運用しているチームはあるか。特に夏時間の切り替え時にどう対応しているか知りたい。