要約

  • 任意の timeQuality は送信元が把握するタイムゾーン、同期状態、想定誤差を伝えるが、受信側の時計検査にはならない。
  • syncAccuracy は同期間隔中の最大偏差について送信元が置く上限であり、その根拠は時刻源の信頼性と運用者の設定にある。

ログの順序は、時計の根拠まで運んでいるか

障害対応では、別々のシステムから集めたログを時刻順に並べ、何が先に起きたかを推定する。ミリ秒まで記された時刻は強い根拠に見えるが、それだけでは送信元が正しい時刻を得ていたかは分からない。ホストがタイムゾーンを把握していたか、信頼できる時刻源に同期していたか、同期を監視する仕組みが動いていたかは、時刻の書式とは別の問題である。RFC 5424の timeQuality は、その違いをメッセージの構造化データとして残すために設けられた。

第6.2.3節はRFC 3339を限定した形式で TIMESTAMP を定義し、時計精度と性能が許す場合には小数秒を含めることを推奨する。第7.1節は、送信元がシステム時刻について持つ認識を表す timeQuality を追加できるようにする。ここで示されるのは送信元の認識であって、コレクターが実時間を検査して得た判定ではない。

第7.1節は、信頼できる外部時刻源に正しく同期していない場合、またはタイムゾーン情報が正しいか分からない場合に、送信元が timeQuality を記すよう推奨している。各パラメーターは任意のままであり、細部をすべて埋めなくても制約を伝えられる設計である。

この区別を保てば、ログの数値を読み取ることと、その数値をどこまで信頼するかを判断することを混同せずに済む。

三つのパラメーターは異なる問いに答える

tzKnown は、送信元が自分のタイムゾーン情報を把握しているかを示す。UTC表記かどうかとは別で、RFC 5424は Z を使う場合でもタイムゾーンが既知であり得ると説明する。逆に、UTCで書かれていることだけでは、ホストの設定が正しいと分からない。附属書A.7は保守的な既定値を勧め、タイムゾーンを既知と申告する前に管理者が設定または確認する考え方を示している。

isSynced は、送信元がNTPなどの信頼できる外部時刻源に同期していると判断しているかを伝える。Syslogの受信者がこの値を読んでも、時刻源に問い合わせて状態を再確認するわけではない。したがって、受信側に届くのは送信元の状態申告である。

syncAccuracy は、同期間隔のあいだに時計がずれる可能性のある最大値を、マイクロ秒単位の整数で示す。isSynced="0" のときに併記してはならない。RFCの例では60,000,000マイクロ秒、すなわち60秒を使い、09:00という時刻が08:59から09:01までの範囲を持ち得ることを示す。この幅は第三者が測った実績値ではなく、送信元が見込む限界である。

RFC 5424は、時刻源の信頼性を送信元が実際に把握している場合に限ってこの精度を記すよう勧める。附属書は、通常その把握には運用設定が必要だとし、根拠のない精度を示して誤解を招かないよう注意する。また、isSynced="1" があり syncAccuracy がない場合、コレクターまたはリレーは受信時刻を正しいと考えられる精度として扱ってよい。これは受信者の解釈規則であり、時刻源の健康状態を独立に証明する仕組みではない。

保存するなら、時刻と一緒に保存する

IANAのSyslogパラメーター登録簿では、timeQuality と三つの属性はいずれも任意である。受信システムは、属性があるメッセージとないメッセージの双方を扱う必要がある。属性がないことは時計が誤っている証拠ではないが、受信側が明示的に参照できる根拠が少ないことを意味する。

ログを共通形式に変換する処理が時刻だけを残し、同じメッセージの timeQuality を捨てると、後日読む人は元の留保を知らずに細かな時刻を比較するかもしれない。属性を保存したうえで、送信元と設定の責任者、対象期間の監視記録をたどれることも必要になる。

NTPの運用指針RFC 8633は、時刻源とNTPインスタンスの監視、非同期サーバーの検出を勧める。これは送信元の申告を運用面で確かめる方向を示すが、特定のシステムが実施している証拠ではない。参照した資料から実運用の普及率や誤差発生率を推定することもできない。

フィールドが示す境界

timeQuality は、送信元が自らの時刻状態をどう申告したかを示す証拠である。受信側がログの確からしさを区別し、元の不確実性を残す助けになる。一方で、イベントの真正性、システムをまたぐ因果順序、申告された同期状態の真偽までは確定しない。

Heng LuのRunning-Code Primacy論は、ここでは限定的な編集上の視点として使える。文書上のラベルだけでは、実際に稼働するシステムの検証や運用を代替できない。RFCが定義するのは申告の形式であり、その根拠は送信元の時計設定と監視に残る。コレクターはその境界を維持できるが、後から根拠を補うことはできない。

出典