要約

  • RFC 3164はレガシーsyslogパケット全体を1,024バイト以下に制限し、有効な時刻がないときはリレーに時刻の挿入を求め、ホスト名の追加も推奨する。
  • 追加後に上限を超えればリレーはパケットを切り詰めなければならず、元メッセージ末尾の重要情報が失われる可能性があるとRFCは警告する。

ヘッダーも同じ容量を使う

時刻を含まない、ほぼ上限まで埋まったsyslogパケットを機器が送ったとする。転送前にリレーはPRIを確認する。RFC 3164第4.3.2節では、PRIの直後にリレーの現在のローカル時刻を入れなければならない。特定できるならホスト名も追加すべきとされ、残りの受信内容はメッセージのCONTENTとして扱われる。

この補完は無料ではない。第4.1節が制限するのはイベント本文だけではなくパケット全体だ。PRI、HEADER、MSGが1,024バイトを分け合う。時刻、ホスト名、区切り文字で上限を超えたら、リレーは長さを確認し、1,024バイトに切り詰めなければならない。RFCは、その結果、元パケット末尾の重要情報が失われることもあると明記する。

それでも受信記録は整って見えるかもしれない。PRIとヘッダーは読める一方、イベント末尾の理由説明、コマンド出力、機器識別子、診断値などが欠けている可能性がある。これは起きうる例であり、実際の事故を主張するものではない。補完によって長い入力が共有上限を超えると、プロトコル上メッセージ末尾が危険にさらされる。

規範上の要件と実装実態は別

RFC 3164は2001年8月のInformationalメモであり、BSD syslogを記述したものだ。すべてのリレーが規則どおり動作した証拠ではない。第4.2節はUDPポート514宛ての内容に有効なsyslogメッセージを許容し、リレーによる改変を避けるため送信側がPRI、HEADER、MSGを含めるよう推奨する。第6.1節は1,024バイト超で受信側が故障しないよう求め、複数の受信挙動を記す。実際の頻度、リレーの適合状況、保存結果は測定していない。

このメッセージ上限は経路MTUと同じではない。IPフラグメント化、UDP処理、アプリケーション層の切り詰めは別の仕組みだ。挿入される時刻はリレーの現在のローカル時刻であり、イベント発生時刻とは限らない。ホスト名もリレーが把握する名前、または送信元IPアドレスで、RFCは送信元との照合を要求しない。

後続形式は層の違いを示すが移行完了を証明しない

RFC 5424はRFC 3164を置き換え、より明確なヘッダーと構造化データを定めた。RFC 6587はTCPフレーミングを説明し、標準化syslogでは旧来の1,024オクテット制限が拡張されたと記す。RFC 3195のRAWプロファイルはBEEPフレーミング分を除いてイベント本文を1,024バイト以下に制限する。同じ数字でも対象層は異なる。新しいRFCが公開されたことは、旧送信機やリレーが消えた証拠ではない。

歴史的な教訓は限定的だ。リレーの文脈補完が、運んでいる本文と共有する有限容量を使う。パケットが到着し、解析され、保存されても、原文全体の保持は証明されない。実システムでは送信元バイト、各リレーの入出力、収集側の解析、後日の読み戻しを照合する必要がある。

出典