Assinatura de dados de telemetria usando 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 Junos nativo.
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. Essa atualização, também conhecida como sincronização inicial, é 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 do próximo evento ser visto. Dessa forma, o coletor está ciente do estado dos dados antes que o próximo evento aconteça. -
Os sensores do mecanismo de encaminhamento de pacotes que contêm valores de contador zero que normalmente não aparecem em dados transmitidos devido à supressão zero 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 intial, 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 está fechada. -
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.
As seguintes limitações se aplicam aos caminhos de configuração:
-
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. -
Apenas a codificação do PROTO é suportada.
-
Extensões nas
SubscribeRequestmensagens não são suportadas -
A filtragem dos 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.
-
Para listas de assinatura em que o identificador ou a chave seja a única leaf configurada, pode não haver uma mensagem de atualização.
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"
}
}
}