テレメトリを使用したネットワークモニタリング戦略の拡張

SNMP、Syslog、CLI などの従来のポーリング方式を使用してネットワークをモニタしていますか。その場合、ネットワークから抽出したデータは、次の質問に答えるために役立ちますか。

ネットワークトラフィックは現在、ネットワーク帯域幅の何パーセントを消費していますか。
ネットワーク内のすべてのリンクは 100% の使用率で実行されますか。
無人ルータに障害が発生した場合、問題と関連する影響はネットワークオペレータにはリアルタイムで通知されますか。
CPU 使用率が過大または過小ではありませんか。
トラフィックおよびデータ損失に基づいてネットワークの効率性を計算できますか。
トラフィック損失またはネットワーク遅延の原因となるパフォーマンスの問題として、どのようなものが考えられますか。
発生する可能性のある問題をどのようにしてプロアクティブに防止しますか。データはネットワークパターンの調査をリアルタイムでサポートしていますか。

これらの従来の方式では、情報を一定の間隔で要求するプルモデルが使用されています。収集したデータは、管理可能なサイズのネットワークを効率的にモニタするのに役立ちます。ただし、ネットワークがより複雑かつ大規模になるにつれて、ポーリングするデータが効率的かつ効果的なモニタリングを行うためには不十分となる可能性があります。さらに、ポーリング方式ではリソースが大量に消費されるほか、ネットワークオペレータが収集された情報におけるギャップに直面することになります。プルモデルでは、ネットワークデバイス（サーバ）は、データコレクタ（クライアント）が要求した場合にのみデータを送信します。このような要求を開始するには、手動による介入が継続的に必要となります。この手動による介入のため、このモデルは適切ではなく、自動化と拡張性も制限されます。ネットワークの可視性が制限されるため、ネットワークを効率的に制御することができません。ネットワークにさらなる復元力と安定性を与えるモニタリング戦略が必要です。

テレメトリでは、まさにそれが実現されます。テレメトリでは、ネットワークデバイスからデータを自動的にストリーミングするプッシュモデルが使用されます。コレクタが一定の間隔でデータを要求するのではなく、ネットワークデバイスが運用データをリアルタイムでストリーミングします。

テレメトリは、規模、速度、および自動化によって実現される機能に重点を置いています。柔軟性によって実現される機能により、関心のあるデータをルータから選択し、そのデータをモニタリングのため、構造化された形式でリモート管理ステーションに送信することができます。テレメトリを通じて頻繁に得られるきめ細かいデータを利用することで、組織内の DevOps（開発および運用）エンジニアは、問題が発生したらすぐにそれを特定し、調査することができます。これにより、ネットワークのモニタリングおよびより適切な管理を協力して行うことができるようになります。

次の図は、テレメトリプッシュモデルを使用したテレメトリデータのストリーミングの利点を、従来のプルモデルと比較して示します。プルモデルでは、リソースのボトルネックが発生し、ルータから貴重な運用データが取得できなくなることがあります。他方、プッシュモデルは、このようなボトルネックを排除し、データが効率的に提供されるように設計されています。

プッシュモデルベースのモデル駆動型テレメトリを使用する利点を SNMP、Syslog、CLI などのプルモデルベースの従来の手法と比較して示す図。

テレメトリデータによってどのようにネットワーク内のインテリジェンスが利用可能になり、問題をプロアクティブに予測してトラブルシューティングすることが可能になるかについては、こちらのビデオを視聴してください。

この記事では、テレメトリデータを使用する利点と、ネットワークデバイスから意味のあるデータをストリーミングするためのさまざまな方法について説明します。

ネットワークモニタリングをプルモデルからテレメトリプッシュモデルに移行することの利点

リアルタイムのテレメトリデータは、次の場合に役に立ちます。

ネットワークのリモート管理：テレメトリの主な利点は、エンドユーザがネットワーク要素の状態をリモートでモニタできるようになることです。ネットワークの展開後は、ネットワークサイトに駐在して、何が役立っているのか、何が煩雑となっているのか特定することはできません。テレメトリを使用すると、これらの分析情報をリモートロケーションから分析および活用し、実行することができます。
トラフィックの最適化：ネットワーク内でのリンク使用率やパケットのドロップ数を頻繁にモニタリングすると、リンクの追加や削除、トラフィックのリダイレクト、ポリシングの変更などを簡単に行えます。高速再ルーティングのようなテクノロジーにより、ネットワークは新しいパスに切り替わり、従来の SNMP ポーリングインターバルメカニズムよりも迅速に再ルーティングできます。テレメトリデータのストリーミングは、トラフィックの高速転送への応答時間を短縮するのに役立ちます。
予防的なトラブルシューティング：ネットワーク状態インジケータ、ネットワーク統計情報、および重要なインフラストラクチャ情報がアプリケーションレイヤに公開され、操作性能の向上やトラブルシューティング時間の短縮に使用されます。テレメトリを通じて頻繁に得られるきめ細かいデータが、パフォーマンスのモニタリングを向上させ、それによって優れたトラブルシューティングが行えます。
データの可視化：テレメトリデータは、ネットワーク展開に関する貴重な分析情報を可視化するために分析ツールチェーンおよびアプリケーションが使用するデータレイクとして機能します。
分散デバイスのモニタリングと制御：モニタリング機能は、ストレージおよび分析の機能から分離されています。この分離により、デバイスの依存関係を減らせるほか、パイプラインを使用してデータを柔軟に変換できるようになります。これらのパイプラインは、テレメトリデータを消費および変換し、結果として生成されたコンテンツを（通常は既成の）ダウンストリームコンシューマに転送するユーティリティです。サポートされているダウンストリームコンシューマは、Apache Kafka、Influxdata、Prometheus、および Grafana などです。

したがって、テレメトリのストリーミングにより、モニタリングプロセスは、大規模なデータセットを高速で抽出および分析することを可能にし、よりよい意思決定を可能にするビッグデータ計画へと転換されます。

ルータから宛先にテレメトリデータをストリーミングするためのメカニズムの確認

テレメトリデータは、パターン駆動型またはイベント駆動型のいずれかのメカニズムを使用してストリーミングできます。

パターン駆動型テレメトリ

パターン駆動型のテレメトリは、データ（運用統計および状態遷移）を設定されたパターンで継続的にストリーミングします。継続的にストリーミングされるデータの頻度が高いほど、ネットワーク内の新たなパターンを厳密に特定するのに役立ちます。

次の図は、設定された時間間隔での継続的なデータストリームを示しています。

イベント駆動型テレメトリ

イベント駆動型テレメトリは、受信側で収集されたデータを最適化し、状態遷移が発生した場合にのみデータをストリーミングするため、収集されたデータは受信側で最適化されます。たとえば、EDT は、インターフェイスの状態遷移や IP ルートの更新などに関するデータをストリーミングします。

次の図は、状態が変化した後のデータストリームを示しています。

テレメトリデータのストリーミングを可能にする要素について

次の要素は、ネットワーク内のテレメトリを有効にするための構成要素です。

センサーパス

センサーパスは、コンテナを含む YANG データモデル内の YANG パスまたはデータ定義のサブセットを記述します。YANG モデルでは、コンテナ階層内の任意のレベルで終了するようにセンサーパスを指定できます。

YANG モジュールは、ルータのデータを介してデータモデルを定義し、そのデータに対する階層的な組織と制約を定義します。

YANG は 4 つのノードタイプを定義します。各ノードには名前があります。ノードタイプに応じて、ノードは値を定義するか、一連の子ノードを含めます。データモデリングの場合、次のノードタイプがあります。

リーフノード：特定のタイプの単一の値が含まれています。
リーフリストノード：一連のリーフノードが含まれています。
リストノード：一連のリーフリストエントリが含まれています。リーフリストエントリのそれぞれは 1 つ以上のキーリーフによって一意に識別されます。
コンテナノード：子ノードのみを含む関連ノードのグループが含まれます。子ノードは 4 つのノードタイプのいずれかです。

データモデルの詳細については、『Programmability Configuration Guide for Cisco Series Routers』を参照してください。

次の表に、センサーパスの例をいくつか示します。

表 1. センサーパス
機能	センサーパス
CPU	`Cisco-IOS-XR-wdsysmon-fd-oper:system-monitoring/cpu-utilization`
メモリ	`Cisco-IOS-XR-nto-misc-oper:memory-summary/nodes/node/summary`
インターフェイス	`Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters` `Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/data-rate` `openconfig-interfaces:interfaces/interface`
光出力レベル	`Cisco-IOS-XR-dwdm-ui-oper:dwdm/ports/port/info/optics-info`
ノードサマリー	`Cisco-IOS-XR-nto-misc-oper:memory-summary/nodes/node/summary`
転送情報ベース（FIB）	`Cisco-IOS-XR-fib-common-oper:fib-statistics/nodes/node/drops` `Cisco-IOS-XR-fib-common-oper:fib/nodes/node/protocols/protocol/vrfs/vrf/summary`
MPLS トラフィックエンジニアリング（MPLS-TE）	`Cisco-IOS-XR-mpls-te-oper:mpls-te/tunnels/summary` `Cisco-IOS-XR-ip-rsvp-oper:rsvp/interface-briefs/interface-brief` `Cisco-IOS-XR-mpls-te-oper:mpls-te/fast-reroute/protections/protection` `Cisco-IOS-XR-mpls-te-oper:mpls-te/signalling-counters/signalling-summary` `Cisco-IOS-XR-mpls-te-oper:mpls-te/p2p-p2mp-tunnel/tunnel-heads/tunnel-head`
MPLS ラベル配布プロトコル（MPLS-LDP）	`Cisco-IOS-XR-mpls-ldp-oper:mpls-ldp/nodes/node/bindings-summary-all` `Cisco-IOS-XR-mpls-ldp-oper:mpls-ldp/global/active/default-vrf/summary` `Cisco-IOS-XR-mpls-ldp-oper:mpls-ldp/nodes/node/default-vrf/neighbors/neighbor`
ルーティング	`Cisco-IOS-XR-clns-isis-oper:isis/instances/instance/statistics-global` `Cisco-IOS-XR-clns-isis-oper:isis/instances/instance/neighbors/neighbor` `Cisco-IOS-XR-ip-rib-ipv4-oper:rib/rib-table-ids/rib-table-id/summary-protos/summary-proto` `Cisco-IOS-XR-clns-isis-oper:isis/instances/instance/levels/level/adjacencies/adjacency` `Cisco-IOS-XR-ipv4-bgp-oper:bgp/instances/instance/instance-active/default-vrf/process-info` `Cisco-IOS-XR-ip-rib-ipv6-oper:ipv6-rib/rib-table-ids/rib-table-id/summary-protos/summary-proto`

（注）

特定のパスを使用して、目的に合わない可能性のあるデータがストリーミングされないようにします。たとえば、MPLS TE の概要のみに関する情報をストリーミングする場合は、sensor-path Cisco-IOS-XR-mpls-te-oper:mpls-te センサーパスではなく、sensor-path Cisco-IOS-XR-mpls-te-oper:mpls-te/autotunnel/mesh/summary を使用します。

ルータなどの MDT 対応デバイスは、センサーパスをモデル内の最も近いコンテナパスに関連付けます。ルータは、単一のテレメトリメッセージ内でコンテナパスをエンコードしてストリーミングします。受信者は、このコンテナパス以下のすべてのコンテナおよびリーフノードに関するデータを受信します。ルータは、1 つ以上のセンサーパスのテレメトリデータを、設定された頻度で（パターン駆動型テレメトリ）またはイベントの発生時に（イベント駆動型テレメトリ）サブスクライブされたセッションを通じて 1 つ以上のコレクタにストリーミングします。

サブスクリプション

サブスクリプションは、1 つ以上のセンサーパスと宛先をバインドします。

コレクタは、このサブスクリプションを使用して、ルータ上のデータの状態に関する最新情報を受信します。サブスクリプションは、1 つ以上のセンサーパスで構成できます。サブスクライブしたパスのデータについてストリーミングが開始し、セッションがコレクタによって終了されるか、またはテレメトリのサブスクリプション設定が削除されてサブスクリプションがキャンセルされるまで続きます。

エンコーダ

ルータからストリーミングされるデータは、次のいずれかの形式を使用してエンコードできます。

GPB エンコーディング：GPB エンコーディングを設定するには、コンパイルされた .proto ファイル形式のメタデータが必要です。.proto ファイルはデータのストリーミングに使用する GPB メッセージ形式を記述します。.proto ファイルは、Github の [Cisco Network Telemetry Proto] で入手できます。
- コンパクト GPB エンコーディング：データは、圧縮された形式で、かつ自己記述形式ではない形式でストリーミングされます。ストリーミングされたデータを復号化するには、コレクタは各センサーパスに対応する .proto ファイルを使用する必要があります。
- 自己記述 GPB エンコーディング：各センサーパスについてストリーミングされるデータは、自己記述形式の ASCII テキスト形式です。センサーパスのデータの復号化には、コレクタにより、単一の .proto ファイル telemetry.proto が使用されます。自己記述 GPB エンコーディングは、メッセージサイズが大きい場合でも、単一の .proto ファイルでどのセンサーパスのデータも復号化できるため、管理が容易です。
JSON エンコーディング：データはキーの文字列でストリーミングされ、その値は人間に読める形式です。

トランスポート

テレメトリプッシュモデルでは、ルータはトランスポートプロトコルを使用してテレメトリデータをストリーミングします。生成されたデータは、エンコーダを使用して目的の形式にカプセル化されます。

モデル駆動型テレメトリ（MDT）データは、次のサポートされている次のトランスポートプロトコルを通じてストリーミングされます。

Google プロトコル RPC（gRPC）：ダイヤルインモードとダイヤルアウトモードの両方に使用されます。
Transmission Control Protocol（TCP）：ダイヤルアウトモードにのみ使用されます。
User Datagram Protocol（UDP）：ダイヤルアウトモードにのみ使用されます。UDP がコネクションレス型であるため、UDP 宛先はコレクタの状態に関係なく Active として表示されます。これは、ビジーネットワークには最適ではありません。メッセージがコレクタに到達する前にネットワークによって廃棄された場合、プロトコルはデータを再送信しません。

TLS 認証

gRPC プロトコルは、データを暗号化するための Transport Layer Security（TLS）をサポートしています。モデル駆動型テレメトリは、デフォルトで TLS を使用してダイヤルアウトします。

TLS が有効になっている場合、サーバはコレクタに対して認証するための証明書を送信します。コレクタは、どの認証局が署名したかを確認することで証明書を検証し、セッションを暗号化するためのセッションキーを生成します。

TLS 証明書は /misc/config/grpc/dialout/ パスにコピーする必要があります。protocol grpc コマンドのみが設定されている場合、TLS はデフォルトで有効になり、ホスト名はデフォルトで宛先の IP アドレスになります。また、証明書では、Common Name（CN）を protocol grpc tls-hostname <> と設定する必要があります。

次の出力は、gRPC がダイヤルアウトセッションを確立するために使用する証明書を示します。


Router#run
[node:]$ls -l /misc/config/grpc/dialout/
total 4
-rw-r--r-- 1 root root 4017 dialout.pem

TLS オプションをバイパスするには、protocol grpc no-tls コマンドを使用します。

テレメトリセッションを確立する方法について確認する

テレメトリセッションは、ダイヤルアウトモードまたはダイヤルインモードのいずれかを使用して開始できます。テレメトリセッションを確立するためのモードは異なりますが、どちらのモードも同じデータモデルを使用し、同じデータをストリーミングします。

ダイヤルアウトモード

ダイヤルアウトモードでは、ルータが受信者にダイヤルアウトし、サブスクリプションベースのテレメトリセッションを確立します。ルータが接続を開始するため、着信トラフィックのポートを管理する必要はありません。このデフォルトの動作モードでは、セッションを確立するために使用するプロトコルにより、単純性（TCP）またはセキュリティ（gRPC）を柔軟に選択できます。単純なプロトコルで必要なのは、コレクタ上のソケットにアクセスできることだけです。セキュアなプロトコルでは、さらにセッションを認証および暗号化するためのセキュリティ機能が利用できます。そのため、コレクタを保護し、ルータとの通信方法を非常に高度に設定できます。ルータと宛先の間の接続が失われた場合、ルータは宛先との接続を再確立し、データのプッシュを再開します。ただし、再接続中に送信されたデータは失われます。

ダイヤルアウトモードをさらに確認し、ダイヤルアウトセッションを作成するには、ルータからコレクタへのモデル駆動型テレメトリセッションの確立を参照してください。

ダイヤルインモード

ダイヤルインモードでは、コレクタがルータにダイヤルインし、サブスクリプションで指定された 1 つ以上のセンサーパスを動的にサブスクライブします。ルータはコレクタからの接続のために開かれています。このモードは、ルータとの単一の通信チャネルを確立するのに便利です。コレクタがセッションを確立するため、設定で接続先を作成する必要はありません。さらに、セッションを確立するために使用されるプロトコル（gRPC）により、セッションを認証および暗号化するための高度なセキュリティ機能が提供されます。ルータとコレクタの間の接続が失われると、セッションはキャンセルされます。データのストリーミングを再開するには、コレクタがルータに再接続する必要があります。ダイヤルインセッションをサポートするのは gRPC のみです。

ダイヤルインモードをさらに知り、ダイヤルインセッションを作成するには、コレクタからルータへのモデル駆動型テレメトリセッションの確立を参照してください。

ネットワークに適したテレメトリセッションを特定する

ネットワーク内のトランスポートプロトコルおよびエンコーディング形式は、どちらのモードがニーズに適しているか判断するのに役立ちます。エンコーディングの効率性は、ネットワーク上でデータが占有するスペース、メモリ使用率、およびルータからストリーミングする計画のデータ量によって決まります。

単一のルータとコレクタでのシンプルなセットアップを使用してテレメトリデータをストリーミングする計画の場合は、TCP ダイヤルアウトモードを使用します。これは簡単に設定でき、プロトコルに関する幅広い知識は必要ありません。着信接続のポートを管理する必要がなくなります。
セットアップで多数のデバイスへのスケールアウトを行う場合、またはデータの暗号化が必要な場合は、gRPC ダイヤルアウトモードを使用します。このモードでは、着信接続のポートを管理する必要がなくなります。
ネットワークで gRPC をすでに使用していて、固定の宛先にデータをストリーミングするのではなくセッションを動的にする場合は、gRPC ダイヤルインモードを使用します。このモードは、ネットワークの設定および運用データの要求を一元的な方法で行う場合に便利です。

Cisco NCS 560 シリーズルータ（IOS XR リリース 7.1.x）テレメトリコンフィギュレーションガイド

偏向のない言語

翻訳について

Book Title

Cisco NCS 560 シリーズルータ（IOS XR リリース 7.1.x）テレメトリコンフィギュレーションガイド

Chapter Title