O F5 Automation Toolchain tem três extensões declarativas, e o jeito mais limpo de mantê-las juntas é por aquilo que cada uma faz com a caixa. O AS3 configura os serviços de aplicação de Camada 4-7. O DO faz o onboarding de Camada 1-3. O Telemetry Streaming é a terceira, e é a diferente do grupo: onde o AS3 e o DO configuram o BIG-IP, o TS o observa. Ele agrega, normaliza e encaminha estatísticas e eventos do dispositivo para uma aplicação consumidora, tudo a partir de uma única declaração JSON que você faz POST em /mgmt/shared/telemetry/declare. Esta ferramenta renderiza essa declaração de volta para você do jeito que a documentação descreve.
Cole o JSON e ela primeiro confirma que a class de topo é Telemetry, depois lê o objeto Controls opcional (seu logLevel, se debug está ligado, e se o memoryMonitor beta está definido). Então percorre cada objeto de classe nomeado, mas em vez de agrupá-los pela ordem de onboarding como o explicador de DO faz, agrupa-os pelo seu papel no pipeline de telemetria, porque esse pipeline é a intuição que vale carregar.
São três papéis. As fontes de dados produzem telemetria: um Telemetry_System com um systemPoller coleta e normaliza estatísticas de dispositivo, virtual server, pool e membro de pool em um intervalo; um Telemetry_System_Poller isolado faz o mesmo como objeto referenciado, por exemplo para puxar estatísticas de um BIG-IP adicional; e um Telemetry_Listener ingere os logs e eventos que o BIG-IP publica, tanto em TCP quanto em UDP, na porta 6514 por padrão. Os consumidores encaminham a telemetria para fora: um Telemetry_Consumer é um consumidor push cujo type seleciona o destino, e o catálogo é longo, Splunk, Azure Log Analytics, AWS CloudWatch e S3, Graphite, Kafka, ElasticSearch, DataDog, Generic HTTP, OpenTelemetry e mais; um Telemetry_Pull_Consumer em vez disso expõe a telemetria para um sistema externo como o Prometheus fazer scrape. As classes de apoio agrupam e estendem o resto: um Telemetry_Namespace isola um conjunto de pollers, listeners e consumidores para que só enxerguem uns aos outros, e Telemetry_Endpoints define endpoints customizados que um poller pode consultar além da saída padrão.
A verificação mais útil que a ferramenta faz é a completude do pipeline. Uma declaração TS pode ser estruturalmente válida e ainda não fazer nada, e as duas formas em que isso acontece são uma declaração com consumidores mas sem fonte de dados (nada é coletado para encaminhar) e uma declaração com fontes mas sem consumidor (a telemetria não tem para onde ir). A ferramenta sinaliza as duas. Ela também sinaliza a pegadinha específica que o guia de troubleshooting aponta, um Telemetry_System sem systemPoller, que silenciosamente não coleta métrica nenhuma, e um Telemetry_Consumer sem type. De forma crucial, ela conta fontes e consumidores que vivem dentro de um Telemetry_Namespace, para que uma declaração corretamente com namespace não seja falsamente reportada como faltando qualquer uma das metades.
Uma coisa vale dizer com clareza: a F5 colocou o Telemetry Streaming em modo de manutenção. Ele continua recebendo suporte com correções críticas e atualizações de segurança, e não há plano de depreciá-lo, mas não é mais o caminho em crescimento ativo que já foi. Isto é um explicador de estrutura e verificador de sanidade, não um validador completo de JSON-Schema; uma declaração que lê limpo aqui ainda pode ser rejeitada pelo TS. Tudo roda localmente, nada do que você cola sai da página, e nada aqui jamais contata um BIG-IP.