NESTA PÁGINA
Entendendo a telemetria dial-in
A telemetria dial-in é 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 "disca" para o dispositivo de rede e normalmente usa protocolos como gRPC para solicitar e receber dados.
No modo dial-in, o coletor de dados inicia a conexão com o dispositivo de rede e se inscreve em 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 configuração e dados operacionais.
dial-in
A Telemetria Junos oferece suporte a conexões dial-in gNMI e Juniper Extension Toolkit (JET) por meio do transporte de gRPC.
Você pode usar o gNMI de forma dial-in para solicitações sob demanda (por exemplo, uma operação única de "obter" para obter dados). Para conexões dial-in gNMI, você deve habilitar o serviço gNMI. Os modos de assinatura POLL (o coletor pesquisa instantâneos) e ONCE (um único instantâneo) são suportados. O dispositivo geralmente inicia o gRPC para telemetria de streaming na Telemetria Junos.
Serviço gRPC
gRPC é uma estrutura de código aberto que fornece transporte de dados seguro e confiável. Você pode usar um conjunto de interfaces de chamada de procedimento remoto (RPC) para configurar a Telemetria Junos e transmitir dados de telemetria usando a estrutura do gRPC. As chamadas de procedimento remoto do gRPC são usadas para provisionar sensores e assinar e receber dados de telemetria. O OpenConfig oferece suporte aos modelos de dados YANG. O modelo de dados do OpenConfig gera dados como mensagens de buffer de protocolo do Google (.gpb) em um formato universal de chave/valor.
Use o gRPC para transmitir dados
De acordo com a especificação openconfig, apenas o transporte baseado em gRPC é suportado para dados de streaming. O servidor gRPC encerra as sessões de gRPC do sistema de gerenciamento que está executando o cliente. As chamadas de RPC desencadeiam a criação de sensores Junos OS, que transmitem dados em intervalos regulares ou relatam eventos específicos. Esses sensores então encaminham atualizações pelo canal gRPC apropriado.
A partir do Junos OS Release 18.2R1, quando um servidor de streaming externo, ou coletor, provisiona sensores para exportar dados por gRPC em dispositivos que executam o Junos OS, a configuração do sensor está comprometida com a junos-analytics instância do banco de dados de configuração efêmero. 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 está comprometida com a instância padrão do banco de dados de configuração efêmero.
O cabeçalho de telemetria da Juniper, anteriormente exportado como parte de 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. - Uso
GnmiJuniperTelemetryHeaderExtension.protopara dispositivos que executam o Junos OS Release 19.4 ou posterior.
Consulte a Tabela 1 para 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 transmita dados para a lista especificada de caminhos OpenConfig. |
|
|
Recuperar a lista de assinaturas criadas por |
|
|
Cancelar assinatura de uma assinatura criada por |
Os dados transmitidos pelo gRPC são formatados em pares de valor de chave OpenConfig em mensagens de buffer de protocolo (.gpb). Neste formato universal, as chaves são strings que correspondem ao caminho dos recursos do sistema no esquema OpenConfig para dispositivos monitorados. Os valores correspondem a inteiros ou strings 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 valor-chave para sensores openconfig-based Routing Engine (RE). Esses sensores estão além dos sensores PFE (Packet Forwarding Engine, Mecanismo de encaminhamento de pacotes).
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 cordas-chave do OpenConfig.
Habilite a telemetria do Junos usando o OpenConfig
O OpenConfig para Junos OS especifica um modelo RPC para habilitar a telemetria Junos. Este pacote também inclui os modelos YANG necessários.
Você pode localizar todos os modelos de dados YANG em um repositório do GitHub para um determinado SO e ser lançado em um único pacote de download. O pacote e o repositório incluem os modelos de dados nativos de configuração, estado e RPC e os modelos de dados OpenConfig e IETF suportados por esse OS. Você também pode acessar os modelos de dados YANG do site de download da Juniper Networks.
Use um navegador web para navegar até a URL do software All Junos Platforms na página da Juniper Networks: https://www.juniper.net/support/downloads/. Na guia gerenciamento de rede, role para baixo e selecione OpenConfig. Selecione a guia de software. Selecione a versão apropriada do módulo OpenConfig.
A interface OpenConfigTelemetry programática define o serviço gRPC de telemetria. O telemetrySubscribe RPC especifica os seguintes parâmetros de assinatura:
-
Caminho openconfig que identifica o recurso do sistema para transmitir dados de telemetria, por exemplo:
/interfaces/interface/state/counters/ -
Intervalo em que 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 em linha 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
A telemetria Junos permite a configuração de serviços de várias portas, permitindo que você configure vários conjuntos de serviços de telemetria para ouvir em diferentes portas.
A Telemetria Junos oferece recursos flexíveis de configuração de serviços 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 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
A 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 as operadoras de rede retomem e modifiquem dados de configuração de dispositivos e assinem dados de telemetria em tempo real de dispositivos de rede. A coleta de dados é uma tarefa essencial em soluções de telemetria. O gNMI oferece suporte a modos de assinatura como ONCE, POLL e STREAM para atualizações de telemetria. A gNMI usa a estrutura gRPC, oferece suporte a formatos eficientes de codificação de dados, como buffers de protocolo (protobuf), e garante uma comunicação segura por meio do TLS. Os modelos YANG definem a estrutura dos dados de configuração e telemetria.
Os principais componentes do gNMI são:
-
cliente gNMI: funciona em um sistema externo. Ele envia solicitações de 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 mudança de gerenciamento de configuração, o servidor gNMI atualiza a configuração do dispositivo e envia uma resposta ao cliente. Ele transmite dados para o cliente gNMI se for uma solicitação de coleta de dados de telemetria.
O gNMI oferece suporte às seguintes chamadas de procedimento remoto (RPCs) para controlar e monitorar dispositivos de rede:
-
Obtenha: Este RPC recupera o estado atual do dispositivo de rede, incluindo configuração e dados operacionais.
Nota:Use a opção
typeno gNMI obtenha comando para especificar o tipo de dados a recuperar. As opções disponíveis sãoCONFIG,STATEeALL. A opção de tipo válido éCONFIG. Use a codificação para definir os formatos de codificação de valor que o protocolo gNMI oferece suporte. As opções disponíveis incluem, , , eASCIIJSON_IETF.PROTOBYTESJSONAs 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.
-
Inscreva-se: Use este RPC para assinar dados de telemetria de um dispositivo de rede. Os seguintes modos de assinatura são suportados:
- UMA VEZ: Recupera os valores atuais apenas uma vez.
- ENQUETE: Envia valores atuais sempre que uma mensagem de pesquisa é recebida.
- STREAM: Envia atualizações continuamente em intervalos especificados ou quando as alterações ocorrem.
Para obter mais informações, veja Diretrizes para assinaturas de dados de telemetria por gNMI
-
Recursos: Use este RPC para descobrir os recursos do dispositivo, como modelos e codificações compatíveis.
Origem do gNMI
O Path campo da origin mensagem identifica o esquema do caminho. O origin campo é codificado como uma corda. O <origin, path> tuple identifica exclusivamente o caminho dentro da mensagem.
O origin campo é válido em qualquer contexto de uma Path mensagem. Normalmente, é usado das seguintes maneiras:
- Use um
SetRequestpara indicar que um esquema em particular modifica a configuração alvo. - Use um
GetRequestpara recuperar o conteúdo de um esquema específico ou usar umGetResponsepara indicar que a carga contém dados de um esquema específico<origin, path>. - Use um
SubscribeRequestpara se inscrever em caminhos dentro de um esquema específico, ou usar umSubscribeResponsepara indicar que uma atualização corresponde a um tuple específico<origin, path>.
Quando uma mensagem usa mais de uma origin, não especifique um caminho no prefix, porque isso prefix se aplica a todos os caminhos da mensagem. Quando um prefix é especificado, inclua qualquer necessidade origin. Não especifique origin os campos de caminho e os prefix campos de caminho em uma única solicitação para qualquer mensagem de carga de RPC.
- Valores especiais de origem
- Definição de
origindados modelados para YANG - Especificações parciais de origem no 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 é especificado, seu valor deve ser padrão para openconfig. Recomenda-se que a origem seja definida de forma explicável.
Definição de origem para dados modelados em YANG
O openconfig-extensions:origin campo pode ser utilizado para determinar a origem em que um módulo específico é instanciado.
origin é diferente.namespace Embora um namespace YANG seja definido em qualquer profundidade dentro da árvore do esquema, um origin só é usado para desambiguar árvores de esquema inteiras. Ou seja, qualquer elemento que não esteja na raiz herda a sua origin de sua entidade raiz, independentemente dos módulos de esquema YANG que compõem essa raiz.
Especificações parciais de origem no conjunto
Se um Set RPC especificar delete, updateou replace campos que incluam uma origin dentro de suas Path mensagens, a alteração correspondente deve ser restringida à origem especificada das seguintes maneiras:
replaceas operações só devem substituir o conteúdo dos especificadosoriginno caminho especificado. As origens que não são especificadas noSetRequestinterior não devem ter seu conteúdo substituído. Para que umareplaceoperação substitua qualquer conteúdo de umaoriginempresa, deve ser explicitamente especificado noSetRequest.deleteas operações devem excluir apenas o conteúdo no caminho especificado dentro do determinadoorigin. Para excluir conteúdos de várias origens, um cliente deve especificar vários caminhos dentrodeletedoSetRequest.
Essas regras se aplicam onde as origens representam dados que não se sobrepõem. Em alguns casos (por exemplo, as origens da CLI e do OpenConfig) podem refletir diferentes "visões" sobre os mesmos dados e, portanto, sua interação é mais complexa.
Transacionalidade de conjuntos com múltiplas origens
Quando um SetRequest especifica mais de uma origem (ou seja, quando inclui duas ou mais operações cujos caminhos fazem referência a diferentes origens), todas as árvores de dados afetadas devem ser tratadas como uma única transação. Isso SetResponse só indica sucesso se todas as operações tiverem sucesso. Se alguma operação falhar, as alterações em todas as origens devem ser revertidas, e um status de erro deve ser devolvido em resposta ao Set RPC.