# Telemetry Streaming: A Extensão do Automation Toolchain que Observa em Vez de Configurar

> O AS3 configura serviços de aplicação e o DO faz o onboarding do dispositivo. O Telemetry Streaming é a terceira extensão do F5 Automation Toolchain, e é a que observa em vez de configurar: ele agrega, normaliza e encaminha estatísticas e eventos do BIG-IP para um consumidor como Splunk, ElasticSearch, DataDog ou Prometheus, tudo a partir de uma única declaração JSON. Este artigo percorre o modelo da classe Telemetry, o pipeline de fonte-e-consumidor, e as lacunas que fazem uma declaração ter sucesso sem coletar nada.

Source: https://ronutz.com/pt-BR/learn/bigip-telemetry-streaming-ts  
Updated: 2026-07-05  
Related tools: https://ronutz.com/pt-BR/tools/telemetry-streaming-explainer, https://ronutz.com/pt-BR/tools/as3-explainer-validator, https://ronutz.com/pt-BR/tools/do-explainer-validator

---

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](https://ronutz.com/pt-BR/tools/telemetry-streaming-explainer) 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.