· 1271 words · 6 min read

6. オブザーバビリティ#

あるサービスプロバイダーのコアルーターで、ファンモジュールが夜間に無音で故障した。アラートは何も発生しなかった。ラインカード上の熱管理サブシステムが温度上昇を検知し、ハードウェアを保護するためにフォワーディングASICのスロットリングを開始した。本番トランジットリンクのスループットが40%低下した。監視システムは何も捉えなかった。ポーリングしていた温度センサーはシャーシスーパーバイザー上のものであり、個々のラインカード上のものではなかったのだ。SNMPポーリングは5分おきに実行されており、デバイスは正常と報告されていた。インターフェースカウンターはスループット低下を示していたが、そのリンクはずっと容量に余裕があったため、そのパターンに対するしきい値が設定されていなかった。

3時間後、顧客SLA違反がチケットを生成した。オンコールエンジニアがルーターにSSHし、ローカルアラームログでファンの故障を発見し、ファンモジュールを再起動した。ファンコントローラーが再起動し、熱スロットリングは数分で解除された。トラフィックは回復した。SLA違反が文書化され、顧客に通知され、インシデントはクローズされた。

根本原因は最後まで確認されなかった。調査が始まるころにはルーターは何時間も正常稼働していた。ラインカードの温度データもスロットリングイベントの記録もなく、どの監視システムにもスループット低下とファン故障を関連付ける手段がなかった。インシデントレポートの結論は「ハードウェア問題と推測、ハードウェアリセットで解決」だった。6ヶ月後、別のルーターで同じ事象が起きた。

この失敗はしきい値の欠如ではなかった。チームには数千ものしきい値があった。失敗は対象範囲の不完全さにあった。監視システムは従来からポーリングしていたソースからデータを収集していたが、デバイスの動作に影響しうるすべてのソースからは収集していなかった。3種類のシャーシすべてでgNMI経由のラインカード温度データは利用可能だった。ファン故障のためのランブックを誰も書いていなかったから、誰もその収集パスを設定しなかったのだ。

従来のネットワーク監視は壊れているものを監視する。インターフェースは上がっているか？CPUは90%を超えているか？このサービスは応答しているか？それは有用だが、リアクティブだ。障害を待ち受けているだけである。

オブザーバビリティは異なる。なぜ壊れているのか、あるいは壊れかけているのかを理解することだ。「あのデバイスがダウンしている」ではなく「なぜダウンしているのか、何がそれで壊れているのか、ビジネスへの影響は何か」という問いに答える。ネットワーク自動化において、オブザーバビリティはフィードバックループになる。何かを観察し、システムがそれを検知し、対応を決定し、アクションを実行し、修正が機能したことを検証する。このサイクルが繰り返されることが「クローズドループ自動化」だ。

本章では、ネットワークで起きていることを把握するために必要なすべてをカバーする。どのデータを収集するか、どうやって収集するか、どう保存するか、どうアラートを出すか、そして意思決定に本当に役立つ形で人々に見せる方法を説明する。

ここでは2つのビルディングブロック、CollectorとObservabilityを扱う。これらは密接に関連しているためだ。

従来のオールインワンプラットフォーム（SolarWinds、LibreNMS）、クラウドサービス（Datadog、New Relic）、オープンソースのピースから自前で構築するスタック（Prometheus、Grafanaなど）のいずれを使う場合でも、基本的なアーキテクチャは同じだ。これらのパターンを理解することで、自分のスケールとチームに合ったアプローチを選択できる。

注記: このセクションでは、例示のためにさまざまなベンダーやソリューションに言及している。これは推薦ではなく、あくまで説明目的である。

このセクションはPacktが出版した書籍Modern Network Observabilityから大きな影響を受けている。私はDavid FloresとJosh Vanderaaと共著したその書籍で、TPG（Telegraf-Prometheus-Grafana）スタックやその他のツールを用いた実装を手を動かして学びたい場合には、ぜひ参照してほしい。

6.1. 基礎#

低レベルの詳細に入る前に、ネットワーク自動化戦略の中におけるネットワークオブザーバビリティの基礎を確立し、そのゴール、支持する柱、およびスコープを定義する。

6.1.1. コンテキスト#

おそらく、すでにネットワークを監視しているだろう。Simple Network Management Protocol (SNMP)を使い、System Logging Protocol (Syslog)を見て、リンク使用率を示すダッシュボードを持っている。それが監視だ。物事が機能しているかを教えてくれる。

しかし自動化にはそれ以上が必要だ。ネットワークが変化したとき（自動化が変更したため）、それが何かを壊していないかをすぐに知る必要がある。アラートが発生したとき、コンテキストが必要だ。どの顧客が影響を受けているか？どのサービスが失敗したか？影響範囲はどこまでか？従来の監視はアラームを提供する。自動化にはインテリジェンスが必要だ。

重要な違いを以下に示す:

監視: インターフェースは上がっているか？CPUは高いか？単純なYes/Noの問い。
オブザーバビリティ: なぜインターフェースがダウンしたか？何に影響しているか？どう自動修復するか？これに至った過去の履歴は何か？

オブザーバビリティは自動化を支える。システムがネットワークを観察し、問題を検知し、対処法を決定し、アクションを実行し、修正が機能したかを検証する。そのサイクルの繰り返しが「クローズドループ自動化」と呼ばれる。

従来の監視ツール（SolarWindsのような大規模モノリシックなもの）は、1つの製品ですべてをこなそうとする。それで機能させることは可能だが、不要な機能にコストを払い、必要な機能で制約を受けることが多い。代替策はオブザーバビリティをピースから構築することだ。デバイスに合ったコレクター、データにスケールするストレージ、自動化ワークフローに合ったアラートを選ぶ。これは組み立てが難しいが、はるかに柔軟だ。

本章ではどちらのアプローチも、そしてどちらを選んでも機能するパターンを解説する。

最初の選択はプラットフォームをどこで動かすかだ:

モノリシック（SolarWinds、LibreNMS）: 1製品がすべてをこなす。インストールして設定すれば動く。ネットワークが単純でDevOpsの経験がなければ適している。柔軟性が欲しいかネットワークが特殊な場合は不向きで、そのモデルに縛られる。
クラウドSaaS（Datadog、New Relic、Kentik）: すべてを代わりに運用してくれる。デプロイが早く、インフラの手間なし、すぐに使える美しいダッシュボード。しかしボリュームベースの月額課金で、データはそのサーバーに置かれ（コンプライアンス上問題になる場合がある）、限界に達しても身動きが取れない。オブザーバビリティのSaaSに月5万ドルを支出してCFOを困らせているチームを見てきた。
自前構築（Prometheus + Grafana、またはTelegraf-Prometheus-Grafana (TPG)スタック）: 完全な柔軟性、ベンダーロックインなし、スケールにおける優れた経済性。しかし今やデータベース、メッセージキュー、コレクターインフラを運用する立場になる。これを運用できる人材がいなければ、ネットワーク修正よりオブザーバビリティの修正に時間を費やすことになる。

本当の問いはそれを運用できるチームがあるかだ。あるなら構築する。なければ購入する。自分がどちらのカテゴリーにいるかについて自己欺瞞に陥らないこと。

その選択の後、さらに2つの問いが出てくる:

どこで動かすか？ 自前のオンプレミス（すべてをコントロールするが自分で運用する）、クラウド（運用してもらえるがデータがネットワーク外に出る）、またはハイブリッド（一部はローカル、一部はクラウド）？
コストモデルは何か？ デバイス単位？取り込んだメトリクス単位？定額サブスクリプション？毎分数百万のデータポイントを収集していると、これらの決定はすぐに積み重なる。

6.1.2. ゴール#

オブザーバビリティシステムには7つのことを実現させる必要がある:

すべてを自動的に観測する。 新しいデバイスが接続された？誰かが手動で登録しなくてもデータを報告し始めるべきだ。新しいサービスがオンラインになった？すでに監視されている。これにはオブザーバビリティが何が存在するかを把握できるよう、信頼できる情報源（SoT）との統合が必要だ。
優れたデータで異種環境を扱う。 ネットワークにはおそらくCisco、Arista、Juniper、クラウドプロバイダー、Linuxサーバー、コンテナがある。それぞれデータを公開する方法が異なる。5分間隔のことは忘れよう。自動化が変更を行っているときはほぼリアルタイムのデータが必要だ。
レイヤー間でデータを相関させる。 サーバーが遅い。ネットワークが輻輳しているのか、それともデータベースの問題か？ネットワークデバイス、サーバー、アプリケーションからのデータが共通の言語を話すことで、それらを結びつけることができる。
溶けることなくスケールする。 ネットワークは成長する。毎秒100万のメトリクスを収集しているとき、従来のアーキテクチャは崩壊する。最初からスケールを念頭に置いたシステムが必要だ。
データをインテリジェントに分析できるようにする。 アナリストが事前構築されたダッシュボードだけでなく、強力なクエリで自分自身の問いに答えられるようデータへのアクセスを提供する。リアルタイムデータと履歴（トレンド、異常検知）の両方が必要だ。
問題を検知して自動修復する。 ほとんどの場合、自動化は人間を待たずに問題に対応すべきだ。自動化が判断できない場合にのみ誰かがページを受け取る。そのアラートは生の数値を見せるのではなく、何が悪いかを説明すべきだ。
必要なものを人々に見せる。 多すぎるか間違ったものを見せるダッシュボードは役に立たない。ネットワーク運用チームには彼らのビュー、ビジネスには彼らのビュー、エンジニアには彼らのビューを提供する。各人が仕事をするのに役立つものを受け取る。

6.1.3. 柱#

各ゴールは機能するために特定のビルディングブロックを必要とする。必要なものを以下に示す:

何を観測するかを知る。 SoTにはすべてのデバイス、サービス、認証情報がある。オブザーバビリティがそのデータを自動的に取得することで、コレクターが何を監視すべきかを知る。SoTにデバイスを追加すると、自動的に監視が開始される。
データを効率的に収集する。 古い機器のためのSimple Network Management Protocol (SNMP)、モダンなデバイスへのgRPC Network Management Interface (gNMI)ストリーミング、イベントのためのSystem Logging Protocol (Syslog)、トラフィックのためのフロー（NetFlow、IP Flow Information Export (IPFIX)）、深いトラブルシューティングのためのパケットキャプチャなど、複数の収集方法が必要だ。ツールによって速度もデータの豊富さも異なる。良いニュースは、1つだけを選ぶ必要がないことだ。
すべてを正規化する。 ArstaのメトリクスはCiscoのメトリクスとは見た目が違い、クラウドプロバイダーのメトリクスとも異なる。ログは非構造化テキストで、フローはバイナリだ。これらすべてを共通の言語に変換し、コンテキスト（デバイス、顧客、サービス）を追加するレイヤーが必要だ。
スケールでデータを確実に転送する。 従来の監視パイプラインは直線的だ。コレクター → プロセッサー → ストレージ。スケールではこれがボトルネックになる。各ステージを独立してスケールできるよう分離するメッセージバスとストリーミングプラットフォームが必要だ。
スマートに保存する。 時系列データ（メトリクス）はそれに最適化されたデータベースが必要だ。ログには別のものが必要だ。数百万のデータポイントをミリ秒でクエリできる必要がある。すべてのデータベースが同等ではない。
データをアクションに変える。 生のメトリクスは自動化をトリガーしない。ルールが必要だ。「CPUが90%を超えたら、予定メンテナンスかどうかを確認し、そうでなければこれらのステップを実行する。」そしてそれらのルールが自動化オーケストレーターやアラートシステムに供給される。
視覚的に表示する。 誰も見なければデータは役に立たない。ダッシュボードが必要だが、スマートなもの。異なる人々への異なるビュー、ドリルダウンでき、トレンドと比較を表示できるもの。

最後に、これらの柱を実現する7つの機能を詳述する前に、オブザーバビリティのスコープに含まれるものを明確にしよう。

6.1.4. スコープ#

上で紹介したゴールを拡張すると、オブザーバビリティの責任範囲に属する他のポイントもある:

ユーザーの視点（技術的、運用的、ビジネス的）に合わせた異なる観測レベル
CI/CDパイプラインとの統合、自動テストと検証のためのフィードバック提供
自動化システム自体のオブザーバビリティ（Collector、プロセッサー、アラートシステムのメタ監視）

一方、アーキテクチャの他のコンポーネントに属する機能もある:

ネットワークインテントの定義: ネットワークがどうあるべきか（インテント/SoTの責任）
ネットワーク変更の実行: 実際の修復の実装（Executorの責任）
複雑なワークフローのオーケストレーション: 複数システムにまたがる多段階修復の調整（Orchestratorの責任）

この明確な境界により、Observabilityは検知とインサイトに集中し、他のビルディングブロックがインテント定義、実行、オーケストレーションを担う。

モダンなオブザーバビリティへの移行には慎重な計画が必要だ。1つの監視ツールを別のものに置き換えるほど単純なことだと思わないこと。思考方法を変革する必要がある。大きな力には大きな責任が伴い、選択と調整すべきことが増える。

オブザーバビリティブロックに関連する主要な概念を紹介したこの初期導入の後、次は各機能について詳しく見ていこう。

6.2. 機能#

7つのゴールと柱は7つのコア機能を通じて実現される。各機能はゴールとその支持する柱に対応しており、ビジネス要件から技術的実装まで直接的なチェーンを形成している:

インベントリ: SoTからインテントを消費し、すべての下流コンポーネントにメタデータ、デバイスリスト、収集ターゲットを提供する。
Collector: 複数のプロトコルと収集方法（プルベースのポーリングとプッシュベースのストリーミングの両方）を使用してネットワークから観測データを取得する。
プロセッサー: 異種データを共通スキーマに正規化し、コンテキストメタデータ（タグ、関係、ビジネスコンテキスト）で強化し、その他のデータ操作も行う。
配信: 分散型の非同期パターンを使用してデータプロデューサーとコンシューマーを分離する。Collectorからプロセッサーを経て永続化システムとアラートシステムへデータとイベントを確実に移送する。
永続化: 正規化されたデータを、スケールでの効率的な取り込み、保持、クエリに最適化されたデータベースに保存する。
アラート: 柔軟なルールとしきい値を使用して永続化データを分析し、関心のある条件を検知し、外部システム（自動化または人間への通知）をトリガーするイベントを生成する。
可視化: 異なるユーザーの対象者とユースケースに合わせたダッシュボード、レポート、その他のビジュアルインターフェースに観測データとトリガーされたイベントをレンダリングする。

graph LR

    %% --- Subgraphs ---
    subgraph ゴール
        direction TB
        A1[最小限の人手でネットワーク全体を観測する]
        A2[十分なデータと精度で異種ネットワーク環境をサポートする]
        A3[コンテキストを持つ異なるITレイヤーのデータを観測する]
        A4[大規模ネットワークシナリオに対応する]
        A5[ほぼリアルタイムで高度な分析のための観測データへのアクセスを提供する]
        A6[ネットワーク問題を積極的に検出し回復時間を短縮する]
        A7[ユーザー向けカスタマイズされた可視化を作成する]
    end

    subgraph 柱
        direction TB
        B1[監視対象を把握するためのSoTとの緊密な統合]
        B2[高頻度/オンデマンド更新をサポートする複数プロトコルによるデータ収集能力]
        B3[より豊かな分析のためのコンテキストメタデータによる異種データの正規化]
        B4[スケールアウトアーキテクチャをサポートするスケーラブルなデータ配信システム]
        B5[時系列データと強力なクエリ言語をサポートする永続化レイヤー]
        B6[外部システム統合を備えた柔軟なルール定義とルーティングシナリオ]
        B7[カスタム可視化と複数データストアの統合]
    end

    subgraph 機能
        direction TB
        C1[インベントリ]
        C2[コレクター]
        C3[プロセッサー]
        C4[配信]
        C5[永続化]
        C6[アラート]
        C7[可視化]
    end


    %% --- Row connections ---
    A1 --> B1 --> C1
    A2 --> B2 --> C2
    A3 --> B3 --> C3
    A4 --> B4 --> C4
    A5 --> B5 --> C5
    A6 --> B6 --> C6
    A7 --> B7 --> C7

    %% --- Row gradient classes ---
    classDef row1 fill:#eef7ff,stroke:#4a90e2,stroke-width:1px;
    classDef row2 fill:#ddeeff,stroke:#4a90e2,stroke-width:1px;
    classDef row3 fill:#cce5ff,stroke:#4a90e2,stroke-width:1px;
    classDef row4 fill:#b3d8ff,stroke:#4a90e2,stroke-width:1px;
    classDef row5 fill:#99ccff,stroke:#4a90e2,stroke-width:1px;
    classDef row6 fill:#80bfff,stroke:#4a90e2,stroke-width:1px;
    classDef row7 fill:#66b2ff,stroke:#4a90e2,stroke-width:1px;

    %% --- Apply classes per row ---
    class A1,B1,C1 row1;
    class A2,B2,C2 row2;
    class A3,B3,C3 row3;
    class A4,B4,C4 row4;
    class A5,B5,C5 row5;
    class A6,B6,C6 row6;
    class A7,B7,C7 row7;

これらのコンポーネントはデータパイプラインまたはETL（抽出、変換、ロード）として捉えることができ、以下の図で表される:

flowchart TB
    A[ネットワーク] --> B[コレクター]

    subgraph オブザーバビリティ
       direction LR
       B --> C[配信] -->  D[永続化]
       B -.-> P[処理]
       C -.-> P
       D -.-> P
       D --> E[アラート]
       E -.-> P
       D --> G[可視化]
       X[インベントリ] -.-> B
       X -.-> G
       X -.-> P
    end

    E -.-> F[オーケストレーション]
    G -.-> H[プレゼンテーション]
    Y[SoT] -.-> X

図1: オブザーバビリティパイプライン。

6.2.1. インベントリ#

インベントリコンポーネントはシンプルな問いに答える: 何を監視すべきか？

このデータはすでにどこかにある。信頼できる情報源（SoT）の中だ。デバイス名、IPアドレス、それが何であるか、アクティブかどうか、認証情報がある。それを手動で複製するな。自動的に取り込む。

SoTから必要なもの:

ユニークな名前またはID (デバイスごと、または対象サービスごと。思っているデバイスであることを確認するため)
到達方法: IPアドレス、ホスト名、認証情報（アクティブにデータを取得する必要がある場合）
何であるか: タイプとベンダー（どのCollectorが機能するかを知るため）
アクティブかどうか: 計画中、アクティブ、廃止中（予定ダウンタイムでアラートを出さないため）

基本の先に気にするかもしれないこと:

OSやデバイス固有の情報: 一部のデバイスは異なるプロトコルを使い、古いものは特別な処理が必要
コンテキスト: 誰が所有しているか、どこにあるか、どの顧客が依存しているか（アラートやダッシュボードのフィルタリングに有用）

なぜリストを手動で作る代わりにこれを自動化するのか？人々はリストの更新を忘れるからだ。デバイスが追加され、誰も監視に伝えず、突然可視性が失われる。しかし、オブザーバビリティがSoTから読み込めば、そこにデバイスを追加したときに自動的に監視が開始される。

プッシュ vs プル？

プル: オブザーバビリティがSoTを定期的に更新チェックする。シンプルだが、間隔中に何かが変化したら見逃す。
プッシュ: SoTが変化したとき、オブザーバビリティに自動的にシグナルを送る（Webhook、メッセージバス）。より速く信頼性が高い。

SoTに良いデータがあり、本物の統合（手動のコピー＆ペーストではなく）があれば、インベントリは自動化され、新しいデバイスの観測を見逃すことはない。

6.2.2. コレクター#

データはどこかから来なければならない。Collectorはネットワークとオブザーバビリティプラットフォームの橋渡しだ。デバイスからデータを取得（または受信）し、パイプラインに供給する責任を持つ。効果的なCollectorなしには、下流のすべてがゴミになる。

データフローの所有者という観点から2つの根本的なアプローチがある:

パッシブまたはプッシュ: デバイスがコレクターにデータを送る。Syslogサーバーがルーターからログメッセージを受け取る、またはIPFIXコレクターがフローレコードをリッスンする形態だ。デバイスが何を送るか、いつ送るかを決める。
アクティブまたはポール: Collectorがデバイスにデータを要求する。Simple Network Management Protocol (SNMP)、gRPC Network Management Interface (gNMI)、Representational State Transfer (REST) Application Programming Interface (API)、またはストリーミングデータのサブスクリプションを使って各デバイスに接続し情報を取得する。Collectorが主導権を持ち、何を要求するか、いつ要求するかを決める。

デプロイメントによってもコレクターを分類できる:

エージェントレス: デバイスへのソフトウェアのインストールが不要。中央のコレクターサーバー（通常は別の場所で動作）が各デバイスに個別に接続する。開始は簡単だが、スケールするにつれてボトルネックになる可能性がある。
エージェントベース: 各デバイスやサービスに小さなエージェントをインストールする。エージェントはデータを中央の場所にプッシュするか、ローカルソースから直接取得する。より分散しており、スケールしやすいが、管理する可動部品が増える。

収集方法に関わらず、ネットワーク自動化環境で関心を持たれる可能性のある異なるデータタイプを強調することが重要だ。4つの大きなカテゴリーに分類する:

管理プレーン: デバイスの状態、または設定、ログ、ネットワーク統計に関するデータを読み取る。このグループのプロトコルにはSimple Network Management Protocol (SNMP)、System Logging Protocol (Syslog)、gRPC Network Management Interface (gNMI)、NETCONF、RESTCONFがある。
コントロールプレーン: レイヤー2またはレイヤー3フォワーディングテーブルなど、ネットワークのパケット転送を決定する分散プロトコルが動作する場所だ。OSPFや IS-IS、BGPなどがコントロールプレーンプロトコルの例だ。PingやTraceroute、BMPなどのテレメトリプロトコルによって観測できる。
フォワーディングプレーン: パケットが移動する（ネットワークインターフェースなど）場所で、データ量とベロシティの観点から最も要求が高い。観測する際は、そのプレーンの主目的であるパケット転送に影響を与えないことが重要だ。TcpDump、IPFIX、sFlow、Netflow、Cisco SLA、PSAMP、eBPFなどのツールがこのグループに属する。
外部データ: ネットワークデバイス固有でないすべてのものが含まれる。例えば、外部アセットマネージャーシステムから来る回線プロバイダー情報や特定のインターフェースの連絡先、物理的なIoTセンサーなどがこの広いフィールドに該当する。

flowchart TB
    subgraph ネットワークデバイス/サービス
        direction TB
        A[管理プレーン]
        B[コントロールプレーン]
        C[フォワーディングプレーン]
        A --> B
        B --> C
    end

    D[外部データ]

図2: コレクターのスコープ。

Command Line Interface (CLI)出力のスクリーンスクレイピングはやめよう。みんなやっていたことはわかっている。でも今は2026年で、主要なベンダーはすべて適切なテレメトリをサポートしている。

CLIスクレイピングは壊れやすく（ベンダーが出力フォーマットを変える）、遅く（スクリーンスクレイピングとテキスト解析はコストが高い）、信頼性がなく（ランダムなコマンドタイムアウト）、スケールが非常に難しい。デバイスが古すぎてCLIしかないなら、交換するか、観測性が制限されることを受け入れるしかない。最小公倍数に合わせてモニタリングスタック全体を構築するな。

要するに、収集するものについての2つの核心的な問いに行き着く:

何を収集するか: メトリクス？ログ？フローレコード？それぞれ異なるデータモデルを持つ。SNMPにはMIBがあり、モダンな機器はgNMIを話し、アプリケーションはOpenTelemetryを使う。すべてにわたってデータを相関できる普遍的な標準への夢があるが、まだ存在しない。そのため、これらすべての異なるフォーマットを一貫したものに変換する独自の変換レイヤーを構築する必要があるかもしれない（それが次の処理レイヤーの役割だ）。
どうやって取得するか: どのプロトコル？SNMPは古いが安定しており、gNMIはモダンで継続的にデータをプッシュし、IPFIXは実際に流れているものをキャプチャする。観測しようとしているものによって異なる。

この表は収集可能なものと利用可能なツールをまとめている:

データタイプ	プロトコル/収集方法	注記/例
メトリクス	Simple Network Management Protocol (SNMP), Hypertext Transfer Protocol (HTTP)スクレイピング, Command Line Interface (CLI)ポーリング, OpenTelemetry (OpenTelemetry Protocol (OTLP)), ストリーミングテレメトリ (gRPC Network Management Interface (gNMI))	デバイスメトリクス、ホストメトリクス、アプリケーションメトリクス
ログ	OpenTelemetry (OTLP), ファイルテイリング, syslog	アプリケーションログ、システムログ、構造化ログ
トレース	OpenTelemetry (OTLP)	サービス間の分散トレーシング
ネットワークフロー	NetFlow, IPFIX	トラフィックフロー、送信元/宛先分析
プロトコル固有	BMP, BGP, ARP, OSPF	BGP監視 (BMP)、ARPテーブル、BGPテーブル、OSPFテーブル
パケットキャプチャ	PCAP (libpcap), SPAN/TAP	フルパケット検査、深いトラブルシューティング

表1: 収集するデータとプロトコル。

さまざまな選択肢のより深い理解には、Modern Network Observabilityの書籍を参照してほしい。

ネットワークデータ収集はデータセンター、ISPバックボーン、クラウドネットワークサービス、Linuxカーネルインターフェース、生のパケットに適用される。環境による。

重要なのは、何を収集するかを決める前に、解決しようとしている問題から始めることだ。その決定がすべてを駆動する。インターフェースの飽和を検出しているのか？BGPコンバージェンスを監視しているのか？DDoSトラフィックを追跡しているのか？問題がどのデータが必要でどれくらいの頻度で必要かを決める。

収集されるデータの頻度を増やすため（一部のケースで興味深い）、または収集方法を統一するために、最近採用が増えているパターンをいくつか示す:

ストリーミングテレメトリ

デバイスはYANGモデルを使用してデータを継続的にプッシュする。サブスクリプションを設定すると、データがリアルタイムで流れる。2つの種類がある:

ダイヤルイン: コレクターがデバイスにストリーミング開始を要求する（コレクターが開始）。
ダイヤルアウト: デバイスがあなたへのストリーミングように事前設定されている（デバイスが開始）。

ポーリングより遥かに低いレイテンシで、デバイスがフローの制御を保持する。

flowchart TB
    A[コレクター]
    B[デバイス]
    A -.->|ダイヤルイン| B
    B -->|ストリーミング| A
    B -.->|ダイヤルアウト| A

図3: ストリーミングテレメトリ。

Hypertext Transfer Protocol (HTTP)公開メトリクス

Hypertext Transfer Protocol (HTTP)スクレイピング（プルベースのメトリクス）はシンプルでスケールしやすい。Simple Network Management Protocol (SNMP)もこれを行うが、増えつつあるネットワークOSはPrometheusフォーマットでHypertext Transfer Protocol (HTTP)経由で直接メトリクスを公開している。Collectorが消費しやすく、特別なSimple Network Management Protocol (SNMP) Management Information Base (MIB)解析が不要だ。SONiC、Cumulus、Arista EOSなどがこの方法でメトリクスを公開している。

ベンダー/OS	メトリクスタイプ	メトリクス例
SONiC	インターフェーストラフィック	`sonic_interface_rx_bytes_total{interface="Ethernet32"} 1.234e+12`
NVIDIA Cumulus	インターフェーストラフィック	`node_network_receive_bytes_total{device="swp1"} 9.21e+10`
Arista EOS	インターフェーストラフィック	`arista_interface_in_octets_total{interface="Ethernet1"} 8.3e+11`

表2: HTTP公開メトリクス。

スクレイピングアプローチは低レイテンシとほぼリアルタイムのメトリクス、豊富なラベル、プルベースの収集（レート/タイムアウトの中央制御）を提供し、クラウドスケールのオブザーバビリティと親和性が高い。

OpenTelemetry

OpenTelemetryはテレメトリデータを収集、処理、エクスポートするためのベンダー中立の標準とツールキットだ。ネットワーク、システム、アプリケーション全体でメトリクス、ログ、トレースを統一する共通のテレメトリ言語とパイプラインと考えるとよい。

SNMP、NetFlow、gNMI、BMPなどのネットワークプロトコルを置き換えるものではない。代わりに、収集後のテレメトリの表現と転送方法を標準化する。

従来のネットワーク監視では、データモデルが多様でベンダー固有のスキーマと命名を使用しており、レイヤー間（ネットワーク対システム対アプリケーション）の相関が難しい。対照的に、OpenTelemetryは以下を提供することで助けになる:

メトリクス、ログ、トレースの共通データモデル
gRPC Remote Procedure Call (gRPC)またはHypertext Transfer Protocol (HTTP)上の標準転送プロトコル（OpenTelemetry Protocol (OTLP)）
複数のシグナルタイプに対する単一の処理パイプライン

Grafana AlloyやTelegrafはOpenTelemetry Protocol (OTLP)を実装したCollectorの例だ。異なるエクスポーターからデータを収集し、メトリクス（Prometheus互換のTime Series Database (TSDB)）、ログ（Loki、Elasticsearch、ClickHouse）、トレース（Tempo、Jaeger）などの異なるバックエンドにエクスポートする。

そしてこれにより、入力、プロセッサー、出力ステージを持つモダンなプラガブルコレクターの共通構造に至る。例えばTelegrafでは、OTLPは出力プラグインのオプションだ。

アーキテクチャ上の選択としてのOpenTelemetry

OpenTelemetryの採用は単なるツーリングの決定ではない。オブザーバビリティパイプラインをどう統一するかというアーキテクチャ上の決定だ。2つのアプローチの選択がある:

プロトコルネイティブ: 各シグナルタイプはエンドツーエンドでそのネイティブプロトコルを通じて転送される（gNMIからPrometheus、syslogからElasticsearch、NetFlowからClickHouse）。各パイプラインはそのシグナルに最適化される。コストは複数の独立したパイプラインで共通データモデルを持たないため、シグナルタイプ間の相関が高コストになることだ。

OTelネイティブ: シグナルはできるだけ早い段階でOpenTelemetry Protocol (OTLP)に変換され、単一のパイプラインを通じて統合バックエンドに流れる。メトリクス、ログ、トレース間の相関はデータモデルを共有するため自然だ。コストは、ネットワークデバイスのOTelサポートがまだ成熟していないことだ。ほとんどのベンダーはOTLPをネイティブに発行しておらず、操作の複雑さを増すアダプターレイヤー（gNMIからOTel、SNMPからOTel）が必要になる。

ネットワーク自動化環境の今日における実践的な推奨: ベンダーサポートが充実しているアプリケーション隣接シグナル（自動化プラットフォームのテレメトリ、サービスヘルス、構造化アプリケーションログ）にOTelを採用し、デバイス側のOTelサポートが成熟するまで従来のネットワークテレメトリ（SNMPポーリング、gNMIストリーミング）にはプロトコルネイティブパイプラインを継続する。すべてのネットワークデバイスにアダプターを必要とする時期尚早な標準化を強制するのではなく、両方のアプローチを並列で受け入れられるパイプラインを設計する。

トレンドは明確だ。OpenTelemetryは最終的にすべてのオブザーバビリティデータの標準になるだろう。自動化プラットフォーム自体（第5章のメタ監視）から始めるのは、ネットワークデバイスに拡張する前に親しみを構築するリスクの低い最初のステップだ。

コレクターのアーキテクチャ

簡単に言えば、すべてのコレクターは3つの部分に分解できる（これらがプラガブルな場合もあれば、よりハードコードされた場合もある）。

flowchart LR
    A[入力] --> B[処理] --> C[出力]

図4: コレクターのアーキテクチャ。

入力: 何を観測するか、どのパラメーターで観測するかを定義する。
処理: オプションではあるが、データがデータパイプラインに入った時点でデータ構造の一貫性を確保するために非常に便利だ。処理は非常に複雑になる可能性があり、スケールでパフォーマンスに影響を与えるため、すべての処理をこのレベルで行う必要はない。
出力: コレクターがデータをパイプラインにどう移動させるかを示す。処理や永続化などの他のブロックに直接送ったり、スケールのために配信コンポーネントを使ったりする。

Telegraf、Grafana Alloy、gNMIc、PMACCT、goflowなど多くのコレクター（それぞれ異なる機能を持つ）があるが、同様のアーキテクチャを使用している。選ぶ際（複数必要な場合もある）は、次のようにアプローチする:

デバイスの機能: デバイスはどのプロトコルをサポートしているか？
データ量: 高ボリュームはストリーミングが必要で、低ボリュームはポーリングで可能。
レイテンシ要件: ほぼリアルタイムか従来の間隔か。
チームのスキルとバックエンドとのエコシステムの適合性。

Suzieq、Kentik、その他の「完全な」ネットワークオブザーバビリティソリューションも、カバーされるオブザーバビリティデータのための組み込みコレクターを実装している。

データが収集された後、パイプラインのさまざまな段階でデータを操作するプロセッサーのステップが導入される。

6.2.3. プロセッサー#

コレクターからの生データは乱雑だ。異なるデバイスがメトリクスをそれぞれ異なる方法でエクスポートし、ログは非構造化テキストで、値が異なる単位の場合もある。プロセッサーレイヤーはこれをクリーンにし、有用にする。

ゴール: データが受信されたら、複数のソースからのシグナルを収束させ、相関させ、追加のコンテキストで強化するために、共有標準に準拠しなければならない。このプロセッサーステップなしに、オブザーバビリティパイプラインはすぐに断片化し、クエリが難しく、運用コストが高くなる。スケール、複雑さ、運用要件に応じて、複数の処理機会がある。

以下はオブザーバビリティパイプラインに適用される一般的な処理アクションだ。

6.2.3.1. 正規化/変換#

データはさまざまなフォーマットで来る。Aristaはメトリクスを1つの方法で送り、Ciscoは別の方法で、syslogはテキストで、NetFlowはバイナリだ。正規化はこれらすべてを共通フォーマットに変換するので、バックエンドが50の異なる方言を理解する必要がない。

構造化

デバイスは自分たちに合った方法でデータを発行する。分析に機能するフォーマットに変換するのがあなたの仕事だ:

ログベース:

Mar 18 14:22:11 leaf01 IFACE-5-STATE: swp1 oper-state changed from UP to DOWN

変換後:

{
"timestamp": "2025-03-18T14:22:11Z",
"level": "INFO",
"device": "leaf01",
"component": "interface",
"event": "oper_state_change",
"interface": "swp1",
"previous_state": "UP",
"current_state": "DOWN"
}

メトリクスベース: <メトリクス名>{<ラベル>} <値>

interface_admin_state{hostname="leaf01", ifname="swp1"} 1
interface_oper_state{hostname="leaf01", ifname="swp1"} 0
interface_speed_bps{hostname="leaf01", ifname="swp1"} 100000000000
interface_in_errors_total{hostname="leaf01", ifname="swp1"} 0
interface_out_errors_total{hostname="leaf01", ifname="swp1"} 12

テーブルベース: 一部のツール（Suzieqなど）はデータを表形式の時間インデックス付き状態ビューに整理する:

| hostname | ifname | adminState | operState | speed | inErrors | outErrors | timestamp |
|----------|--------|------------|-----------|-------|----------|-----------|-----------|
| leaf01   | swp1   | up         | up        | 100G  | 0        | 0         | t1        |
| leaf01   | swp1   | up         | down      | 100G  | 0        | 12        | t2        |

リネームとアライメント

異なるテレメトリソースは異なる名前、パス、ラベル規則を使って同じ概念を記述する。例えば:

Openconfig: /interfaces/interface/state/oper-status value: UP tags: source=192.0.2.1 and interface_name=eth1
SNMP: ifOperStatus{ifName="GigabitEthernet0/1", device="router01"} 1
Native Prometheus: interface_oper_state{interface="swp1", host="leaf01"} 1

正規化はオブジェクト名、ラベルのリネーム、値（同じ単位変換を使用）を含む一貫したモデルに整合させる:

intf_oper_state{name="eth1", device="192.0.2.1"} 1
intf_oper_state{name="GigabitEthernet0/1", device="router01"} 1
intf_oper_state{name="swp1", device="leaf01"} 1

6.2.3.2. エンリッチメント#

エンリッチメントは実際に観測されたもの以上の内容をオブザーバビリティデータに追加する。データに追加されたこれらの次元は、より高度なデータ消費を可能にする。例えば、メトリクスがネットワーク上で特定の役割を果たすデバイスに属することを理解し、それに応じて行動できる。

エンリッチメントには2つの主なアプローチがある:

データの拡張 観測データに補完するための追加のメタデータまたはラベルを加える。このデータは静的（例: org=my-companyでデータをマーク）、収集コンテキストに基づく動的（例: collector_id=1234）、または観測データ自体に基づく動的（例: hostname=rtr-1に対してSoTと相関させることでlocation=BCN-01というラベルを作成）のいずれかだ。
```
intf_oper_state{
    name="swp1", 
    device="leaf01",
    role="leaf",
    location="BCN0001"
} 1
```
新しいデータの作成 Prometheusエコシステムの「infoメトリクス」パターンに従い、実際の状態を表さず意図された状態を表すメトリクスを生成できる。これらのメトリクスは後のオブザーバビリティパイプラインステージで分析にさらなる次元を加えるために有用だ（アラートセクションで発見するだろう）。
```
device_info{
    name="leaf1",
    role="leaf",
    vendor="arista",
    model="7050SX3",
    platform="eos",
    os_version="4.29.2F",
    location="BCN0001",
    rack="AB1",
    rack_unit="U32",
    environment="prod"
} 1
```
infoメトリクスは興味深いタイプのデータで、関連データが値（前のメトリクスの1など）ではなくラベルにある。このトリックにより、文字列などの一部の値タイプをサポートしないTime Series Database (TSDB)を再利用できる。

両アプローチともにラベルとコンテキストを追加する。それはアラートと分析に強力だ。しかし考慮すべきコストがある:

カーディナリティ: すべての新しいラベルが時系列を乗算する。デバイス × インターフェース × メトリクスはすでに高カーディナリティだ。注意なくラベルを追加するとストレージが爆発し、クエリが遅くなる。慎重に。
更新頻度: デバイスのラックや管理IPは毎秒変わらない。不安定なメトリクスのようにエンリッチメントデータをポーリングするな。イベント駆動の更新の方が効果的で、信頼できる情報源へのクエリが少なくなる。
レジリエンス: 信頼できる情報源がオフラインになった場合、エンリッチメントが止まる。劣化した状態でも動作し続けられるよう、キャッシュする。自動化はこのデータに依存しているため、堅牢にする。

6.2.3.3. 変換/導出/集計#

生のメトリクスを取って新しいメトリクスを導出する。例: リーフとスパインスイッチのすべてのインターフェース入力トラフィックを単一の「ファブリック帯域幅使用量」メトリクスにマージしてトレンドを追う。既存のデータを組み合わせてより大きな質問に答えるか、ダッシュボードを供給する。Prometheusはこれを「記録ルール」と呼ぶ。

- record: fabric:interface:in_bps
expr: 
    (
    sum by (fabric, role, hostname, name) (
        rate(interface_in_octets_total{role=~"leaf|spine"}[5m])
    ) * 8
    )
    * on (hostname, name) group_left (fabric, role)
    sot_interface_info{role=~"leaf|spine"}

Prometheusエコシステムでは、これは記録ルールとして知られている。

データ量を削減するもう1つの処理機能は集計で、データの最終的な使用に合わせて次元を削減する。例えば、デバイスごとにインターフェース情報をまとめたり、サイトごとにデバイス情報をまとめたりする。例えば、カウンターメトリクスからレート計算を作成したり、ヒストグラムバケットを作成したりすることは、多くの分析に有用だ。

6.2.3.4. フィルタリング#

早い段階でゴミを捨てる。すべてのログラインが保存する価値があるわけではない。すべてのインターフェースメトリクスが重要なわけでもない（ループバックは気にしないかもしれない）。早くフィルタリングするほど、ストレージと処理の無駄が減る。許可リスト（これだけ保持）はブロックリスト（それを捨てる）より安全だ。

6.2.3.5. サンプリング/スロットリング#

フィルタリング後もボリュームが高すぎる可能性がある。スロットリングする。確率的にサンプリング（「これらのリクエストの10%を保持」）、上位Kメトリクスに集中（「最もビジーな100インターフェースのみを保存」）、またはソースごとにレート制限（「デバイスあたり最大1000メトリクス」）する。データベース内のデータが古くなると、ロールアップする（5秒の粒度が5分平均になる）ことでスペースを節約する。

最後に、これらのプロセッサーはすべて、ユースケースに応じてオブザーバビリティパイプラインのさまざまなステージで実行される可能性がある:

コレクター: 軽量な初期正規化とフィルタリングに最適
専用プロセッサー: スケールで動的エンリッチメントと複雑な変換に必要
永続化レイヤー: 記録ルールと長期ロールアップに適している（正規化はこの前に常に行う）
アラートレイヤー: 保存データからイベントを導出し、ビジネスロジックを適用する

実際、効果的なオブザーバビリティパイプラインはツーリング、スケール、運用上の制約に応じてレイヤー間に処理を分散する。

6.2.4. 配信#

単純な線形パイプライン（コレクター → プロセッサー → データベース）はスケールしない。データベースが遅くなると、コレクターがバックアップする。プロセッサーをアップグレードする必要があれば、収集を止める。すべてが密結合で壊れやすい。

ここでメッセージブローカーの出番だ。

Apache KafkaやNATSのようなメッセージブローカーが中間に座る。プロデューサー（コレクター、デバイス）がトピックにパブリッシュする。コンシューマー（プロセッサー、データベース、アラート）が自分のペースで取得する。完全に分離されている。

メリット:

スケーリング: 各コンポーネントが独立してスケールする。
レジリエンス: コンシューマーが遅くてもデータはドロップされず待機する。
柔軟性: 同じデータがソースでの重複なしに複数のバックエンドに供給される。他のものに影響を与えずに1つのコンポーネントをアップグレードまたは再起動できる。

スケーリングと信頼性パターンについては第11章で詳しく説明する。

6.2.5. 永続化#

データが処理されたら、どこかに保存する必要がある。データベースレイヤーはすべてのオブザーバビリティデータを保存する。大きなボリュームを処理し、高速クエリをサポートし、コストを合理的に保つ必要がある。

オブザーバビリティに適したデータベースには共通の特性がある:

時間を意識する: データは本質的にタイムスタンプ付きだ。データベースは範囲クエリと時間ウィンドウ計算に最適化する。
高い書き込みスループット: 継続的なメトリクスの取り込み。データベースは速度を落とさずに処理する。
多次元: メトリクスはラベルを持つ（デバイス、インターフェース、場所）。それらを効率的にクエリして集計する。
柔軟なクエリ: 事前定義されたスキーマなしにデータを探索するための表現力豊かな言語（PromQL、LogQL）が必要だ。
ライフサイクル管理: ストレージは急速に増える。保持、ダウンサンプリング、削除をサポートしてコストをコントロールする。
スキーマの柔軟性: 新しいメトリクスが絶えず現れる。データベースはコストのかかるマイグレーションなしに進化を処理する。

どのデータベースタイプが機能するか？

単一のデータベースがすべてのオブザーバビリティワークロードを完璧に処理することはなく、そう言う人は何かを売ろうとしている。実際に機能するものを示す:

時系列データベース（Time Series Database (TSDB)）: ここから始める。Prometheusはメトリクス戦争に勝利した。そのデータモデル（ラベル付きメトリクス）は事実上の標準となり、PromQLは誰もが知るクエリ言語になった。1億のアクティブシリーズ以下ならPrometheusを使う。それを超えたら、VictoriaMetrics（Prometheusと互換性があり、スケールが良く、メモリ使用が少ない）を検討する。InfluxDBは良いが、ライセンスが変わり続けている。エコシステムにすでにロックインされていない限り、ベンダー固有のソリューションは避ける。
カラム型データベース: ClickHouseはここでの王様だ。ログ集計とフロー分析において驚くほど高速だ。レポートや履歴分析のために数十億行をクエリする必要があるなら、これがツールだ。InfluxDB v3が競合しようとしているが、ClickHouseには長年の強化がある。Parquetファイルはリアルタイム書き込みが不要な分析ワークロード（Suzieqがするように）に有効だ。
テキスト検索データベース: 必要ならElasticsearch、しかし実際には、Loki（Grafanaから）のようなモダンな代替案がシンプルで安く運用できる。Splunkは誰かが費用を払ってくれるなら素晴らしい。不都合な真実: ほとんどのチームはログ検索に過剰投資し、検索を不要にする構造化ログには過少投資している。

推奨: メトリクスにはPrometheus（または同様のもの）、ログにはLoki（または同様のもの）から始める。本格的な履歴分析が必要になったらClickHouse（または同様のもの）を追加する。そのスタックはより高度なものが必要になる前に大規模スケールまで対応できる。

この分類は絶対的ではない。ほとんどのツールには主要な分類があるが、他の特性（特に時系列）も実装している。

ストレージ設計における2つの重要な概念: カーディナリティ（ラベルが取れるユニークな値の数）と次元性（1つのメトリクスが持つラベルの数）。高カーディナリティのラベルと多くの次元の積は保存データの爆発と遅いクエリをもたらす。これはオブザーバビリティの最大の課題の1つだ。深いスケーリング考慮事項については第11章を参照。

各データベースには、解決する必要があるユースケースにマッピングされる特性がある。例えば、SuzieqはApache Parquetファイルによるカラム型ソリューションを使用する。それが答えようとする質問が時系列よりもリレーショナルだからだ。例えば: 「スパインには存在するがすべてのリーフには存在しないルートは何か？」

要件:
- 多くの属性をフィルタリングする
- デバイス間で行を比較する
- テーブルを結合する（インターフェース、ネイバー、ルート）
- ある時点での状態を見る（履歴の変化ではなく）
解決策: これはカラム型分析ソリューションが設計されているものだ。Time Series Database (TSDB)はルート数の確認には役立つが、欠落しているルートを特定するには多くのラベルが必要で、それはその主な強みではない。

すべてのデータ管理の後、2つの最終ステップがある:

他の自動化が使用したり人間が介入したりするためのイベントを作成する: アラート
意思決定のための情報を提供するためにデータを可視化する: 可視化

6.2.6. アラート#

アラートはデータをアクションに変える。ゴールは自動化に供給すること。自動化が修正できないときに人間に通知する。

アラートはステージを通じて流れる:

検知: データ内の問題を見つける。
処理: コンテキストでエンリッチする。重大か？軽微か？誤検知か？ノイズを減らすために関連するアラートを相関させる。
ルーティング: オーケストレーション（ワークフローを実行）、チーム（Slack）、またはインシデント管理（PagerDuty）に送る。
エスカレーション: 自動化が失敗したら、人間が引き継ぐ。

flowchart LR
    A[検知] --> B[プロセッサー] --> C[ルーティング] --> D[エスカレーション]

図5: アラートステージ。

難しいのはアラートの設定ではない。アラート疲れを防ぐことだ。誰もそれらを見なくなった1万のアクティブアラートを持つNOCを見てきた。その時点では監視ではなく、高価なノイズを持っているだけだ。

実際に修正する方法を示す:

アラートの95%を人間ではなく自動化にルーティングする。 人間がアラートを見るのは、自動化が試みて失敗したためであるべきだ。インターフェースのフラッピング？自動化がメンテナンスかどうかを確認し、光学部品を再起動し、ベンダーとのチケットを開く。自動化が解決できない場合にのみ人間がページを受け取る。
静的しきい値をなくす。 「CPU > 80%」のアラートは役に立たない。80%はそのデバイスにとって正常かもしれない。動的なベースラインを使う。何かが任意の数値からではなく、その履歴パターンから逸脱したときにアラートを出す。
関連するアラートをグループ化する。 コアスイッチがダウンすると、下流デバイスから500のアラートが来る。1つを表示する: 「コアスイッチダウン、500デバイスが影響を受けている。」500個の個別アラートではなく。
すべてのアラートにランブックを要求する。 アラートを受け取ったときに誰かが何をすべきかを書き下せないなら、アラートを削除する。真剣に。アクションが「調査する」なら、それはアクションではなく、時間の無駄だ。
アラートの質を測定する。 偽陽性率を追跡する。偽陽性率が10%を超えるアラートは修正するか削除する。確認応答までの時間を追跡する。アラートが何時間も未確認のまま置かれているなら、存在する価値がないほど重要ではない。

ゴールは「包括的な監視」ではない。ゴールは「人間が修正する必要があることだけを人間にページングする」ことだ。

6.2.6.1. オブザーバビリティにおけるAIとAIOpsの役割#

誇大宣伝を切り抜けよう: ほとんどの「AI搭載オブザーバビリティ」はマーケティング予算を持つ異常検知に過ぎない。しかし、正しくデプロイすれば本物の価値がある。

実際に機能するもの:

異常検知: MLは各デバイスの「正常」を学習するという点で静的しきい値より本当に優れている。デバイスAにとって85%のCPUは問題ないが、デバイスBにとっては災害かもしれない。MLはこれを自動的に把握する。これは今や標準であり、魔法ではない。
アラート相関: 50のものが同時に壊れたとき、MLはそれらをグループ化し「コアスイッチがおそらく根本原因だ」と示唆できる。トラブルシューティングの時間を数時間節約する。しかしMLは20%の時間で間違えるため、確認するために人間が必要だ。
キャパシティ予測: MLは「トレンドに基づき、このリンクは6週間で飽和する」という予測がそれほど悪くない。グラフを目視で確認する人間よりも優れている。気にすべきかどうかについては依然として人間の判断が必要だ。

誇大宣伝されているもの:

自動根本原因分析: すべてのベンダーがこれを約束する。信頼性を持って実現しているものはない。提案は得られるが、時に良いものもあるが、「AIが問題を診断して修正した」は95%がマーケティングで5%がセレクティブな例だ。
自己修復ネットワーク: 自動化は既知のソリューションで既知の問題を修正できる。それはAIではなく、良いエンジニアリングだ。新規の問題に対する真の「自己修復」はまだ存在しない。ベンダーがデモするとき、失敗ケースを見せるよう求めよう。
「AIOpsがNOCを置き換える」: いや、AIOpsはNOCをより効果的にするのに役立つ。人間の判断、ビジネスコンテキスト、エッジケースを処理する能力は依然として人間のものだ。

結論: 異常検知とアラートランキングにはMLを使う。ベンダーデモではなく、実際のネットワークでテストするまで他のすべては懐疑的に見る。

6.2.6.2. アラートからアクションへのインターフェース#

人間が読むアラートは通知だ。自動化が消費するアラートはコントラクトだ。この2つのコンシューマーは異なる要件を持っており、それらを混同することがオーケストレーター境界でアラートパイプラインが失敗する最も一般的な理由の1つだ。

アラートが自動化向けである場合、そのペイロードは解析なしに機械が消費できなければならない。つまり、人間が読めるサブジェクト行ではなく、構造化データが必要だ。自動化向けのアラートペイロードには最低限以下を含める:

デバイスアイデンティティ: SoTレコードと正確に一致する正規識別子（DNSとCMDB間で異なる可能性があるホスト名ではなく）
アラートクラス: オーケストレーターがルーティングできる安定した列挙型（アラートルールを誰かが編集したときに変わる自由テキストの説明ではなく）
重大度: 定義された列挙型（数値しきい値ではなく）
タイムスタンプ: 通知配信時刻ではなく、UTC ISO 8601形式のイベント時刻
関連コンテキスト: オーケストレーターが直接読めるフィールドのアラートをトリガーした特定のメトリクスまたは状態（メッセージ文字列に埋め込まれたものではなく、例: "interface": "Ethernet0/1"）
ソーストレース: オブザーバビリティシステムの生のイベントへのリンクまたは参照（オーケストレーターが追加コンテキストのために再クエリできるよう）

このコントラクトを満たすペイロードにより、オーケストレーターは文字列解析なしに、アラートを正しいワークフローにルーティングし、SoTルックアップにデバイスアイデンティティを渡し、構造化パラメーターでエグゼキューターを呼び出すことができる。このコントラクトを満たさないペイロードはオーケストレーターに人間が読めるテキストを解析させることになり、アラートの説明が変わるたびに壊れる。

アラートルールを構築する前に、このコントラクトを定義すること。人間の読みやすさのために書くアラートルール作成者は自動化しにくいメッセージを生成する。両方の対象者のために書くアラートルール作成者はどちらにもうまく機能しないメッセージを生成する。最もクリーンな解決策は2つの並列ルーティングパス: 人間向けの1つのアラートフォーマット（Slack、PagerDuty）、自動化向けの1つのフォーマット（メッセージキュー、Webhookエンドポイント）。同じ検知ルールによって両方がトリガーされ、異なるコンシューマー向けに異なるペイロードテンプレートを使う。

6.2.7. 可視化#

ゴール: 観測されたすべてのデータが意思決定者に価値を提供すべきであり、ユーザー指向の可視化を構築することでユーザーニーズに答えるべきだ。

最後のブロックはダッシュボード/レポートレイヤーだ。率直に言おう: ほとんどのダッシュボードは最悪だ。経営幹部を気持ちよくさせるバニティメトリクス（「99.99%のアップタイム！」）か、データの嘔吐物（1画面に50グラフで、誰もその意味を知らない）のどちらかだ。

実際に役立つダッシュボードの構築方法を示す:

装飾ではなく決定のために構築する。 すべてのウィジェットは特定の質問に答えるか特定のアクションをトリガーすべきだ。グラフを見て何をすべきかわからないなら、グラフを削除する。
データだけでなく問題を見せる。 生の数値より緑/黄/赤のシグナルの方が優れている。「インターフェース使用率: 45%」は役に立たない。「インターフェース使用率: 正常」または「インターフェース使用率: 警告、飽和に向かってトレンド中」はアクション可能だ。
階層的ドリルダウンは1つの大きなダッシュボードに勝る。 グローバルヘルスサマリーから始める（「3サイトに問題あり」）。サイトをクリックしてデバイスヘルスを見る。デバイスをクリックしてインターフェースを見る。5つの集中したダッシュボードは1つの散らかった混乱に勝る。
対象者に合わせる。 NOCスタッフはリアルタイムの運用状態とドリルダウンが必要だ。マネージャーはトレンドサマリーとビジネスインパクトが必要だ。エンジニアは生データアクセスとクエリインターフェースが必要だ。全員に対応しようとする1つのダッシュボードは誰にも対応できない。
インタラクティブにするか、作らない。 静的ダッシュボードはすぐに古くなる。人々がフィルタリング、ズーム、時間範囲の調整ができるようにする。きれいな絵を見せるだけでなく、調査をサポートする。

そして物議を醸す意見: ほとんどのチームはダッシュボードを持ちすぎている。各人が200以上のダッシュボードのうち2つしか見ない組織を見てきた。誰も見ないダッシュボードを削除する。3ヶ月間誰も見なければ、それは重要ではない。

可視化/プレゼンテーションの境界

可視化は脚注として残すよりも直接取り上げる価値があるアーキテクチャ上の境界に位置する。プレゼンテーションレイヤー（第8章）はユーザー向けインターフェースを担当する: アクセスコントロール、セルフサービスポータル、ITSM統合、そして人々が情報をリクエストして消費する方法のユーザーエクスペリエンスデザイン。オブザーバビリティデータの可視化がここ第6章に属するのは、設計上の決定がデータによって完全に駆動されるからだ: どのメトリクスが利用可能か、アラートがどう構造化されているか、永続化レイヤーがどのドリルダウンパスをサポートしているか。データモデルを理解せずに効果的なオブザーバビリティダッシュボードを設計することはできない。

実際に重要な区別: 運用上の決定（今何が起きているか、このサービスは健全か）のためにオブザーバビリティデータに直接構築されたダッシュボードはオブザーバビリティの関心事だ。同じダッシュボードを非技術ユーザーに提供したり、セルフサービスポータルに埋め込んだり、変更管理ワークフローと統合する方法はプレゼンテーションの関心事だ。第8章はアクセスとワークフローの視点からこれらのツールを再訪する。ほとんどの可視化ツール（Grafanaが最も一般的）は両方を行うことでこの線を曖昧にしており、分離が人工的に感じられる。そうではない。同じツールが両方を提供していても、関心事は本当に異なる。

基本ルール:

明確性: 理解しやすい。すべての要素に目的がある。
関連性: 決定を支えるデータのみを見せる。ノイズはインサイトを殺す。
ユーザー焦点: 対象者向けに構築する。NOCスタッフとマネージャーは異なるビューが必要だ。
インタラクティブ: ドリル、ズーム、時間調整ができるようにする。調査をサポートする。
階層的: まずグローバル概要、次にドリルダウン。多くの集中したダッシュボードは1つの散らかったダッシュボードに勝る。

flowchart TD
    A[グローバル概要] --> B[サイトサマリー] --> C[デバイスサマリー] --> D[デバイス詳細] --> E[インターフェース詳細]

図6: 階層的ドリルダウン。

Modern Network Observabilityの書籍第11章（「オブザーバビリティデータの応用」）では、ダッシュボードのアーキテクチャについてより詳しく説明している。

このブロックはユーザー認識と深く関連しているため、ユーザーにインタビューしてプロセスに参加させることを忘れないように。

6.2.8. 自動化システムのオブザーバビリティ#

ほとんどのチームはネットワークのオブザーバビリティを構築する。自動化システム自体のオブザーバビリティを構築するチームはほとんどいない。これは重大な盲点だ: 自動化パイプラインが壊れると、障害はしばしばサイレントだ。アラートを生成する責任があるシステムがちょうど停止したものかもしれないため、アラートが発生しない。

ステータス0で終了したがゼロのデバイスにデプロイしたPlaybookはエラーを生成しない。ベンダー固有のプロトコルのポーリングをサイレントに停止したTelegrafインスタンスは、それを特別に計装しない限り欠落データのアラートを生成しない。午前2時に失敗してインベントリを12時間古い状態のままにしておくSoT同期ジョブは、その後のすべての実行が古いデバイスリストに対して実行されるが、これが起きたことを何もシグナルしない。

自動化プラットフォームで監視すべきもの

実行レイヤー（AWX、Ansible）:
- 時間を経たジョブ成功率: ゆっくり上昇する失敗率は何かが劣化しているという早期警告
- 実行時間: 通常4分かかるジョブが40分かかる場合は、プラットフォーム、ネットワーク、またはその両方に問題があることを示す
- 予想される時間ウィンドウを超えてペンディングまたは実行中の状態で止まったジョブ
- ロールバック頻度: 上昇するロールバック率は通常、インテントデータまたはテンプレートに欠陥があることを意味する
- ジョブごとに到達したデバイス数と期待値: 800の代わりに10デバイスに触れるデプロイメントはエラーなしにサイレントにインベントリ同期に失敗している可能性がある
信頼できる情報源レイヤー:
- APIレスポンス時間とエラー率: 遅いSoT APIはそれをクエリするすべての実行ジョブを停滞させる
- ソース別の同期ジョブヘルス: 最後の成功した同期時刻、連続失敗数
- データ完全性: 実行が依存する必須フィールドが欠落しているデバイスレコードの数
収集レイヤー:
- デバイスごとの最後の成功した収集タイムスタンプ: 3連続インターバルでポーリングされていないデバイスは事実上の監視盲点
- フリート全体の収集遅延: 平均データ年齢が増加している場合、コレクターが遅れている
- プロトコルごとの見逃されたポーリングサイクル: SNMPの失敗とgNMIサブスクリプションのドロップは別々にカウントしてアラートすべき

サイレント失敗問題

検出が最も難しい自動化の失敗は、正常に完了するが意味のある変更を生成しないジョブだ。壊れたインベントリフィルターのためにゼロのデバイスにデプロイするPlaybookはステータス0で終了する。このクラスの失敗を検出する唯一の方法は、結果レベルで計装することだ: 「ジョブプロセスがクリーンに終了したか」ではなく「期待された数のデバイスが状態を変更したか」を確認する。

これは実行ジョブに結果メトリクスを追加することを意味する: 正常に設定されたデバイスのカウンター、ロールバックが必要なデバイスのゲージ、そして少なくともNのデバイスに触れないと成功としてマークしないチェック。

アーキテクチャ上の推奨

自動化プラットフォームは、サポートする主要なオブザーバビリティシステムに依存しない、別の最小限のオブザーバビリティスタックで監視する。メインのPrometheusインスタンスがダウンした場合、自動化パイプラインのアラートはそれと一緒にダウンすべきではない。コア自動化コンポーネント（AWX、Telegraf、SoT API、同期ジョブ）のヘルスをカバーする軽量なセカンダリスタック（またはSaaSアラートサービス）は、主要なオブザーバビリティシステムが自分自身のために提供できないセーフティネットを提供する。

これは第7章（オーケストレーション）に直接つながる: 健全なオーケストレーターは自身の運用状態をファーストクラスの関心事として報告すべきだ。オーケストレーターが観測できなければ、それが調整する自動化も観測できない。

6.3. 実装例#

このセクションでは、Telegraf、Prometheus、Grafanaスタックおよびその他のツールを使用した実用的なユースケースを通じて、オブザーバビリティ機能がどのように組み合わさるかを説明する。

これはツールの推薦では全くなく、完全にオープンソースコンポーネントの上に構築されているため、試すことができる。

6.3.1. ユースケース: キャンパスサービスのデプロイ後検証と継続的監視#

第5章のキャンパスネットワークを継続する。新しいVLANサービスが実行ブロックによってbuilding-bのターゲットスイッチ全体にデプロイされた。今度はオブザーバビリティが引き継ぐ: 最初にデプロイメントがネットワーク状態の観点から実際に成功したかを検証し、次にキャンパス全体でサービスヘルスを継続的に監視する。

シナリオ: Cisco、Arista、HPEからの約800のキャンパススイッチ全体に新しいVLANサービスセグメントをデプロイした後、運用チームはすべての意図されたデバイスでサービスがアクティブで一貫していることを確認し、スイッチがVLANを失った場合の設定ドリフトを検出し、手動でデバイスごとに確認せずに経時的なトラフィックヘルスを監視する必要がある。

要件:

デプロイメント後にすべてのターゲットスイッチでVLANメンバーシップがアクティブで一貫していることを検証する
設定ドリフトのアラート: スイッチからVLANが欠落、予期しないトランクメンバーシップの変更
サービストラフィックヘルスの監視: アクセスポートごとの使用率レベルとエラー率
誤ったルーティングのフローを示す可能性のある突然のトラフィックスパイク（50%以上の変化）を検出する
コンプライアンスとキャパシティ計画のために30秒解像度で30日間のデータを維持する
デバイスインベントリとVLANインテントデータのためにNautobotと統合する
ドリフトが検出されたときの自動修復のためにオーケストレーションワークフローをトリガーする

6.3.2. ソリューションアーキテクチャ#

ソリューション分析を始める前に、シナリオのスケールの見積もりを得ることが重要だ。約800のキャンパススイッチ × 48ポート × 8メトリクス = 約307Kのアクティブ時系列。これは単一のPrometheusノードが処理できる範囲内だが（約1Mシリーズまで快適）、コレクターレイヤーは30秒間隔で800デバイスにポーリング負荷を分散するために複数のTelegrafインスタンスを必要とする。

コンポーネント選択の根拠:

Telegrafはマルチプロトコルサポート（レガシーHPEと古いCiscoデバイスのSNMP、ArstaとよりモダンなCiscoプラットフォームのgNMI）、広範なプラグインエコシステム、データ正規化のための組み込みプロセッサーのためにコレクターとして選択された。800デバイスのスケールでは、30秒ポーリング間隔で単一のTelegrafインスタンスは限界に達するため、各インスタンスが所有するターゲットをConsulが調整しながら2〜3インスタンスをデプロイする。
Prometheusは複雑なアラート条件のための強力なPromQLクエリ言語を持つ時系列データに最適化された永続化レイヤーとして機能する。32Kシリーズではその快適ゾーン内で動作しながら、Alertmanagerとのネイティブ統合を提供する。
GrafanaはPrometheusメトリクスとNautobotメタデータの両方を同時にクエリし、異なる対象者（NOC、キャパシティ計画、管理）向けにカスタマイズされたコンテキスト豊かなダッシュボードを作成するマルチデータソースサポートで可視化を提供する。

アーキテクチャ

高レベルでは、次の図が主要なコンポーネントと役割を示している:

flowchart TB
    subgraph Sources["データソース"]
        NB[Nautobot<br/>信頼できるSoT]
        SW[ネットワークデバイス<br/>SNMP/gNMI]
    end

    subgraph Collection["収集レイヤー"]
        T[Telegraf<br/>コレクター]
        SD[Consul<br/>サービスディスカバリー]
    end

    subgraph Storage["ストレージ"]
        P[Prometheus<br/>TSDB]
    end

    subgraph Alerting["アラート"]
        AM[Alertmanager<br/>ルーティング]
    end

    subgraph Presentation["可視化"]
        G[Grafana<br/>ダッシュボード]
    end

    subgraph Integration["外部システム"]
        ORCH[オーケストレーター<br/>自動化]
        SLACK[Slack<br/>通知]
    end

    NB -->|デバイスインベントリ| SD
    SD -->|動的ターゲット| T
    SW -->|メトリクス| T
    T -->|HTTP公開| P
    P -->|アラートルール| AM
    P <-->|クエリ| G
    NB -->|メタデータ| G
    AM -->|Webhook| ORCH
    AM -->|アラート| SLACK

図7: オブザーバビリティソリューション例。

このシンプルなソリューションアーキテクチャはModern Network Observabilityの書籍で広くカバーされている。ラボシナリオでハンズオンアプローチを試したい場合はぜひ参照してほしい。

6.3.3. 実装フロー#

インベントリ統合: Nautobotは単一の信頼できる情報源として機能し、監視プロファイルとSNMP認証情報を持つ監視対象デバイスを定義する。軽量な同期サービス（例: Webhookを使用したPythonスクリプト）がNautobotからデバイス情報でConsulのサービスレジストリを継続的に更新し、コレクターからの動的ディスカバリーを可能にする。

データ収集: TelegrafはサービスディスカバリーにConsulを使用し、Nautobotに現れるデバイスからSNMPを自動的にポーリングする。Telegrafプロセッサーはデータを正規化してエンリッチし（ステータスコードをラベルに変換、フィールドを標準名にリネーム、Nautobotからのコンテキスト情報を追加）、HTTPエンドポイントでPrometheusフォーマットのメトリクスを公開する。

永続化と分析: PrometheusはConsulサービスディスカバリーを使用してTelegrafエンドポイントをスクレイピングし、時系列データベースにメトリクスを保存する。記録ルールはクエリパフォーマンスを最適化するためにインターフェース使用率のパーセンテージと帯域幅レートを事前計算する。

アラートロジック: Prometheusのアラートルールは条件を定義する（例: 5分間インターフェース使用率>80%、トラフィックスパイク>50%増加）。条件が一致すると、Alertmanagerがルーティングを処理し、automation: enabledラベルの付いた重大なアラートはオーケストレーターWebhookに送られ、それ以外は重大度に基づいてSlackまたはPagerDutyにルーティングされる。

可視化: Grafanaダッシュボードは複数のビューを提供する: ファブリック全体の帯域幅トレンド、上位の飽和インターフェース、インターフェースヒートマップを持つデバイスごとのドリルダウン。テンプレート変数でサイト、役割、デバイスごとのフィルタリングが可能だ。ダッシュボードはコンテキストエンリッチメントのためにPrometheus（メトリクス）とNautobot（デバイスメタデータ）の両方をクエリする。

クローズドループ自動化: 重大な飽和アラートが発生すると、AlertmanagerはオーケストレーションプラットフォームにWebhookを送り、利用可能なパスにわたって負荷を再分散する自動トラフィックエンジニアリングワークフローをトリガーする。このコンポーネントは第7章でカバーする。

6.3.4. ソリューションサマリー#

運用上のメリット:

SoT統合による手動監視作業の削減
1分未満のレイテンシでの積極的な問題検出
MTTRを数時間から数分に削減するクローズドループ修復
メトリクスとインベントリデータを組み合わせた豊かなコンテキスト

スケーラビリティの考慮事項:

現在のアーキテクチャはConsulを背後に持つ2〜3の分散Telegrafインスタンスを使用して約800のキャンパススイッチを処理する。建物やデバイスを追加するには、アーキテクチャの再設計ではなく、コレクターインスタンスを追加するだけでよい。
Prometheusのキャパシティは約307Kシリーズで成長の余地があり十分だ。フェデレーションや分散バックエンドが必要になる前に単一ノードで最大約1Mシリーズを処理できる。

この簡潔なソリューション演習は、ネットワーク自動化アーキテクチャ内のオブザーバビリティの基本的なゴールと機能を定義するこの章を締めくくる。

6.4. サマリー#

ネットワーク自動化におけるオブザーバビリティは従来の監視をはるかに超え、ネットワークの動作を理解し、問題を積極的に検出し、スケールで自動修復を可能にするためのアーキテクチャ的基盤を提供する。最小限の人手での自動発見から高度なリアルタイム分析とユーザー中心の可視化まで7つのコアゴールの上に構築されたオブザーバビリティは、リアクティブなトラブルシューティングから積極的なデータ駆動の運用へとシフトすることで、組織がネットワークイベントに応答する方法を変革する。

これらのゴールの実現には、7つの相互接続されたアーキテクチャの柱と機能が必要だ: 自動インベントリ発見のためのSoT統合、ストリーミングテレメトリとモダンプロトコルを通じたほぼリアルタイムのデータ取り込みをサポートするマルチプロトコルコレクター、コンテキストメタデータで異種データを正規化してエンリッチするプロセッサー、大ボリュームでのスケーラブルなデータ移動のための分散システム、異なるオブザーバビリティワークロードに最適化された専用データベース（時系列、カラム型、テキスト検索）、AI/ML強化された検知とオーケストレーションまたは人間の応答者へのルーティングを持つインテリジェントなアラート、そして異なる対象者に適切な抽象化レベルで情報を提示するカスタマイズされた可視化。

オブザーバビリティの実装には設計プロセスの早い段階でのアーキテクチャ上の決定が必要だ。組織は従来のオンプレミスプラットフォーム、迅速なデプロイメントとAI搭載分析を提供するクラウドネイティブSaaSソリューション、または最大の柔軟性を提供するコンポーザブルなオープンソーススタックの間で選択しなければならない。各アプローチにはコスト、コントロール、運用オーバーヘッド、機能においてトレードオフが伴う。成功はまた、正規化とエンリッチメントからフィルタリングと集計まで、データ処理要件の理解と、アラート疲れを軽減して予測的運用を可能にする新興のAIOps機能の活用にも依存する。

オブザーバビリティは単一のツールではなく、一貫したアーキテクチャパターンだ。成功は、インベントリが収集を駆動し、収集が処理を可能にし、処理が配信を供給し、配信が永続化に接続し、永続化がアラートに情報を与え、アラートが最終的に可視化と自動応答を駆動するシステムとして扱うことに依存する。各コンポーネントとその相互作用を慎重に設計することで、組織はネットワークとともにスケールし、OpenTelemetryやgNMIなどのモダンプロトコルと統合し、運用の可視性をクローズドループ自動化を強化するアクション可能なインテリジェンスに変革するオブザーバビリティシステムを構築できる。

参考文献と追加資料#

Modern Network Observability (David Flores, Christian Adell, Josh Vanderaa): Telegraf、Prometheus、Grafanaなどのオープンソースツールを使用したハンズオンアプローチ

💬 Found something to improve? Send feedback for this chapter