NESTA PÁGINA
Entender a telemetria de discagem
A telemetria de discagem é um método de monitoramento de rede em que o coletor inicia a conexão com o dispositivo para recuperar dados de telemetria. O coletor "liga" para o dispositivo de rede e normalmente usa protocolos como gRPC para solicitar e receber dados.
No modo de discagem, o coletor de dados inicia a conexão com o dispositivo de rede e assina os dados de telemetria. O coletor e o dispositivo estabelecem uma sessão. O dispositivo transmite dados para o coletor em intervalos configurados. Esse modo é comumente usado quando as operadoras exigem um canal unificado para dados operacionais e de configuração.
O Junos Telemetry oferece suporte a conexões de discagem gNMI e Juniper Extension Toolkit (JET) sobre transporte gRPC.
Você pode usar o gNMI de forma discada para solicitações sob demanda (por exemplo, uma operação única "get" para buscar dados). Para conexões de discagem gNMI, você deve habilitar o serviço gNMI. Há suporte para os modos de assinatura POLL (o coletor sonda instantâneos) e ONCE (um único instantâneo). O dispositivo geralmente inicia o gRPC para transmitir telemetria no Junos Telemetry.
Serviço gRPC
O gRPC é uma estrutura de código aberto que oferece transporte de dados seguro e confiável. Você pode usar um conjunto de interfaces de chamada de procedimento remoto (RPC) para configurar a telemetria do Junos e transmitir dados de telemetria usando a estrutura gRPC. As chamadas de procedimento remoto gRPC são usadas para provisionar sensores e para assinar e receber dados de telemetria. O OpenConfig oferece suporte aos modelos de dados YANG. O modelo de dados OpenConfig gera dados como mensagens do Google Protocol Buffer (.gpb) em um formato universal de chave/valor.
Usar o gRPC para transmitir dados
De acordo com a especificação OpenConfig, somente o transporte baseado em gRPC tem suporte para dados de streaming. O servidor gRPC encerra as sessões gRPC do sistema de gerenciamento que está executando o cliente. As chamadas RPC desencadeiam a criação de sensores do Junos OS, que transmitem dados em intervalos regulares ou relatam eventos específicos. Esses sensores então encaminham atualizações por meio do canal gRPC apropriado.
A partir do Junos OS Release 18.2R1, quando um servidor de streaming externo, ou coletor, provisiona sensores para exportar dados através do gRPC em dispositivos que executam o Junos OS, a configuração do sensor é confirmada na instância do banco de dados de configuração efêmera junos-analytics . A configuração pode ser visualizada usando o show ephemeral-configuration instance junos-analytics comando operacional. Em versões anteriores, a configuração do sensor é confirmada na instância padrão do banco de dados de configuração efêmera.
O cabeçalho Juniper Telemetria, anteriormente exportado como parte das atualizações de telemetria, agora é exportado como um cabeçalho de extensão.
- Use
GnmiJuniperTelemetryHeader.protopara decodificar atualizações de dispositivos que executam o Junos OS Release 19.3 ou anterior. - Use
GnmiJuniperTelemetryHeaderExtension.protopara dispositivos que executam o Junos OS Release 19.4 ou posterior.
Consulte a Tabela 1 para obter uma lista e descrições dos RPCs implementados para oferecer suporte à solução de telemetria Junos.
| Nome do RPC |
Descrição |
|---|---|
|
|
Especifique parâmetros de telemetria e dados de fluxo para a lista especificada de caminhos OpenConfig. |
|
|
Recupere a lista de assinaturas criadas por meio |
|
|
Cancelar a assinatura de uma assinatura criada por meio do |
Os dados transmitidos por meio do gRPC são formatados em pares de valores-chave OpenConfig em mensagens de buffers de protocolo (.gpb). Nesse formato universal, as chaves são cadeias de caracteres que correspondem ao caminho dos recursos do sistema no esquema OpenConfig para dispositivos monitorados. Os valores correspondem a inteiros ou cadeias de caracteres que identificam o estado operacional do recurso do sistema, como contadores de interface.
A partir do Junos OS Release 18.2R1, os dados transmitidos pelo gRPC podem ser formatados como protobuf, além de pares de valores-chave para sensores de Mecanismo de Roteamento (RE) baseados em OpenConfig. Esses sensores são adicionais aos sensores do Mecanismo de Encaminhamento de Pacotes (PFE).
O seguinte mostra o formato universal de chave/valor:
message KeyValue {
string key = 1 [(telemetry_options).is_key = true];
uint64 int_value = 2;
string str_value = 3;
string prefix_str = 4;
}
message TelemetryStream {
// router name or export IP address
required string system_id = 1 [(telemetry_options).is_key = true];
// line card / RE (slot number)
optional uint32 component_id = 2 [(telemetry_options).is_key = true];
// PFE (if applicable)
optional uint32 sub_component_id = 3 [(telemetry_options).is_key = true];
// timestamp (common to all entries in the kv array)
optional uint64 timestamp = 4 [(telemetry_options).is_timestamp = true];
// key / value pairs
repeated KeyValue kv;
}
O exemplo a seguir mostra como um conjunto de contadores para uma interface pode ser representado:
key = “/interfaces/counters/rx-bytes”, int_value = 1000 key = “/interfaces/counters/tx-bytes”, int_value = 2000 key = “/interfaces/counters/rx-packets”, int_value = 10 key = “/interfaces/counters/rx-bytes” , int_value = 20 key = “/interfaces/counters/oper-state”, str_value = “up”
Uma tabela de mapeamento mapeia nomes de campo para as cadeias de caracteres de chave OpenConfig.
Habilitar a telemetria do Junos usando o OpenConfig
OpenConfig para Junos OS especifica um modelo RPC para habilitar a telemetria do Junos. Este pacote também inclui os modelos YANG necessários.
Você pode localizar todos os modelos de dados YANG em um repositório GitHub para um determinado sistema operacional e liberar em um único pacote de download. O pacote e o repositório incluem os modelos de dados de configuração, estado e RPC nativos e os modelos de dados OpenConfig e IETF compatíveis com esse sistema operacional. Você também pode acessar os modelos de dados YANG no site de download da Juniper Networks.
Para baixar arquivos de modelo OpenConfig e YANG, abra um navegador da Web, navegue até https://www.hpe.com/us/en/networking/hpe-juniper-networking.html e clique em Suporte para abrir o portal de suporte Juniper em https://support.juniper.net/support/. Selecione a guia Downloads , insira um nome de produto no campo Digite um nome de produto, clique em Encontrar um produto, pesquise e selecione o produto desejado e escolha o Junos OS apropriado e a VERSÃO do software na lista suspensa. Role para baixo na mesma página, expanda a seção + Ferramentas e baixe os arquivos necessários: Arquivos de modelo de dados de interface de telemetria JUNOS para modelos OpenConfig e Módulo YANG para arquivos YANG.
A interface OpenConfigTelemetry programática define o serviço gRPC de telemetria. O telemetrySubscribe RPC especifica os seguintes parâmetros de assinatura:
-
Caminho do OpenConfig que identifica o recurso do sistema para transmitir dados de telemetria, por exemplo:
/interfaces/interface/state/counters/ -
Intervalo no qual os dados são relatados e transmitidos para o servidor coletor, em milissegundos, por exemplo:
sample_frequency = 4000
Um servidor ou coletor de streaming usa o telemetrySubscribe RPC para solicitar uma assinatura embutida de dados no caminho especificado. Em seguida, o dispositivo envia dados de telemetria de volta na mesma conexão que a solicitação de assinatura.
Visão geral do servidor gRPC
O Junos Telemetry permite a configuração de serviços de várias portas, permitindo que você configure vários conjuntos de serviços de telemetria para escutar em diferentes portas.
O Junos Telemetry oferece recursos flexíveis de configuração de serviço gRPC, permitindo que você configure vários servidores gRPC, cada um com serviços, endereços de escuta e portas distintos. Esses recursos fornecem controle granular sobre o gerenciamento de serviços e a coleta de dados de telemetria. Você pode configurar certificados TLS para cada servidor para garantir uma comunicação segura. Para configurar o servidor gRPC, consulte Configurar serviços gRPC.
Serviço gNMI
O gNMI (gRPC Network Management Interface) é um protocolo baseado no gRPC que configura e monitora dispositivos de rede. Desenvolvido pela OpenConfig especificamente para gerenciamento de rede, o gNMI permite que os operadores de rede recuperem e modifiquem dados de configuração de dispositivos e assinem dados de telemetria em tempo real dos dispositivos de rede. A coleta de dados é uma tarefa fundamental em soluções de telemetria. O gNMI é compatível com modos de assinatura como ONCE, POLL e STREAM para atualizações de telemetria. O gNMI usa a estrutura gRPC, oferece suporte a formatos de codificação de dados eficientes, como buffers de protocolo (protobuf), e garante a comunicação segura por meio de TLS. Os modelos YANG definem a estrutura de configuração e dados de telemetria.
Os principais componentes do gNMI são:
-
Cliente gNMI: é executado em um sistema externo. Ele envia solicitações gNMI para configurar o dispositivo, recuperar dados de configuração e assinar fluxos de telemetria.
-
Servidor gNMI: é executado no dispositivo de rede e fornece acesso a dados de telemetria e configuração. O servidor gNMI processa a solicitação com base em seu tipo. Se for uma alteração de gerenciamento de configuração, o servidor gNMI atualizará a configuração do dispositivo e enviará uma resposta ao cliente. Ele transmite dados para o cliente gNMI se for uma solicitação de coleta de dados de telemetria.
O gNMI suporta as seguintes chamadas de procedimento remoto (RPCs) para controlar e monitorar dispositivos de rede:
-
Obter: esse RPC recupera o estado atual do dispositivo de rede, incluindo dados operacionais e de configuração.
Observação:Use a
typeopção no comando gNMI get para especificar o tipo de dados a ser recuperado. As opções disponíveis sãoCONFIG,STATEeALL. A opção de tipo válido éCONFIG. Use Codificação para definir os formatos de codificação de valor compatíveis com o protocolo gNMI. As opções disponíveis incluemJSON,BYTES,PROTO,ASCIIeJSON_IETF. As opções de codificação válidas sãoJSON_IETFeASCII. Escolher qualquer outra configuração além das opções válidas resulta em uma mensagem de erro. -
Conjunto: O RPC definido modifica a configuração do dispositivo de rede.
-
Assinar: use esse RPC para assinar dados de telemetria de um dispositivo de rede. Há suporte para os seguintes modos de assinatura:
- ONCE: Recupera os valores atuais apenas uma vez.
- POLL: Envia os valores atuais sempre que uma mensagem de enquete é recebida.
- STREAM: envia atualizações continuamente em intervalos especificados ou quando ocorrem alterações.
Para obter mais informações, consulte Assinatura gNMI
-
Recursos: use esse RPC para descobrir os recursos do dispositivo, como modelos e codificações com suporte.
Origem do gNMI
O Path campo da origin mensagem identifica o esquema do caminho. O origin campo é codificado como uma cadeia de caracteres. A <origin, path> tupla identifica exclusivamente o caminho dentro da mensagem.
O origin campo é válido em qualquer contexto de uma Path mensagem. Normalmente, ele é usado das seguintes maneiras:
- Use a
SetRequestpara indicar que um esquema específico modifica a configuração de destino. - Use a
GetRequestpara recuperar o conteúdo de um esquema específico ou use aGetResponsepara indicar que a carga contém dados de um esquema específico<origin, path>. - Use a
SubscribeRequestpara assinar caminhos dentro de um esquema específico ou use aSubscribeResponsepara indicar que uma atualização corresponde a uma tupla específica<origin, path>.
Quando uma mensagem usa mais de um origin, não especifique um caminho no prefix, porque o prefix se aplica a todos os caminhos na mensagem. Quando a prefix for especificado, inclua qualquer originarquivo . Não especifique origin nos prefix campos e caminho em uma única solicitação para qualquer mensagem de payload RPC.
- Valores especiais de origem
- Definição de
originpara dados modelados em YANG - Especificações parciais de origem em conjunto
- Transacionalidade de conjuntos com múltiplas origens
Valores especiais de origem
Os valores de origem são acordados fora de banda com o protocolo gNMI. Quando o origin campo não for especificado, seu valor deve ser padrão para openconfig. Recomenda-se que a origem seja definida explicitamente.
Definição de origem para dados modelados em YANG
O openconfig-extensions:origin campo pode ser utilizado para determinar a origem dentro da qual um determinado módulo é instanciado.
origin é diferente de namespace. Enquanto um namespace YANG é definido em qualquer profundidade dentro da árvore de esquema, an origin é usado apenas para desambiguar árvores de esquema inteiras. Ou seja, qualquer elemento que não esteja na raiz herda sua origin entidade raiz, independentemente dos módulos do esquema YANG que compõem essa raiz.
Especificações parciais de origem em conjunto
Se um Set RPC especificar delete, update, ou replace campos que incluem um origin em suas Path mensagens, a alteração correspondente deverá ser restrita à origem especificada das seguintes maneiras:
replaceAs operações devem substituir apenas o conteúdo do especificadooriginno caminho especificado. As origens que não são especificadas noSetRequestnão devem ter seu conteúdo substituído. Para que umareplaceoperação substitua qualquer conteúdo de umorigin, ela deve ser especificada explicitamente noSetRequest.deleteAs operações devem excluir apenas o conteúdo no caminho especificado dentro doorigin. Para excluir conteúdo de várias origens, um cliente deve especificar vários caminhos dentrodeletedoSetRequest.
Essas regras se aplicam quando as origens representam dados que não se sobrepõem. Em alguns casos (por exemplo, CLI e OpenConfig), as origens podem refletir diferentes "visualizações" sobre os mesmos dados e, portanto, sua interação é mais complexa.
Transacionalidade de conjuntos com múltiplas origens
Quando a SetRequest especifica mais de uma origem (em outras palavras, quando inclui duas ou mais operações cujos caminhos fazem referência a origens diferentes), todas as árvores de dados afetadas devem ser tratadas como uma única transação. O SetResponse deve indicar êxito somente se todas as operações forem bem-sucedidas. Se qualquer operação falhar, as alterações em todas as origens deverão ser revertidas e um status de erro deverá ser retornado em resposta ao Set RPC.