要約

  • RFC 1404 は、独立して運用されるネットワークのために、最小限の測定項目、保存形式、報告方法を提案した。中央の収集基盤を求めた文書ではない。
  • 値には UTC 時刻、実測ポーリング間隔、集約期間、資源の識別、poll delta、total または peak という区分が伴った。それが比較可能性の境界になった。
  • 後継の RFC 1857 は、集約がデータ量だけでなく利用可能な情報も減らすと明記した。平均と最大を残しても、削除した標本列には戻れない。

棒の高さより先に、窓の長さを聞く

二つの運用組織が「一日のピーク」を持ち寄ったとする。片方は一分値から最大を選び、もう片方は十五分平均の最大を選んだ。単位が同じでも、前者が捉えた短い混雑を後者は消しているかもしれない。数値の大小を比べる前に、何を一つの値へ畳んだのかを比べなければならない。

1993 年 1 月に Informational として出た RFC 1404 は、NOC 間で運用統計を共有する際の開発・維持負担を小さくするモデルを示した。対象は最小限のメトリクス、共通保存形式、日次・週次・月次・年次の報告方法である。既存ツールには変換フィルターを足せばよく、共通ツールは public domain で提供する構想だった。

共通部分を薄くすることで、各ネットワークはローカルな道具と将来の判断を保てる。ただし、外へ出す記録は、その値が生まれた条件を受け手が読めるものでなければならない。共通化されたのは支配者ではなく、最小の説明責任だった。

オブジェクト定義と現場の観測は別物だった

推奨項目には、interface の入出力 octet、unicast・non-unicast packet、discard、ifOperStatus、ipForwDatagrams、sysUpTime が含まれた。RFC 1213 の MIB-II はそれぞれの型と意味を定義した。これは辞書であり、ある時刻のネットワーク状態そのものではない。

RFC 1157 の SNMP は agent に値を問い合わせる操作を提供した。GetResponse が返ったなら、ある poll である値が返ったことは分かる。しかし、予定どおりの時刻だったか、counter reset がなかったか、対象 interface が分析したい回線そのものか、後段のファイルが忠実かまでは証明しない。

RFC 1404 は取得可能性も分類した。standard MIB にあるもの、enterprise MIB にしかないもの、高解像度 polling が必要なもの、MIB に存在しないもの、node 単位でしか得られないもの、SNMP では取れないものがある。共通の関心は共通のセンサーを自動的には生まない、という現実的な区分だった。

設定値ではなく、実際の間隔を残す

interface octet と unicast packet について、初期 polling は最長一分が推奨された。それが無理なら六十秒の整数倍を使い、実際に採用した初期間隔を保存する。他の変数は低い頻度でもよいが、同じく明示的な倍数にする。

「一分ごと」という設定は、常に六十秒後に観測したという証拠ではない。scheduler の遅延、device の負荷、応答欠落がある。データ行が timestamp と poll delta を持ったのは、counter の差を実経過時間から切り離さないためだった。

aggregate period も値の一部である。集約後の一点だけを見て、元の標本間隔や窓を推定してはならない。同じラベルの peak でも、peak period が違えば異なる極値を保存する。

追いたい回線と、読んだポートは同一とは限らない

長期に追跡する資源は、今日 counter を返した物理 interface より長く生きることがある。カード交換やポート移設のたびに interface index だけを追えば、回線の歴史が人工的に分断される。

RFC 1404 の preprocessing は、生の interface を継続する resource へ対応付けられた。この正規化によって、設備変更をまたぐ利用率系列を作れる。しかし、それは分析上の連続性を宣言する処理であり、新旧装置が同じ挙動だったことや、切替時に欠測がなかったことの証拠ではない。

network、router、link、bandwidth と unit、protocol、address、timezone、tag table を device 記述に含める意味はここにある。受け手は「何を同じ対象として扱ったか」を検査できる。

共通ファイルは小さな来歴台帳だった

label section は UTC の開始・終了と data file を示した。device section は観測元と資源を記述した。data section の一行は timestamp、tag、poll delta、delta value を持った。各 variable には initial polling period と aggregation period が結び付き、tag は total と peak を区別した。

値は単独で届かなかった。場所、時間、周期、変換、結果の種類が最小限の lineage として付いた。変換フィルターでローカル形式から共通形式へ移せば、別のソフトウェアが解釈できる。だが parse できることは、正確性や真正性の証明ではない。

さらに、報告に使う “customer” は各 installation が定義するとされた。同じ列名でも、契約、回線、組織など母集団が異なり得る。文法の共有だけでは、ローカルな分類を世界共通の意味へ昇格させられなかった。

保存期間を延ばすほど、問いは減った

細かい標本を長く持つのは高価である。RFC 1404 は、一分データを短期間、十五分集約をおよそ一日、一時間集約をおよそ一か月、一日集約をおよそ一年持つ段階化を提案した。average と maximum の双方を残す考えだった。

1995 年 10 月の RFC 1857 は RFC 1404 を obsolete にし、交換用文法を改訂した。そこで集約は保存量を減らす一方、利用可能な情報も減らすと明記された。average は arithmetic mean、peak は maximum で求める。peak は選んだ peak period に依存し、短い窓ほど高い値を捉える場合がある。

平均は中心を残して順序を捨てる。最大は一点を残して継続時間と周囲を捨てる。両方があっても、元の並び、短い burst、別の窓での極値を完全には再計算できない。生データが失効すれば、その問いは保存容量と一緒に削除される。

比較できることと、結果を証明すること

RFC 1404 は共有に伴う法的・倫理的・政治的問題を挙げ、integrity、conformity、confidentiality を課題にした。有用な比較には同じメトリクスと同じ polling・aggregation interval が必要だとも述べた。ただし、交換ファイル全体を保証する暗号的な信頼機構を規定してはいない。

証拠の階段は分けて読む必要がある。MIB object の定義、SNMP response、時刻付き標本、resource mapping、平均・total・maximum、共通形式、限定された比較、運用判断、そして容量変更や障害復旧、利用者の結果である。下段の存在は上段の成立を保証しない。

高い peak は調査理由になっても、混雑の確定ではない。共通形式の二ファイルが同じ local definition を使うとは限らない。グラフを見て増強しても、その後の改善は別に観測する必要がある。

参照資料

これらは文書の状態、object の意味、推奨、交換形式を示す。普遍的導入、収集の正確性、実事故、設備判断、利用者の結果を立証するものではない。