要約

  • 正常に動くログ設定でも、障害の症状を残しながら、原因を見分ける文脈を除外することがある。後から検索しても、最初から記録されなかった内容は取り戻せない。
  • RFC 9742 はコンソール、ファイル、遠隔宛先ごとに選択条件を持たせる。選択、実際に使われた設定、配送、収集先での保存は別々の主張である。
  • 共通モデルは差異を調べるための言葉になるが、同等の機能や保存期間を保証しない。事前に条件を変えられる人は、将来の検証可能性にも影響を与える。

復旧してからでは分からない前提

事故対応の後、エラーは見つかったのに、その前の操作が正当な変更だったかを判断できない。遠隔出力が高い緊急度のメッセージだけを選び、判断に必要な低い緊急度の文脈を除外していたとすれば、これは設定どおりに動いた結果でも起きる。本稿の仮定例であり、実際の事故を発見したという主張ではない。

「記録がない」という結論は、どの履歴を検索したかを説明して初めて意味を持つ。その出力に入る資格があったメッセージは何か、配送されたか、コピーはまだ残っているか。事故後の検索画面には、事故前の選択がすでに反映されている。

2025 年 4 月に IETF の標準化過程で公開された RFC 9742 は、ietf-syslog YANG 設定モデルを定義する。コンソール、ローカルファイル、遠隔の relay や collector への出力を共通形式で表す。公開されたこと自体は、あるベンダーの採用や特定機器への実装を示す証拠ではない。

このモデルで妥当な設定を表せても、アプリケーションが関連イベントをすべて生成したとは限らない。設定の適用、メッセージの到着、到着後の永続保存も別に確認する必要がある。「ログを有効にした」という一文では、そのどれも十分に説明できない。

緊急度は、将来の証拠価値とは違う

selector はコンソール、名前付きファイル、名前付き遠隔宛先にそれぞれ適用される。ローカルにある記録が遠隔にもあるとは限らない。同じ装置の二つの履歴が異なることは、それぞれ別の条件に従った結果かもしれない。

severity の既定比較は、指定した緊急度と、それより緊急なクラスを選ぶ。syslog の数値は逆向きで、緊急なほど小さい。error を選んでも、error と完全一致するメッセージだけを選ぶわけではない。一方、より低い緊急度の文脈は除外され得る。処置の成功を示すメッセージはエラーほど緊急でなくても、事故後には「処置が効いたか」を見分ける材料になる。

all と none は明示的な値である。任意機能 select-adv-compare があれば、equals と equals-or-higher の比較、および log、block、stop の処理を指定できる。stop はそのメッセージの以後の処理を止める。高度な比較のコンテナ内では equals-or-higher と log が既定値となる。「error レベル」という説明だけでは、等価比較、しきい値、抑止の違いが隠れる。

正規表現による選択には select-match が必要となる。規範となるモジュールは pattern-match を、末尾の MSG だけでなく syslog メッセージ全体である SYSLOG-MSG に対する POSIX 正規表現と記述している。facility とパターンの両方を設定した場合、両方が一致しなければならない。広い facility 条件でも、別の条件によって対象が狭くなる。

このため、アプリケーションの文言や形式の変更も調査対象になる。運用上の意味が同じでも、選択結果が変わる可能性がある。具体的な動作は対象実装で観察すべきで、本稿は特定の照合エンジンや、すべてのルールリストに共通する処理順序を実測・断定していない。ノイズの削減は、説明の選択肢を減らすことでもあり得る。

保存設定から期間の保証を読み込まない

選択された後の記録には、保存容量という境界がある。file-limit-size は保持ファイル数と最大ファイルサイズを設定可能にし、数の既定値は一である。file-limit-duration は分単位の rollover と retention を設定可能にする。いずれも任意機能で、RFC が証拠を何日保存せよと決めているわけではない。

rollover は期間を過ぎてイベントが到着したときに現行ファイルを閉じ、新しいファイルを開く動作を表す。retention は完了・閉鎖したファイルを削除前に保存する期間を表す。「各イベントが発生した時点から必ずこの期間検索できる」という保証とは違う。アーカイブの限度が指定されなければ、実装で定めた限度が使われる。

付録 B.3 の命名、改名、削除の説明は参考となる実装指針であり、強制されるアルゴリズムではない。複数の制限の優先関係を完全に決めてもいない。ファイル数とサイズから単純に保存時間を算出すると、圧縮、イベントの大きさ、ファイルの数え方、他の制約を飛ばしてしまう。

容量が限られていれば、事故時の大量メッセージは過去を早く押し出し得る。これは容量による仕組みの説明であり、本稿で測った保存時間ではない。設定が変わらなくても、最古の検索可能イベントは新しくなることがある。症状の増加によって、その前を知るための履歴が短くなるという問題だ。

ローカルファイルは装置と同じ故障に巻き込まれる可能性もある。遠隔への出力はその依存を変えるが、配送と受信側の保存方針を追加する。装置のローテーション設定で、collector の削除権限や保存期間までは証明できない。

TLS の保護と、記録の存在証明を分ける

各遠隔宛先の項目では UDP または TLS の選択が必須で、その選択の中にアドレス一覧を置く。既定ポートは 514 と 6514 である。選択の範囲はその宛先項目であり、別名の宛先まで同一トランスポートに限定すると読むべきではない。

RFC 5426 は、UDP では通知なしの損失があり、到着順は権威あるイベント順序ではないと説明する。適切に認証・認可された TLS は、伝送の一ホップにおける機密性と完全性を保護する。RFC 5425 第 3 節 では、伝送送信者の認証済み識別子と HOSTNAME の対応は必須ではない。信頼した relay との接続だけで、その中のすべての発信元主張が真になるわけではない。

第 6.3 節 はアプリケーション層の確認応答がないことも指摘する。接続が切れた場合、どのメッセージが相手のアプリケーションに届いたかを常に送信側で判断できるとは限らない。到着後の永続化、後日の削除、内容の真実性はさらに別の問題である。暗号化は、送信前にフィルターで除外された内容を復元しない。

ファイルと遠隔出力の任意機能 structured-data も、過大に読めない。既定は false で、false は NILVALUE、true は一つ以上の構造化データ要素を書き込む。RFC 5424 はこの解析可能なフィールドを任意の本文テキストと分けて定義する。有効化は欠けた事実を生成せず、意味を検証するものでもない。無効化は下流で期待される構造化された文脈を失わせる場合がある。

モデル名の先にある差異

RFC 8525 の YANG Library は、モジュール修訂、対応機能、deviation、datastore ごとのスキーマを示す。if-feature の定義 はノードの実装を機能対応に条件付ける。ietf-syslog という名前だけでは、正規表現や期間ベースの保存制御は確認できない。共通形式は差異を消すのではなく、調べられる形にする。

RFC 9742 付録 B.1 は、拡張 facility が RFC 5424 では使えず、ローカルの syslog に似た機能に限られる場合を示す。ローカル分類をそのまま遠隔分類だと思えない。facility-override は送る facility を置き換え、任意の送信元インターフェース指定は出口を選ぶが、組織の同一性を認証しない。

最後に、RFC 8342 は、変換後に適用を試みる intended と、実際に使用される設定および状態を含む operational を区別し、報告能力などの留保を置く。比較は現在の差を明らかにしても、復旧後の一枚のスナップショットは事故当時の設定を単独では証明しない。

RFC 9742 は証拠の保管経路、自動監査、完全な事故履歴を与える規格ではない。選択、稼働状態、配送、保存という境界を記述する道具である。それらが不明な間、「見つからない」はまず利用できる記録についての説明であり、出来事がなかったという証明にはならない。