ダイヤルインテレメトリについて
ダイヤルインテレメトリは、コレクターがデバイスへの接続を開始してテレメトリデータを取得するネットワーク監視方法です。コレクターはネットワーク デバイスに「ダイヤルイン」し、通常は gRPC などのプロトコルを使用してデータを要求および受信します。
ダイヤルインモードでは、データコレクターがネットワークデバイスへの接続を開始し、テレメトリデータにサブスクライブします。コレクターとデバイス間でセッションが確立され、設定された間隔でデータがデバイスからコレクターにストリーミングされます。この方法は、単一の設定と運用データチャネルを必要とするオペレーターに好まれます。
JTIは、gRPCトランスポートを介したgNMIとJuniper Juniper Extension Toolkit(JET)ダイヤルイン接続の両方をサポートします。
JTI におけるジュニパーの gNMI サポートは、主にダイヤルアウトです。デバイスは gRPC クライアントとして機能し、コレクターは gRPC サーバーです。ダイヤルイン(デバイスに接続するコレクター)は、gNMI/gRPCテレメトリストリーミングの標準JTI機能ではありません。ただし、オンデマンド要求(たとえば、データを取得するための 1 回限りの「取得」操作)にはダイヤルイン方式で gNMI を使用できますが、これは永続的なテレメトリ サブスクリプションとは異なります。ストリーミング テレメトリの場合、JTI の gRPC は通常、デバイスによって開始されます。gNMI ダイヤルイン接続の場合は、gNMI サービスをイネーブルにする必要があります。POLL (コレクター、ポーリング、スナップショット)、および ONCE (単一スナップショット) サブスクリプションモードがサポートされています。
gRPC サービス
gRPC は、安全で信頼性の高いデータ転送を提供するオープンソースのフレームワークです。一連のリモート プロシージャ コール(RPC)インターフェイスを使用して、Junos Telemetry Interface を設定し、gRPC フレームワークを使用してテレメトリ データをストリーミングできます。gRPC リモート プロシージャ コール(gRPC)は、センサーのプロビジョニングとテレメトリ データのサブスクライブと受信に使用されます。OpenConfig は YANG データ モデルをサポートします。OpenConfig データ モデルは、ユニバーサル キー/値形式の GPB(Google Protocol Buffer)メッセージとしてデータを生成します。
gRPC を使用したデータのストリーミング
OpenConfig 仕様によると、ストリーミング データでは gRPC ベースのトランスポートのみがサポートされています。gRPC サーバーは、クライアントを実行する管理システムから gRPC セッションを終了します。RPC呼び出しは、データを定期的にストリーミングするか、イベントを報告するJunos OSセンサーの作成をトリガーし、適切なgRPCチャネルに送ります。
Junos OS リリース 18.2R1 以降、外部ストリーミング サーバーまたはコレクターが、Junos OS を実行しているデバイスで gRPC を介してデータをエクスポートするようにセンサーをプロビジョニングすると、センサー構成は一時構成データベースの junos-analytics インスタンスにコミットされ、 show ephemeral-configuration instance junos-analytics 操作コマンドを使用して構成を表示できます。以前のリリースでは、センサー設定はエフェメラル設定データベースのデフォルトインスタンスにコミットされています。
アップデートの一部としてエクスポートされたJuniperテレメトリヘッダーは、拡張ヘッダーとしてエクスポートされるようになりました。GnmiJuniperTelemetryHeader.protoは、Junos OS リリース19.3以前を実行しているジュニパーデバイスからのアップデートをデコードするために使用され、GnmiJuniperTelemetryHeaderExtension.protoは、Junos OS リリース19.4以降を実行しているデバイスに使用されます。
Junos Telemetry Interfaceをサポートするために実装されたRPCの一覧と説明については、 表1 を参照してください。
| RPC 名 |
形容 |
|---|---|
|
|
テレメトリパラメータを指定し、指定されたOpenConfigパスのリストのデータをストリーミングします。 |
|
|
|
|
|
|
gRPC を介してストリーミングされるデータは、プロトコル バッファ(gpb)メッセージ内の OpenConfig のキーと値のペアでフォーマットされます。このユニバーサル形式では、キーは、監視対象のデバイスのOpenConfigスキーマ内のシステムリソースのパスに対応する文字列です。値は、インターフェイス カウンターなどのシステム リソースの運用状態と、リソースの状態を識別する整数または文字列に対応します。
Junos OS リリース 18.2R1 以降、gRPC を介してストリーミングされるデータは、OpenConfig ベースのルーティング エンジン(RE)センサーのキーと値のペアに加えて、protobuf としてフォーマットできます。これらのセンサーは、パケット転送エンジン(PFE)センサーに追加されます。
次に、ユニバーサル キー/値の形式を示します。
message KeyValue {
string key = 1 [(telemetry_options).is_key = true];
uint64 int_value = 2;
string str_value = 3;
string prefix_str = 4;
}
message TelemetryStream {
// router name or export IP address
required string system_id = 1 [(telemetry_options).is_key = true];
// line card / RE (slot number)
optional uint32 component_id = 2 [(telemetry_options).is_key = true];
// PFE (if applicable)
optional uint32 sub_component_id = 3 [(telemetry_options).is_key = true];
// timestamp (common to all entries in the kv array)
optional uint64 timestamp = 4 [(telemetry_options).is_timestamp = true];
// key / value pairs
repeated KeyValue kv;
}
次の例は、インターフェイスのカウンターのセットをどのように表現できるかを示しています。
key = “/interfaces/counters/rx-bytes”, int_value = 1000 key = “/interfaces/counters/tx-bytes”, int_value = 2000 key = “/interfaces/counters/rx-packets”, int_value = 10 key = “/interfaces/counters/rx-bytes” , int_value = 20 key = “/interfaces/counters/oper-state”, str_value = “up”
マッピング テーブルは、フィールド名を OpenConfig キー文字列にマッピングします。
OpenConfigを使用してJunos Telemetry Interfaceを有効にする
Junos OS向けOpenConfigは、Junos Telemetry Interfaceを有効にするRPCモデルを指定します。このパッケージには、必要な YANG モデルも含まれています。
すべての YANG データ モデルは 、特定の OS の GitHub リポジトリにあり、1 つのダウンロード パッケージでリリースできます。パッケージとリポジトリには、ネイティブの設定、状態、RPC データ モデルと、その OS でサポートされている OpenConfig および IETF データ モデルが含まれています。また、ジュニパーネットワークスのダウンロード サイトから YANG データ モデルにアクセスすることもできます。
Web ブラウザを使用して、ジュニパーネットワークスの Web ページですべての Junos プラットフォーム ソフトウェアのダウンロード URL に移動します。 https://www.juniper.net/support/downloads/。 [Network Management] タブで、下にスクロールして [OpenConfig] を選択します。「ソフトウェア」タブを選択します。適切なバージョンの OpenConfig モジュールを選択します。
プログラム インターフェイスは、テレメトリ gRPC サービスを定義する OpenConfigTelemetry 。 telemetrySubscribe RPC は、次のサブスクリプション パラメーターを指定します。
-
テレメトリデータをストリーミングするシステムリソースを特定するOpenConfigパス(例:
/interfaces/interface/state/counters/ -
データが報告され、コレクター サーバーにストリーミングされる間隔 (ミリ秒単位)。
sample_frequency = 4000
telemetrySubscribe RPC は、ストリーミング サーバー (コレクター) によって使用され、指定されたパスにあるデータのインライン サブスクリプションを要求します。その後、デバイスはサブスクリプション要求と同じ接続でテレメトリ データを送り返す必要があります。
gRPC サーバーの概要
Junos Telemetry Interface(JTI)には、マルチポート サービス構成の機能が含まれており、異なるポートでリッスンするテレメトリ サービスの複数のセットを設定できます。
テレメトリ インターフェイスには柔軟な gRPC サービス設定機能が導入されており、それぞれ異なるサービス、リスニング アドレス、ポートを持つ複数の gRPC サーバーをセットアップできます。この機能により、サービス管理とテレメトリデータ収集をきめ細かく制御できます。各サーバーのTLS証明書を設定して、安全な通信を確保できます。gRPC サーバーを構成するには、「 gRPC サービスの構成」を参照してください。
gNMIサービス
gNMI(gRPC Network Management Interface)は、ネットワーク デバイスの設定と監視を行う gRPC をベースにしたプロトコルです。ネットワーク管理専用にOpenConfigによって開発されたgNMIにより、ネットワーク事業者はデバイス設定データを取得および変更し、ネットワークデバイスからのリアルタイムテレメトリデータをサブスクライブできます。データ収集は、テレメトリソリューションの重要なタスクです。gNMIは、テレメトリ更新用に、ONCE、POLL、STREAMなどのサブスクリプションモードをサポートしています。gNMIは、gRPCフレームワークを活用し、プロトコルバッファ(protobuf)などの効率的なデータエンコーディング形式を使用し、TLSを使用して安全な通信を保証します。YANGモデルを使用して、設定やテレメトリデータの構造を定義します。
gNMI の主なコンポーネントは次のとおりです。
-
gNMI クライアント:外部システムで実行します。gNMI 要求を送信して、デバイスの設定、設定データの取得、テレメトリ ストリームへのサブスクライブを行います。
-
gNMIサーバー:ネットワークデバイス上で実行され、テレメトリおよび設定データへのアクセスを提供します。gNMI サーバは、リクエストのタイプに基づいてリクエストを処理します。構成管理の変更の場合は、デバイス構成を更新し、クライアントに応答を送信します。テレメトリ データ収集要求の場合、データは gNMI クライアントにストリーミングされます。
gNMI は、ネットワーク デバイスの管理と監視のために、以下のリモート プロシージャ コール(RPC)をサポートしています。
-
Get: この RPC は、構成や運用データなど、ネットワーク デバイスの現在の状態を取得します。
手記：gNMI get コマンドでは、
typeオプションを使用して、取得するデータのタイプを指定します。使用可能なオプションは、CONFIG、STATE、およびALLです。有効な type オプションはCONFIGです。エンコーディングは、gNMI プロトコルでサポートされる値エンコーディング形式を定義します。JSON、BYTES、PROTO、ASCII、およびJSON_IETFが利用可能なオプションです。有効なエンコード オプションはJSON_IETFとASCIIです。有効なオプション以外の設定を選択すると、エラーメッセージが表示されます。 -
設定:設定されたRPCは、ネットワークデバイスの設定を変更します。
-
サブスクライブ: この RPC を使用して、ネットワーク デバイスからのテレメトリ データをサブスクライブできます。次のサブスクリプションモードがサポートされています。
- ONCE: 現在の値を一度だけ取得します。
- POLL: ポーリング・メッセージを受信するたびに、現在の値を送信します。
- STREAM: 指定した間隔で、または変更が発生したときに、更新を継続的に送信します。
詳細については、gNMI 経由のテレメトリ データ サブスクリプションのガイドラインを参照してください。
-
機能: この RPC は、サポートされているモデルやエンコードなど、ネットワーク デバイスの機能を検出します。
gNMI の起点
Pathメッセージの origin フィールドは、パスが属するスキーマを識別します。 originは文字列としてエンコードされます。メッセージ内で指定されたパスは、<origin, path> のタプルによって一意に識別されます。
origin フィールドは、Pathメッセージのどのコンテキストでも有効です。通常、次のように使用されます。
- 特定のスキーマがターゲット構成の変更に使用されていることを示す
SetRequest内。 - 特定のスキーマの内容を取得する
GetRequest、またはペイロードに特定の<origin, path>スキーマからのデータが含まれていることを示すGetResponse。 - 特定のスキーマ内のパスをサブスクライブする
SubscribeRequest、または更新が特定の<origin, path>タプルに対応することを示すSubscribeResponse。
1 つのメッセージ内で複数のoriginが使用されている場合、プレフィックスはメッセージ内のすべてのパスに適用されるため、prefix内のパスを指定することはできません。prefixを指定する場合は、必要なoriginを指定する必要があります。1 つのリクエストで、RPC ペイロード メッセージの prefix フィールドと path フィールドの両方に origin を指定してはなりません。
原産地の特別な値
起点値は、gNMI プロトコルのアウトオブバンドで合意されます。 origin フィールドが指定されていない場合、その値はデフォルトで openconfigになります。原点を明示的に設定することをお勧めします。
YANGモデルデータのオリジンの定義
openconfig-extensions:originフィールドは、特定のモジュールがインスタンス化される原点を決定するために利用され得る。
originnamespaceとは異なります。YANG 名前空間はスキーマ ツリー内の任意の深さで定義されますが、originはスキーマ ツリー全体のあいまいさを解消するためにのみ使用されます。つまり、ルートにない要素は、そのルートを構成する YANG スキーマ モジュールに関係なく、ルート エンティティからそのoriginを継承します。
セット内の原点の部分仕様
Set RPC が、Path メッセージ内にoriginを含む delete、update、または replace フィールドを指定する場合、対応する変更は、次の方法で指定されたオリジンに制限する必要があります。
replace操作は、指定されたパスにある指定されたoriginの内容のみを置き換える必要があります。SetRequest内で指定されていない配信元は、その内容を置き換えてはなりません。replace操作でoriginの内容を置き換えるには、SetRequestで明示的に指定する必要があります。delete操作では、指定されたorigin内の指定されたパスにあるコンテンツのみを削除する必要があります。複数の配信元からコンテンツを削除するには、クライアントはSetRequestのdelete内に複数のパスを指定する必要があります。
これらのルールは、配信元が重複しないデータを表す場合に適用されます。場合によっては(CLIやOpenConfigなど)、オリジンは同じデータに対する異なる「ビュー」を反映することがあり、その結果、それらの相互作用はより複雑になります。
複数のオリジンを持つセットのトランザクション性
SetRequestが複数のoriginを指定する場合、つまり、パスに複数のオリジンが含まれる2つ以上の操作の場合、影響を受けるすべてのツリーに対する操作は、単一のトランザクションと見なす必要があります。つまり、すべてのトランザクションが成功した場合にのみ、SetResponseは成功を示す必要があります。いずれかのトランザクションが失敗した場合は、すべてのオリジンの内容をロールバックし、Set RPC への応答時にエラーステータスを返す必要があります。