/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`](../doca-bare-metal-deployment/SKILL.md) and [`doca-container-deployment`](../doca-container-deployment/SKILL.md): 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`](TASKS.md) and start at [`## configure`](TASKS.md#configure). If the question is *what surfaces does the collector even have and where is the scope boundary*, start at [`CAPABILITIES.md`](CAPABILITIES.md). If the user has not installed DOCA yet, route to [`doca-setup`](../doca-setup/SKILL.md) 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](../../AGENTS.md#non-goals-questions-the-agent-should-recognize-and-refuse-politely). 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`](../libs/doca-telemetry/SKILL.md); the application-side **publisher** API (emit counters / events from a DOCA program) is owned by [`doca-telemetry-exporter`](../libs/doca-telemetry-exporter/SKILL.md). 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 [`doca-public-knowledge-map` externally-productized routing row](../doca-public-knowledge-map/SKILL.md#externally-productized-doca-software--not-in-this-bundle-but-here-is-where-to-route) and the public DTS guide it points at. The agent must NOT synthesize DTS config file names, provider knob names, or paths from memory.

The load-bearing first-touch failure this skill exists to prevent is **collapsing these four surfaces into "DOCA telemetry"**: the clx collection mechanism, the `doca-telemetry` reader library, the `doca-telemetry-exporter` publisher library, and the productized DTS container are four different things with four different owners. The agent surfaces the decomposition BEFORE any config-level guidance.

Audience

This skill serves **external operators standing up or running a CollectX-based telemetry collector** on a host or BlueField they administer — people who already have:

• a DOCA install on the side they are collecting from (host x86

or BlueField Arm), verified per [`doca-setup ## test`](../doca-setup/TASKS.md#test),

• a goal of *getting counters off the box* through a collector +

exporter, not of writing the reader / publisher library code (that is the two `libs/` skills above), and

• access to the public DOCA Telemetry and DTS guides on

`docs.nvidia.com` as the authoritative source for any concrete provider name, schema field, flag, or config path.

It is **not** for:

• developers writing the hardware-counter reader API (route to

[`doca-telemetry`](../libs/doca-telemetry/SKILL.md)) or the publisher API (route to [`doca-telemetry-exporter`](../libs/doca-telemetry-exporter/SKILL.md)),

• operators deploying / configuring the **productized DTS

container** as a turnkey service — that is externally productized (Non-goal #7); route to the public DTS guide,

• fres