gNMI を介したテレメトリ データ サブスクリプションのガイドライン
この項では、gNMI 接続でサポートされるサブスクリプション モードについて説明します。
gNMI プロトコルは、テレメトリ データにサブスクライブするための Subscribe RPC を定義します。テレメトリコレクターは、このRPCを使用して、状態と設定データの更新をネットワークデバイスに要求します。
新しいサブスクリプションの要求は、1 つ以上のリソース パスを含む SubscribeRequest メッセージ内でカプセル化されます。サブスクライブされたパスは、ターゲットネットワークデバイス上の特定のデータインスタンスに関連しています。要求には、OpenConfig またはネイティブの Junos® OS スキーマに基づくパスを含めることができます。
サブスクリプション要求には、次のいずれかのモードも含める必要があります。
-
ONCE- 1 回限りのデータ要求。 -
POLL- データを定期的にオンデマンドで取得するため。 -
STREAM- 指定されたトリガーに従ってデータをストリーミングする有効期間の長いサブスクリプション。
STREAM モードのサブスクリプションでは、以下のサブモードのいずれかを指定する必要があります。
-
ON_CHANGE- データの更新は、データ項目の値が変更された場合にのみ送信されます。 -
SAMPLE- データの更新は、サブスクリプション要求で指定された間隔に基づいて、サンプル間隔ごとに 1 回送信されます。デフォルトのサンプル間隔は 30 秒です。 -
TARGET_DEFINED- サブスクリプション要求を受信するネットワークデバイスが、リーフごとにデータの最適な配信タイプを決定します。メッセージ内で指定されたパスがイベント駆動型データを参照している場合は、ON_CHANGEサブスクリプションが作成される可能性があります。カウンター値を表すデータの場合、SAMPLEサブスクリプションが作成される場合があります。手記：設定パスに対する
TARGET_DEFINEDサブスクリプション要求は、ON_CHANGE要求としてのみ扱われます。
ONCE、ON_CHANGE、SAMPLEサブスクリプションの場合、コレクターはサブスクリプション内のパスの現在の状態を含む初期更新を要求できます。最初の同期更新は、次の理由で役立ちます。
-
コレクターは、そのセンサーパスのデバイス上のすべてのフィールドの現在の状態を完全に把握できます。
-
イベント駆動型データ(
ON_CHANGE)は、次のデータが発生する前に少なくとも1回コレクターによって受信されるため、コレクターは事前にデータの状態を認識し続けることができます。 -
ゼロ抑制機能により通常はストリーミング データに表示されないゼロ カウンター値を含むパケット転送エンジン センサーも送信されます。これにより、各ラインカードのすべてのフィールドがコレクターに認識されます。
ターゲットデバイスは、 SubscribeResponse メッセージでサブスクリプション要求に応答します。サブスクリプション要求で初期同期が呼び出された場合、ターゲットはデータを送信し、その後に sync_response フラグが true に設定された応答メッセージを送信します。初期同期の後、ターゲットデバイスはサブスクリプションモードに従ってパスの更新を続行します。
SubscribeRequestメッセージには、updates_onlyと呼ばれるフラグが含まれています。このフラグを true に設定すると、ターゲットデバイスは初期同期を送信せず、次のように後続の更新のみを送信します。
-
SAMPLEモードのSTREAMサブスクリプションの場合、更新は次のサンプル間隔で送信されます。 -
ON_CHANGEモードのSTREAMサブスクリプションの場合、次の値変更時に更新が送信されます。 -
ONCEサブスクリプションの場合、sync_responseがfalseに設定されたSubscribeResponseのみが送信され、サブスクリプションは閉じられます。 -
TARGET_DEFINEDサブスクリプションは設定パスのON_CHANGEとして扱われ、次の値変更時に更新が送信されます。
SubscribeRequestおよびSubscribeResponseメッセージの内容は、gnmi.proto ファイルで定義されます。サブスクライブ RPC およびサブスクリプション モードの詳細については、『gNMI Specification: Subscribing to Telemetry Updates』の gNMI 仕様を参照してください。
設定パスには、以下の制限があります。
-
POLLサブスクリプションはサポートされていません。 -
プレフィックス パスは更新メッセージに含まれません。
-
gNMI 応答は、
active/inactive、insert before/after、comment/annotate、protect/unprotectなどのジュニパー固有のメタデータ操作ではサポートされていません。これらはメッセージに表示される場合がありますが、無効です。 -
SubscribeRequestでサポートされていないパラメータには、suppress_redundant、heartbeat_level、allow_aggregation、およびqosが含まれます。 -
サポートされている唯一のエンコーディングは PROTO エンコーディングです。
-
SubscribeRequestメッセージの拡張子はサポートされていません -
サブスクリプション パスのフィルタリングは、キー レベルでのみサポートされます。
以下のコミットバリアントは、
ON_CHANGEおよびTARGET_DEFINEDサブスクリプションではサポートされていません。commit at、commit prepare/activate、バッチコミット。コミットは、
edit dynamicおよびedit private編集または構成モード。-
プレゼンス コンテナの更新メッセージは送信されません。
-
識別子またはキーに設定されたリーフが 1 つしかないサブスクリプション リストでは、更新メッセージが生成されない場合があります。
gNMIによる「ON CHANGE」センサーサポートの有効化
Junos OS リリース 16.1 以降では、OpenConfig の動作状態とカウンターの定期的なストリーミングが利用でき、ジュニパー機器から外部コレクタにテレメトリ データをエクスポートできます。必要な情報をすべて収集し、ベースラインの「スナップショット」を作成するのには便利ですが、定期的なストリーミングはタイムクリティカルなミッションにはあまり役に立ちません。外部コレクタON_CHANGE、運用状態が変化した場合にのみ情報を受信するようにストリーミングを設定します。
ON_CHANGE ストリーミングをサポートするために、gRPC ネットワーク管理インターフェイス(gNMI)と呼ばれる新しい仕様が実装され、ネットワーク要素から設定を変更および取得できます。さらに、gNMI仕様を使用して、ネットワーク要素からデータ収集システムへのテレメトリストリームを生成および制御できます。新しい gNMI 仕様では、1 つの gRPC サービス定義で、設定とテレメトリ用にネットワーク要素に 1 つの実装を提供できます。また、ネットワーク管理システム(NMS)が、統合されたテレメトリと設定RPCを通じてデバイスと対話することもできます。
Junosファイルパッケージ(junos-telemetry-interface)には、gnmi.protoファイルとgNMIサポート用のGnmiJuniperTelemetryHeader.protoジュニパー拡張が含まれています。
この機能をサポートする RPC に関する情報は、gNMI Proto ファイル バージョン 0.4.0(サポートされているバージョン)およびリリースされた仕様に記載されています
gNMI サービスのテレメトリ RPC subscribe は、ON_CHANGE ストリーミングをサポートしています。RPC subscribe を使用すると、クライアントはターゲットにデータツリー内の特定のパスの値を送信するように要求できます。値は、ストリーミング (STREAM)、存続期間の長いチャネルで 1 回限りの送信 (POLL)、または検索として 1 回限りの送信 (ONCE) が可能です。
サンプル頻度が 0 の最上位コンテナをサブスクライブすると、ON_CHANGE をサポートするリーフがイベントに基づいてストリーミングされます。他のリーフはストリーミングされません。
どのノードが ON_CHANGE としてストリーミングされるか、またはどのノードが SAMPLE であるかをデバイスに判別させるには、コレクターが sample_interval でTARGET_DEFINEDをサブスクライブする必要があります。
gNMI を使用した「TARGET_DEFINED」サブスクリプション モードの有効化
Junos OS リリース 20.2R1では、MX5、MX10、MX40、MX80、MX104、MX150、MX204、MX240、MX480、MX960、MX2008、MX2010、MX2020、MX10003、MX10008、MX10016ルーターのgNMI(ネットワーク管理インターフェイス)サービスによるTARGET_DEFINEDサブスクリプションモードのサポートが追加されています。
gNMI サブスクリプションを使用する外部コレクタが、センサー データの配信方法を決定します。
-
STREAMINGモードは、指定された間隔でDUTからセンサーデータを定期的にストリーミングします。
-
ON_CHANGEモードでは、データ値が変更された場合にのみ、DUTからのセンサーデータの更新を送信します。
-
新たにサポートされたTARGET_DEFINEDモード(サブモード0)は、DUTに適切なモード(ストリーミングまたはON_CHANGE)を選択して、センサデータの各要素(リーフ)を外部コレクタに配信するように指示します。外部コレクタがサブモード0のセンサーのサブスクリプションをDUTに送信すると、DUTが応答してセンサーサブスクリプションをアクティブ化し、定期的なストリーミングにON_CHANGE更新が含まれないようにします。DUTは、適格なON_CHANGEイベントが発生するたびにコレクターに通知します。
サブスクリプションは、コレクターがサブスクリプション要求で特に指定しない限り、デフォルトで 30 秒の定期的なストリーミング頻度に設定されます。
以下の JavaScript Object Notation(JSON)ファイルは、gNMI サブスクリプションのサンプルを示しています。TARGET_DEFINED モードは、リソース(センサー)パス /interfaces/interface[name='lo0']/state の submode=0 を使用して設定されます。
$ cat gnmi.json
{
"dut_list":[
{
"port":32767,
"rpc":["sub_request"],
"sub_request":{
"subscription":[
{
"path":"/interfaces/interface[name='lo0']/state",
"submode":0,
"sample_interval":30
}
],
"mode":0,
"encoding":2
}
}
]
$ python ./gnmi_subscribe_client_sample.py -c ./gnmi.json -d 10.53.32.102 -l client.log
Junosファイルパッケージ(junos-telemetry-interface)には、gnmi.protoファイルとgNMIサポート用のGnmiJuniperTelemetryHeader.protoジュニパー拡張が含まれています。
詳細については、次の gNMI 仕様と gNMI プロトコル ファイルを参照してください。
gNMI を使用した「INITIAL_SYNC」サブスクリプション モードの有効化
Junos OS リリース 20.2R1 以降、gNMI サービスを使用するパケット転送エンジンセンサーからのINITIAL_SYNC統計情報のサポートが利用可能です。この機能は、MX960、MX2008、MX2010、MX2020、PTX1000、PTX5000ルーターに適用されます。ジュニパーネットワーク®スのルーター PTX10000シリーズ、ジュニパーネットワーク®スのQFX5100スイッチ、およびジュニパーネットワーク®スのQFX5200スイッチでもこのサポートを提供しています。
Junos OS Evolved リリース 20.4R1 以降、gNMI サービスを使用するパケット転送エンジンセンサーからのINITIAL_SYNC統計情報のサポートが利用可能です。ジュニパーネットワークスの® QFX5130-32CDスイッチには、このサポートが含まれています。
外部コレクタがINITIAL_SYNC(gnmi-submode 2)のセンサーのサブスクリプション要求を送信すると、ホストは、そのリソースパスの下にあるサポートされているすべてのターゲットリーフ(フィールド)を、現在の値を持つコレクタに少なくとも1回送信します。これらの統計の収集は、次の理由で有益です。
-
コレクターは、そのセンサーパスのデバイス上のすべてのフィールドの現在の状態を完全に把握できます。
-
イベント駆動型データ(ON_CHANGE)は、次のイベントが発生する前に少なくとも1回はコレクターに到着します。このアプローチにより、次のイベントが発生する前に、コレクターがデータの状態を確実に認識できます。
-
通常はストリーミング データに表示されないゼロ カウンター値(ゼロ抑制)を持つパケット転送エンジン センサーは、少なくとも 1 回は送信されます。このアプローチにより、コレクターは各ラインカードのすべてのフィールド(多くの場合、ソースと呼ばれます)を可視化できます。
INITIAL_SYNCサブモードでは、デバイスが少なくとも 1 つのコピーをコレクターに送信する必要がありますが、複数のコピーを送信することも可能です。
サブスクリプションは、サブスクリプション要求でコレクターが特に指定しない限り、デフォルトで 30 秒の定期的なストリーミング頻度になります。
以下の JavaScript Object Notation(JSON)ファイルは、gNMI サブスクリプションのサンプルを示しています。INITIAL_SYNC モードは、リソース(センサー)パス /interfaces/ の gnmi_submode 2 を使用して設定されます。gnmi_modeは 0 に設定されます。GBPのプロトコルエンコーディングは2に設定されています。
{
"influx": {
"server": "server1",
"port": 8086,
"dbname": "gD40",
"measurement": "OC",
"user": "influx",
"password": "influxdb",
"recreate": true
},
"gnmi": {
"mode": 0, <---- STREAM
"encoding": 2, <--- PROTO encoding
"prefix": "/x/y/z"
},
"host": "10.10.130.73",
"port": 10162,
"user": "user1",
"password": "password1",
"cid": "cid-1jk",
"paths":[
{
"path": "/interfaces/",
"Freq": 10000000000,
"gnmi_submode": 2 <---- SAMPLE
}
]
}
Junosファイルパッケージ(junos-telemetry-interface)には、gnmi.protoファイルとgNMIサポート用のGnmiJuniperTelemetryHeader.protoジュニパー拡張が含まれています。
詳細については、次の gNMI 仕様と gNMI プロトコル ファイルを参照してください。
gNMI テレメトリ仕様 gNMI プロトコル定義
例
次の例は、gNMI クライアントとターゲット デバイスによって行われたサブスクリプション要求と応答を protobuf 形式で示しています。
例: ONCE モード
次の例は、gNMI クライアントから protobuf 形式で送信されたサブスクリプション要求を示しています。サブスクリプション モードは ONCE で、OpenConfig リソース パスは /system/aaa/authentication/users です。
root@controller:~# /usr/local/bin/gnmic sub -a 10.225.0.0:32767 --mode once --path /system/aaa/authentication/users -u <username> -p <password> --format prototext
ターゲットは 1 回限りの更新で応答します。
update: {
timestamp: 1676294840
update: {
path: {
elem: {
name: "system"
}
elem: {
name: "aaa"
}
elem: {
name: "authentication"
}
elem: {
name: "users"
}
elem: {
name: "user"
key: {
key: "username"
value: "test1"
}
}
elem: {
name: "config"
}
elem: {
name: "username"
}
}
val: {
string_val: "test1"
}
}
update: {
path: {
elem: {
name: "system"
}
elem: {
name: "aaa"
}
elem: {
name: "authentication"
}
elem: {
name: "users"
}
elem: {
name: "user"
key: {
key: "username"
value: "test1"
}
}
elem: {
name: "config"
}
elem: {
name: "password"
}
}
val: {
string_val: "$ABC123"
}
}
update: {
path: {
elem: {
name: "system"
}
elem: {
name: "aaa"
}
elem: {
name: "authentication"
}
elem: {
name: "users"
}
elem: {
name: "user"
key: {
key: "username"
value: "test1"
}
}
elem: {
name: "config"
}
elem: {
name: "role"
}
}
val: {
string_val: "superuser"
}
}
update: {
path: {
elem: {
name: "system"
}
elem: {
name: "aaa"
}
elem: {
name: "authentication"
}
elem: {
name: "users"
}
elem: {
name: "user"
key: {
key: "username"
value: "test2"
}
}
elem: {
name: "config"
}
elem: {
name: "role"
}
}
val: {
string_val: "superuser"
}
}
}
例: ON_CHANGE
以下の例は、サブモードを備えた STREAM モードで ON_CHANGE サブスクリプション要求を示しています。OpenConfig リソース パスは /system/aaa/authentication/users/user[username="test1"] です。
root@controller:~# /usr/local/bin/gnmic sub -a 10.225.0.0:32767 --mode stream --stream-mode on-change --path /system/aaa/authentication/users -u <username> -p <password> --format prototext
サブスクリプション要求時の OpenConfig 設定:
user@root> show configuration openconfig-system:system aaa authentication | display set set openconfig-system:system aaa authentication users user test1 config password $ABC123 set openconfig-system:system aaa authentication users user test1 config role superuser
応答メッセージの例では、構成パスの値と、true に設定された sync_response フラグが示されています。
update: {
timestamp: 1676311979
update: {
path: {
elem: {
name: "system"
}
elem: {
name: "aaa"
}
elem: {
name: "authentication"
}
elem: {
name: "users"
}
elem: {
name: "user"
key: {
key: "username"
value: "test1"
}
}
elem: {
name: "config"
}
elem: {
name: "password"
}
}
val: {
string_val: "$ABC123"
}
}
update: {
path: {
elem: {
name: "system"
}
elem: {
name: "aaa"
}
elem: {
name: "authentication"
}
elem: {
name: "users"
}
elem: {
name: "user"
key: {
key: "username"
value: "test1"
}
}
elem: {
name: "config"
}
elem: {
name: "role"
}
}
val: {
string_val: "superuser"
}
}
}
sync_response: true
サブスクライブされたパスに対して、以下の設定変更が加えられます。
-
test1のユーザー名を追加します。 -
test1のパスワードを削除します。
ターゲットデバイスは、応答として次の更新を送信します。
update: {
timestamp: 1676312428
update: {
path: {
elem: {
name: "system"
}
elem: {
name: "aaa"
}
elem: {
name: "authentication"
}
elem: {
name: "users"
}
elem: {
name: "user"
key: {
key: "username"
value: "test1"
}
}
elem: {
name: "config"
}
elem: {
name: "username"
}
}
val: {
string_val: "test1"
}
}
delete: {
elem: {
name: "system"
}
elem: {
name: "aaa"
}
elem: {
name: "authentication"
}
elem: {
name: "users"
}
elem: {
name: "user"
key: {
key: "username"
value: "test1"
}
}
elem: {
name: "config"
}
elem: {
name: "password"
}
}
}
例: サンプル
以下の例は、 STREAM モードと SAMPLE サブモードでのサブスクリプション要求を示しています。OpenConfig リソース パスは /system/aaa/authentication/users/user[username="test1"] です。
root@controller:~# /usr/local/bin/gnmic sub -a 10.225.0.0:32767 --mode stream --stream-mode sample --sample-interval 5s --path /system/aaa/authentication/users -u <username> -p <password> --format prototext
サブスクリプション要求時の OpenConfig 設定:
user@root> show configuration openconfig-system:system aaa authentication | display set set openconfig-system:system aaa authentication users user test1 config username test1 set openconfig-system:system aaa authentication users user test1 config password "$ABC123" set openconfig-system:system aaa authentication users user test1 config role superuser
応答メッセージの例では、 sync_response フラグを true に設定して送信された最初の更新と、5 秒間隔で送信された後続の更新が示されています。
update: {
timestamp: 1676295454
update: {
path: {
elem: {
name: "system"
}
elem: {
name: "aaa"
}
elem: {
name: "authentication"
}
elem: {
name: "users"
}
elem: {
name: "user"
key: {
key: "username"
value: "test1"
}
}
elem: {
name: "config"
}
elem: {
name: "username"
}
}
val: {
string_val: "test1"
}
}
update: {
path: {
elem: {
name: "system"
}
elem: {
name: "aaa"
}
elem: {
name: "authentication"
}
elem: {
name: "users"
}
elem: {
name: "user"
key: {
key: "username"
value: "test1"
}
}
elem: {
name: "config"
}
elem: {
name: "password"
}
}
val: {
string_val: "$ABC123"
}
}
update: {
path: {
elem: {
name: "system"
}
elem: {
name: "aaa"
}
elem: {
name: "authentication"
}
elem: {
name: "users"
}
elem: {
name: "user"
key: {
key: "username"
value: "test1"
}
}
elem: {
name: "config"
}
elem: {
name: "role"
}
}
val: {
string_val: "superuser"
}
}
}
sync_response: true
update: {
timestamp: 1676295459
update: {
path: {
elem: {
name: "system"
}
elem: {
name: "aaa"
}
elem: {
name: "authentication"
}
elem: {
name: "users"
}
elem: {
name: "user"
key: {
key: "username"
value: "test1"
}
}
elem: {
name: "config"
}
elem: {
name: "username"
}
}
val: {
string_val: "test1"
}
}
update: {
path: {
elem: {
name: "system"
}
elem: {
name: "aaa"
}
elem: {
name: "authentication"
}
elem: {
name: "users"
}
elem: {
name: "user"
key: {
key: "username"
value: "test1"
}
}
elem: {
name: "config"
}
elem: {
name: "password"
}
}
val: {
string_val: "$ABC123"
}
}
update: {
path: {
elem: {
name: "system"
}
elem: {
name: "aaa"
}
elem: {
name: "authentication"
}
elem: {
name: "users"
}
elem: {
name: "user"
key: {
key: "username"
value: "test1"
}
}
elem: {
name: "config"
}
elem: {
name: "role"
}
}
val: {
string_val: "superuser"
}
}
}
update: {
timestamp: 1676295464
update: {
path: {
elem: {
name: "system"
}
elem: {
name: "aaa"
}
elem: {
name: "authentication"
}
elem: {
name: "users"
}
elem: {
name: "user"
key: {
key: "username"
value: "test1"
}
}
elem: {
name: "config"
}
elem: {
name: "username"
}
}
val: {
string_val: "test1"
}
}
update: {
path: {
elem: {
name: "system"
}
elem: {
name: "aaa"
}
elem: {
name: "authentication"
}
elem: {
name: "users"
}
elem: {
name: "user"
key: {
key: "username"
value: "test1"
}
}
elem: {
name: "config"
}
elem: {
name: "password"
}
}
val: {
string_val: "$ABC123"
}
}
update: {
path: {
elem: {
name: "system"
}
elem: {
name: "aaa"
}
elem: {
name: "authentication"
}
elem: {
name: "users"
}
elem: {
name: "user"
key: {
key: "username"
value: "test1"
}
}
elem: {
name: "config"
}
elem: {
name: "role"
}
}
val: {
string_val: "superuser"
}
}
}