/doca-dts

license: Apache-2.0
name: doca-dts
description: >
  Deploy and configure the NVIDIA DOCA Telemetry Service (DTS) as it
  is actually run: (A) BlueField (built-in static pod), (B) Host
  (docker) on x86_64 / aarch64, or (C) DPF (DPUService / helm chart)
  — plus
  the shared configuration layer (`dts_config.ini`, providers,
  exporters, level labels) that all three share. The user's
  DEPLOYMENT TYPE decides everything; pick it first. Trigger even
  without "DTS" for "prometheus on the DPU shows nothing on 9100",
  "telemetry container exits right after start", "add ethtool
  counters to the telemetry DPUService", "how do I upgrade the
  built-in telemetry on BlueField", or "level labels per rack/pod".
  Refuse and route elsewhere for installing DOCA itself, the
  `doca_telemetry` / `doca_telemetry_exporter` library API, installing
  the DPF cluster, Grafana / Prometheus server setup or dashboard /
  PromQL authoring, and BFB / BSP imaging — those belong to other
  skills or to external products.
metadata:
  kind: service
  doca_version: "3.5"
compatibility: >
  Container-shaped DOCA service. On BlueField Arm it ships inside
  the BlueField OS image (upgradable from the NGC image); on an
  x86_64 or aarch64 host it runs from the NGC `-host` image under
  docker; under DPF it is a `DPUService` rendered from the NGC
  `doca-telemetry` helm chart. The version anchor is the container
  tag / chart version, not the host DOCA install. Never fabricate
  a tag or chart version — read it from the NGC page or
  `helm show values`.

DOCA Telemetry Service (DTS)

**Scope note.** DTS is an *externally productized* DOCA service: it is not one of the DOCA SDK libraries, and its source of truth is the public DTS guide plus the NGC container / helm-chart pages and the DOCA Platform (DPF) public docs. This skill covers DTS **as deployed and configured** — which manifest or invocation starts it, which `dts_config.ini` keys shape it, how to verify it exports. It does not cover the library side: reading telemetry in your own program is `libs/doca-telemetry` (`doca-telemetry/SKILL.md`), publishing into DTS over IPC from your own program is `libs/doca-telemetry-exporter` (`doca-telemetry-exporter/SKILL.md`).

**Where to start:** decide the **deployment type** before anything else — it selects the manifest, the config-directory path, the restart mechanism and the debug commands. Route through `doca-setup ## recognize` (`doca-setup/TASKS.md#recognize`) (`uname -m`, `lspci -d 15b3:`, `bf-release`) to learn whether you are on a BlueField Arm image (shape A), a plain host (shape B), or inside a DPF-managed cluster (shape C), then open [`TASKS.md ## configure`](TASKS.md#configure) and follow that shape's column. State the shape in the answer before the first command, even when the question implies it ("on my BlueField" is shape A: the built-in static pod under kubelet, inspected with `crictl`, not `docker`). Every configure, change or debug answer ends with the verification contract, whose green signal is two `/metrics` scrapes at least two `update` intervals apart showing a counter that advanced ([`TASKS.md ## test`](TASKS.md#test) step 3). If the question is *what can DTS collect and export, and in which mode*, start at [`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes). If DOCA / the BlueField OS is not installed yet, route to `doca-setup/SKILL.md` first.

**Host docker container exits right after start (shape B).** Check the documented host shape and copy the exact invocations from the version-matched guide's "Host Deployment" section instead of inventing flags: (1) a `-host` image tag copied from the NGC `doca_telemetry` tag list, never guessed; (2) the one-shot init container (`DTS_CONFIG_DIR=host /usr/bin/telemetry-init.sh`) runs and exits 0 before the long-running `telemetry-run.sh` container; (3) the guide's host-namespace flags and the `config`, `ipc_sockets`, `data` and `log` mounts under `/opt/mellanox/doca/services/telemetry/`; (4) the documented run uses `--rm`, so `docker logs` finds nothing: read the host-mounted `.../telemetry/log` directory or re-run once without `-d`.

**BlueField built-in DTS (shape A) serves nothing on port 9100.** Inspect with `crictl pods`, `crictl ps -a` and `crictl logs <id>` (not docker); check `prometheus=` and `enable-provider=` in `/opt/mellanox/doca/services/telemetry/config/dts_config.ini` (edit the file it links to and allow about 60 s for the respawn). Green signal: two `curl <bluefield-ip>:9100/metrics` scrapes at least two update intervals apart show a counter that advanced. Change one variable per iteration.

**DPF-managed DTS (shape C).** Change providers and keys in the `DPUService` helm values (`configMapData`), confirm the keys with `helm show values`, apply with `kubectl apply -f`, and check the service conditions with `dpfctl`. Never hand-edit the INI on a DPF-managed DPU.

Example questions this skill answers well

The CLASSES of DTS questions this skill is built to answer, each with one worked example. The class is the load-bearing piece; the worked example is one instance.

• **"Which deployment shape am I in, and what does that change?"** —

worked example: *"I have a BlueField with DTS already running and a separate x86 host with no DPU; do I configure them the same way?"*. Answered by the shape table in [`CAPABILITIES.md ## Pattern overview`](CAPABILITIES.md#pattern-overview)

• the shape-first step in

[`TASKS.md ## configure`](TASKS.md#configure).

• **"How do I enable or disable a provider / component?"** — worked

example: *"turn on `ethtool` counters and drop `sysfs.eth`"*. Answered by the provider inventory in [`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes)

• the `enable-provider=` / `disable-provider=` step in

[`TASKS.md ## modify`](TASKS.md#modify) (in DPF the same option is set as `key: value` under `configMapData`, not in the INI).

• **"Whi