Directrices para suscripciones de datos de telemetría a través de gNMI
En esta sección se describen los modos de suscripción admitidos por las conexiones gNMI.
El protocolo gNMI define el Subscribe RPC para suscribirse a datos de telemetría. El recopilador de telemetría usa esta RPC para solicitar actualizaciones del dispositivo de red para obtener datos de estado y configuración.
Las solicitudes de nuevas suscripciones se encapsulan dentro de un SubscribeRequest mensaje que contiene una o varias rutas de recursos. Las rutas suscritas se relacionan con instancias de datos específicas en el dispositivo de red de destino. La solicitud puede contener rutas basadas en OpenConfig o esquemas nativos de Junos® OS.
La solicitud de suscripción también debe incluir uno de los siguientes modos:
-
ONCE- una solicitud única de datos. -
POLL- para la recuperación periódica y bajo demanda de datos. -
STREAM- Una suscripción de larga duración que transmite datos de acuerdo con desencadenantes especificados.
Las suscripciones en STREAM modo deben especificar uno de los siguientes submodos:
-
ON_CHANGE- Las actualizaciones de datos solo se envían cuando cambia el valor del elemento de datos. -
SAMPLE- Las actualizaciones de datos se envían una vez por intervalo de muestra en función de un período de intervalo especificado en la solicitud de suscripción. El intervalo de muestreo predeterminado es de 30 segundos. -
TARGET_DEFINED- El dispositivo de red que recibe la solicitud de suscripción determina el mejor tipo de entrega para los datos por hoja. Si la ruta especificada en el mensaje hace referencia a datos controlados por eventos, es posible que se cree unaON_CHANGEsuscripción. Para los datos que representan valores de contador, se puede crear unaSAMPLEsuscripción.Nota:Las
TARGET_DEFINEDsolicitudes de suscripción para rutas de configuración se tratan únicamente comoON_CHANGEsolicitudes.
Para ONCElas suscripciones ON_CHANGE y SAMPLE las suscripciones, el recopilador puede solicitar una actualización inicial que contenga el estado actual de las rutas de acceso de la suscripción. Una actualización de sincronización inicial es valiosa porque:
-
El recolector tiene una vista completa del estado actual de cada campo del dispositivo para esa ruta del sensor.
-
El recopilador recibe datos controlados por eventos (
ON_CHANGE) al menos una vez antes de que ocurra la siguiente, lo que garantiza que el recopilador permanezca al tanto del estado de los datos de antemano. -
También se envían sensores del motor de reenvío de paquetes que contienen valores de contador cero que normalmente no aparecen en los datos transmitidos debido a la función de supresión de cero. Esto garantiza que el recolector conozca todos los campos de cada tarjeta de línea.
El dispositivo de destino responde a la solicitud de suscripción con un SubscribeResponse mensaje. Si la solicitud de suscripción requiere una sincronización inicial, el destino envía los datos seguidos del mensaje de respuesta con el sync_response indicador establecido en true. Después de la sincronización inicial, el dispositivo de destino procede con las actualizaciones de las rutas de acuerdo con el modo de suscripción.
El SubscribeRequest mensaje incluye un indicador denominado updates_only. Cuando este indicador se establece en , el dispositivo de destino no envía una sincronización inicial, solo actualizaciones posteriores como se indica a truecontinuación:
-
Para
STREAMlas suscripciones enSAMPLEmodo, la actualización se envía en el siguiente intervalo de ejemplo. -
Para
STREAMlas suscripciones enON_CHANGEmodo, la actualización se envía al siguiente cambio de valor. -
En el caso de
ONCElas suscripciones, solo se envía elSubscribeResponseconsync_responseestablecido enfalsey la suscripción se cierra. -
TARGET_DEFINEDLas suscripciones se tratan comoON_CHANGErutas de configuración y la actualización se envía en el siguiente cambio de valor.
El contenido de los mensajes y SubscribeResponse se define en el SubscribeRequest archivo gnmi.proto. Para obtener más información sobre el RPC de suscripción y los modos de suscripción, consulte la especificación de gNMI en: Especificación de gNMI: suscripción a actualizaciones de telemetría.
Las rutas de acceso de configuración tienen estas limitaciones:
-
POLLNo se admiten suscripciones. -
Las rutas de prefijo no se incluyen en los mensajes de actualización.
-
La respuesta gNMI no es compatible con operaciones de metadatos específicas de Juniper, como
active/inactive,insert before/after,comment/annotateyprotect/unprotect. Estos pueden aparecer en el mensaje, pero no son válidos. -
Parámetros no admitidos en el
SubscribeRequestcuadro incluyensuppress_redundant,heartbeat_level,allow_aggregation, yqos. -
La codificación PROTO es la única codificación compatible.
-
No se admiten extensiones en
SubscribeRequestmensajes -
El filtrado de rutas de suscripción solo se admite en un nivel de clave.
No se admiten
ON_CHANGElas siguientes variantes de confirmación yTARGET_DEFINEDsuscripciones:commit at,commit prepare/activatey confirmaciones por lotes.No se admiten confirmaciones desde el
edit dynamicyedit privateeditar o configurar modos.-
Los mensajes de actualización no se envían para los contenedores de presencia.
-
Es posible que las listas de suscripción que solo tienen una hoja configurada para el identificador o la clave no generen un mensaje de actualización.
Habilitación de la compatibilidad con sensores "ON CHANGE" a través de gNMI
La transmisión periódica de estados operativos y contadores de OpenConfig está disponible desde Junos OS versión 16.1, exportando datos de telemetría desde equipos Juniper a un recopilador externo. Aunque es útil para recopilar toda la información necesaria y crear una "instantánea" de referencia, la transmisión periódica es menos útil para misiones de tiempo crítico. Configure ON_CHANGE streaming para que un recopilador externo reciba información solo cuando cambien los estados operativos.
Para admitir ON_CHANGE streaming, se implementa una nueva especificación denominada interfaz de administración de red gRPC (gNMI) para la modificación y recuperación de configuraciones de un elemento de red. Además, la especificación gNMI se puede utilizar para generar y controlar flujos de telemetría desde un elemento de red a un sistema de recopilación de datos. La nueva especificación gNMI permite que una definición de servicio gRPC proporcione una única implementación en un elemento de red para configuración y telemetría. También permite que un sistema de administración de red (NMS) interactúe con el dispositivo a través de RPC de telemetría y configuración unificadas.
El paquete de archivos de Junos (junos-telemetry-interface) incluye el archivo gnmi.proto y la extensión GnmiJuniperTelemetryHeader.proto de Juniper para compatibilidad con gNMI.
La información sobre los RPC que admiten esta función se encuentra en el archivo gNMI Proto versión 0.4.0 (la versión compatible) y la especificación publicada
El RPC subscribe de telemetría bajo el servicio gNMI admite ON_CHANGE streaming. RPC subscribe permite a los clientes solicitar al destino que envíe valores para rutas particulares dentro del árbol de datos. Los valores se pueden transmitir (STREAM), enviar de forma única en un canal de larga duración (POLL) o enviarse de forma única como recuperación (ONCE).
Si se suscribe a un contenedor de nivel superior con una frecuencia de muestreo de 0, las hojas con soporte ON_CHANGE se transmiten en función de los eventos. Otras hojas no se transmiten.
Para permitir que un dispositivo determine qué nodos se transmiten como ON_CHANGE o cuáles son SAMPLE, el recopilador debe suscribirse a TARGET_DEFINED con sample_interval.
Habilitación del modo de suscripción "TARGET_DEFINED" a través de gNMI
Junos OS versión 20.2R1 agrega compatibilidad con el modo de suscripción TARGET_DEFINED con los servicios de la interfaz de administración de red gRPC (gNMI) en enrutadores MX5, MX10, MX40, MX80, MX104, MX150, MX204, MX240, MX480, MX960, MX2008, MX2010, MX2020, MX10003, MX10008 y MX10016.
Un recopilador externo que utiliza una suscripción a gNMI determina cómo se entregan los datos del sensor:
-
El modo STREAMING transmite periódicamente datos del sensor desde el DUT a un intervalo especificado.
-
ON_CHANGE modo envía actualizaciones para los datos del sensor desde el DUT solo cuando cambian los valores de los datos.
-
El modo de TARGET_DEFINED recientemente admitido (submodo 0) indica al DUT que seleccione el modo relevante (STREAMING o ON_CHANGE) para entregar cada elemento (hoja) de datos del sensor al recolector externo. Cuando el recopilador externo envía una suscripción para un sensor con submodo 0 al DUT, el DUT responde, activando la suscripción del sensor para que la transmisión periódica no incluya ninguna de las actualizaciones ON_CHANGE. El DUT notifica al recopilador cada vez que se producen eventos ON_CHANGE calificados.
El valor predeterminado de las suscripciones tiene una frecuencia de transmisión periódica de 30 segundos, a menos que el recopilador especifique lo contrario en la solicitud de suscripción.
El archivo JavaScript Object Notation (JSON) a continuación muestra una suscripción gNMI de ejemplo. TARGET_DEFINED modo se establece utilizando submode=0 para la ruta de recursos (sensor) /interfaces/interface[name='lo0']/state.
$ 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
El paquete de archivos de Junos (junos-telemetry-interface) incluye el archivo gnmi.proto y la extensión GnmiJuniperTelemetryHeader.proto de Juniper para compatibilidad con gNMI.
Para obtener más información, consulte las especificaciones de gNMI y el archivo de protocolo gNMI aquí:
Habilitación del modo de suscripción "INITIAL_SYNC" a través de gNMI
A partir de Junos OS versión 20.2R1, está disponible la compatibilidad con estadísticas de INITIAL_SYNC de los sensores del motor de reenvío de paquetes mediante los servicios de gNMI. Esta función se aplica a MX960, MX2008, MX2010, MX2020 PTX1000 y al enrutador PTX5000. La línea de enrutadores Juniper Networks® PTX10000, el conmutador QFX5100 Juniper Networks® y el conmutador QFX5200 Juniper Networks® también ofrecen este soporte.
A partir de Junos OS Evolved versión 20.4R1, está disponible la compatibilidad con estadísticas de INITIAL_SYNC de los sensores del motor de reenvío de paquetes mediante los servicios de gNMI. El conmutador QFX5130-32CD de Juniper Networks® incluye este soporte.
Cuando un recolector externo envía una solicitud de suscripción para un sensor con INITIAL_SYNC (gnmi-submodo 2), el host envía todas las hojas (campos) de destino admitidas bajo esa ruta de recurso al menos una vez al recolector con el valor actual. La recopilación de estas estadísticas es beneficiosa porque:
-
El recolector tiene una vista completa del estado actual de cada campo del dispositivo para esa ruta del sensor.
-
Los datos controlados por eventos (ON_CHANGE) llegan al recopilador al menos una vez antes de que se produzca el siguiente evento. Este enfoque garantiza que el recopilador conozca el estado de los datos antes de que ocurra el siguiente evento.
-
Los sensores del motor de reenvío de paquetes con valores de contador cero (cero suprimidos) que normalmente no aparecen en los datos transmitidos se envían al menos una vez. Este enfoque garantiza que el recolector tenga visibilidad de todos los campos de cada tarjeta de línea, a menudo denominada fuente.
INITIAL_SYNC submodo requiere que el dispositivo envíe al menos una copia al recopilador, aunque es aceptable enviar más de una.
Las suscripciones tendrán de forma predeterminada una frecuencia de transmisión periódica de 30 segundos, a menos que el recopilador especifique lo contrario en la solicitud de suscripción.
El archivo JavaScript Object Notation (JSON) a continuación muestra una suscripción gNMI de ejemplo. INITIAL_SYNC modo se establece utilizando gnmi_submode 2 para la ruta de recursos (sensor) /interfaces/. El gnmi_mode se establece en 0. La codificación de protocolo se establece en 2 para GBP.
{
"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
}
]
}
El paquete de archivos de Junos (junos-telemetry-interface) incluye el archivo gnmi.proto y la extensión GnmiJuniperTelemetryHeader.proto de Juniper para compatibilidad con gNMI.
Para obtener más información, consulte las especificaciones de gNMI y el archivo de protocolo gNMI aquí:
Especificación de telemetría gNMI Definición de protocolo gNMI
Ejemplos
Los siguientes ejemplos muestran las solicitudes de suscripción y las respuestas realizadas por un cliente gNMI y un dispositivo de destino en formato protobuf.
Ejemplo: modo ONCE
El siguiente ejemplo muestra una solicitud de suscripción enviada desde un cliente gNMI en formato protobuf. El modo de suscripción es ONCE y la ruta del recurso de OpenConfig es /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
El destino responde con una actualización única:
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"
}
}
}
Ejemplo: ON_CHANGE
En el ejemplo siguiente se muestra una solicitud de suscripción en STREAM modo con ON_CHANGE submodo. La ruta del recurso de OpenConfig es /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
La configuración de OpenConfig en el momento de la solicitud de suscripción:
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
El mensaje de respuesta de ejemplo muestra los valores de las rutas de configuración y el sync_response indicador establecido en 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
Se realizan los siguientes cambios de configuración en las rutas suscritas:
-
Agregue el nombre de usuario para
test1. -
Elimine la contraseña de
test1.
El dispositivo de destino envía la siguiente actualización en respuesta:
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"
}
}
}
Ejemplo: SAMPLE
En el ejemplo siguiente se muestra una solicitud de suscripción en STREAM modo y SAMPLE submodo. La ruta del recurso de OpenConfig es /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
La configuración de OpenConfig en el momento de la solicitud de suscripción:
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
Los mensajes de respuesta de ejemplo muestran una actualización inicial enviada con el indicador establecido en true y actualizaciones posteriores enviadas a intervalos de sync_response 5 segundos:
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"
}
}
}