Richtlinien für Telemetriedatenabonnements über gNMI
In diesem Abschnitt werden die Abonnementmodi beschrieben, die von gNMI-Verbindungen unterstützt werden.
Das gNMI-Protokoll definiert den RPC für das Subscribe Abonnieren von Telemetriedaten. Der Telemetriesammler verwendet diesen RPC, um vom Netzwerkgerät Aktualisierungen für Zustands- und Konfigurationsdaten anzufordern.
Anforderungen für neue Abonnements werden in einer Nachricht gekapselt, die SubscribeRequest einen oder mehrere Ressourcenpfade enthält. Die abonnierten Pfade beziehen sich auf bestimmte Dateninstanzen auf dem Zielnetzwerkgerät. Die Anforderung kann Pfade enthalten, die auf OpenConfig oder nativen Junos® OS-Schemata basieren.
Die Abonnementanforderung muss außerdem einen der folgenden Modi enthalten:
-
ONCE- Eine einmalige Datenanfrage. -
POLL- für den periodischen, bedarfsgerechten Abruf von Daten. -
STREAM- Ein langlebiges Abonnement, das Daten gemäß bestimmten Triggern streamt.
Abonnements im STREAM Modus müssen einen der folgenden Untermodi angeben:
-
ON_CHANGE- Datenaktualisierungen werden nur gesendet, wenn sich der Wert des Datenelements ändert. -
SAMPLE- Datenaktualisierungen werden einmal pro Abtastintervall basierend auf einem in der Abonnementanforderung angegebenen Intervallzeitraum gesendet. Das Standardabtastintervall beträgt 30 Sekunden. -
TARGET_DEFINED- Das Netzwerkgerät, das die Abonnementanforderung erhält, bestimmt die beste Art der Bereitstellung für die Daten auf Leaf-Basis. Wenn sich der in der Nachricht angegebene Pfad auf ereignisgesteuerte Daten bezieht, wird möglicherweise einON_CHANGEAbonnement erstellt. Für Daten, die Zählerwerte darstellen, kann einSAMPLEAbonnement erstellt werden.Anmerkung:Die
TARGET_DEFINEDAbonnementanforderungen für Konfigurationspfade werden nur alsON_CHANGEAnforderungen behandelt.
Für ONCEund ON_CHANGE SAMPLE Abonnements kann der Collector ein erstes Update anfordern, das den aktuellen Status der Pfade im Abonnement enthält. Ein erstes Synchronisierungsupdate ist aus folgenden Gründen wertvoll:
-
Der Kollektor hat eine vollständige Ansicht des aktuellen Zustands jedes Feldes auf dem Gerät für diesen Sensorpfad.
-
Ereignisgesteuerte Daten (
ON_CHANGE) werden vom Collector mindestens einmal empfangen, bevor der nächste auftritt, wodurch sichergestellt wird, dass der Collector den Datenzustand vorher kennt. -
Packet Forwarding Engine-Sensoren, die Null-Zählerwerte enthalten, die normalerweise aufgrund der Nullunterdrückungsfunktion nicht in gestreamten Daten angezeigt werden, werden ebenfalls gesendet. Dadurch wird sichergestellt, dass alle Felder jeder Linecard dem Kollektor bekannt sind.
Das Zielgerät antwortet auf die Abonnementanforderung mit einer SubscribeResponse Nachricht. Wenn die Abonnementanforderung eine erste Synchronisierung aufruft, sendet das Ziel die Daten, gefolgt von der Antwortnachricht, wobei das sync_response Flag auf festgelegt ist true. Nach der ersten Synchronisierung fährt das Zielgerät mit Updates für die Pfade gemäß dem Abonnementmodus fort.
Die SubscribeRequest Nachricht enthält ein Flag mit dem Namen updates_only. Wenn dieses Flag auf truefestgelegt ist, sendet das Zielgerät keine erste Synchronisierung, sondern nur nachfolgende Aktualisierungen wie folgt:
-
Bei
STREAMAbonnements imSAMPLEModus wird das Update im nächsten Beispielintervall gesendet. -
Bei
STREAMAbonnements imON_CHANGEModus wird das Update bei der nächsten Wertänderung gesendet. -
Bei
ONCEAbonnements wird nur dieSubscribeResponsemitsync_responseset tofalsegesendet, und das Abonnement wird geschlossen. -
TARGET_DEFINEDAbonnements werden wieON_CHANGEKonfigurationspfade behandelt, und das Update wird bei der nächsten Wertänderung gesendet.
Der Inhalt der und-Nachrichten ist in der SubscribeRequest SubscribeResponse Datei gnmi.proto definiert. Weitere Informationen zu den Abonnement-RPC- und Abonnementmodi finden Sie in der gNMI-Spezifikation unter: gNMI-Spezifikation: Abonnieren von Telemetrieupdates.
Für Konfigurationspfade gelten folgende Einschränkungen:
-
POLLAbonnements werden nicht unterstützt. -
Präfixpfade sind in den Aktualisierungsmeldungen nicht enthalten.
-
Die gNMI-Antwort wird für Juniper-spezifische Metadatenvorgänge wie
active/inactive,insert before/after,comment/annotateundprotect/unprotectnicht unterstützt. Diese werden möglicherweise in der Nachricht angezeigt, sind aber ungültig. -
Nicht unterstützte Parameter in den include-Parametern
SubscribeRequestsuppress_redundant,heartbeat_level,allow_aggregationundqos. -
Die PROTO-Codierung ist die einzige unterstützte Codierung.
-
Erweiterungen in
SubscribeRequestNachrichten werden nicht unterstützt -
Das Filtern des Abonnementpfads wird nur auf Schlüsselebene unterstützt.
Die folgenden Commit-Varianten werden für
ON_CHANGEundTARGET_DEFINEDSubskriptionen nicht unterstützt:commit at,commit prepare/activateund Batch-Commits.Commits werden von der
edit dynamicund Bearbeitungs- oderedit privateKonfigurationsmodi.-
Für Anwesenheitscontainer werden keine Aktualisierungsmeldungen gesendet.
-
Abonnementlisten, die nur ein konfiguriertes Leaf für den Bezeichner oder Schlüssel enthalten, generieren möglicherweise keine Aktualisierungsmeldung.
Ermöglichung von "ON CHANGE"-Sensorunterstützung durch gNMI
Seit Junos OS Version 16.1 ist ein regelmäßiges Streaming von OpenConfig-Betriebszuständen und -Zählern verfügbar, wobei Telemetriedaten von Geräten des Juniper Computers in einen externen Kollektor exportiert werden. Obwohl es nützlich ist, um alle benötigten Informationen zu sammeln und einen Baseline-"Snapshot" zu erstellen, ist regelmäßiges Streaming für zeitkritische Missionen weniger nützlich. Konfigurieren Sie ON_CHANGE Streaming für einen externen Collector, um Informationen nur dann zu empfangen, wenn sich Betriebszustände ändern.
Zur Unterstützung des ON_CHANGE Streamings wird eine neue Spezifikation namens gRPC Network Management Interface (gNMI) für die Änderung und den Abruf von Konfigurationen aus einem Netzwerkelement implementiert. Darüber hinaus kann die gNMI-Spezifikation verwendet werden, um Telemetrieströme von einem Netzwerkelement zu einem Datenerfassungssystem zu erzeugen und zu steuern. Mit der neuen gNMI-Spezifikation kann eine einzige gRPC-Dienstdefinition eine einzelne Implementierung auf einem Netzwerkelement für Konfiguration und Telemetrie bereitstellen. Außerdem kann ein Netzwerkmanagementsystem (Network Management System, NMS) über einheitliche Telemetrie- und Konfigurations-RPCs mit dem Gerät interagieren.
Das Junos-Dateipaket (junos-telemetry-interface) enthält die Datei gnmi.proto und die Juniper-Erweiterung GnmiJuniperTelemetryHeader.proto für gNMI-Unterstützung.
Informationen zu den RPCs, die diese Funktion unterstützen, finden Sie in der gNMI Proto-Dateiversion 0.4.0 (die unterstützte Version) und in der veröffentlichten Spezifikation
Der Telemetrie-RPC subscribe unter dem gNMI-Dienst unterstützt ON_CHANGE Streaming. RPC subscribe ermöglicht es Clients, das Ziel aufzufordern, Werte für bestimmte Pfade innerhalb der Datenstruktur zu senden. Werte können gestreamt (STREAM), einmalig an einen langlebigen Kanal gesendet (POLL) oder einmalig als Abruf (ONCE) gesendet werden.
Wenn Sie einen Container der obersten Ebene mit einer Stichprobenhäufigkeit von 0 abonnieren, werden Blätter mit ON_CHANGE Unterstützung basierend auf Ereignissen gestreamt. Andere Blätter werden nicht gestreamt.
Damit ein Gerät bestimmen kann, welche Knoten als ON_CHANGE gestreamt werden oder welche SAMPLE sind, muss der Collector TARGET_DEFINED mit sample_interval abonnieren.
Aktivieren des "TARGET_DEFINED"-Abonnementmodus über gNMI
Junos OS Version 20.2R1 bietet Unterstützung für TARGET_DEFINED Abonnementmodus mit gRPC Network Management Interface (gNMI)-Diensten auf MX5-, MX10-, MX40-, MX80-, MX104-, MX150-, MX204-, MX240-, MX480-, MX960-, MX2008-, MX2010-, MX2020-, MX10003-, MX10008- und MX10016-Routern.
Ein externer Collector, der ein gNMI-Abonnement verwendet, bestimmt, wie Sensordaten bereitgestellt werden:
-
Der STREAMING-Modus streamt in regelmäßigen Abständen Sensordaten vom Prüfling in einem bestimmten Intervall.
-
ON_CHANGE-Modus sendet nur dann Aktualisierungen für Sensordaten vom Prüfling, wenn sich die Datenwerte ändern.
-
Der neu unterstützte TARGET_DEFINED-Modus (Submode 0) weist den Prüfling an, den entsprechenden Modus (STREAMING oder ON_CHANGE) auszuwählen, um jedes Element (Leaf) der Sensordaten an den externen Kollektor zu liefern. Wenn der externe Kollektor ein Abonnement für einen Sensor mit dem Submodus 0 an den Prüfling sendet, reagiert der Prüfling und aktiviert das Sensorabonnement, sodass das regelmäßige Streaming keine der ON_CHANGE Aktualisierungen enthält. Der Prüfling benachrichtigt den Kollektor, wenn qualifizierende ON_CHANGE Ereignisse auftreten.
Abonnements verwenden standardmäßig eine regelmäßige Streamingfrequenz von 30 Sekunden, es sei denn, der Collector gibt in der Abonnementanforderung etwas anderes an.
Die folgende JSON-Datei (JavaScript Object Notation) zeigt ein gNMI-Beispielabonnement. TARGET_DEFINED Modus wird mit submode=0 für die Ressource (Sensor) Pfad /interfaces/interface[name='lo0']/state gesetzt.
$ 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
Das Junos-Dateipaket (junos-telemetry-interface) enthält die Datei gnmi.proto und die Juniper-Erweiterung GnmiJuniperTelemetryHeader.proto für gNMI-Unterstützung.
Weitere Informationen finden Sie in den gNMI-Spezifikationen und in der gNMI-Protokolldatei hier:
Aktivieren des "INITIAL_SYNC"-Abonnementmodus über gNMI
Ab Junos OS Version 20.2R1 ist Unterstützung für INITIAL_SYNC Statistiken von Packet Forwarding Engine Sensoren verfügbar, die gNMI-Dienste verwenden. Diese Funktion gilt für MX960, MX2008, MX2010, MX2020, PTX1000 und den PTX5000-Router. Die Juniper Networks® PTX10000-Reihe von Routern, Juniper Networks® QFX5100 Switch und Juniper Networks® QFX5200 Switch bieten diese Unterstützung ebenfalls.
Ab Junos OS Evolved Version 20.4R1 ist Unterstützung für INITIAL_SYNC Statistiken von Packet Forwarding Engine Sensoren mit gNMI-Services verfügbar. ® Juniper Networks QFX5130-32CD-Switch enthält diese Unterstützung.
Wenn ein externer Kollektor eine Subskriptionsanforderung für einen Sensor mit INITIAL_SYNC (gnmi-submode 2) sendet, sendet der Host alle unterstützten Zielblätter (Felder) unter diesem Ressourcenpfad mindestens einmal an den Kollektor mit dem aktuellen Wert. Das Sammeln dieser Statistiken ist aus folgenden Gründen von Vorteil:
-
Der Kollektor hat eine vollständige Ansicht des aktuellen Zustands jedes Feldes auf dem Gerät für diesen Sensorpfad.
-
Ereignisgesteuerte Daten (ON_CHANGE) erreichen den Kollektor mindestens einmal, bevor das nächste Ereignis eintritt. Dieser Ansatz stellt sicher, dass der Datensammler über den Datenzustand informiert ist, bevor das nächste Ereignis eintritt.
-
Packet Forwarding Engine Sensoren mit null Zählerwerten (zero-suppressed), die normalerweise nicht in den gestreamten Daten erscheinen, werden mindestens einmal gesendet. Dieser Ansatz stellt sicher, dass der Collector Einblick in alle Felder jeder Linecard hat, die oft als Quelle bezeichnet wird.
INITIAL_SYNC Untermodus erfordert, dass das Gerät mindestens eine Kopie an den Kollektor sendet, obwohl das Senden von mehr als einer Kopie akzeptabel ist.
Abonnements verwenden standardmäßig eine regelmäßige Streamingfrequenz von 30 Sekunden, es sei denn, der Collector hat in der Abonnementanforderung etwas anderes angegeben.
Die folgende JSON-Datei (JavaScript Object Notation) zeigt ein gNMI-Beispielabonnement. INITIAL_SYNC Modus wird mit gnmi_submode 2 für den Ressourcenpfad (Sensor) / interfaces/ festgelegt. Der gnmi_mode Wert ist auf 0festgelegt. Die Protokollcodierung ist auf 2 GBP festgelegt.
{
"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
}
]
}
Das Junos-Dateipaket (junos-telemetry-interface) enthält die Datei gnmi.proto und die Juniper-Erweiterung GnmiJuniperTelemetryHeader.proto für gNMI-Unterstützung.
Weitere Informationen finden Sie in den gNMI-Spezifikationen und in der gNMI-Protokolldatei hier:
gNMI-Telemetriespezifikation gNMI-Protokolldefinition
Beispiele
Die folgenden Beispiele zeigen Abonnementanforderungen und -antworten eines gNMI-Clients und eines Zielgeräts im protobuf-Format.
Beispiel: ONCE-Modus
Das folgende Beispiel zeigt eine Abonnementanforderung, die von einem gNMI-Client im protobuf-Format gesendet wird. Der Abonnementmodus und ONCE der OpenConfig-Ressourcenpfad lautet /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
Das Ziel antwortet mit einem einmaligen Update:
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"
}
}
}
Beispiel: ON_CHANGE
Das folgende Beispiel zeigt eine Abonnementanforderung im STREAM Modus mit ON_CHANGE Untermodus. Der OpenConfig-Ressourcenpfad lautet /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
Die OpenConfig-Konfiguration zum Zeitpunkt der Abonnementanfrage:
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
Die Beispielantwortnachricht zeigt die Werte für die Konfigurationspfade und das Flag an, das sync_response auf :true
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
Die folgenden Konfigurationsänderungen werden an den abonnierten Pfaden vorgenommen:
-
Benutzername für
test1hinzufügen. -
Löschen Sie das Kennwort für
test1.
Das Zielgerät sendet als Antwort das folgende Update:
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"
}
}
}
Beispiel: SAMPLE
Das folgende Beispiel zeigt eine Abonnementanforderung im Modus und SAMPLE im STREAM Untermodus. Der OpenConfig-Ressourcenpfad lautet /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
Die OpenConfig-Konfiguration zum Zeitpunkt der Abonnementanfrage:
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
Die Beispielantwortnachrichten zeigen eine erste Aktualisierung, die mit dem Flag gesendet wird, true und nachfolgende Aktualisierungen, die sync_response in Intervallen von 5 Sekunden gesendet werden:
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"
}
}
}