要約

  • RFC 3434 では、大容量値の絶対量と HcValueStatus を一緒に解釈する。ゼロと valueNotAvailable(1) の組合せは取得失敗であり、ゼロという測定結果ではない。
  • 取得失敗でもアラーム行は残り、失敗回数が増え、前回値を欠く差分は無効になる。しきい値遷移、イベント関連付け、通知到達、対応完了は別の証拠である。

空欄にできなかった数値欄

RFC 3434 の hcAlarmAbsValue は、監視対象を取得できない場合にゼロを保持する。しかし同じ行の hcAlarmValueStatus は値取得不能を示す。数値欄だけを見ればゼロだが、記録全体は「観測なし」と述べている。

この状態欄は符号も担う。カウンタ自体は非負でも、差分は負になり得るため、絶対量に正・負・取得不能の状態を添える必要があった。絶対量だけを転送すれば、負値は正値に、欠測はゼロに変わる。データは整ったまま、意味だけが壊れる。

プレーンテキスト、RFC Editor の記録、IETF 文書ページ、履歴、参照関係は仕様の来歴を示す。特定製品の実装、現在の配備、現実の障害を示す資料ではない。

32 ビットのアラーム表が足りなくなった理由

RFC 2819 の RMON アラーム表は、周期採取、上昇・下降しきい値、イベント表への関連付けを備えていた。しかし対象は 32 ビット値だった。RFC 2863 が示した例では、32 ビットのオクテットカウンタは 1 Gbit/s で約 34 秒しか持たない。回り込みを見逃さないための高頻度ポーリングは、速度が上がるほど不安定な解決策になる。

そこで RFC 3434 は Counter64 と、RFC 2856 の CounterBasedGauge64 を扱う独立表を定義した。旧表を別の意味に読み替えず、RMON のイベント表だけを共有した。

しきい値も複合値だった。上昇・下降の各しきい値は下位 32 ビット、上位 32 ビット、符号状態の三つから構成される。下位値に上位値を二の三十二乗倍して加え、状態に応じて符号を得る。一部だけを保存すれば、形式は正常でも別のしきい値になる。

行を残して、観測を偽らない

対象値が一回取れなかっただけでは、RFC 3434 のアラーム行は破棄されない。設定は維持される。さらに hcAlarmValueFailedAttempts が、行の活動中に値を得られなかった回数を数える。

ここでは三つの主張が分かれる。行があることは設定の存続、失敗カウンタは取得失敗の発生、状態欄はその区間に有効値がないことを示す。失敗の原因までは分からない。アクセス制御、対象オブジェクトの消失、エージェント内部、負荷、時刻条件などは別に調べなければならない。

差分採取では、欠測の影響が次の区間まで伸びる。差分は現在値から前回値を引く。前回値がなければ、現在値が取得できても正当な差分は作れない。RFC 3434 はその差分を取得不能とした。後から成功した測定は、過去の基準値を生成できない。

一回の失敗は、失敗区間をゼロ測定にしないだけでなく、次の変化量も無効にする。時間的な連続性が値の一部だった。

遷移と結果の間

上昇イベントは、前回が上昇しきい値未満で、現在が同値以上になったときに生じる。次の上昇イベントを可能にするには、値が下降しきい値まで戻らなければならない。下降側も対称である。このヒステリシスは境界付近の揺れを毎回のイベントにしない。

最初の有効サンプルがすでに範囲外なら、起動方針により一回のイベントを出せる。それでもイベント索引がゼロなら関連イベントはない。非ゼロでもイベント表に対応行がなければ関連は成立しない。関連があっても、通知送信、受信、人による確認、修復完了はまだ別である。

取得、妥当性確認、絶対値または差分計算、符号付きしきい値比較、遷移判定、イベント行解決、動作実行、通知輸送、受信、判断、対応。アラームという一語に、この全工程の成功を入れることはできない。

変数ポインタが広げる読み取り権限

hcAlarmVariable は RMON 外の整数型 MIB オブジェクトも指せる。RFC 3434 は、SNMP ビューがオブジェクトへのアクセスを制限できても、ポインタ値を特定ビュー内のオブジェクトだけに制限する適切な仕組みがないと説明した。そのため、このポインタへの書込みは、プローブ上の全オブジェクトを読めるビューにのみ与えるべきだとした。

RFC 3410 は管理枠組み、RFC 3414 は USM、RFC 3415 は VACM を示す。引用されているだけで、安全な設定を証明するわけではない。RFC 2578、RFC 2579、RFC 2580、RFC 2119も定義方法を与えるが、運用結果は与えない。

IANA SMI 登録表は識別子の文脈を保存し、RFC 3434 の正誤情報は取得時点の既知修正を示す。どちらも採用状況の測定ではない。

「不明」を消さない設計

時刻と数値だけの監視表は扱いやすい。しかし RFC 3434 が必要としたのは、状態、符号、採取方式、前回値の連続性、行の識別、失敗履歴を含む記録だった。これらを削ることは表示の簡略化ではなく、主張の変更である。

Heng Lu の現実の層と象徴的権力という議論は、画面上のゼロが、その意味を否定する状態欄より強く見える理由を説明する。実行されるコードを重視する論考は、規格の区別が実装と輸出経路で維持されて初めて価値を持つと示す。

RFC 3434 は通知の到達を保証しなかった。代わりに、設定は残っている、観測は来なかった、ゼロは測定されていない、という三つを同時に記録できるようにした。

参照資料