ログファイルと夏時間

Question 1

ログファイルはプレーンテキストファイルであり、各行は末尾に追加されます。そのため、UTC 以外のタイムゾーンを使用する場合でもデータが失われることはありません。

もちろん、混乱を招く可能性のあるツールを使用してファイルを表示する場合もあります。ただし、UTC を使用する通常の理由は、あいまいさを避けるためです。データを解釈するためにローカルタイムゾーンを知る必要はありません。

ログファイルでUTCを使用するのは良いこと、そしてよく行われるただし、これを行わなくてもログファイルのデータは失われません。

Answer

ログファイルはプレーンテキストファイルであり、各行は末尾に追加されます。そのため、UTC 以外のタイムゾーンを使用する場合でもデータが失われることはありません。

もちろん、混乱を招く可能性のあるツールを使用してファイルを表示する場合もあります。ただし、UTC を使用する通常の理由は、あいまいさを避けるためです。データを解釈するためにローカルタイムゾーンを知る必要はありません。

ログファイルでUTCを使用するのは良いこと、そしてよく行われるただし、これを行わなくてもログファイルのデータは失われません。

Question 2

ログファイルはタイムゾーンを「処理」するのではなく、アプリケーションまたはサービスがそこに書き込んだ内容を記録するだけです。したがって、アプリケーションが「メッセージだけ」を「直接ログファイルに」書き込む場合は、運が悪いことになります。

一部のsyslogサーバー（syslog-ngなど）では、タイムスタンプで「生の」ログデータを「装飾」することができます。あなたUTC またはオフセットあり/なしのローカル時間の使用を選択できます。

stdout ログと syslog サービスの中間として使用できるログプログラム (例: logger) も利用できます。

Answer

ログファイルはタイムゾーンを「処理」するのではなく、アプリケーションまたはサービスがそこに書き込んだ内容を記録するだけです。したがって、アプリケーションが「メッセージだけ」を「直接ログファイルに」書き込む場合は、運が悪いことになります。

一部のsyslogサーバー（syslog-ngなど）では、タイムスタンプで「生の」ログデータを「装飾」することができます。あなたUTC またはオフセットあり/なしのローカル時間の使用を選択できます。

stdout ログと syslog サービスの中間として使用できるログプログラム (例: logger) も利用できます。

Question 3

ログファイルでは、UTC の調整としてローカル時間を表示する ISO 8601 やその類似の RFC 3339 などの時間形式を使用できます。

時間エントリが Z で終わる場合、またはハイフン (8601)、マイナス、またはプラスに続いてオフセット値が続く場合は、UTC に基づく形式が使用されています。

ログが UTC に基づいている場合、夏時間はオフセットの変化として表示されます。オフセットにより、現地時間と夏時間が曖昧さなく表示されます。

時計が調整された場合、後続のエントリでも時間の重複が発生する可能性があります。

Answer

ログファイルでは、UTC の調整としてローカル時間を表示する ISO 8601 やその類似の RFC 3339 などの時間形式を使用できます。

時間エントリが Z で終わる場合、またはハイフン (8601)、マイナス、またはプラスに続いてオフセット値が続く場合は、UTC に基づく形式が使用されています。

ログが UTC に基づいている場合、夏時間はオフセットの変化として表示されます。オフセットにより、現地時間と夏時間が曖昧さなく表示されます。

時計が調整された場合、後続のエントリでも時間の重複が発生する可能性があります。

Question 4

他の人が説明しているように、ログファイルの性質上、故障中タイムスタンプがどうなっても、エントリは保存されます。あなたが想定している問題は曖昧さタイムスタンプメカニズムの選択が不適切だと、単一の時点を一意に示すことができません。

このため、ログを読むシステム管理者がいつ何が起こったのかを判断するのは困難です。事後では、(たとえば) タイムスタンプだけのログエントリでは、Apr 3 02:14:57それが現地時間なのか UTC なのかはわかりません。また、(例として現地時間、具体的にはオーストラリア東部標準時であると仮定した場合) 02:14:57 AEST なのか 02:14:57 AEDT なのかもわかりません。

しかし、これは「Linux ログファイル」というものが 1 つだけ存在すると不当に推測することになります。すべてのログファイルが同じ方法で動作するわけではなく、1980 年代以降、人々はこのタイプのタイムスタンプの使用をやめつつあります。

例えば、デーモンツールやその類似品を長年使用してきた私たちは、Linux ログファイルTAI64N タイムスタンプを使用します。ログエントリは次のようになります。

@40000000577d024d2d10bb6d こんにちは!

16 進数の長い文字列は TAI64N タイムスタンプです。これは、非常に遠い過去のある時点 (1970-01-01 00:00:00 国際原子時より 2 62^秒前) からの 64 ビットの秒数と、それに続く 32 ビットのナノ秒数にすぎません。

TAI には異なるタイムゾーンのバリエーションはありません。繰り返される「うるう」秒もありません。すべての秒には一意の固定番号があります。

そして実際、それらのタイムスタンプを人間が読めるローカル時間に処理することが、まさにプログラムの仕事ですtai64nlocal。

jdebp % echo @40000000577d024d2d10bb6d こんにちは\! | TZ=UTC0 tai64nlocal
2016-07-06 13:05:45.756071277 こんにちは!
jdebp % echo @40000000577d024d2d10bb6d こんにちは\! | TZ=PST8PDT tai64nlocal
2016-07-06 06:05:45.756071277 こんにちは!
jdebp %

タイムゾーンと夏時間の変更は、私の「Linux ログファイル」を使用すると、任意のタイムゾーンでログファイルを読み取ることができます。(sortの-mオプションを使用して、複数のログファイルを 1 つにマージソートするなどの操作も実行できます。)

Answer