Entender a telemetria do Junos
A telemetria do Junos é uma estrutura desenvolvida pela Juniper Networks que permite a exportação de dados operacionais de dispositivos Junos para coletores externos. Esses dados são analisados para monitoramento de dispositivos em tempo real. Este tópico descreve os conceitos de telemetria orientada por modelo, modos de telemetria, protocolos de transporte, sensores de telemetria, caminhos de sensores e modelos de dados usados pelo Junos Telemetry.
Telemetria de rede
A telemetria de rede é o processo de coleta, transmissão e análise de dados de dispositivos de rede. Esses dados podem incluir informações sobre padrões de tráfego, status do dispositivo, taxas de erro e outras métricas que fornecem insights sobre a integridade e o comportamento da rede. Usando esses dados, você pode obter insights úteis e aplicá-los para monitorar e gerenciar o desempenho e a segurança da rede com eficiência. Os administradores de rede podem usar dados de telemetria para solucionar problemas de rede, detectar anomalias e otimizar a utilização de recursos na rede. Um dos principais benefícios da telemetria de rede é sua capacidade de fornecer visibilidade em tempo real das operações de rede.
A telemetria de rede também desempenha um papel crucial no aprimoramento da segurança da rede. Ao analisar os dados de telemetria, as equipes de segurança podem identificar padrões incomuns que podem indicar um ataque cibernético ou outras ameaças à segurança, permitindo assim uma detecção e resposta mais rápidas a possíveis incidentes de segurança e ajudando a proteger a rede e seus dados.
Telemetria Junos
O Junos Telemetry é a solução de telemetria da Juniper, desenvolvida para transmitir dados de telemetria. Ele é altamente escalável e pode oferecer suporte a dispositivos de monitoramento remotamente em uma rede. Ela também ajuda a melhorar a solução de problemas, gerenciar proativamente a rede e reduzir os custos operacionais.
A telemetria do Junos pode ser aplicada em uma variedade de cenários de rede:
- Monitoramento de desempenho: Monitore métricas importantes, como utilização de interface, latência e perda de pacotes, para garantir o desempenho ideal da rede.
- Monitoramento de Segurança: Rastreie eventos de segurança, analise padrões de tráfego e identifique possíveis ameaças à segurança.
- Gerenciamento de desempenho de aplicativos: Obtenha insights sobre o desempenho dos aplicativos correlacionando dados de rede com dados de aplicativos.
- Planejamento de capacidade da rede: Analise dados históricos e em tempo real para identificar possíveis gargalos e planejar necessidades futuras de capacidade.
Outros aplicativos da Juniper também utilizam a telemetria do Junos para fornecer dados em tempo real, oferecendo suporte à sincronização de estado operacional entre elementos de rede e um controlador externo, como o Mist da Juniper, o Routing Director da Juniper e o Apstra.
Telemetria orientada por modelos
O Junos Telemetry adotou uma arquitetura de telemetria orientada por modelo (MDT). Um sistema de telemetria de rede orientado por modelos é uma abordagem avançada para o monitoramento de rede que utiliza modelos de dados para definir e coletar dados de telemetria de dispositivos de rede. Nesse sistema, os modelos de dados são definidos usando uma linguagem YANG (Yet Another Next Generation) para especificar a estrutura e os tipos de dados a serem coletados ou transmitidos.
Atualmente, a Juniper oferece suporte aos seguintes modelos de dados diferentes:
-
Modelo de dados nativo da Juniper
-
Modelo de dados OpenConfig
-
Modelo de estado de geração
Todos os modelos usam YANG para especificar a estrutura de dados e os tipos de dados a serem transmitidos, para obter mais informações, consulte Modelos de dados.
A escolha do modelo de dados certo depende das necessidades específicas. Você pode assinar sensores de qualquer modelo simultaneamente. Os sensores nativos têm uma vantagem no suporte a casos de uso variados.
Siga as etapas abaixo para configurar uma solução de telemetria orientada por modelo:
-
Configure o dispositivo da Juniper para transmitir dados de telemetria: Certifique-se de que o dispositivo da Juniper execute uma versão compatível do Junos OS que ofereça suporte à telemetria do Junos e que a conectividade de rede entre o dispositivo da Juniper e o coletor esteja presente.
- Configurar o coletor de dados: configure o coletor para coletar e decodificar os dados. Para obter mais informações, consulte Coletor de dados de telemetria.
- Estabelecer os protocolos de transporte: Escolha e configure os protocolos de transporte apropriados para transmissão de dados. Para obter mais informações, consulte Protocolos de transporte.
- Configure o sensor: Um perfil de sensor define os parâmetros do recurso do sistema a ser monitorado e transmitido. Você pode habilitar apenas um recurso do sistema para monitorar cada perfil de sensor ou configurar um perfil de sensor diferente para cada recurso do sistema. No entanto, é possível configurar mais de um sensor para monitorar o mesmo recurso do sistema. Para obter mais informações, consulte Sensores e caminhos de sensores.
- Criar assinaturas: configure assinaturas para os fluxos de dados que você precisa monitorar. A sessão de telemetria pode ser estabelecida no modo de discagem ou no modo de discagem, dependendo se o dispositivo ou receptor está configurado para iniciar a assinatura. Para obter mais informações, consulte Modos de telemetria.
Sensores e caminhos de sensores
Os sensores de telemetria são um componente importante de uma solução de telemetria. Eles medem vários parâmetros físicos, ambientais e de desempenho e os convertem em dados que são transmitidos por conexões TCP ou UDP ao coletor para monitoramento e análise remotos. Alguns exemplos são sensores de temperatura, sensores de interface, sensores de fluxo e assim por diante. Um caminho de sensor de telemetria é uma rota específica dentro de um modelo de dados, definida usando YANG, que especifica os dados exatos a serem coletados e transmitidos de um dispositivo de rede. A Juniper oferece suporte a sensores de modelos Openconfig, nativos e de estado de geração. Os sensores Openconfig rastreiam métricas baseadas em contador ou estado, e os sensores nativos rastreiam efetivamente métricas orientadas a eventos, pois esses sensores têm acesso a dados detalhados do dispositivo. Você pode configurar caminhos de sensores baseados em Openconfig para recuperar informações do sensor em um formato neutro de fornecedor ou configurar caminhos de sensor nativos para recuperar informações proprietárias da Juniper em um formato nativo. Para obter mais informações, consulte Explorar caminhos do sensor.
Coletor de dados de telemetria
O coletor de telemetria é uma ferramenta ou software especializado que realiza coleta, processamento, transmissão e armazenamento de dados de telemetria. É um intermediário entre os dispositivos Junos que geram dados de telemetria e os sistemas de back-end que os armazenam, analisam e visualizam.
Funções de um coletor de dados:
- Coleta de dados: O coletor recebe dados de telemetria de dispositivos da Juniper por meio de conexões gRPC ou UDP.
- Processamento de dados: o coletor processa os dados coletados agregando-os e normalizando-os para filtrar informações desnecessárias, agregar métricas e realizar uma análise inicial. Esse processamento ajuda a reduzir o volume de dados e a focar nas métricas mais críticas.
- Transmissão de dados: Garante uma transmissão de dados confiável e baixa latência.
- Armazenamento de dados: Os dados processados são então exportados para vários sistemas de back-end para análise, visualização e armazenamento adicionais. Ele pode ser armazenado em data lakes para análise de longo prazo e comparação histórica. O coletor suporta vários formatos e protocolos de dados, tornando-o compatível com diferentes ferramentas de monitoramento e análise. Os dados analisados podem ser apresentados por meio de painéis e relatórios interativos, fornecendo insights acionáveis aos administradores da rede.
Modos de telemetria
O Junos Telemetry oferece suporte a sessões de telemetria em dois modos:
Os dispositivos da Juniper podem operar nos modos de discagem e discagem. Você pode configurar o dispositivo da Juniper em qualquer um dos modos com base na topologia da sua rede. Ambos os modos usam os mesmos modelos de dados e transmitem os mesmos dados de telemetria pela rede. A diferença entre os dois modos é baseada em se o coletor ou dispositivo da Juniper inicia e mantém a conexão.
Tipos de assinatura
O Junos Telemetry oferece suporte a vários modos de assinatura, permitindo a coleta de dados personalizados com base em necessidades e condições específicas. Os modos de assinatura são configurados no dispositivo usando comandos CLI ou fazem parte da solicitação de assinatura com base no tipo de telemetria. Esses modos determinam o comportamento do fluxo de dados. Os intervalos de streaming determinam a frequência de transmissão de dados de telemetria entre o dispositivo e o coletor. A coleta e o streaming de dados são acionados quando determinadas condições são atendidas ou ocorrem eventos que iniciam a coleta e o streaming de dados de telemetria. Esses gatilhos garantem que os dados sejam coletados quando critérios específicos são atendidos. Por exemplo, os dados de telemetria podem ser coletados e transmitidos quando a perda de pacotes é detectada. Há suporte para os seguintes modos de assinatura:
- Uma vez: esta é uma solicitação única de dados de telemetria. Você pode configurar esse tipo de assinatura quando um instantâneo do estado atual dos dados inscritos for necessário. O dispositivo envia os dados de telemetria uma vez para o coletor e para.
- Sondagem: é a recuperação periódica sob demanda de dados de telemetria. Esta configuração é adequada para monitorar sensores em intervalos específicos. Em um cenário de discagem, o coletor assina dados de telemetria por meio desse tipo de assinatura e, em seguida, pesquisa as informações conforme necessário.
- Fluxo: essa assinatura contínua transmite dados continuamente quando ocorrem gatilhos configurados.
Observação: Nem todos os sensores (OpenConfig ou nativos) dão suporte a todos os tipos de assinatura.
Modos de assinatura
A telemetria do Junos oferece suporte aos seguintes modos de assinatura:
- ON_CHANGE: O dispositivo envia atualizações somente quando os dados monitorados são alterados (por exemplo, um contador de interface é incrementado ou um estado é invertido). Esse modo é adequado para métricas orientadas por eventos em vez de orientadas pelo tempo.
- AMOSTRA: As atualizações de telemetria são transmitidas em intervalos regulares com base no intervalo configurado. Esse modo é adequado para métricas como contagens de pacotes ou bytes transferidos, que são amostrados ao longo do tempo.
- TARGET_DEFINED: O dispositivo decide o melhor modo (SAMPLE ou ON_CHANGE) com base no sensor ou recurso monitorado. A implementação do Juniper pode ser padronizada para SAMPLE, a menos que ON_CHANGE tenha suporte explícito para o sensor.
- Observação: As TARGET_DEFINED solicitações de assinatura para caminhos de configuração são tratadas apenas como solicitações ON_CHANGE.
Determinar a configuração de telemetria apropriada para sua rede
A topologia de rede e os requisitos de dados determinam os sensores, o tipo de assinatura e o modo de assinatura apropriados. Por exemplo, use sensores OpenConfig com o modo de assinatura SAMPLE para monitoramento periódico padronizado, como o suporte a painéis de vários fornecedores. Para insights específicos de Juniper ou orientados a eventos, como solução de problemas de hardware, use sensores nativos com o modo de assinatura ON_CHANGE.
Protocolos de transporte
Os protocolos de transporte definem como os dados de telemetria são transmitidos entre os dispositivos Junos e os coletores de telemetria.
Há suporte para os seguintes protocolos:
-
Protocolo de controle de transmissão (TCP)
-
Protocolo de datagrama de usuário (UDP)
TCP
O TCP é o principal protocolo suportado pelo Junos Telemetry. O TCP é orientado para conexão, com estado e seguro (suporte a TLS), o que o torna confiável para a entrega de dados. O TCP é suportado nos modos de telemetria dial-in e dial-out. Ele forma a camada de base para mecanismos de telemetria, como o pré-gNMI (proprietário da Juniper) e o gNMI.
| Discagem | Discagem de saída | |
|---|---|---|
| Transporte | TCP | TCP |
| Sessão | HTTP/2 | HTTP/2 |
| Estrutura RPC | GRPC | GRPC |
| API de telemetria | gNMI | gNMI |
| Modelos de dados |
|
|
Para configurar a telemetria e decodificar mensagens de telemetria, consulte , Assinatura gNMI, Configurar serviços gRPC, Tipos de dados suportados, Repositório GitHub da Juniper e Formato compacto de mensagem Protobuf (proprietário da Juniper).
UDP
O UDP é um protocolo de transporte leve e sem conexão compatível com o Junos Telemetry. O UDP é suportado no modo de telemetria de discagem.
| Discagem | Discagem de saída | |
|---|---|---|
| Transporte | - | UDP |
| Sessão | - | - |
| Estrutura RPC | - | GRPC |
| API de telemetria | - | - |
| Modelos de dados | - |
|
Na telemetria UDP, os arquivos proto são necessários para decodificar a estrutura da mensagem de telemetria. Para configurar e decodificar mensagens de telemetria, consulte Streaming de dados de telemetria por UDP, Formato de encapsulamento de dados do sensor, Tipos de dados suportados, Repositório GitHub da Juniper e Formato de mensagem compacta Protobuf (proprietário da Juniper).
Modelos de dados
Os modelos de dados de telemetria do Junos definem a estrutura dos dados de telemetria coletados de dispositivos de rede usando YANG (Yet Another Next Generation, na sigla em inglês). YANG é uma linguagem de modelagem de dados extensível baseada em padrões usada no Junos Telemetry para definir configuração, dados de estado operacional e chamadas de procedimento remoto (RPCs) para dispositivos de rede. No Junos Telemetry, os modelos YANG expressam a estrutura e os detalhes dos modelos de dados que contêm os sensores, como estatísticas de interface. O padrão YANG é definido no RFC 6020 e RFC 7950.
A Juniper Networks publica módulos YANG para dispositivos Junos, que podem ser baixados do repositório GitHub da Juniper. A partir da versão 23.4, os modelos YANG de configuração e telemetria são mesclados e publicados no repositório GitHub da Juniper. Ele contém definições YANG para configuração, RPCs e modelos de telemetria.
O grupo de trabalho OpenConfig define o modelo de dados OpenConfig. É um modelo de dados neutro de fornecedor para configurar e gerenciar a rede. O modelo de dados OpenConfig gera dados como mensagens do Google Protocol Buffers (GPB) em um formato universal de chave/valor. O Junos Telemetry permite que você aproveite os modelos OpenConfig para uma visão mais ampla e independente de fornecedor de sua rede. Os caminhos do sensor Openconfig são usados para recuperar informações do sensor de sensores com base no modelo de dados Openconfig. Para exploração detalhada do caminho do recurso Openconfig, consulte Explorador do modelo de dados YANG do Junos.
O modelo de dados nativos da Juniper é uma estrutura aberta e extensível desenvolvida pela Juniper. Esse modelo é usado para transmitir dados de telemetria sobre os recursos exclusivos encontrados nos dispositivos da Juniper. Isso inclui estatísticas de interface, informações de roteamento, métricas de segurança e assim por diante. Além disso, o modelo nativo permite a definição de sensores específicos da empresa. Para acessar informações da Juniper ou de sensores específicos da empresa, assine os sensores nativos da Juniper. Os caminhos de sensor nativos são usados para recuperar informações do sensor de sensores com base no modelo de dados nativo. Os módulos YANG da Juniper para sensores nativos estão disponíveis no repositório YANG da Juniper no GitHub.
Os modelos de estado de geração são modelos YANG gerados automaticamente derivados de dados de estado operacional. Os modelos YANG genstate expõem um subconjunto de dados do comando show por meio do RPC de assinatura gNMI. Um coletor de telemetria gNMI pode se inscrever nos caminhos de recursos definidos nos modelos publicados para obter dados de estado específicos. Para configurar a assinatura gNMI, consulte Assinatura gNMI. Os coletores consomem modelos de estado de geração para emitir consultas de caminho de recurso para recuperar dados de estado operacional específicos. Cada marca raiz corresponde a um único modelo de estado genstate (ou seja, um arquivo YANG por marca raiz).
Explore os caminhos dos sensores
Um caminho de sensor de telemetria descreve o caminho hierárquico para os pontos de dados ou métricas que precisam ser monitorados. Ele é usado para identificar, ativar e transmitir os dados relevantes. O Junos Telemetry oferece suporte a Openconfig, Genstate e caminhos de sensores nativos:
-
Caminhos do sensor OpenConfig
Para configurar a coleta de dados de sensores Openconfig, defina as assinaturas e os caminhos do sensor (por exemplo,
/interfaces/interface/state/counters), configure o coletor de dados e baixe os arquivos de buffers do protocolo de telemetria do Junos na página de suporte da Juniper Networks. Capture e decodifique os dados capturados no coletor. -
Caminhos de sensores nativos
Os caminhos de sensores nativos são específicos do Junos OS (por exemplo,
/junos/system/line card/interface/) e oferecem acesso granular e otimizado pela Juniper a métricas específicas do dispositivo.Os modos de assinatura são configurados no dispositivo usando comandos CLI ou fazem parte da solicitação de assinatura com base no tipo de telemetria. Use os arquivos do buffer de protocolo para decodificar os dados do sensor no coletor.
-
Caminhos do sensor de estado de geração
Os caminhos de recursos de estado de geração são usados para recuperar dados de estado expostos por meio de modelos de dados YANG de estado de geração de um dispositivo de rede. Os modelos YANG genstate expõem um subconjunto de dados do comando show por meio do RPC de assinatura gNMI. Os caminhos de recursos do modelo genstate são acrescentados com
/genstate/. Por exemplo, o coletor envia a seguinte consulta para recuperar o nome mpls lsp:genstate:/genstate/mpls-lsp-information/rsvp-session-data/rsvp-session/mpls-lsp/nameObservação:Para obter mais informações sobre os módulos YANG genstate e como descobrir o módulo correspondente e os caminhos de recursos disponíveis para um determinado comando show, consulte Modelos de dados YANG do Junos Genstate.
Consulte Modelos de dados YANG de estado geral para visualizar os comandos show suportados e os caminhos raiz.
Todos os tipos de caminho permitem a saída estruturada de dados em formatos como JSON ou XML, garantindo a compatibilidade com coletores externos para monitoramento e análise eficientes.
- Explorador de caminhos de sensores
- Selecionando caminhos do sensor de telemetria
- Diretrizes importantes e convenções de nomenclatura para caminhos de sensores
- Exemplo de caminho do sensor
Explorador de caminhos de sensores
O Junos YANG Data Model Explorer da Juniper Networks é uma ferramenta on-line para visualizar todos os caminhos de recursos compatíveis, suas folhas correspondentes e as plataformas de dispositivos que os suportam. Ele permite que você explore ou compare vários atributos do modelo de dados. Use a opção de filtro com base no número de versão do software ou produto para visualizar a lista de caminhos de recursos e sensores em cada plataforma.
Selecionando caminhos do sensor de telemetria
Em um sistema de telemetria orientado por modelo, o caminho do sensor pode ser configurado para terminar em qualquer nível dentro da hierarquia de contêineres do modelo de dados. Com base nas informações de telemetria necessárias, você pode configurar o caminho do sensor para recuperar um conjunto de dados amplo ou ser muito específico e recuperar informações direcionadas para um sensor específico. Por exemplo, um caminho de sensor pode apontar para um contêiner que inclui todas as estatísticas de interface em um roteador ou pode ser mais granular, concentrando-se em uma única métrica, como perda de pacotes em uma interface específica.
Por exemplo, para receber dados de telemetria sobre alarmes gerados no dispositivo (usando o modelo de dados OpenConfig ), você pode configurar um dos seguintes caminhos de recursos com base na granularidade dos dados do sensor necessários:
/system/alarms/alarm/id: Este caminho recupera apenas o ID do alarme./system/alarms/alarm/config: Este caminho recupera as informações detalhadas do alarme.
A configuração dos caminhos corretos do sensor garante um sistema de telemetria eficiente. Cada caminho de recurso permite o streaming de dados para o recurso do sistema globalmente, ou seja, em todo o sistema. Você pode modificar cada caminho de recurso para especificar uma interface lógica ou física. O caminho do recurso "/interfaces/interface/config" recupera a lista de itens configuráveis no nível da interface física global, enquanto o caminho "/interfaces/interface/config/name" especifica o nome da interface, e o dispositivo pode restringir os valores permitidos para essa folha, dependendo do tipo da interface.
Diretrizes importantes e convenções de nomenclatura para caminhos de sensores
Na maioria dos casos, você deve fornecer o caminho completo e direto do recurso ao configurar sensores. Fornecer caminhos de recursos parciais, como "/components/component/", pode resultar em configurações incompletas e erros potenciais. Esses caminhos de recursos podem impor uma carga significativa ao dispositivo, pois ele deve recuperar e exibir todas as opções disponíveis dentro dessa hierarquia. Para evitar isso, sempre verifique e use o caminho completo do recurso para garantir uma configuração precisa e eficiente do sensor.
Use a convenção de nomenclatura hierárquica de componentes para componentes do sistema. Essa convenção permite a identificação precisa do componente, usando um caminho completo a partir do nó raiz, como CHASSIS0:REx para mecanismos de roteamento e CHASSIS0:FPCx:PICy:NPUz para unidades de processamento de rede (NPUs).
A tabela a seguir inclui exemplos de como os nomes dos componentes foram alterados:
|
Categoria de componentes |
Nome antigo |
Novo nome |
|---|---|---|
|
Chassi |
|
|
|
Placa de controle (CB) |
|
|
|
Bandeja do ventilador |
Bandeja do ventilador, Bandeja do ventilador 0 |
|
|
Ventilador |
Bandeja do ventilador 0 Ventilador 0 |
|
|
FPC |
|
|
|
RE CPU |
|
|
|
CPU FPC (lógica) |
|
|
|
FPC CPU (núcleo) |
|
|
|
PIC |
|
|
|
CC |
|
|
|
NPU |
|
|
|
DP |
|
|
|
Porta |
|
|
|
XCVR |
|
|
|
OCH |
|
|
|
Pista |
|
|
|
FPM |
|
|
|
PLANO INTERMEDIÁRIO |
|
|
|
PSM |
|
|
|
Mecanismo de Roteamento (RE) |
|
|
|
FTC |
|
|
|
SIB |
|
|
|
RE Bootloader |
|
|
|
RE BIOS |
|
|
|
FEV |
|
|
Um exemplo de caminho completo, por fpc exemplo, é /components/component[name="CHASSIS0:FPC0"]/state/parent : CHASSIS0.
Para obter mais informações sobre convenções de nomenclatura de componentes, consulte Nomenclatura de interface
Exemplo de caminho do sensor
| Caminho completo do sensor | Caminho parcial do sensor |
|---|---|
/interfaces/interface/subinterfaces/subinterface/state/counters/out-pkts |
/interfaces/interface |
/interfaces/interface/ inscrito que produz o caminho /junos/system/linecard/interface/logical/ usage/ transmitido relata o nome da chave sai parent_ae_name e init_time (com sublinhados no nome folha). O caminho /interfaces/interface/state/ inscrito que produz o caminho / junos/system/linecard/interface/queue/ transmitido relata o nome da chave sai parent-ae-name e init-time (com hífens no nome folha).
O desempenho dos dispositivos Junos Evolved é otimizado por meio de uma arquitetura baseada em serviços, na qual alguns processos ou daemons são ativados com base na configuração do serviço. Esses processos permanecem inativos até que o serviço seja configurado. Se uma assinatura de telemetria for direcionada a um serviço inativo, nenhuma saída de telemetria será gerada.
Formato de encapsulamento de dados do sensor
A telemetria do Junos oferece suporte a duas maneiras de exportar dados no formato de buffers de protocolo (gpb). Esta seção descreve o formato de dados usado por sensores nativos ao exportar dados de telemetria por UDP. Os dados são encapsulados em um cabeçalho UDP, que é encapsulado ainda mais na carga IPv4. Esse modelo de telemetria segue uma arquitetura distribuída, onde os dados gerados pelos sensores configurados são exportados diretamente do plano de dados. Ao ignorar o plano de controle, essa abordagem ajuda a conservar os recursos do plano de controle para outras funções críticas.
Um sensor nativo exporta dados próximos à fonte usando UDP. Vários tipos de dados de telemetria, como estatísticas de interface física, estatísticas de contador de filtro de firewall ou estatísticas para caminhos comutados por rótulos (LSPs) podem ser exportados. Um sensor começa a emitir dados assim que é ativado.
Os dados do sensor são representados como uma única mensagem de buffer de protocolo estruturado, chamada TelemetryStream. A mensagem, ou .proto arquivo, mostrado abaixo, inclui vários atributos que identificam a fonte de dados, como uma placa de linha, um Mecanismo de Encaminhamento de Pacotes ou um Mecanismo de Roteamento. O nome do sensor configurado também está incluído. Para obter mais informações sobre como configurar sensores, consulte Explorar caminhos do sensor. Para obter uma lista de sensores nativos compatíveis, consulte sensor (Interface de telemetria do Junos).
Você também deve baixar os .proto arquivos de todos os sensores suportados para um servidor de streaming ou coletor. Para baixar arquivos de modelo OpenConfig e YANG, abra um navegador da Web e 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 Localizar um produto, pesquise e selecione o produto desejado e escolha a VERSÃO do software e do Junos OS apropriada 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. Para obter mais informações sobre como configurar um servidor de streaming, consulte servidor de streaming (Interface de telemetria do Junos).
Formato compacto de mensagem Protobuf (proprietário da Juniper)
As informações transmitidas para o coletor são enviadas usando a estrutura de mensagem de nível superior de TelemetryStream (arquivo telemetria_top.proto). A mensagem contém os metadados dos dados do sensor que estão sendo transmitidos (por exemplo, o caminho do sensor, o sistema de onde os dados estão sendo enviados, o nó de onde os dados são enviados e assim por diante). Os dados reais do sensor são enviados como uma extensão para a mensagem de nível superior. Um arquivo proto separado é enviado para os dados do sensor. O arquivo telemetria_top.proto e o arquivo proto do sensor são usados para decodificar os dados do sensor no coletor.
Estrutura do arquivo telemetria_top.proto
message TelemetryStream {
required string system_id = 1
[(telemetry_options).is_key = true];
optional uint32 component_id = 2
[(telemetry_options).is_key = true];
optional string sensor_name = 4
[(telemetry_options).is_key = true];
….
optional EnterpriseSensors enterprise = 101;
}
message EnterpriseSensors {
extensions 1 to max;
}
extend EnterpriseSensors {
// re-use IANA assigned numbers
optional JuniperNetworksSensors juniperNetworks = 2636;
}
message JuniperNetworksSensors {
extensions 1 to max; → ends with the extension message
}
Esse arquivo termina com a extension mensagem.
Estrutura do arquivo Proto do sensor
Esse arquivo começa com a extension mensagem.
extend JuniperNetworksSensors { → begins with the extension message
optional Port jnpr_interface_ext = 3;
}
message Port {
repeated InterfaceInfos interface_stats = 1;
}
message InterfaceInfos {
required string if_name = 1
[(telemetry_options).is_key = true];
optional uint64 init_time = 2;
…..
}
A TelemetryStream mensagem também inclui estruturas aninhadas opcionais que transportam diferentes tipos de dados. As estruturas aninhadas também podem transportar dados de sensores definidos de forma privada, como EnterpriseSensors. Veja o exemplo abaixo:
//
// This file defines the top level message used for all Juniper
// Telemetry packets encoded to the protocol buffer format.
// The top level message is TelemetryStream.
//
import "google/protobuf/descriptor.proto";
extend google.protobuf.FieldOptions {
optional TelemetryFieldOptions telemetry_options = 1024;
}
message TelemetryFieldOptions {
optional bool is_key = 1;
optional bool is_timestamp = 2;
optional bool is_counter = 3;
optional bool is_gauge = 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];
// configured sensor name
optional string sensor_name = 4 [(telemetry_options).is_key = true];
// sequence number, monotonically increasesing for each
// system_id, component_id, sub_component_id + sensor_name.
optional uint32 sequence_number = 5;
// timestamp (milliseconds since 00:00:00 UTC 1/1/1970)
optional uint64 timestamp = 6 [(telemetry_options).is_timestamp = true];
// major version
optional uint32 version_major = 7;
// minor version
optional uint32 version_minor = 8;
optional IETFSensors ietf = 100;
optional EnterpriseSensors enterprise = 101;
}
message IETFSensors {
extensions 1 to max;
}
message EnterpriseSensors {
extensions 1 to max;
}
extend EnterpriseSensors {
// re-use IANA assigned numbers
optional JuniperNetworksSensors juniperNetworks = 2636;
}
message JuniperNetworksSensors {
extensions 1 to max;
}
Empresas individuais, como a Juniper Networks, definem e mantêm os atributos gerados pelos sensores corporativos. Cada empresa recebe um identificador de atributo exclusivo. A convenção atual é usar identificadores MIB corporativos atribuídos pela IANA para cada atributo. Para a Juniper Networks, esse identificador atribuído é 2636.
Recomendado: Para verificar se um determinado tipo de mensagem foi exportado e recebido, verifique esses atributos na TelemetryStream.enterprise.juniperNetworks mensagem gpb.
Consulte a Tabela 5 para obter descrições de cada elemento coletado pelos dados do sensor, incluindo semântica e esquema correspondente.
|
Tipo de elemento |
Descrição |
|---|---|
|
Contador |
Um inteiro sem sinal que aumenta monotonicamente. Quando atinge seu valor máximo, ele começa em zero. |
|
Bitola |
Um inteiro não assinado de 32 bits ou 64 bits que pode aumentar ou diminuir de valor. Um exemplo dos dados representados por esse elemento é o valor instantâneo de um recurso específico, como profundidade da fila ou temperatura. |
|
Taxa |
Taxa na qual uma métrica base é alterada, como um contador ou um medidor. Para esse tipo de elemento, as unidades de medida são definidas explicitamente (como bits por segundo), bem como o intervalo sobre o qual a taxa é coletada. |
|
Média |
A média de várias amostras de uma métrica base. Por exemplo, um elemento de dados de profundidade média da fila seria calculado calculando a média de vários elementos da profundidade da fila. Para esse tipo de elemento, é altamente recomendável definir o número de medições usadas para calcular a média, bem como o intervalo de tempo entre as medições. Caso contrário, você deve definir explicitamente os meios pelos quais esse valor médio é calculado. |
|
Pico |
Valor máximo entre vários exemplos de uma métrica base. Por exemplo, um elemento de profundidade da fila de pico seria calculado comparando várias medidas da profundidade da fila e selecionando o máximo. Para esse tipo de elemento de dados, é altamente recomendável que você defina o número de medições usadas para calcular o valor de pico, bem como o intervalo de tempo entre as medições. Caso contrário, defina explicitamente como esse valor de pico é definido. Você também deve saber se esse valor nunca é limpo e, portanto, representa o valor máximo geral em todos os tempos. |
Cada tipo de elemento de dados também inclui subconjuntos de elementos. Por exemplo, os elementos Counter de dados e Gauge incluiriam subconjuntos para rate, averagee peak medidas.
Tipos de dados compatíveis
Um GetRequest é enviado quando um cliente coletor inicia um Get RPC para receber dados de telemetria. Especificados no GetRequest são os elementos de dados com os quais o destino deve retornar dados ao coletor, incluindo o tipo de dados. O tipo de dados é a variável que especifica a forma na qual os dados devem ser entregues.
A Tabela 6 lista os tipos de dados suportados pela telemetria do Junos. A menos que especificado, o tipo de dados é suportado para exportação de dados de telemetria do Junos usando serviços de chamada de procedimento remoto (gRPC), serviços de interface de gerenciamento de rede gRPC (gNMI) ou por UDP.
|
Digite |
Valor |
Descrição |
|---|---|---|
|
string |
|
String. |
|
int64 |
|
Valor inteiro. |
|
uint64 |
|
Valor inteiro sem sinal. |
|
bool |
|
Valor booleano. |
|
flutuador |
|
Valor de ponto flutuante.
Observação:
Esse tipo de dados foi preterido. Use |
|
duplo |
|
Um valor double é um valor de ponto flutuante de 64 bits. |
|
Decimal64 |
|
Decimal64 valor codificado. Suportado apenas com serviços gNMI. Use decimal64 para codificar um número decimal de precisão fixa. O valor é expresso como um conjunto de dígitos com a precisão especificando o número de dígitos após o ponto decimal no conjunto de dígitos. Por exemplo: message Decimal64 {
int64 digits = 1; // Set of digits.
uint32 precision = 2; // Number of digits following the decimal point.
Observação:
Esse tipo de dados foi preterido. Use |
|
Matriz Escalar |
|
Valor de matriz escalar de tipo misto. Uma matriz homogênea dos valores de tipos de dados mistos (string, int64, uint64, bool float ou decimal64). Suportado apenas com serviços gNMI. |
| Digite | Valor | Descrição |
|---|---|---|
| ieeefloat32 | Binário, comprimento = 4 |
Um número de ponto flutuante IEEE de 32 bits. Esse é um tipo de dados do modelo Open Config. O formato desse número está no formato: 1-bit sign
8-bit exponent
23-bit fraction
The floating point value is calculated using:
(-1)**S * 2**(Exponent-127) * (1+Fraction)";
Observação: O tipo de dados gNMI equivalente ao formato binário é "byte". Em uma resposta gNMI, os dados foram recebidos incorretamente de um dispositivo no formato float_val e um erro de não conformidade foi exibido. Foram incorporadas alterações para retornar dados no formato bytes_val. Os quatro bytes (que representam um valor de ponto flutuante) são enviados na ordem de bytes da rede. Certifique-se de reordená-los na ordem de bytes do host antes de interpretar o valor.
|
Para obter mais informações sobre tipos de dados, consulte github e http://www.openconfig.net/.
Monitoramento de desempenho usando a telemetria Junos
Uma das principais funções do Junos Telemetry é o monitoramento de desempenho. A transmissão de dados para um sistema de gerenciamento de desempenho permite que os administradores de rede meçam as tendências na utilização de links e nós e solucionem problemas como o congestionamento da rede em tempo real.
Em uma implantação típica, o elemento de rede, ou dispositivo, transmite dados duplicados para dois servidores de destino que funcionam como coletores do sistema de gerenciamento de desempenho. O streaming de dados para dois coletores fornece redundância. Consulte a Figura 1 para obter uma ilustração de como os coletores do sistema de gerenciamento de desempenho solicitam dados e como o dispositivo transmite dados. O dispositivo provisiona sensores para coletar e exportar dados usando a interface de linha de comando (CLI), configuração por meio de NETCONF ou chamadas de assinatura gRPC. Os coletores solicitam dados iniciando uma assinatura de telemetria. Os dados são solicitados apenas uma vez e são transmitidos periodicamente.
desempenho
Outras aplicações do Junos Telemetry incluem o fornecimento de dados em tempo real para apoiar a sincronização de estado operacional entre um elemento de rede e um controlador externo, como o Northstar Controller, que automatiza a criação de caminhos de engenharia de tráfego em toda a rede. O NorthStar Controller pode assinar dados de telemetria sobre determinados elementos da rede, como estatísticas de caminho comutado por rótulos (LSP).