doca-collectx-deployment

license	Apache-2.0
name	doca-collectx-deployment
description	Use this skill to deploy and operate a CollectX (clx) based DOCA telemetry collector on a host or BlueField — wiring providers / counters into the collector, running the collection daemon, and shaping its exporters (Prometheus pull, Fluent Bit push, NetFlow, file / IPC) so the metrics actually leave the box. Trigger even when the user never says CollectX or clx — implicit phrasings: {collector emits nothing downstream}, {add a provider to the clx collector}, {turn on the Prometheus endpoint}, {ship counters to Fluent Bit from the DPU}, {daemon starts but no schema rows appear}. This skill owns the CollectX collection mechanism plus the operator's own doca-telemetry / doca-telemetry-exporter usage; it ROUTES the productized DOCA Telemetry Service (DTS) to public docs (AGENTS.md Non-goal #7), the reader API to doca-telemetry, and the publisher API to doca-telemetry-exporter. Refuse to invent clx symbols, provider names, schema fields, flags, or config paths — describe the class and route to the live source.
metadata	{"kind":"library"}
compatibility	No DOCA install required to read this skill (it is a deployment / operation overlay over the DOCA telemetry libraries and the CollectX collection mechanism). The hands-on steps DO require a live DOCA install at /opt/mellanox/doca on a host or BlueField, an operator account that can run the collector and reach its exporter sinks, and the public DOCA Telemetry / DTS guides on docs.nvidia.com for any concrete provider name, schema field, flag, or config path (this skill never invents those).

DOCA CollectX telemetry deployment

Where to start: This skill is the bundle's home for operating a CollectX (clx) based telemetry collector — the collection framework that gathers provider counters into a schema and ships them out through one or more exporters. It is a deployment / operation skill, parallel to doca-bare-metal-deployment and doca-container-deployment: it owns the runtime shape of a telemetry collector on the operator's host or BlueField, not the library APIs the operator's own program calls. If the user wants to stand up, wire, or debug a collector and its exporters, open TASKS.md and start at ## configure. If the question is what surfaces does the collector even have and where is the scope boundary, start at CAPABILITIES.md. If the user has not installed DOCA yet, route to doca-setup first.

The scope boundary (read this before anything else)

CollectX (clx) is NVIDIA's telemetry collection framework. It underpins the DOCA Telemetry Service (DTS) — and DTS as-deployed (the productized, NGC-shipped / kubelet-started service container) is out of scope for this bundle per AGENTS.md Non-goal #7. This skill therefore draws a hard line and the agent MUST state it up front:

• In scope here: the CollectX collection mechanism as a class (providers / counters → schema → collector daemon → exporters), and the operator deploying / running / debugging a collector that they own, plus the operator's own usage of the two in-bundle telemetry libraries when those feed or consume the collector.
• Routed to the DOCA telemetry libraries: the hardware-counter reader API is owned by doca-telemetry; the application-side publisher API (emit counters / events from a DOCA program) is owned by doca-telemetry-exporter. This skill does not re-document either API surface.
• Routed to public docs (Non-goal #7): the productized DTS container — its packaged config schema, its built-in provider set, its kubelet manifest, its NGC image — is externally productized. Route every "operate the DTS service" question to the and the public DTS guide it points at. The agent must NOT synthesize DTS config file names, provider knob names, or paths from memory.