White paper sobre telemetria orientada a modelos ASR9K
Contents
Introduction
Público-alvo
Este white paper tem como objetivo ajudar os clientes a obter um rápido entendimento sobre o recurso de telemetria orientada a modelos (MDT) em geral e como ele foi implementado no Aggregation Services Router 9000 (ASR9K), incluindo algumas diretrizes de design e detalhes de configuração. Ele também inclui algumas considerações de implantação, que serão úteis durante a implantação desse recurso usando o ASR9K. Em geral, este white paper pode ser um guia de referência rápida para qualquer pessoa que trabalhe com esse recurso.
Embora a telemetria seja introduzida como um recurso genérico, o foco é na implementação do ASR9K; isto é, nem todos os recursos suportados por outras plataformas da cisco são suportados pela plataforma ASR9K e algumas implementações de recursos podem ser específicas do ASR9K.
Uma breve introdução à telemetria
Para começar, em termos simples, a telemetria é o processo de coleta de dados operacionais úteis. De acordo com a Wikipédia, a telemetria é um processo de comunicação automatizado pelo qual as medições e outros dados são coletados em pontos remotos ou inacessíveis e transmitidos para o equipamento receptor para monitoramento. A própria palavra de telemetria é derivada das raízes gregas: tele = remoto, e metron = medida.
Para o gerenciamento de rede, os operadores de rede têm um longo histórico de confiar no SNMP (Simple Network Management Protocol Protocolo de Gerenciamento de Rede Simples). Embora o SNMP seja amplamente adotado para monitoramento de rede, ele nunca foi usado para configuração, embora a capacidade de configuração com snmp estivesse sempre lá. Os operadores escreveram scripts de automação para lidar com tarefas de configuração diárias, mas os scripts são desafiadores para essas tarefas e difíceis de gerenciar.
Assim, os operadores passaram para o gerenciamento orientado por modelo de dados. A configuração de rede é baseada em modelos de dados YANG enviados por protocolos como o netconf, por exemplo. O simples envio da configuração não implica que o serviço configurado esteja em execução; é necessário que haja um mecanismo que possa monitorar os dados operacionais dos serviços ao mesmo tempo que a configuração. É aqui que os modelos de dados oper, que a telemetria usa para enviar informações para fora do dispositivo, ajudam. Portanto, a configuração é orientada pelo modelo de dados YANG, assim deve ser a verificação do serviço também; como no caso da telemetria, a fim de ter o mesmo objeto semântico. Assim, o termo é chamado telemetria orientada a modelos ou telemetria de fluxo contínuo.
A telemetria orientada a modelos (MDT - Model Driven Telemetry) foi introduzida no cXR (IOS XR de 32 bits) desde a versão 6.1.1 e permite a coleta e a medição de dados críticos em tempo quase real, fornecendo uma resposta rápida para a maioria dos problemas operacionais da rede moderna.
Arquitetura de telemetria de alto nível
O MDT utiliza modelos de dados estruturados suportados pelo dispositivo de rede e fornece dados críticos definidos nesses modelos de dados. A telemetria ajuda os clientes a gerenciar sua rede de vários fornecedores usando um sistema de gerenciamento de rede, processo e aplicativos comuns, já que os dados coletados da rede são baseados em padrões e são uniformes em toda a implementação do fornecedor.
Em vez de esperar pela recuperação de dados (pull) de uma estação de gerenciamento centralizada (normalmente SNMP NMS); com MDT, os dispositivos de rede enviam proativamente (push) dados de desempenho relativos às funções vitais da rede, como informações de encaminhamento de pacotes, estatísticas de erro, status do sistema, recursos de CPU e memória, etc.
Por que telemetria
A coleta de dados para fins analíticos e de solução de problemas sempre foi um aspecto importante no monitoramento da integridade de uma rede. Há vários mecanismos disponíveis, como SNMP, CLI e Syslog, para coletar dados de uma rede. Embora esses métodos tenham servido a rede por muito tempo, mas não se encaixem na rede moderna em que a demanda por automação, os serviços em escala são fundamentais. As informações de integridade da rede, estatísticas de tráfego e informações críticas de infraestrutura são enviadas para uma estação remota no NMS, onde são usadas para melhorar o desempenho operacional e reduzir o tempo de solução de problemas. Um modelo pull, como o snmp, no qual um cliente faz o poll de todos os nós de rede, não é eficiente. A carga de processamento nos nós de rede aumenta quando há mais clientes para pesquisar. Ao contrário, um modelo push tem a capacidade de transmitir dados continuamente para fora da rede e notificar o cliente. A telemetria permite o modelo push, que fornece acesso quase em tempo real aos dados de monitoramento.
A telemetria de fluxo fornece um mecanismo para selecionar dados de interesse dos roteadores e transmiti-los em um formato padrão para estações de gerenciamento remoto para monitoramento. Esse mecanismo permite o ajuste fino da rede com base em dados em tempo real, o que é crucial para sua operação contínua. A granularidade mais fina e a maior frequência dos dados disponíveis por telemetria permitem um melhor monitoramento do desempenho, resultando em uma melhor solução de problemas.
Ele ajuda na utilização mais eficiente da largura de banda na rede, na utilização do link, na avaliação de riscos e na escalabilidade. Com a telemetria de fluxo contínuo, mais dados quase em tempo real estão disponíveis à disposição dos operadores de rede, o que ajuda a melhorar a tomada de decisões.
A necessidade de abandonar o SNMP
O SNMP existe há três décadas e a maneira como ele opera não mudou para atender às necessidades de monitoramento das redes modernas. O problema real é a velocidade de execução do SNMP.
Os três principais desafios impostos pelo SNMP são, na verdade, parte de seu comportamento operacional fundamental e, portanto, o SNMP oferece pouco ou nenhum espaço para aprimoramento e a telemetria trata todos os três inerentemente.
- Velocidade de execução e necessidade de monitoramento em tempo real
O SNMP usa o modelo PULL - operações GetBulk / GetNext que funcionam de forma linear atravessando as tabelas de uma coluna para outra caixa. Além disso, várias solicitações são necessárias no caso de tabelas grandes que não se encaixam em um pacote. Esse é o maior gargalo que faz com que o SNMP fique lento e os dados enviados geralmente ficam desatualizados por um determinado fator de tempo em minutos. Esse atraso simplesmente não é aceitável para os requisitos modernos de monitoramento de rede.
MDT (Model Driven Telemetry) usa o modelo PUSH e está inerentemente livre da limitação listada acima, pois sabe quais dados devem ser enviados a quem e em que intervalo. Ele precisa apenas de uma consulta para coletar dados e usa modelos internos pré-desenvolvidos para velocidade ultrarrápida das operações internas, permitindo assim a entrega de muito mais dados em um tempo consideravelmente menor.
- Despesas gerais adicionais e falta de opções de otimização
Os dados que estão sendo extraídos pelo SNMP são, na verdade, armazenados como estruturas de dados internas e precisam ser convertidos internamente pelo nó. Esse é um trabalho adicional nos bastidores onde o nó de rede mapeia estruturas de dados internas no formato SNMP. Há otimizações internas executadas, mas elas ainda não são suficientes.
Por outro lado, a Telemetria retira diretamente as estruturas de dados internas e executa um processamento mínimo antes de enviar esses dados, fornecendo assim os dados mais atualizados com o menor tempo e esforço possível.
- Natureza Linear da Carga de Trabalho
Cada estação de polling adicional levará a carga de trabalho adicional no nó, mesmo se estivermos fazendo polling dos mesmos dados exatos ao mesmo tempo. O acesso paralelo do mesmo MIB a partir de várias estações de interrogação pode levar a uma resposta mais lenta e a uma maior utilização da CPU. Isso é evidente especialmente no caso de tabelas grandes, onde várias estações acessam partes diferentes da mesma tabela MIB.
A telemetria, por outro lado, precisa receber dados uma vez e replicar os pacotes se os mesmos dados forem exigidos por vários destinos. O modelo Push supera o SNMP Pull para velocidade e escala.
Com o MDT, a abordagem da coleta de dados muda radicalmente e seus princípios fundamentais são listados na tabela abaixo e comparados com os pontos-chave da tecnologia SNMP.
| Simple Network Management Protocol | Telemetria orientada a modelo (MDT) |
| Informações não em tempo real |
Informações em tempo real |
| Pouco escalável |
Altamente escalável |
| Modelo de recepção |
Modelo de envio |
| Não automatizado |
Automação pronta/orientada por modelo de dados |
Vantagens da telemetria de transmissão
Os dados de telemetria em tempo real transmitidos são úteis para:
Planejamento de capacidade/Otimização de tráfego: quando a utilização da largura de banda e as quedas de pacotes em uma rede são monitoradas com frequência, é mais fácil adicionar ou remover links, redirecionar o tráfego, modificar a vigilância e assim por diante. Com tecnologias como o redirecionamento rápido, a rede pode comutar para um novo caminho e redirecionar mais rápido do que o mecanismo de intervalo de poll SNMP. A transmissão contínua de dados de telemetria ajuda a fornecer tempo de resposta rápido para tráfego mais rápido.
Melhor visibilidade: ajuda a detectar e evitar rapidamente situações de falha que resultam após uma condição problemática na rede.
Especificações técnicas de telemetria orientada por modelo
A seção a seguir trata das funções técnicas e dos principais componentes da Telemetria Acionada por Modelo IOS XR, também conhecida como MDT.
Funções de telemetria
A estrutura de telemetria é organizada em três blocos funcionais separados e interligados.
O primeiro bloco trata da representação de dados, que é como a informação referente a análise ou medições é organizada a bordo.
O segundo bloco é sobre codificação. A cada intervalo de amostra, a telemetria converte os dados de medição acima em um formato que pode ser serializado através do fio. É claro que o controlador na outra extremidade deve ser capaz de decodificar os dados para ter uma cópia idêntica dos dados originais enviados pelo dispositivo.
O último bloco é sobre transporte. Essa é a pilha de protocolos usada para transferir dados entre dispositivos.
A tabela a seguir resume a estrutura principal dos blocos de construção de telemetria orientada a modelos:
| Função | Componentes |
| Representação de dados |
Modelos de dados YANG |
| Codificação |
Autodescrição de GPB / GPB |
| Transporte |
TCP/gRPC |
Tabela 3 Blocos de construção de telemetria
Componentes da telemetria
Antes de entender como a telemetria e as partes de configuração subjacentes funcionam, é importante entender os diferentes componentes da telemetria para avaliar uma configuração ideal. A telemetria depende da pilha de programabilidade IOS XR, onde uma nova estrutura de infraestrutura fornece os recursos essenciais para a automação da rede.
A YANG recentemente se tornou um padrão para modelagem de dados, e isso é usado pela pilha de programabilidade da Cisco para formar um conjunto de dados estruturado que pode ser codificado e transportado o mais rápido possível pela rede. A flexibilidade da YANG oferece a grande vantagem de ser usada também como uma ferramenta de configuração para processos de automação. Esses modelos de dados são combinados com formatos de codificação específicos e protocolos de transporte para tornar o MDT uma solução completa para a análise de rede.
Para a configuração da telemetria orientada a modelos, o modelo de dados YANG se torna um componente crucial para permitir o fluxo de dados necessário para coleta e análise.
Pilha de programabilidade IOS XR
YANG
Yang é definido como "linguagem de modelagem de dados usada para modelar dados de configuração, dados de estado e notificações para protocolos de gerenciamento de rede". Devido à sua natureza dissociada de uma arquitetura típica de linguagem de programação, o YANG pode ser implementado para interagir com uma grande variedade de ferramentas.
A estrutura de dados de modelagem YANG é construída em torno do conceito de módulos e submódulos que define uma hierarquia de dados em uma árvore como a moda, que pode ser usada para várias operações, incluindo ações de configuração e tratamento de notificação.
Há várias fontes de modelos YANG disponíveis para uso, das quais três abaixo são consideradas primárias:
- Modelos nativos/específicos da Cisco
- OpenConfig
- IETF
Modelos específicos da Cisco: Eles também são chamados de modelo nativo e são publicados por vários fornecedores de dispositivos, incluindo a Cisco. por exemplo, Cisco-IOS-XR-ptp-oper.yang
Modelos OpenConfig: O OpenConfig é um grupo de trabalho informal de operadores de rede. O OpenConfig define modelos YANG comuns que todos os fornecedores devem suportar para configurar recursos de missão crítica. por exemplo, openconfig-interfaces.yang
modelos IETF: O IETF também define alguns Módulos YANG comuns que descrevem a configuração básica para interfaces, QOS e definem outros tipos de dados comuns (como Ipv4, IPv6, etc.). por exemplo, ietf-syslog-types.yang
A Cisco oferece suporte aos modelos Openconfg disponíveis. Os fornecedores estão convergindo para uma forma padronizada de modelar dados para oferecer suporte a um ambiente de vários fornecedores.
Existem três tipos de modelos Yang:
- Operacional
- Configuração
- Ação
A telemetria só se preocupa com os modelos Operacionais Yang que podem ser identificados como *-oper-*.yang.
O YANG é definido no RFC 7950: https://tools.ietf.org/html/rfc7950.
Codificação
A codificação (ou "serialização") converte dados (objetos, estado) em um formato que pode ser transmitido pela rede. Quando o receptor decodifica ("desserializa") os dados, ele tem uma cópia semanticamente idêntica dos dados originais.
Durante os estágios iniciais de desenvolvimento da telemetria, o XML foi inicialmente considerado como um formato de codificação de primeira escolha devido à sua estrutura baseada em tags. O problema, no entanto, com o XML era sua estrutura de codificação não compacta. O GPB (Google Protocol Buffers) foi finalmente adotado pela Cisco porque melhora a eficiência e a velocidade nas operações de codificação.
Há dois tipos de GPB como opções de codificação para transmissão de telemetria:
- GPB compacta
- GPB de autodescrição
A principal diferença entre os dois formatos de telemetria GPB é como eles representam e codificam as chaves em um fluxo de dados de telemetria.
JSON é outro esquema de codificação amigável disponível que é muito fácil de entender e quase qualquer aplicativo será capaz de decodificar.
Do ponto de vista da implantação, há alguns prós e contras de um esquema de codificação. A comparação sobre vários esquemas de codificação é fornecida na seção Telemetry Design Guidelines.
Transporte
A telemetria oferece três opções possíveis para protocolos de transporte:
- TCP
- gRPC
- UDP
A telemetria também define dois modos de iniciação diferentes para iniciar uma sessão entre o nó e o coletor:
- Discagem
- Discagem
A diferença entre os dois modos consiste apenas em como a sessão de transporte é estabelecida.
Durante as sessões de discagem externa, o dispositivo inicia a conexão enviando um pacote syn para a porta pré-configurada do servidor. Depois que a conexão é estabelecida, os fluxos de dados são imediatamente empurrados para longe do dispositivo.
Para sessões de discagem, o roteador ouve passivamente uma porta tcp esperando por uma conexão de servidor.
No entanto, uma vez estabelecida a sessão, o roteador não é interrogado pelo próprio servidor porque o dispositivo ainda é responsável pelas operações de envio de dados. No MDT, o conceito de pesquisa de dados nem mesmo existe.
O TCP é, por padrão, o método de transporte predefinido para Telemetria, pois é confiável e muito fácil de configurar como uma opção.
O gRPC é uma estrutura moderna de código aberto projetada para ser executada em qualquer ambiente. Ele é construído sobre HTTP/2 e fornece um conjunto avançado e rico de recursos.
Telemetria baseada em cadência vs telemetria baseada em evento
Os dados do conjunto de dados inscrito são transmitidos para o destino em um intervalo periódico configurado ou somente quando ocorre um evento. Esse comportamento é baseado em se o MDT está configurado para telemetria baseada em cadência ou telemetria baseada em evento.
A configuração para a telemetria baseada em eventos é semelhante à telemetria baseada em cadência, com apenas o intervalo de amostra como o diferenciador. Configurar o valor do intervalo de amostra como zero define a assinatura para telemetria baseada em eventos, enquanto configurar o intervalo para qualquer valor diferente de zero define a assinatura para telemetria baseada em cadência.
É recomendável usar a telemetria orientada a eventos para eventos relacionados a alterações.
Diretrizes de design de telemetria
Conforme explicado, há muitos componentes na pilha de telemetria. Aqui estão algumas diretrizes a serem consideradas durante a implementação da telemetria em dispositivos XR.
Como selecionar o esquema de codificação
Conforme mencionado, a codificação ou a serialização converte dados (objetos, estado) em um formato que pode ser transmitido pela rede. Quando o receptor decodifica ou desserializa os dados, ele tem uma cópia semanticamente idêntica dos dados originais.
Várias opções de codificação variam em termos de eficiência de fio e facilidade de uso.
| Codificação | Breve descrição | Eficiência com fio | Outra consideração |
| GPB (Compacto) | Tudo Binário (Exceto os valores que são strings) 2X mais rápido, operacionalmente mais complexo (mas não em relação ao SNMP) |
Alto | Arquivo de proto por modelo |
| GPB - KV (Par chave-valor) | Chaves de string e valores binários (exceto valores que são strings) 3X Maior, Modelos nativos: ainda precisam de heurística para nomes de chave |
Média a Baixa | Arquivo .proto único para decodificação |
| JSON | Cadeias de Caracteres Totais: Chaves e Valores | Baixa | Amigável. Legível por pessoas, amigável com aplicativos e fácil de analisar |
O GPB-KV fornece um ponto médio bom e equilibrado para o esquema de codificação.
Com relação ao comprimento da mensagem para o esquema de codificação escolhido, abaixo está a comparação no fio.
Comparação de Codificação - Comprimento da Mensagem em bytes
Consideração de projeto de rede de transporte
Opções de codificação diferentes representam requisitos de largura de banda diferentes. Ao considerar a telemetria, o operador de rede precisa cuidar do provisionamento de largura de banda suficiente de acordo com o esquema de codificação escolhido. Só para ter uma boa ideia, abaixo do consumo de largura de banda por comparação de esquema de codificação.
Comparação de largura de banda de rede
A Cisco recomenda o uso de KV-GPB. Ele funciona como um bom ponto de equilíbrio entre eficiência e conveniência.
Avaliando opções de configuração de telemetria
Ao configurar a Telemetria orientada por modelo, o operador deve entender todos os diferentes componentes envolvidos na Telemetria. Com base nas opções disponíveis para transporte, codificação e direção de fluxo conforme detalhado acima, é possível escolher ainda mais a combinação mais adequada a um ambiente.
Os quatro componentes principais são:
- Transporte
- Codificação
- Direção da sessão
- Modelos de dados YANG
Transporte: Conforme mencionado, o nó pode fornecer dados de telemetria usando TCP, UDP ou gRPC sobre HTTP/2.
Embora o TCP seja a opção preferencial para a simplicidade, o gRPC oferece o recurso TLS opcional, que pode ser considerado como um benefício adicional do ponto de vista da segurança.
Codificação: O roteador pode fornecer dados de telemetria em dois tipos diferentes de Buffers de Protocolo do Google: Compacto e autodescritivo GPB.
Compact GPB é a codificação mais eficiente, mas requer um .proto exclusivo para cada modelo YANG que é transmitido. A autodescrição GPB é menos eficiente, mas usa um único arquivo .proto para decodificar todos os modelos YANG porque as chaves são passadas como strings no .proto.
Direção da sessão: Há duas opções para início de sessão na implantação de telemetria. O roteador pode discar para o coletor ou o coletor pode discar para o roteador.
A YANG é o padrão aceito pelo setor para modelagem de dados e a pilha de programabilidade da Cisco também a utiliza para formar um conjunto de dados estruturado que pode ser codificado e transportado o mais rápido possível pela rede.
Esses modelos de dados, juntamente com formatos de codificação específicos e protocolos de transporte, conforme discutido acima, tornam a Telemetria Acionada por Modelos (MDT - Model Driven Telemetry) uma solução completa para Analíticos.
Exemplos de configuração de telemetria
IOS-XR
Divisão da Configuração de Discagem Externa
No modo de discagem externa, o roteador é responsável por iniciar uma sessão TCP para o coletor e envia dados que são especificados pelo grupo de sensores na assinatura.
Discagem de TelemetriaDo ponto de vista da configuração, a configuração de telemetria é um processo de três etapas. Primeiro, identificamos as informações que queremos transmitir e as capturamos na configuração do Sensor Group. Em segundo lugar, identificamos o destino para o qual as informações devem ser transmitidas e as capturamos na configuração do grupo de destino. Em terceiro lugar, usamos as informações identificadas nas duas etapas anteriores para configurar a assinatura real.
- Definir grupos de sensores
- Definir grupos de destinos
- Definir Assinatura
Definir grupos de sensores
A configuração do grupo Sensor identifica as informações que devem ser transmitidas. O modelo de configuração a seguir fornece a configuração necessária para configurar grupos de sensores.
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#config RP/0/RP0/CPU0:XR(config)#telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)#sensor-group <Sensor-Group-Name> RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path <Sensor-Path> RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# commit RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# end RP/0/RP0/CPU0:XR#
O exemplo a seguir mostra um exemplo real da CLI do roteador, onde um exemplo real da configuração do grupo de sensores:
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#config RP/0/RP0/CPU0:XR(config)#telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)#sensor-group SensorGroup101 RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# commit RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# end RP/0/RP0/CPU0:XR#
Podemos ter vários Caminhos de Sensor como parte da mesma definição de SensorGroup:
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#config RP/0/RP0/CPU0:XR(config)#telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)#sensor-group SensorGroup101 RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path sensor-path Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/data-rate RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# commit RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# end RP/0/RP0/CPU0:XR#
Definir grupos de destinos
A configuração do grupo Destino identifica o destino para o qual as informações devem ser transmitidas.
Ele tem três parâmetros principais
- Direção da sessão
- Codificação a ser usada
- Protocolo de transporte a ser usado
A seguir, está um exemplo:
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#config RP/0/RP0/CPU0:XR(config)# telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)# destination-group DestGroup101 RP/0/RP0/CPU0:XR(config-model-driven-dest)# address family ipv4 10.1.1.1 port 5432 RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)# encoding self-describing-gpb RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)# protocol tcp RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)# commit RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# end RP/0/RP0/CPU0:XR#
Definir a Assinatura
A Inscrição vincula as informações do Sensor-Group e do Destination-Group como a parte final da configuração. O intervalo de exemplo é definido como parte da Assinatura.
A seguir, está um exemplo:
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#config RP/0/RP0/CPU0:XR(config)telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)#subscription Subscription101 RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id SensorGroup101 sample-interval 30000 RP/0/RP0/CPU0:XR(config-model-driven-subs)#destination-id DestGroup101 RP/0/RP0/CPU0:XR(config-model-driven-subs)# commit RP/0/RP0/CPU0:XR(config-model-driven-subs)# end RP/0/RP0/CPU0:XR#
Exemplo de configuração completa
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#conf RP/0/RP0/CPU0:XR(config)# RP/0/RP0/CPU0:XR(config)#telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)#sensor-group SensorGroup101 RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)#destination-group DestGroup101 RP/0/RP0/CPU0:XR(config-model-driven-dest)#address family ipv4 10.1.1.2 port 5432 RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#encoding self-describing-gpb RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#protocol tcp RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#subscription Subscription101 RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id SensorGroup101 sample-interval 30000 RP/0/RP0/CPU0:XR(config-model-driven-subs)#destination-id DestGroup101 RP/0/RP0/CPU0:XR(config-model-driven-subs)#commit RP/0/RP0/CPU0:XR(config-model-driven-subs)#end RP/0/RP0/CPU0:XR#
Vantagens da discagem externa
- Maior flexibilidade para opções de transporte.
- Não há necessidade de abrir portas para tráfego de gerenciamento de entrada.
- Anycast e balanceamento de carga.
Separação da Configuração de Discagem
No modo de discagem, um coletor/receptor/orquestrador MDT disca para o roteador e se inscreve dinamicamente em um ou mais caminhos ou assinaturas do sensor. O roteador atua como o servidor e o cliente como o receptor.
Apenas uma única sessão é formada e o roteador transmite dados de telemetria através da mesma sessão. Essa assinatura dinâmica é encerrada quando o receptor cancela a assinatura ou quando a sessão é encerrada.
Telemetria de discagem
Como o coletor "disca" para o roteador, não há necessidade de especificar cada destino MDT na configuração. Basta ativar o serviço gRPC no roteador, conectar o cliente e ativar dinamicamente a assinatura de telemetria desejada.
Do ponto de vista da configuração, a configuração de telemetria é um processo de três etapas semelhante ao descrito acima. Primeiro, precisamos habilitar o gRPC. Em segundo lugar, identificamos o destino para o qual as informações devem ser transmitidas e as capturamos na configuração do grupo de sensores. Em terceiro lugar, usamos as informações identificadas nas duas etapas anteriores para configurar a assinatura real.
- Habilitar gRPC
- Definir grupos de sensores
- Definir Assinatura
Habilitar gRPC
Primeiro, precisamos habilitar o servidor gRPC no roteador para aceitar conexões de entrada do coletor.
- O intervalo <port-number> vai de 57344 a 57999. Se um número de porta não estiver disponível, um erro será exibido.
RP/0/RP0/CPU0:XR#config RP/0/RP0/CPU0:XR(config)# grpc RP/0/RP0/CPU0:XR(config-grpc)#port 57890 RP/0/RP0/CPU0:XR(config-grpc)#commit RP/0/RP0/CPU0:XR(config-grpc)#end RP/0/RP0/CPU0:XR#
Definir grupos de sensores
A configuração do grupo Sensor identifica as informações que devem ser transmitidas. O modelo de configuração a seguir fornece a configuração necessária para configurar grupos de sensores.
O exemplo a seguir mostra um exemplo real da CLI do roteador, onde um exemplo real da configuração do grupo de sensores
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#config RP/0/RP0/CPU0:XR(config)#telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)#sensor-group SensorGroup101 RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path openconfig-interfaces:interfaces/interface RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# commit RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# end RP/0/RP0/CPU0:XR#
Definir a Assinatura
A Assinatura vincula o Sensor-Group e o gRPC como a parte final da configuração. O intervalo de exemplo é definido como parte da Assinatura.
O modelo de configuração a seguir fornece a configuração necessária para configurar a assinatura.
O exemplo a seguir mostra um exemplo real da CLI do roteador em que estamos criando uma assinatura e vinculando os grupos de sensor e destino juntos, além de definir a taxa de amostra.
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#config RP/0/RP0/CPU0:XR(config)telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)#subscription Subscription101 RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id SensorGroup101 sample-interval 30000 RP/0/RP0/CPU0:XR(config-model-driven-subs)# commit RP/0/RP0/CPU0:XR(config-model-driven-subs)# end RP/0/RP0/CPU0:XR#
Modelo de configuração completo e exemplo
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#config RP/0/RP0/CPU0:XR(config)# grpc RP/0/RP0/CPU0:XR(config-grpc)#port 57890 RP/0/RP0/CPU0:XR(config-grpc)telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)#subscription Subscription101 RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id SensorGroup101 sample-interval 30000 RP/0/RP0/CPU0:XR(config-model-driven-subs)# commit RP/0/RP0/CPU0:XR(config-model-driven-subs)# end RP/0/RP0/CPU0:XR#
Vantagens da discagem
- Um único canal para configuração e transmissão
- Porta de escuta no roteador/dispositivo
- Conexão Transitória
- Atualmente, somente gRPC/gNMI está disponível
Telemetria orientada a eventos
Na telemetria orientada a eventos, os dados do conjunto de dados inscrito são transmitidos somente quando ocorre um evento.
Configuração de telemetria orientada a eventos
A configuração da telemetria baseada em eventos é semelhante à telemetria baseada em cadência, com a única diferença na configuração da telemetria orientada a eventos é a do intervalo de amostra. Configurar o valor do intervalo de amostra como zero define a assinatura para telemetria baseada em eventos.
Modelo de Configuração Completo e Exemplo para DISCAGEM
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#conf RP/0/RP0/CPU0:XR(config)# RP/0/RP0/CPU0:XR(config)#telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)#sensor-group <Sensor-Group-Name> RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path <Sensor-Path> RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)#destination-group <Destination-Group-Name> RP/0/RP0/CPU0:XR(config-model-driven-dest)#address family ipv4 <Destination-IP> port <Destination-Port> RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#encoding <Encoding-Type> RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#protocol <Transport-Protocol> RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#subscription <Subscription-Name> RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id <Sensor-Group-Name> sample-interval <0> RP/0/RP0/CPU0:XR(config-model-driven-subs)#destination-id <Destination-Group-Name> RP/0/RP0/CPU0:XR(config-model-driven-subs)#commit RP/0/RP0/CPU0:XR(config-model-driven-subs)#end RP/0/RP0/CPU0:XR#
O exemplo a seguir mostra um exemplo real da CLI do roteador.
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#conf RP/0/RP0/CPU0:XR(config)# RP/0/RP0/CPU0:XR(config)#telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)#sensor-group SensorGroup101 RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)#destination-group DestGroup101 RP/0/RP0/CPU0:XR(config-model-driven-dest)#address family ipv4 10.1.1.2 port 5432 RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#encoding self-describing-gpb RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#protocol tcp RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#subscription Subscription101 RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id SensorGroup101 sample-interval 0 RP/0/RP0/CPU0:XR(config-model-driven-subs)#destination-id DestGroup101 RP/0/RP0/CPU0:XR(config-model-driven-subs)#commit RP/0/RP0/CPU0:XR(config-model-driven-subs)#end RP/0/RP0/CPU0:XR#
Modelo de Configuração Completo e Exemplo para DISCAGEM
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#config RP/0/RP0/CPU0:XR(config)# grpc RP/0/RP0/CPU0:XR(config-grpc)#port <port-number> RP/0/RP0/CPU0:XR(config-grpc)telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)#subscription <Subscription-Name> RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id <Sensor-Group-Name> sample-interval <0> RP/0/RP0/CPU0:XR(config-model-driven-subs)#commit RP/0/RP0/CPU0:XR(config-model-driven-subs)#end RP/0/RP0/CPU0:XR#
O exemplo a seguir mostra um exemplo real da CLI do roteador.
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#config RP/0/RP0/CPU0:XR(config)# grpc RP/0/RP0/CPU0:XR(config-grpc)#port 57890 RP/0/RP0/CPU0:XR(config-grpc)telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)#subscription Subscription101 RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id SensorGroup101 sample-interval 0 RP/0/RP0/CPU0:XR(config-model-driven-subs)# commit RP/0/RP0/CPU0:XR(config-model-driven-subs)# end RP/0/RP0/CPU0:XR#
Validando a telemetria com comandos SHOW
Do ponto de vista do roteador, podemos verificar os parâmetros configurados para cada grupo de sensores, grupo de destino e assinatura
// ALL CONFIGURED SUBSCRIPTIONS
RP/0/RP0/CPU0:XR#show telemetry model-driven subscription
Subscription: Subscription101 State: ACTIVE
-------------
Sensor groups:
Id Interval(ms) State
SensorGroup101 30000 Resolved
Destination Groups:
Id Encoding Transport State Port IP
DestGroup101 self-describing-gpb tcp Active 5432 172.16.128.3
// DETAILS ON A PARTICULAR SUBSCRIPTION
RP/0/RP0/CPU0:XR#show telemetry model-driven subscription Subscription101
Subscription: Subscription101
-------------
State: ACTIVE
Sensor groups:
Id: SensorGroup101
Sample Interval: 30000 ms
Sensor Path: Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters
Sensor Path State: Resolved
Destination Groups:
Group Id: DestGroup101
Destination IP: 172.16.128.3
Destination Port: 5432
Encoding: self-describing-gpb
Transport: tcp
State: Active
Total bytes sent: 4893
Total packets sent: 1
Last Sent time: 2019-11-01 10:04:11.2378949664 +0000
Collection Groups:
------------------
Id: 1
Sample Interval: 30000 ms
Encoding: self-describing-gpb
Num of collection: 5
Collection time: Min: 6 ms Max: 29 ms
Total time: Min: 6 ms Avg: 12 ms Max: 29 ms
Total Deferred: 0
Total Send Errors: 0
Total Send Drops: 0
Total Other Errors: 0
Last Collection Start:2019-11-01 10:06:11.2499000664 +0000
Last Collection End: 2019-11-01 10:06:11.2499006664 +0000
Sensor Path: Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters
RP/0/RP0/CPU0:XR#
// ALL CONFIGURED DESTINATIONS
RP/0/RP0/CPU0:XR#show telemetry model-driven destination
Group Id IP Port Encoding Transport State
-----------------------------------------------------------------------------
DestGroup101 172.16.128.3 5432 self-describing-gpb tcp Active
RP/0/RP0/CPU0:XR#
// PARTICULAR DESTINATION
RP/0/RP0/CPU0:XR#show telemetry model-driven destination DestGroup101
Destination Group: DestGroup101
-----------------
Destination IP: 172.16.128.3
Destination Port: 5432
State: Active
Encoding: self-describing-gpb
Transport: tcp
Total bytes sent: 83181
Total packets sent: 17
Last Sent time: 2019-11-01 10:12:11.2859133664 +0000
Collection Groups:
------------------
Id: 1
Sample Interval: 30000 ms
Encoding: self-describing-gpb
Num of collection: 17
Collection time: Min: 5 ms Max: 29 ms
Total time: Min: 6 ms Max: 29 ms Avg: 10 ms
Total Deferred: 0
Total Send Errors: 0
Total Send Drops: 0
Total Other Errors: 0
Last Collection Start:2019-11-01 10:12:11.2859128664 +0000
Last Collection End: 2019-11-01 10:12:11.2859134664 +0000
Sensor Path: Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters
RP/0/RP0/CPU0:XR#
// ALL CONFIGURED SENSOR GROUPS
RP/0/RP0/CPU0:XR#show telemetry model-driven sensor-group
Sensor Group Id:SensorGroup101
Sensor Path: Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters
Sensor Path State: Resolved
// PARTICULAR SENSOR GROUPS
RP/0/RP0/CPU0:XR#show telemetry model-driven sensor-group SensorGroup101
Sensor Group Id:SensorGroup101
Sensor Path: Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters
Sensor Path State: Resolved
RP/0/RP0/CPU0:XR#
Pilha de Coleção de Telemetria
Além da configuração do roteador, uma solução baseada em telemetria exigia vários componentes, como coletor, banco de dados e software de monitoramento/análise. Esses componentes podem ser configurados separadamente ou podem fazer parte de um único produto abrangente.
- Um decodificador deve ser instalado para receber pacotes de entrada e passá-los adiante para armazenamento adicional.
- É necessário um banco de dados Time Series (também conhecido como TSDB) para armazenar informações transmitidas.
- Uma ferramenta gráfica também é necessária para visualizar dados extraídos do banco de dados interno.
Está além do escopo descrever a pilha de coleta em detalhes. O Cisco Crossworks Health Insights permite telemetria automatizada, na qual os dispositivos são provisionados automaticamente com a configuração de telemetria e as tabelas/esquemas são criados em um TSDB (Time Series Database, banco de dados de série temporal). Ele simplifica a sobrecarga operacional e de gerenciamento de rede da coleta e limpeza de dados, permitindo que as operadoras se concentrem em seus objetivos comerciais. A utilização de um coletor comum para coletar dados do dispositivo de rede por SNMP, CLI e telemetria orientada por modelo permite evitar a duplicação de dados e também reduz a carga nos dispositivos e na rede.
Considerações de implantação para telemetria em uma rede
Veja a seguir várias considerações a serem feitas durante a análise da implantação de telemetria em uma rede.
Dimensionamento
A telemetria pode transmitir uma quantidade considerável de dados e recomenda-se uma consideração cuidadosa dos aspectos de escalabilidade.
Transmitir apenas os dados necessários
Cada modelo Yang terá vários nós de folha. É aconselhável ser específico sobre as informações que são necessárias e as informações que não são necessárias. Recomenda-se explorar os modelos Yang e identificar o caminho de dados exigido pelos casos de uso de telemetria.
Considere a quantidade de dados de transmissão
A quantidade total de dados de telemetria sendo transmitida precisará considerar os seguintes pontos:
- Alocação de largura de banda dentro da rede
- qos
- Desempenho de aplicativos/softwares adicionais, como
- Software coletor
- Banco de dados de Série Temporal
- Software de análise/visualização
- A eficiência da codificação (discutida na Seção "Diretrizes de design da telemetria") afeta diretamente a quantidade de dados que está sendo transmitida. A GPB compacta é recomendada sempre que possível.
- O intervalo de coleta afeta diretamente vários aspectos, incluindo, mas não se limitando a seguir.
- Utilização da largura de banda na rede
- Requisito de armazenamento no banco de dados
- Desempenho do dispositivo que transmite os dados
Recomenda-se avaliar a frequência da coleta com base nos requisitos do aplicativo.
Em geral, recomenda-se considerar a filtragem de dados indesejados na origem ou no destino como possível. Temos a opção de filtrar dados indesejados. A filtragem pode ser executada em dois níveis: -
- Na origem - Os dispositivos que transmitem os dados.
- No destino - O coletor coleta e normaliza dados. (A filtragem no coletor está além do escopo deste documento)
O exemplo a seguir mostra dados sendo filtrados somente para interfaces Hundered Gig dentro dos caminhos do sensor, aplicando curingas.
sensor-path Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface[interface-name='HundredGigE*']/latest/generic-counters
Referências
https://blogs.cisco.com/sp/the-limits-of-snmp
https://blogs.cisco.com/sp/why-you-should-care-about-model-driven-telemetry
https://www.cisco.com/c/en/us/td/docs/iosxr/asr9000/telemetry/b-telemetry-cg-asr9000-61x.html
Histórico de revisões
| Revisão | Data de publicação | Comentários |
|---|---|---|
1.0 |
04-Mar-2020 |
Versão inicial |
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)