# Telemetry Streaming (TS) explainer > Paste the JSON you POST to /mgmt/shared/telemetry/declare and it reads it back: it confirms the top-level Telemetry class, reads the optional Controls, and walks every class-object grouped by its role in the telemetry pipeline: the data sources that produce telemetry (system pollers, event listeners), the consumers that forward it out (Splunk, Azure, AWS, DataDog, Prometheus, and the rest of the catalogue), and the grouping and endpoint classes. It flags the pipeline gaps that make a declaration succeed but do nothing. TS is the third F5 Automation Toolchain extension: AS3 and DO configure the box, TS observes it. - Tool: https://ronutz.com/en/tools/telemetry-streaming-explainer - Family: Networking --- # Telemetry Streaming (TS) explainer The F5 Automation Toolchain has three declarative extensions, and the cleanest way to hold them together is by what each one does to the box. AS3 configures the Layer 4-7 application services. DO does the Layer 1-3 onboarding. Telemetry Streaming is the third, and it is the odd one out: where AS3 and DO configure the BIG-IP, TS observes it. It aggregates, normalizes, and forwards statistics and events from the device to a consumer application, all from a single JSON declaration you POST to `/mgmt/shared/telemetry/declare`. This tool renders that declaration back to you the way the docs describe it. Paste the JSON and it first confirms the top-level `class` is `Telemetry`, then reads the optional `Controls` object (its `logLevel`, whether `debug` is on, and whether the beta `memoryMonitor` is set). Then it walks every named class-object, but instead of grouping them by onboarding order the way the DO explainer does, it groups them by their role in the telemetry pipeline, because that pipeline is the intuition worth carrying. There are three roles. Data sources produce telemetry: a `Telemetry_System` with a `systemPoller` collects and normalizes device, virtual-server, pool, and pool-member statistics on an interval; a standalone `Telemetry_System_Poller` does the same as a referenced object, for example to pull statistics from an additional BIG-IP; and a `Telemetry_Listener` ingests the logs and events the BIG-IP publishes, on both TCP and UDP, at port 6514 by default. Consumers forward telemetry out: a `Telemetry_Consumer` is a push consumer whose `type` selects the target, and the catalogue is long, Splunk, Azure Log Analytics, AWS CloudWatch and S3, Graphite, Kafka, ElasticSearch, DataDog, Generic HTTP, OpenTelemetry, and more; a `Telemetry_Pull_Consumer` instead exposes telemetry for an external system such as Prometheus to scrape. The supporting classes group and extend the rest: a `Telemetry_Namespace` isolates a set of pollers, listeners, and consumers so they only see each other, and `Telemetry_Endpoints` defines custom endpoints a poller can query beyond the default output. The single most useful check the tool performs is pipeline completeness. A TS declaration can be structurally valid and still do nothing, and the two ways that happens are a declaration with consumers but no data source (nothing is collected to forward) and a declaration with sources but no consumer (the telemetry has nowhere to go). The tool flags both. It also flags the specific gotcha the troubleshooting guide calls out, a `Telemetry_System` with no `systemPoller`, which quietly collects no metrics, and a `Telemetry_Consumer` with no `type`. Crucially, it counts sources and consumers that live inside a `Telemetry_Namespace`, so a correctly namespaced declaration is not falsely reported as missing either half. One thing worth stating plainly: F5 has placed Telemetry Streaming in maintenance mode. It continues to receive support with critical fixes and security updates, and there is no plan to deprecate it, but it is not the actively growing path it once was. This is a structure explainer and sanity checker, not a full JSON-Schema validator; a declaration that reads cleanly here can still be rejected by TS. Everything runs locally, nothing you paste leaves the page, and nothing here ever contacts a BIG-IP. ## Standards and references - [F5 BIG-IP Telemetry Streaming: Quick Start (the base Telemetry declaration, the Controls class with logLevel default info, the Telemetry_System / Telemetry_Listener / Telemetry_Consumer classes, default Listener port 6514, Consumer protocol default http, and the /mgmt/shared/telemetry/declare and /info endpoints)](https://clouddocs.f5.com/products/extensions/f5-telemetry-streaming/latest/quick-start.html) - [F5 BIG-IP Telemetry Streaming: Using TS (the full class index and the complete push and pull consumer type catalogue: Splunk, Azure, AWS, Graphite, Kafka, ElasticSearch, DataDog, Generic HTTP, OpenTelemetry, Prometheus, and more)](https://clouddocs.f5.com/products/extensions/f5-telemetry-streaming/latest/using-ts.html) - [F5 BIG-IP Telemetry Streaming: Telemetry System class (the system poller and the iHealth poller, and the rule that an iHealth poller must be attached to a Telemetry_System)](https://clouddocs.f5.com/products/extensions/f5-telemetry-streaming/latest/telemetry-system.html) - [F5 BIG-IP Telemetry Streaming: Example Declarations (the base declaration, the referenced Telemetry_System_Poller pulling from an additional BIG-IP, and the Telemetry_Namespace examples)](https://clouddocs.f5.com/products/extensions/f5-telemetry-streaming/latest/declarations.html) - [F5 BIG-IP Telemetry Streaming: Troubleshooting (a Telemetry_System used for metrics must define systemPoller; event ingest needs a Telemetry_Listener whose port matches the BIG-IP log configuration)](https://clouddocs.f5.com/products/extensions/f5-telemetry-streaming/latest/troubleshooting.html) ## Related reading - [Telemetry Streaming: The Automation Toolchain Extension That Observes Instead of Configures](https://ronutz.com/en/learn/bigip-telemetry-streaming-ts.md): 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.