Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

gNMI を使用したテレメトリ データのサブスクライブ

gNMI プロトコルは、 Subscribe テレメトリ データをサブスクライブするための RPC を定義します。テレメトリ コレクターは、この RPC を使用して、状態と構成データの更新をネットワーク デバイスに要求します。

新しいサブスクリプションの要求は、1 つ以上のリソース パスを含むメッセージ内にSubscribeRequestカプセル化されます。サブスクライブされたパスは、ターゲットネットワークデバイス上の特定のデータインスタンスに関連しています。要求には、OpenConfigまたはネイティブJunosスキーマに基づいたパスを含めることができます。

サブスクリプション要求には、次のいずれかのモードも含める必要があります。

  • ONCE - データの 1 回限りの要求。

  • POLL - データの定期的なオンデマンド検索用。

  • STREAM - 指定されたトリガーに従ってデータをストリーミングする有効期間の長いサブスクリプション。

モードの STREAM サブスクリプションでは、次のいずれかのサブモードを指定する必要があります。

  • ON_CHANGE - データの更新は、データ項目の値が変更されたときにのみ送信されます。

  • SAMPLE - データの更新は、サブスクリプション要求で指定された間隔期間に基づいて、サンプル間隔ごとに 1 回送信されます。デフォルトのサンプル間隔は 30 秒です。

  • TARGET_DEFINED - サブスクリプション要求を受信するネットワークデバイスは、リーフごとにデータの最適な配信タイプを決定します。メッセージ内に指定されたパスがイベント ドリブン データを参照している場合は、 ON_CHANGE サブスクリプションが作成される可能性があります。カウンター値を表すデータの場合、 SAMPLE サブスクリプションが作成されることがあります。

    メモ:

    構成パスのサブスクリプション要求は TARGET_DEFINED 、要求として ON_CHANGE のみ扱われます。

ON_CHANGEおよびSAMPLEサブスクリプションの場合ONCE、コレクターは、サブスクリプション内のパスの現在の状態を含む初期更新を要求できます。この更新は初期同期とも呼ばれ、次の理由で役立ちます。

  • コレクターには、そのセンサーパスのデバイス上のすべてのフィールドの現在の状態の完全なビューがあります。

  • イベント駆動型データ(ON_CHANGE)は、次のイベントが見られる前に、少なくとも1回はコレクターによって受信されます。このようにして、コレクターは次のイベントが発生する前にデータの状態を認識します。

  • パケット転送エンジン センサーは、通常はゼロ抑制のためにストリーミング データに表示されないゼロ カウンター値を含むセンサーが送信されます。これにより、各ラインカードのすべてのフィールドがコレクターに認識されます。

ターゲットデバイスは、サブスクリプション要求にメッセージで SubscribeResponse 応答します。サブスクリプション要求で初期同期が呼び出された場合、ターゲットはデータを送信し、その後にフラグが sync_response に設定された true応答メッセージを送信します。初期同期の後、ターゲットデバイスはサブスクリプションモードに従ってパスの更新を続行します。

SubscribeRequestメッセージには、というupdates_onlyフラグが含まれています。このフラグが trueに設定されている場合、ターゲットデバイスは初期同期を送信せず、次のような後続の更新のみを送信します。

  • モードのSAMPLEサブスクリプションの場合STREAM、更新は次のサンプル間隔で送信されます。

  • モードのON_CHANGEサブスクリプションの場合STREAM、更新は次回の値の変更時に送信されます。

  • サブスクリプションの場合ONCE、 のみが SubscribeResponse に設定falseされてsync_response送信され、サブスクリプションはクローズされます。

  • TARGET_DEFINED サブスクリプションは構成パスと同様に ON_CHANGE 扱われ、次の値の変更時に更新が送信されます。

およびSubscribeResponseメッセージの内容SubscribeRequestは、gnmi.proto ファイルで定義されます。サブスクライブ RPC およびサブスクリプション モードの詳細については、「gNMI 仕様: テレメトリ更新プログラムのサブスクライブ」の gNMI 仕様を参照してください。

メモ:

構成パスには、次の制限が適用されます。

  • POLL サブスクリプションはサポートされていません。

  • プレフィックス パスは、更新メッセージに含まれません。

  • gNMI 応答は、 、 、 active/inactiveinsert before/aftercomment/annotateprotect/unprotect、 などのジュニパー固有のメタデータ操作ではサポートされていません。これらはメッセージに表示されることがありますが、無効です。

  • サポートされていないパラメーター 、qosallow_aggregationheartbeat_levelsuppress_redundantおよび SubscribeRequest が含まれます。

  • PROTO エンコーディングのみがサポートされています。

  • メッセージ内の SubscribeRequest 拡張子はサポートされていません

  • サブスクリプション パスのフィルター処理は、キー レベルでのみサポートされます。

  • 以下のコミットバリアントは、 および TARGET_DEFINED サブスクリプションでON_CHANGEはサポートされていません。

    commit at、 、commit prepare/activateおよびバッチコミット。
  • からのコミットはサポートされていません。

    edit dynamicおよびedit private編集モードまたは構成モード。
  • プレゼンス コンテナの更新メッセージは送信されません。

  • 識別子またはキーが構成されている唯一のリーフであるサブスクリプション リストの場合、更新メッセージが表示されない場合があります。

次の例は、gNMI クライアントとターゲット デバイスによって protobuf 形式で行われたサブスクリプション要求と応答を示しています。

例: ONCE モード

次の例は、gNMI クライアントから protobuf 形式で送信されるサブスクリプション要求を示しています。サブスクリプションモード ONCE は で、OpenConfigリソースのパスは/ system/aaa/authentication/usersです。

ターゲットは 1 回限りの更新で応答します。

例: ON_CHANGE

次の例は、サブモードを使用したON_CHANGEモードでのサブスクリプション要求STREAMを示しています。OpenConfig リソースのパスは /system/aaa/authentication/users/user[username="test1"]:

サブスクリプション要求時の OpenConfig 構成:

応答メッセージの例は、構成パスの値と sync_response フラグが にセットされています true

サブスクライブされたパスに対して以下の構成変更が加えられます。

  • test1ユーザー名を追加します。

  • test1パスワードを削除します。

ターゲットデバイスは、応答として次の更新を送信します。

例: サンプル

次の例は、モードとSAMPLEサブモードでのSTREAMサブスクリプション要求を示しています。OpenConfig リソースのパスは /system/aaa/authentication/users/user[username="test1"]:

サブスクリプション要求時の OpenConfig 構成:

応答メッセージの例では、フラグを に設定trueしてsync_response送信された最初の更新と、5 秒間隔で送信される後続の更新を示しています。