| 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.
