# Telemetry Streaming: The Automation Toolchain Extension That Observes Instead of Configures > AS3 configures application services and DO onboards the device. Telemetry Streaming is the third F5 Automation Toolchain extension, and it is the one that observes rather than configures: it aggregates, normalizes, and forwards statistics and events from the BIG-IP to a consumer like Splunk, ElasticSearch, DataDog, or Prometheus, all from one JSON declaration. This walks the Telemetry class model, the source-and-consumer pipeline, and the gaps that make a declaration succeed while collecting nothing. Source: https://ronutz.com/en/learn/bigip-telemetry-streaming-ts Updated: 2026-07-05 Related tools: https://ronutz.com/en/tools/telemetry-streaming-explainer, https://ronutz.com/en/tools/as3-explainer-validator, https://ronutz.com/en/tools/do-explainer-validator --- The F5 Automation Toolchain is usually described in terms of its two configuration extensions, and for good reason: AS3 configures the Layer 4-7 application services on a BIG-IP, and DO does the Layer 1-3 onboarding that gets the box onto the network. Telemetry Streaming is the third extension, and it belongs to a different category of work. AS3 and DO change the device's configuration; TS does not touch the configuration at all. It aggregates, normalizes, and forwards statistics and events from the BIG-IP to a consumer application, which makes it the observability half of a toolchain otherwise about configuration. The mechanics are the same declarative model, you POST a single JSON declaration to a REST endpoint, but the declaration describes a data pipeline rather than a desired configuration. The [TS explainer](https://ronutz.com/en/tools/telemetry-streaming-explainer) reads that pipeline back the way this article describes it. ## One Telemetry class, and a flat bag of named objects A TS declaration has a top-level `class` of `Telemetry`, and you POST it to `/mgmt/shared/telemetry/declare` (there is a companion `/mgmt/shared/telemetry/info` endpoint you GET to confirm TS is running). This is simpler than the DO shape: there is no tenant, no `Common`, no wrapper. Directly under `Telemetry` sit named objects, each with its own `class`, plus one reserved key, `controls`, whose class is always `Controls` and which carries the `logLevel` (info by default), an optional `debug` flag, and the beta `memoryMonitor`. Everything else is a class-object you name yourself, and unlike DO's onboarding order, the objects have no meaningful sequence. What matters is the role each one plays. ## Three roles: sources produce, consumers forward, the rest supports Read a TS declaration by sorting its objects into three groups. The first is data sources, the objects that produce telemetry. A `Telemetry_System` targets a system and, through a `systemPoller` defined inside it, collects and normalizes device, virtual-server, pool, and pool-member statistics on a configurable interval; it can also carry an iHealth poller that generates a QKView and fetches its analysis. A `Telemetry_System_Poller` is the same poller expressed as a standalone referenced object, which is how you pull statistics from an additional BIG-IP by giving it a host, username, and passphrase. A `Telemetry_Listener` is the other kind of source: rather than polling for statistics, it ingests the logs and events the BIG-IP publishes, listening on both TCP and UDP at port 6514 by default, and it is how AFM and ASM security logs and LTM request logs reach TS. The second group is consumers, the objects that forward telemetry out. A `Telemetry_Consumer` is a push consumer, and its `type` selects the destination from a long catalogue: Splunk, Azure Log Analytics and Application Insights, AWS CloudWatch and S3, Graphite, Kafka, ElasticSearch, Sumo Logic, StatsD, Generic HTTP, Fluentd, Google Cloud Monitoring and Logging, DataDog, and the OpenTelemetry Exporter. A `Telemetry_Pull_Consumer`, added in TS 1.11, inverts the direction: instead of TS pushing to an external system, it exposes the telemetry for an external system to scrape, which is how the Prometheus integration works. The third group supports the rest: a `Telemetry_Namespace` groups a set of pollers, listeners, and consumers into an isolated unit where they only see each other, and `Telemetry_Endpoints` defines custom endpoints a poller can query for statistics beyond the default output. ## The failure that passes validation: an incomplete pipeline The most valuable thing to check in a TS declaration is not any single property but the shape of the pipeline as a whole, because a TS declaration can be perfectly valid and still do nothing useful. Telemetry has to be produced by a source and forwarded by a consumer, so a declaration with consumers but no source collects nothing to send, and a declaration with sources but no consumer collects telemetry that has nowhere to go. Neither mistake is a schema error, so neither is caught by validating the declaration alone; both are exactly the kind of thing a structure checker earns its place by catching. The troubleshooting guide adds a specific version of the first trap: a `Telemetry_System` that omits its `systemPoller` quietly collects no metrics, which looks like a working system object but produces nothing. A subtlety worth knowing is that sources and consumers can live inside a `Telemetry_Namespace`, so a naive check that only looked at the top level would falsely flag a correctly namespaced declaration as incomplete; the pipeline check has to look inside namespaces too. ## Maintenance mode, and the limits of a structure checker One fact belongs in any honest description of TS today: F5 has placed Telemetry Streaming in a phase of ongoing maintenance and support. It continues to receive critical fixes and security updates, and F5 has stated there is no plan to deprecate it, but it is no longer the actively expanding product it once was, and new observability investment tends to point elsewhere. That does not diminish its usefulness on the many BIG-IPs already streaming telemetry through it, but it is worth knowing before you build new pipelines on it. As with the AS3 and DO explainers, this tool is a structure explainer and sanity checker rather than the full schema validator, F5 publishes the TS schema for that, and it runs entirely in the browser and never contacts a BIG-IP.