要約

  • RFC 3014 は、届かなかった SNMP Trap や Inform の内容を管理アプリケーションが後で取得できるよう、装置内に Notification Log を定義した。
  • しかし控えの記録にも選別と権限、容量、保存期限、資源不足、再起動、複数管理者の競合があり、完全な事故記録ではなかった。
  • 記録数と破棄数、ログごとの索引、sysUpTime の不連続は一部の欠落を示すが、最初から除外された通知や削除済みの中身は戻せない。

ネットワーク管理では、異常を検出した瞬間と、その知らせを人間が読める場所まで運び切った瞬間の間に大きな溝がある。Trap は一方向に送られて消えることがある。Inform には応答と再送があるが、再送上限を越えればやはり終わる。短い障害ほど、次の定期取得までに痕跡を失いやすい。

2000 年 11 月の Proposed Standard である RFC 3014 は、その溝にローカルな Notification Log MIB を置いた。送信側または受信側が通知情報を保存し、アプリケーションは後からポーリングして、保持された変数バインディングから Notification PDU を再構成できる。

ここで新しくなったのは保存機能だけではない。通知の直接経路とは別に、あとで読む経路ができた。第一の経路が失敗しても、第二の経路が出来事のメッセージを残す可能性がある。しかし RFC は、第二の経路を無条件の真実の倉庫として扱わなかった。

MIB は設定、統計、ログに分かれていた。設定は何を記録し、どれだけ残すかを決める。統計は記録と破棄の動きを示す。ログに見えるのは、その二つの関門をくぐって生き残った通知だけである。空欄は「何も起きなかった」という意味を持たない。

最初の関門はフィルターである。名前付きログは SNMP Notification MIB のフィルターを参照する。仕様の例では linkUp と linkDown だけを選ぶ。別種の通知が同じ装置で生じても、そのログには入らない。したがって、ログの完全性は常に「どのフィルターに対して」という限定を必要とする。

次の関門はアクセス制御だった。名前付きログを作った主体のセキュリティ資格情報が、そのログに関連付けられる。ローカル生成の通知を入れる際、装置は作成者が通知内のオブジェクトを閲覧できるか確認しなければならない。資源の少ない装置は、作成者資格を暗黙に持たない空名の既定ログだけを提供してもよい。

この設計は情報漏えいを抑える一方、正当な二人の管理者が同じ装置から異なる過去を見ることを意味した。片方に行がなく、もう片方にある場合、それは改ざんとは限らない。ログ名、作成者権限、フィルター、SNMP エンジン、管理コンテキストをそろえなければ比較できない。

コンテキストの保存も重要だった。一つのシステムで複数の SNMP エンジンが独立して動き、一つのエンジンが複数の管理コンテキストを扱い得る。RFC 3014 は通知元エンジン ID とコンテキスト名を記録した。同じ linkDown でも、どの管理世界から来たかが違えば別の主張である。

第二の境界は保存容量にある。全ログ合計を制約する nlmConfigGlobalEntryLimit、個別ログを制約する nlmConfigLogEntryLimit、何分後に古い通知を除けるかを定める nlmConfigGlobalAgeOut が用意された。ゼロは設定上の無制限や無期限を表せても、物理メモリーを無限にはしない。

仕様は、設定した件数を実際に保持できる保証はないと明記した。資源が足りず新規行を入れられない場合、全ログの中で最古の行を外してよい。個別上限を越える場合、そのログの最古行が外れる。設定値は約束の形式であり、実行された保持量は別の観測対象だった。

全体上限を下げる操作はさらに強い。既存行が新しい値を越えるなら、システムは最古の通知を捨てて適合しなければならない。その行が保存期限より若く、個別ログの上限以下でも関係ない。管理操作一回で、別の収集者が頼っていた証拠時間が短くなる。

RFC 3014 は複数の管理アプリケーションがこの共有値を競合して書く危険も認めた。一方が値を変えることで、他方が読む前に通知が消える可能性がある。文書はそれをサービス拒否攻撃に利用できるとし、対抗方法を将来の課題として残した。

失われた通知を救うはずの仕組みが、独自の攻撃面を持つことになったのである。直接通知は伝送で消える。控えはフィルターで除外される。入った行は容量で追い出される。期限前でも共有上限の変更で消える。管理サブシステムの初期化では、保存内容と順序の基準自体が切り替わる。

そのため統計は飾りではない。RFC 3014 は全体とログごとに、記録された通知と破棄された通知を数えた。破棄カウンターが増えているなら、画面に残った行だけを「全履歴」と呼ぶことはできない。

ただしカウンターは失われた本文ではない。五件破棄されたと分かっても、それが反復的なリンク変動だったのか、電源異常だったのか、重大障害の唯一の前兆だったのかは戻らない。欠落の存在を記録することと、欠落した意味を復元することは別である。

各行には、名前付きログ内で単調に増える索引も付いた。収集アプリケーションは最後に取得した最大値を覚え、次回はそこから進める。同時に sysUpTime を調べ、初期化で索引がリセットされ、行が失われた可能性のある不連続を検出する必要があった。

索引の連続性が証明する範囲は狭い。現在の管理紀元において、保持された行を順番に読んだということである。フィルター外の通知、権限で除かれた通知、記録前の資源不足、ポーリング前の追い出しは見えない。穴があれば欠落を疑えるが、穴がないことは全イベントを保証しない。

再起動時の扱いは実装依存で、一般には行が残らないと想定された。もし残す実装なら、sysUpTime は再起動でゼロに戻るため、以前の行の nlmLogTime をゼロにしなければならない。メッセージの内容が生き残っても、元の相対時刻は失われる。

日付時刻も常にあるわけではない。時計機能を持つシステムだけがローカル日時を記録する。索引、起動後時刻、カレンダー時刻は別々の証拠であり、時計変更、再起動、複数エンジンをまたいだ唯一の順序にはならない。

保持された一行の表現については、RFC は精密だった。変数バインディングを通知索引と変数索引で並べ、SNMP データ型ごとの値オブジェクトに保存する。アプリケーションはそこから PDU の情報を組み直せる。これは「この通知メッセージに何が記録されていたか」の有効な受領証である。

しかしメッセージが述べた現実の受領証ではない。エージェントの検出が誤っているかもしれない。遠隔通知の信頼性が足りないかもしれない。コンテキスト選択を間違えているかもしれない。保存された主張と、装置や回線の真の状態を同一視してはならない。

さらに、収集者が読んだ後にも段階がある。linkDown 行の取得は、人間が気づいたこと、正しいインターフェースを特定したこと、対応権限を得たこと、変更を実施したこと、利用者から復旧を観測したことを証明しない。

周囲の SNMP 仕様はその後更新された。RFC 1905 は SNMPv2 のプロトコル操作を記述し、RFC 2573 と RFC 2575 はアプリケーションとビュー型アクセス制御を与えた。後に RFC 3413 と RFC 3415 がそれらを置き換えた。周辺枠組みの更新は、ログへの入場と読み出しを別々に検証する必要を消していない。

RFC 3877 の Alarm MIB は該当する Notification Log 行との関係を持ち、RFC 5676 の SYSLOG-MSG-MIB は syslog メッセージをこの汎用ログ機構へ写した。後続仕様による参照は再利用可能性の証拠であり、特定製品の実装、全件保存、運用対応の完了を示すものではない。

Lu Heng の Minimum Initial Specification の観点では、RFC 3014 は共通層を小さく保った。設定、統計、索引、出所、型付き値を共通にし、保持量の最終判断は現場に残した。標準は各装置のメモリー配分や各組織の調査期間を中央で決めなかった。

その自由には実証責任が伴う。Running-Code Primacy が問うのは、ある実装でフィルターが本当に働いたか、行が作られたか、上限が変わらなかったか、カウンター紀元が続いたか、収集者が読んだかである。RFC の存在は、稼働中の装置の結果ではない。

Reality Layers の規律を当てれば、条件、通知、ログ准入、保持、読み出し、解釈、承認、対応、結果は別の層にある。結び付けるべきだが、代用してはならない。

RFC 3014 は「ログがあるから安心」とは言わなかった。むしろ、第二の記憶にも選別者、所有者、予算、期限、紀元があると示した。通知を取り戻せる場合もあれば、破棄数と断点だけが欠落の形を残す場合もある。その先で分からないことを分からないまま記録することが、管理の誠実さになる。

情報源