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.