Diretrizes para assinaturas de dados de telemetria por gNMI
Esta seção descreve os modos de assinatura suportados por conexões gNMI.
O protocolo gNMI define o Subscribe RPC para assinar dados de telemetria. O coletor de telemetria usa este RPC para solicitar atualizações do dispositivo de rede para obter dados de estado e configuração.
As solicitações de novas assinaturas são encapsuladas em uma SubscribeRequest mensagem que contém um ou mais caminhos de recursos. Os caminhos subscritos estão relacionados a instâncias de dados específicas no dispositivo de rede alvo. A solicitação pode conter caminhos com base no esquema openconfig ou nativo do Junos® OS.
A solicitação de assinatura também deve incluir um dos seguintes modos:
-
ONCEuma solicitação única de dados. -
POLLpara recuperação periódica sob demanda de dados. -
STREAM- uma assinatura de longa data que transmite dados de acordo com os gatilhos especificados.
As assinaturas em STREAM modo devem especificar um dos seguintes sub-modos:
-
ON_CHANGE- atualizações de dados só são enviadas quando o valor do item de dados muda. -
SAMPLE- atualizações de dados são enviadas uma vez por intervalo de amostra com base em um período de intervalo especificado na solicitação de assinatura. O intervalo padrão da amostra é de 30 segundos. -
TARGET_DEFINED- o dispositivo de rede que recebe a solicitação de assinatura determina o melhor tipo de entrega para os dados por leaf. Se o caminho especificado na mensagem se refere a dados orientados por eventos, umaON_CHANGEassinatura pode ser criada. Para dados que representam valores contrários, umaSAMPLEassinatura pode ser criada.Nota:As
TARGET_DEFINEDsolicitações de assinatura para caminhos de configuração são tratadas apenas comoON_CHANGEsolicitações.
Para ONCE, ON_CHANGE e SAMPLE assinaturas, o coletor pode solicitar uma atualização inicial contendo o estado atual dos caminhos na assinatura. Uma atualização inicial de sincronização é valiosa porque:
-
O coletor tem uma visão completa do estado atual de cada campo do dispositivo para esse caminho de sensor.
-
Os dados orientados por eventos (
ON_CHANGE) são recebidos pelo coletor pelo menos uma vez antes da próxima ocorrência, garantindo que o coletor permaneça ciente do estado dos dados de antemão. -
Os sensores do mecanismo de encaminhamento de pacotes que contêm valores de contador zero que normalmente não aparecem em dados transmitidos devido ao recurso de supressão zero também são enviados. Isso garante que todos os campos de cada placa de linha sejam conhecidos pelo coletor.
O dispositivo alvo responde à solicitação de assinatura com uma SubscribeResponse mensagem. Se a solicitação de assinatura pedir uma sincronização inicial, o alvo envia os dados seguidos pela mensagem de resposta com o conjunto de sync_response bandeiras para true. Após a sincronização inicial, o dispositivo alvo prossegue com atualizações para os caminhos de acordo com o modo de assinatura.
A SubscribeRequest mensagem inclui uma bandeira chamada updates_only. Quando esta bandeira é definida para true, o dispositivo-alvo não envia uma sincronização inicial, apenas atualizações subseqüentes da seguinte forma:
-
Para
STREAMassinaturas noSAMPLEmodo, a atualização é enviada no próximo intervalo de amostra. -
Para
STREAMassinaturas noON_CHANGEmodo, a atualização é enviada mediante a próxima mudança de valor. -
Para
ONCEassinaturas, apenas oSubscribeResponseé enviado comsync_responseconfiguração parafalse, e a assinatura fecha. -
TARGET_DEFINEDas assinaturas são tratadas comoON_CHANGEcaminhos de configuração e a atualização é enviada após a próxima mudança de valor.
O conteúdo das mensagens e do SubscribeRequest conteúdo SubscribeResponse são definidos no arquivo gnmi.proto . Para obter mais informações sobre o RPC de assinatura e os modos de assinatura, veja a especificação do gNMI em: Especificação gNMI: Assinatura de atualizações de telemetria.
Os caminhos de configuração têm essas limitações:
-
POLLas assinaturas não são suportadas. -
Os caminhos de prefixo não estão incluídos nas mensagens de atualização.
-
A resposta gNMI não é suportada para operações de metadados específicas da Juniper, como
active/inactive,insert before/afterecomment/annotateprotect/unprotect. Estes podem aparecer na mensagem, mas não são válidos. -
Parâmetros sem suporte incluem
SubscribeRequestsuppress_redundant,heartbeat_leveleallow_aggregationqos. -
A codificação do PROTO é a única codificação suportada.
-
Extensões nas
SubscribeRequestmensagens não são suportadas -
A filtragem de caminhos de assinatura é suportada apenas em um nível-chave.
As seguintes variantes de confirmação não são suportadas
ON_CHANGEeTARGET_DEFINEDas assinaturas:commit atecommit prepare/activatecompromissos em lotes.Os commits não são suportados pela
edit dynamiceedit privateeditar ou configurar modos.-
As mensagens de atualização não são enviadas para contêineres de presença.
-
Listas de assinatura que têm apenas uma leaf configurada para o identificador ou chave podem não gerar uma mensagem de atualização.
Habilitando o suporte ao sensor "ON CHANGE" por meio do gNMI
O streaming periódico de estados e contadores operacionais do OpenConfig está disponível desde a versão 16.1 do Junos OS, exportando dados de telemetria dos equipamentos da Juniper para um coletor externo. Embora seja útil na coleta de todas as informações necessárias e na criação de um "instantâneo" básico, o streaming periódico é menos útil para missões críticas de tempo. Configure ON_CHANGE streaming para que um coletor externo receba informações apenas quando os estados operacionais mudarem.
Para oferecer suporte a ON_CHANGE streaming, uma nova especificação chamada gRPC Network Management Interface (gNMI) é implementada para modificação e recuperação de configurações de um elemento de rede. Além disso, a especificação gNMI pode ser usada para gerar e controlar fluxos de telemetria de um elemento de rede para um sistema de coleta de dados. A nova especificação gNMI permite que uma definição de serviço gRPC forneça uma única implementação em um elemento de rede para configuração e telemetria. Ele também permite que um sistema de gerenciamento de rede (NMS) interaja com o dispositivo por meio de telemetria e RPCs de configuração unificados.
O pacote de arquivos Junos (junos-telemetria-interface) inclui o arquivo gnmi.proto e a extensão GnmiJuniperTelemetryHeader.proto Juniper para suporte a gNMI.
As informações sobre os RPCs que oferecem suporte a esse recurso estão no arquivo gNMI Proto versão 0.4.0 (a versão suportada) e a especificação lançada
O RPC subscribe de telemetria sob o serviço gNMI oferece suporte ON_CHANGE streaming. O RPC subscribe permite que os clientes solicitem o alvo para enviar valores para caminhos específicos dentro da árvore de dados. Os valores podem ser transmitidos (STREAM), enviados pontuais em um canal de longa duração (POLL) ou enviados como uma recuperação (ONCE).
Se você se inscrever em um contêiner de alto nível com uma frequência de amostra de 0, as folhas com suporte ON_CHANGE são transmitidas com base em eventos. Outras folhas não são transmitidas.
Para permitir que um dispositivo determine quais nós são transmitidos como ON_CHANGE ou quais são SAMPLE, o coletor deve se inscrever para TARGET_DEFINED com sample_interval.
Habilitando o modo de assinatura "TARGET_DEFINED" por meio do gNMI
O Junos OS Release 20.2R1 adiciona suporte para TARGET_DEFINED modo de assinatura com serviços gRPC Network Management Interface (gNMI) no MX5, MX10, MX40, MX80, MX104, MX150, MX204, MX240, MX480, MX960, MX2008, MX2010, MX2020, MX10003, MX10008 e roteadores de MX10016.
Um coletor externo que usa uma assinatura gNMI determina como os dados dos sensores são fornecidos:
-
O modo STREAMING transmite periodicamente dados dos sensores do DUT em um intervalo especificado.
-
ON_CHANGE modo envia atualizações para dados de sensores do DUT somente quando os valores dos dados mudam.
-
O modo TARGET_DEFINED recém-suportado (submode 0) instrui o DUT a selecionar o modo relevante (STREAMING ou ON_CHANGE) para entregar cada elemento (leaf) de dados do sensor ao coletor externo. Quando o coletor externo envia uma assinatura para um sensor com submode 0 para o DUT, o DUT responde, ativando a assinatura do sensor para que o streaming periódico não inclua nenhuma das atualizações ON_CHANGE. O DUT notifica o coletor sempre que ocorrerem ON_CHANGE eventos qualificados.
As assinaturas são padrão para uma frequência de streaming periódica de 30 segundos, a menos que o coletor especifique o contrário na solicitação de assinatura.
O arquivo De notação de objetos JavaScript (JSON) abaixo mostra uma assinatura gNMI de amostra. TARGET_DEFINED modo é definido usando submode=0 para o caminho /interfaces/interfaces de recursos (sensor)[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
O pacote de arquivos Junos (junos-telemetria-interface) inclui o arquivo gnmi.proto e a extensão GnmiJuniperTelemetryHeader.proto Juniper para suporte a gNMI.
Para obter mais informações, veja as especificações do gNMI e o arquivo de protocolo gNMI aqui:
Habilitando o modo de assinatura "INITIAL_SYNC" por meio do gNMI
A partir do Junos OS Release 20.2R1, o suporte para estatísticas de INITIAL_SYNC dos sensores do Mecanismo de encaminhamento de pacotes usando serviços gNMI está disponível. Esse recurso se aplica ao MX960, MX2008, MX2010, MX2020, PTX1000 e ao roteador PTX5000. A linha de roteadores PTX10000 da Juniper Networks®, o switch QFX5100 da Juniper Networks® e o Switch QFX5200 da Juniper Networks® também oferecem esse suporte.
A partir do Junos OS Evolved Release 20.4R1, o suporte para estatísticas de INITIAL_SYNC dos sensores do Mecanismo de encaminhamento de pacotes usando serviços gNMI está disponível. O switch de QFX5130-32CD da Juniper Networks® inclui esse suporte.
Quando um coletor externo envia uma solicitação de assinatura para um sensor com INITIAL_SYNC (gnmi-submode 2), o host envia todas as folhas-alvo (campos) suportadas sob esse caminho de recursos pelo menos uma vez para o coletor com o valor atual. A coleta dessas estatísticas é benéfica porque:
-
O coletor tem uma visão completa do estado atual de cada campo do dispositivo para esse caminho de sensor.
-
Os dados orientados por eventos (ON_CHANGE) chegam ao coletor pelo menos uma vez antes do próximo evento ocorrer. Essa abordagem garante a conscientização do coletor sobre o estado dos dados antes que o próximo evento ocorra.
-
Os sensores de mecanismo de encaminhamento de pacotes com valores de contador zero (suprimidos zero) que normalmente não aparecem nos dados transmitidos são enviados apenas uma vez. Essa abordagem garante que o coletor tenha visibilidade de todos os campos de cada placa de linha, muitas vezes chamados de fonte.
INITIAL_SYNC submoder requer que o dispositivo envie pelo menos uma cópia ao coletor, embora enviar mais de uma seja aceitável.
As assinaturas serão padrão para uma frequência de streaming periódica de 30 segundos, a menos que especificada pelo coletor na solicitação de assinatura.
O arquivo De notação de objetos JavaScript (JSON) abaixo mostra uma assinatura gNMI de amostra. INITIAL_SYNC modo é definido usando gnmi_submode 2 para o caminho /interfaces de recursos (sensor)/. A gnmi_mode configuração é... 0 A codificação do protocolo está definida para 2 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
}
]
}
O pacote de arquivos Junos (junos-telemetria-interface) inclui o arquivo gnmi.proto e a extensão GnmiJuniperTelemetryHeader.proto Juniper para suporte a gNMI.
Para obter mais informações, veja as especificações do gNMI e o arquivo de protocolo gNMI aqui:
Especificação da telemetria gNMI definição de protocolo gNMI
Exemplos
Os exemplos a seguir mostram solicitações e respostas por assinatura feitas por um cliente gNMI e dispositivo-alvo no formato protobuf.
Exemplo: modo ONCE
O exemplo a seguir mostra uma solicitação de assinatura enviada de um cliente gNMI no formato protobuf. O modo de assinatura é ONCE e o caminho de recursos do 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
O alvo responde com uma atualização ú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"
}
}
}
Exemplo: ON_CHANGE
O exemplo a seguir mostra uma solicitação de assinatura no STREAM modo com ON_CHANGE um sub-modo. O caminho de recursos do 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
A configuração do OpenConfig no momento da solicitação de assinatura:
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
A mensagem de resposta a exemplo mostra os valores para os caminhos de configuração e o conjunto de sync_response bandeiras para 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
As seguintes alterações de configuração são feitas nos caminhos subscritos:
-
Adicione o nome de usuário para
test1. -
Exclua a senha para
test1.
O dispositivo alvo envia a seguinte atualização em resposta:
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"
}
}
}
Exemplo: AMOSTRA
O exemplo a seguir mostra uma solicitação de assinatura no STREAM modo e SAMPLE no sub-modo. O caminho de recursos do 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
A configuração do OpenConfig no momento da solicitação de assinatura:
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
As mensagens de resposta a true exemplo mostram uma atualização inicial enviada com o conjunto de sync_response bandeiras e atualizações subsequentes enviadas em intervalos de 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"
}
}
}