要約

  • RFC 1224 は maxAlertsPerTime、windowTime、alertsEnabled で一エージェントの全警報をまとめて制限した。
  • 閾値を越えると alertsDisabled を一度送り、以後の非同期通知を止めたが、その最後の通知も失われ得た。
  • 別のログは alertId と alertData を保持したものの、取得や削除は人の確認や復旧を証明しなかった。

壊れた装置は自分の故障を報告できない

1991 年 5 月の RFC 1224 は、RFC Editor で Experimental とされ、IETF Datatracker に Alert-Man の履歴が残る。対象は警報条件の作り方ではなく、生成後の情報流だった。

非同期通知には逆向きの二つの失敗がある。障害中の装置や分断されたネットワークは通知を届けられない。一方、回線状態が揺れれば、通知が管理局と経路を埋め尽くし、制御能力そのものを弱める。RFC 1224 は過剰送信の抑制と、欠落を検知・再構成できる保管を同時に要求した。

RFC 1157 の SNMP は信頼性のないデータグラムを使い、Trap-PDU の宛先選択は実装依存だった。RFC 1215 は trap の定義形式を示したが、新設を強く抑制した。正しい形式が受領証になるわけではない。

ピンが意図的な無音を作る

滑動窓のピンは maxAlertsPerTime と windowTime を使う。上限は警報種別ごとではなく、エージェント全体の合計に適用された。

起動時の alertsEnabled は真である。警報が生じるたびに状態を調べ、偽なら送らず、真なら送信時刻を記録する。所定数が窓内に収まると、エージェントは alertsDisabled を一度だけ送り、状態を偽にする。

この停止は資源を守るが、停止を知らせる最後の一報もネットワークで失われ得る。そこで管理局は通常の周期で状態をポーリングし、偽を見つけたら再開するとともに、停止中の trap 欠落を記録する。通信量ゼロは正常の証拠ではなく、制御状態の結果になった。

ログは一時的な保管場所だった

ポーリング可能なログでは、生成した警報ごとに増加する alertId と OPAQUE の alertData を作る。管理局は次の行または特定番号を取得し、対応実装なら SET や DELETE で除去できる。RFC 1189 は、この説明に使われた CMOT/CMIP 操作の同時代背景である。

ログは非同期配送と別経路なので、分断後にも古い状態を回収できる可能性がある。しかし容量は有限で、満杯なら最古行が上書きされる。古い順に読む設計は危険を下げるだけで、全履歴を保証しない。

番号が示すのは、その仕組みで行が作られたことまでだ。送信、到着、上書き前の収集、内容の正しさ、担当者の行動は別の証拠を要する。行の削除も、障害が消えたことを意味しない。複数管理局では community ごとに閾値や表示が異なり、一方の再開や削除が他方の状態を決めるとは限らない。

RFC 1224 は安全性を論じていない。したがって SET や DELETE の記録だけから、実行者の認証や権限を推定することもできない。

情報源