O F5 Automation Toolchain é geralmente descrito em termos de suas duas extensões de configuração, e com razão: o AS3 configura os serviços de aplicação de Camada 4-7 em um BIG-IP, e o DO faz o onboarding de Camada 1-3 que coloca a caixa na rede. O Telemetry Streaming é a terceira extensão, e pertence a uma categoria de trabalho diferente. O AS3 e o DO mudam a configuração do dispositivo; o TS não toca na configuração de forma alguma. Ele agrega, normaliza e encaminha estatísticas e eventos do BIG-IP para uma aplicação consumidora, o que o torna a metade de observabilidade de um toolchain que de resto é sobre configuração. A mecânica é o mesmo modelo declarativo, você faz POST de uma única declaração JSON em um endpoint REST, mas a declaração descreve um pipeline de dados em vez de uma configuração desejada. O explicador de TS lê esse pipeline de volta do jeito que este artigo descreve.
Uma classe Telemetry, e um saco plano de objetos nomeados
Uma declaração TS tem um class de topo igual a Telemetry, e você a faz POST em /mgmt/shared/telemetry/declare (há um endpoint companheiro /mgmt/shared/telemetry/info que você consulta com GET para confirmar que o TS está rodando). Isto é mais simples que a forma do DO: não há tenant, não há Common, não há wrapper. Diretamente sob Telemetry ficam objetos nomeados, cada um com seu próprio class, mais uma chave reservada, controls, cuja classe é sempre Controls e que carrega o logLevel (info por padrão), uma flag debug opcional, e o memoryMonitor beta. Todo o resto é um objeto de classe que você mesmo nomeia, e ao contrário da ordem de onboarding do DO, os objetos não têm sequência significativa. O que importa é o papel que cada um desempenha.
Três papéis: fontes produzem, consumidores encaminham, o resto apoia
Leia uma declaração TS ordenando seus objetos em três grupos. O primeiro são as fontes de dados, os objetos que produzem telemetria. Um Telemetry_System mira um sistema e, através de um systemPoller definido dentro dele, coleta e normaliza estatísticas de dispositivo, virtual server, pool e membro de pool em um intervalo configurável; ele também pode carregar um iHealth poller que gera um QKView e busca sua análise. Um Telemetry_System_Poller é o mesmo poller expresso como objeto referenciado isolado, que é como você puxa estatísticas de um BIG-IP adicional dando a ele um host, username e passphrase. Um Telemetry_Listener é o outro tipo de fonte: em vez de fazer polling por estatísticas, ele ingere os logs e eventos que o BIG-IP publica, escutando tanto em TCP quanto em UDP na porta 6514 por padrão, e é como os logs de segurança do AFM e do ASM e os logs de requisição do LTM chegam ao TS.
O segundo grupo são os consumidores, os objetos que encaminham a telemetria para fora. Um Telemetry_Consumer é um consumidor push, e seu type seleciona o destino de um catálogo longo: Splunk, Azure Log Analytics e Application Insights, AWS CloudWatch e S3, Graphite, Kafka, ElasticSearch, Sumo Logic, StatsD, Generic HTTP, Fluentd, Google Cloud Monitoring e Logging, DataDog, e o OpenTelemetry Exporter. Um Telemetry_Pull_Consumer, adicionado no TS 1.11, inverte a direção: em vez de o TS empurrar para um sistema externo, ele expõe a telemetria para um sistema externo fazer scrape, que é como a integração com o Prometheus funciona. O terceiro grupo apoia o resto: um Telemetry_Namespace agrupa um conjunto de pollers, listeners e consumidores em uma unidade isolada onde só enxergam uns aos outros, e Telemetry_Endpoints define endpoints customizados que um poller pode consultar para estatísticas além da saída padrão.
A falha que passa na validação: um pipeline incompleto
A coisa mais valiosa de verificar em uma declaração TS não é nenhuma propriedade isolada, mas o formato do pipeline como um todo, porque uma declaração TS pode ser perfeitamente válida e ainda não fazer nada útil. A telemetria precisa ser produzida por uma fonte e encaminhada por um consumidor, então uma declaração com consumidores mas sem fonte não coleta nada para enviar, e uma declaração com fontes mas sem consumidor coleta telemetria que não tem para onde ir. Nenhum dos erros é um erro de schema, então nenhum é pego ao validar a declaração sozinha; ambos são exatamente o tipo de coisa pela qual um verificador de estrutura ganha seu lugar ao pegar. O guia de troubleshooting acrescenta uma versão específica da primeira armadilha: um Telemetry_System que omite seu systemPoller silenciosamente não coleta métrica nenhuma, o que parece um objeto de sistema funcionando mas não produz nada. Uma sutileza que vale saber é que fontes e consumidores podem viver dentro de um Telemetry_Namespace, então uma verificação ingênua que só olhasse o nível de topo falsamente sinalizaria uma declaração corretamente com namespace como incompleta; a verificação de pipeline precisa olhar dentro dos namespaces também.
Modo de manutenção, e os limites de um verificador de estrutura
Um fato pertence a qualquer descrição honesta do TS hoje: a F5 colocou o Telemetry Streaming em uma fase de manutenção e suporte contínuos. Ele continua recebendo correções críticas e atualizações de segurança, e a F5 declarou que não há plano de depreciá-lo, mas não é mais o produto em expansão ativa que já foi, e o novo investimento em observabilidade tende a apontar para outro lugar. Isso não diminui sua utilidade nos muitos BIG-IPs que já transmitem telemetria através dele, mas vale saber antes de construir novos pipelines sobre ele. Como nos explicadores de AS3 e DO, esta ferramenta é um explicador de estrutura e verificador de sanidade em vez do validador completo de schema, a F5 publica o schema do TS para isso, e ela roda inteiramente no navegador e nunca contata um BIG-IP.