RFC 5424のsyslog形式と転送層の切り分け

RFC 5424はsyslogメッセージ形式を定め、特定のnetwork transportを必須にしません。メッセージはPRI、VERSION、TIMESTAMP、HOSTNAME、APP-NAME、PROCID、MSGID、STRUCTURED-DATA、任意のMSGで構成されます。-は値がないフィールドのNILVALUEです。PRIはfacilityとseverityを組み合わせます。timestampはtimezone offsetと小数秒を表せますが、常にミリ秒精度であることや送信元clockの正確さを保証しません。送信元は任意のtimeQualityなどで時刻への信頼度を示せます。

専門家の視点：RFC著者・実装者による構造化構文の分析

RFC 5424の著者でsyslog実装者のRainer Gerhardsは、別の技術解説でstructured dataは名前付き要素とparameterの構文を提供するものの、一般的なapplication data modelや各fieldの意味までは規定しないと説明しています。[exampleSDID@32473 userId="…"]を追加しても、すべてのcollectorがuserIdの意味を共有するわけではありません。SD-IDの管理者、parameterの意味、version管理、privacy、parser互換性を送受信側で合意します。timeQualityなど規格内の要素も任意です。

TLSと配送信頼性は別の条件

RFC 5425はsyslogのTLS transport mappingを定め、正しく構成すればpeer認証と通信中の保護に使えます。しかしRFC 5424のmessage形式自体はTLSを有効にせず、ログ損失も防ぎません。TLS over TCPは確立中のsessionで順序付きbyteを運びますが、切断後の送信側queue、retry、永続保存の動作までは定めません。証明書検証、trust chain、相互TLSの要否は運用側で決めます。UDP syslogにはtransport acknowledgementや再送がなく、損失条件が異なります。

framing、parse、運用の確認点

RFC 5424はmessage構文とfield解釈を定めます。stream上の複数messageのframingはtransport mappingに関係します。TLS mappingではoctet-countingでmessage境界を示します。実装ではmessage上限、1接続上の複数message、不正なstructured dataやencodingへの対応を定義します。構造化fieldでもMSGは自由形式の場合があり、collectorごとに保持や変換が異なります。全経路でraw message保持、時刻差・timezone、schema正規化、障害時のqueue容量、drop指標を確認してください。

参考資料