Doca Dts

DOCA Telemetry Service — Capabilities

Where to start: The pattern overview below names the recurring DTS-class operational patterns. Pick the pattern first — and before that, pick the deployment shape ((A) BlueField (built-in static pod) vs (B) Host (docker) vs (C) DPF (DPUService / helm chart)), because the shape decides where the manifest lives, how configuration reaches the container, and which guide section owns the verbatim recipe. Then drill into the H2 that owns the substance. For the how of executing each pattern, jump to TASKS.md.

This file enumerates DTS's documented capabilities, deployment shapes, configuration surface, and operational behaviors as described in the public DOCA Telemetry Service Guide on docs.nvidia.com, the NGC container / helm-chart pages, and the DPF public docs. Treat it as a map of what is documented, not a substitute for the live page. DTS is externally productized — a container image (built into the BlueField image or pulled from NGC) and a helm chart, not source in the DOCA SDK tree. If the version-matched guide page is unavailable, use the installed doca_telemetry_standalone.yaml, the dts_config.ini generated by that image, and helm show values; if none exists for the deployed tag, stop with a version/source gap rather than guess option names, tags, or chart keys.

Pattern overview

Every DTS-class question this skill teaches resolves into one of FIVE patterns. The patterns are CLASSES — they apply across all three deployment shapes; only the carrier of the configuration differs (a kubelet yaml, a docker invocation, or a DPUService values block).

Two cross-cutting rules that apply to every pattern above:

• Shape first, then column. Route the user through doca-setup ## recognize (doca-setup/TASKS.md#recognize) (uname -m, lspci -d 15b3:, bf-release) to learn whether they are on the BlueField Arm side, a plain host, or inside a DPF-managed cluster. Every subsequent instruction is read from that shape's column only; mixing columns (e.g. docker run on a DPU whose NGC page says docker pull is discouraged) is the most common failure.

• One configuration model, three carriers. The option names are identical everywhere and come from dts_config.ini; only the carrier differs. In DPF the documented mapping rule is that every key=value line of dts_config.ini becomes a key: value entry under spec.helmChart.values.configMapData.general (providers and Fluent Bit destinations have their own dedicated groups). Never invent an option name — read it from the guide's "DTS Configuration" section or the generated dts_config.ini of the deployed image.

Capabilities and modes

Architecture

DTS is a single container with a two-phase lifecycle:

• Init step — /usr/bin/telemetry-init.sh runs first (as an initContainers entry on BlueField and in DPF; as a one-shot the one-shot docker run of telemetry-init.sh on the host). It generates the default configuration files into the mounted config directory only if that directory is empty. On the host the documented invocation prefixes DTS_CONFIG_DIR=host so the host-oriented default profile is seeded. On BlueField a second script, /usr/bin/enable-fluent-forward.sh -i=<host> -p=<port>, may follow it to configure the Fluent Bit forward destination (it overwrites fluent_bit_configs).

• Main process — /usr/bin/telemetry-run.sh starts DTS, which reads /config/dts_config.ini (host path /opt/mellanox/doca/services/telemetry/config/dts_config.ini). Editing that file is the reconfiguration verb. The guide documents the automatic pickup only for level_labels.ini (process exits, DTS restarts within 60 s); in practice the same watcher covers dts_config.ini: expect the collector process to exit and respawn inside the container within ~60 s (supervisor lines exited: clx / spawned: 'clx' in the container log — the pod's restart count does not move), and apply the shape's restart rule only if no respawn appears. Edit the symlink's target: in the generated dir dts_config.ini -> clx_config.ini, and sed -i without --follow-symlinks replaces the link with a copy that DTS never reads — ls -l dts_config.ini tells you which one you have.

• Directory layout (host side, all shapes unless the chart's hostVolumePrefix says otherwise): /opt/mellanox/doca/services/telemetry/ with config/ (mounted at /config), data/ (mounted at /data, target of output=/data), ipc_sockets/ (mounted at /tmp/ipc_sockets), and a log directory mounted at the container's /var/log — /opt/mellanox/doca/services/telemetry/log in the guide's host docker run, /var/log/doca/telemetry in the shipped BlueField static-pod yaml (read the hostPath in your own yaml's volumes:).

• Maintenance rule from the guide: after any server configuration change (firmware, networking, firewall), restart DTS.

Deployment shapes

Shape-specific notes worth teaching:

• (A) The NGC page says the DPU image is "configured for K8S-based deployment, hence the use of the docker pull command is discouraged". Do not hand-write the static-pod yaml; download the version-matched one and drop it in place. Shared memory for IPC is /dev/shm/telemetry/ (DTS >= 1.9.0).

• (B) The documented run flags are a family with reasons (host namespaces so providers see host NICs/processes and IPC works; privileged mode; the MST device mapping for MFT-backed providers; --gpus all only with a GPU and the NVIDIA container toolkit; the five bind mounts) — table in TASKS.md ## Command appendix, verbatim command from the guide for the chosen version.

• (C) spec.configPorts (serviceType: None, port named httpserverport) — and the chart's exposedPorts, if the pinned chart exposes it (confirm with helm show values) — must agree with the Prometheus port configured in configMapData — see the port mismatch entry in ## Error taxonomy.

Discovering the inventory

The provider and exporter tables below are examples, validated against the public guide when this skill was written. The inventory that matters is the one shipped by the image tag / chart version actually deployed: it changes per DTS release without a skill change, and it differs between shapes (the host flavour is a different template from the BlueField one). Read it before naming a provider, exporter or option key, and quote what you observed rather than this file.

Fallback order when a layer is out of reach (no web access, no cluster access): generated config → chart values → guide. Never fill a gap from the tables in this file alone.

Providers catalogue

Providers are enabled with enable-provider=<name> and pruned with disable-provider=<name.component> (e.g. disable-provider=sysfs.eth). In DPF the same names go into configMapData.providers (CSV); configMapData.aggregator_providers is a separate CSV group for aggregator-side providers, not a second home for these names. It is a template-only key: the chart's ConfigMap template accepts it but values.yaml does not list it, so helm show values will not show it — the public DPF dpuservices/dts/DPUService.yaml carries it as a commented example, and helm template proves what a given chart version renders. Data-filtering sets live under configMapData.counterset.{cset,fset,xcset} (chart key — confirm with helm show values). Names and components below are the ones documented when this skill was written; the enable-provider= lines of the generated dts_config.ini (or the rendered DPF ConfigMap) are the provider inventory of the deployed version and win over this table (### Discovering the inventory). Provider-specific option families are listed so the agent recognizes them, but their values must be read from the guide's "Telemetry Providers" / "Enabling Providers" sections for the deployed version.

Do-not-invent guard (providers). Name a provider only if it is in this table, in the guide, or on an enable-provider= line (active or commented) of the user's generated config. Names you may remember from older releases (hcaperf, bluefield, ppcc, …) are not to be offered unless the user's file shows them — say "check the commented enable-provider= lines in your generated dts_config.ini" instead.

GPU rule (explicit): nvidia_smi / dcgm and the --gpus all run flag belong to shape (B) and only when the host has NVIDIA GPUs (plus the NVIDIA container toolkit). On a GPU-less host leave both providers disabled and omit --gpus all; on BlueField shapes (A)/(C) they are never applicable. Check first with nvidia-smi -L on the host.

Pruning rule: when the container log names a provider whose prerequisite the target cannot meet, the first single-variable change is to disable that provider, not to add privileges (## Error taxonomy layer 4).

The diagnostic-data providers carry a documented compatibility matrix with the other providers (guide "Diagnostic Data > Providers Compatibility"); read it before enabling diagnostic_data_* next to an existing provider set — the matrix, not this table, decides.

Exporters catalogue

Catalogue boundary: these five are exactly the guide's "Data Export Options" list when this skill was written; the banner section headers of the generated dts_config.ini (or the rendered DPF ConfigMap) are the exporter inventory of the deployed version (### Discovering the inventory). The HFT ad-hoc API reuses the same set per run (prometheus-endpoint, fluentbit-config-dir, open-telemetry-receiver, remote-write-receiver, file-write in the start body) — see ## HFT HTTP API family. Anything else a user asks for (NetFlow / IPFIX export, Kafka or InfluxDB without Fluent Bit in front, syslog) is not in the guide. Some of it is nevertheless visible in the product: the generated dts_config.ini and the published chart's configMapData.general block carry a commented NetFlow section (#netflow-collector-ip=, #netflow-collector-port=, "Exporter is disabled if this option is not set"). Say that it exists but is undocumented, point the user at the commented block in their generated config rather than asserting its semantics, and route collector-level NetFlow design to the public DTS guide via doca-public-knowledge-map/SKILL.md. Never name a key that is not in their file or the guide. A NetFlow "no" still owes a ladder for each alternative: application-side NetFlow through the exporter library → its own test / debug anchors (libs/doca-telemetry-exporter ## test (doca-telemetry-exporter/TASKS.md#test), ## debug (doca-telemetry-exporter/TASKS.md#debug)); the undocumented DTS block, if the user enables it anyway → layer 4 (does the start-up block list the NetFlow exporter as enabled after the restart?), layer 5 (is the collector reachable on the UDP port named in their file — ss -u/listener on the collector side), layer 6 (does the collector's own flow log show records?) — one change per iteration, and say explicitly that NVIDIA documents none of it.

Choosing rule: pull (Prometheus) makes DTS the thing that must be reachable — firewall / port / node exposure questions land here. Push exporters make the destination the thing that must be reachable — DNS / route / destination-up questions land there. Say which side owns the failure before debugging.

Labels

• Level labels — level_labels.ini beside dts_config.ini, enabled with level-labels-file=/config/level_labels.ini. DTS monitors the file: on a change the telemetry process exits on its own and DTS restarts within 60 s with the new labels (guide "Level Labels > Monitoring and Reloading") — a restart right after a label edit is expected behaviour, not a fault. In DPF the chart carries the raw INI in configMapData.levelLabels — a template-only key (rendered into level_labels.ini by the ConfigMap template, absent from values.yaml, so helm show values will not list it; verify with helm template on the pinned chart version), while the fleet-scale path is: per-DPU DPUDevice.spec.values rendered by a DPUFlavorTemplate Go template into a DPUFlavor configFiles entry for level_labels.ini, referenced from DPUDeployment.spec.dpus.flavorTemplate or DPUSet.spec.dpuTemplate.spec.dpuFlavorTemplate. Rendered sections: [global_labels] [device_labels] [device_mapping] [data_types_mapping]. Preview with dpfctl flavor-template render -f template.yaml --dpudevice-file device.yaml. Changing the template or values reprovisions DPUs per the DPUSet rollout strategy — a safety-relevant action. Confirm with helm show values and the DPF level-labels page which carrier the pinned chart wires into level-labels-file=; do not set both.

• Device labels — add-pci-address-label=true, add-numa-node-label=true.

IPC surface

DTS exposes telemetry to co-located applications through a socket directory (host /opt/mellanox/doca/services/telemetry/ipc_sockets, container /tmp/ipc_sockets) and shared memory at /dev/shm/telemetry (the DPF chart's shareHostSharedMemory toggles between the container-private path and the host's /dev/shm for bare-metal IPC clients — confirm with helm show values). The socket dir is created by root, so a client application needs write access and may itself need root. Applications built on the DOCA Telemetry Exporter API publish through DTS over this IPC (guide "DOCA Telemetry Exporter Integration"): the export modules exist in both the library and DTS, so an application exports either directly from the library or indirectly via DTS — which of the two is in play decides whether an exporter symptom belongs to this skill or to the library skill. The application side of IPC (API calls, linking) belongs to libs/doca-telemetry-exporter (doca-telemetry-exporter/SKILL.md) and libs/doca-telemetry (doca-telemetry/SKILL.md); this skill owns only the DTS-side mounts and the guide section "Enabling IPC with External Applications".

HFT HTTP API family

Ad-hoc high-frequency collection is driven over HTTP: enable-http-api=true, http-port=9117 (default); retention knobs ad-hoc-runner-max-size-bytes (1 GiB default), ad-hoc-runner-max-age-seconds (604800), ad-hoc-runner-min-age-seconds (600); endpoints /ad-hoc-collection/{start,stop,hft-counterset,list,status}. A start body can name its own exporters for that run (prometheus-endpoint, fluentbit-config-dir, open-telemetry-receiver, remote-write-receiver; file-write defaults to true) — same exporter set as the ## Exporters catalogue, scoped to the run. Treat this as a separate port to expose and a separate retention budget on the data dir; full request/response bodies are documented in the guide, not here.

Version compatibility

For the canonical DOCA version-detection chain, NGC container semantics, and the headers-win-over-docs rule, see doca-version/SKILL.md. The body lives there; this skill does not duplicate it.

The DTS-specific overlay is:

• The version anchor is the container tag (or the chart version), not the host DOCA install. DTS tags carry both their own version and the DOCA release they were built against (shape <dts-version>-doca<doca-version>); host images add a -host suffix. A BlueField image, a host pkg-config --modversion doca-common, and the DTS tag are three independent anchors — record all three before comparing against the guide.

• Never fabricate a tag. Copy it from the NGC tag list (container page in ## Public-source pointer); tags observed on 2026-09-16 are examples of the shape, not values to reuse (DPU: 1.26.5-doca3.5.0; host: 1.26.5-doca3.5.0-host). If the page cannot be reached, say so and ask the user to paste the tag list. Rule of record: doca-setup ## no-install (doca-setup/TASKS.md#no-install).

• Chart version != image tag. The doca-telemetry chart has its own version series (e.g. 1.26.5, 1.25.5 observed 2026-09-16) and pins the image tag internally; inspect with helm show chart / helm show values rather than assuming they are equal.

• Guide page version vs deployed version. Option names in this file were read from the guide page as published on 2026-09-16 (page version 3.5.0 at that time); confirm the live page version matches the DOCA component of the deployed tag, and when they diverge the dts_config.ini generated by the deployed image wins. Feature floors recorded from the public DTS pages on 2026-09-16: host deployment from DTS 1.13.0-doca2.0.2; /dev/shm/telemetry/ from DTS 1.9.0 (NGC container page note) — re-confirm them on the live page for your tag rather than quoting them as guide facts.

Error taxonomy

DTS errors fall into six layers, ordered the way a deployment fails; identify the layer before changing anything (the debug loop in TASKS.md ## debug is organized by these layers).

1. Image / tag layer — pull fails or the tag does not exist (pod stuck pulling in crictl pods / pod status; docker run exits before the container starts). Cause is almost always a fabricated or mistyped tag, a DPU tag used on a host (or -host on a DPU), or missing NGC credentials in DPF (the chart's imagePullSecrets key — confirm with helm show values). Owner: NGC tag list.

2. Manifest / pod scheduling layer — yaml present but pod not created (kubelet did not pick up /etc/kubelet.d, malformed yaml, or on DPF DPUService conditions ApplicationPrereqsReconciled / ApplicationsReconciled false, nodeSelector / tolerations excluding every DPU). Owner: kubelet / DPF operator; mechanics in doca-container-deployment ## debug (doca-container-deployment/TASKS.md#debug).

3. Init container / config generation layer — telemetry-init.sh ran against a non-empty dir and left stale config in place; on the host the documented DTS_CONFIG_DIR=host prefix was omitted from the init step; on BlueField enable-fluent-forward.sh pointed at an unreachable -i/-p; after an upgrade the freshly downloaded yaml carries the documented default -i=127.0.0.1 -p=24224 and enable-fluent-forward.sh overwrites fluent_bit_configs on every init even when the config dir is non-empty (the non-empty rule protects only telemetry-init.sh output), so the Fluent Bit destination silently resets unless the -i=/-p= edit is re-applied to the new yaml. Signature: DTS starts but with options the operator did not expect. Owner: config dir contents (reset = empty it, restart).

4. DTS process and provider prerequisites layer — the main process restarts in a loop or logs provider errors: dpe not started for grpc.*, fwctl not loaded for diagnostic_data_*, /dev/mst or MFT libs not exposed for amber / ppcc_eth, GPU toolkit missing for nvidia_smi / dcgm, host namespaces missing on shape B so sysfs / ethtool see nothing. Owner: the provider's prerequisite row in the Providers catalogue.

5. Exporter reachability / port mismatch layer — DTS is healthy but the consumer cannot reach it (pull) or DTS cannot reach the destination (push). Canonical DPF instance: configMapData.prometheus.port differs from the port in spec.configPorts (or the chart's exposedPorts, if present — confirm with helm show values; chart defaults and the DPF example may differ — the example uses 9100), so the Service forwards to a port DTS is not listening on. Set both explicitly after reading helm show values. Owner: this skill.

6. Consumer side — Prometheus scrape config, Grafana data source, Fluent Bit / Kafka / OTLP destination. DTS is the conduit; the consumer's own logs are the source of truth. Out of scope beyond the guide's "Deploying with Grafana Monitoring" recipe.

Three paths cross these layers and get their own ladders in TASKS.md ## debug ("Path-specific ladders"): storage read-back with clx_read, remote collection through dpe, and the alternative recommended by a boundary answer.

DTS does not surface DOCA_ERROR_* to the operator; its outward surface is container exit status, log lines, and the exporters. The DOCA error taxonomy matters only on the application side of IPC (libs/doca-telemetry-exporter (doca-telemetry-exporter/SKILL.md)).

Observability

Documented observability surfaces, by shape:

• Container logs. (A) crictl ps then crictl logs <container-id>, plus the persisted copy in the host directory the pod yaml maps to the container's /var/log (/var/log/doca/telemetry in the shipped doca_telemetry_standalone.yaml — confirm from its volumes: block); (B) docker logs doca-telemetry while it runs, and the /var/log bind mount at /opt/mellanox/doca/services/telemetry/log on the host — the documented run uses auto-remove, so an exited container is removed and the host log dir (or a foreground re-run without -d) is the only record of the exit; (C) kubectl logs on the DPU cluster. Provider prerequisite failures (layer 4) and exporter connect failures (layer 5) appear here first.

• Management HTTP API on the Prometheus endpoint. When prometheus= is set, the same listener serves a management surface: GET <addr>:<port>/management prints the route table for your build — read it there rather than from memory. The routes that matter for deployment debugging: /management/provider (statistics and run_status of every provider — the live answer to "which providers are actually running", layer 4), /management/provider/<name> (one provider's runtime status), /management/exporter (state and statistics of every exporter — exported page / record counters, the destination-independent validation signal for push exporters, layer 5), /management/exporter/<name> (use the names the list returns; they are plugin names, not prometheus), /management/config_file (the configuration DTS actually loaded — settles "did my edit reach it" without touching the file), and /management/all_configs / /management/(cset|fset|xcset)[/<name>] (the data-set files behind prometheus-fset-indexes and the chart's counterset.*; GET to read, POST/PUT/DELETE change them — treat the mutating verbs as config edits). On (C) reach it through the service port. Every management request is itself logged in clx.log.

• Reading the log. The public guide documents only the mount, so everything below is read from the target, never assumed. Two logs: the container log (crictl logs / docker logs / kubectl logs) is the supervisor's process view — spawned: 'clx', exited: clx, a sibling service going FATAL — and is where a respawn or a restart loop shows; the collector's own log (clx.log in the mounted log dir, rotated at ~10 MB into clx.log.1…N; inside the container the same file is /var/log/clx.log — crictl exec <id> tail -f /var/log/clx.log, docker exec doca-telemetry tail -f /var/log/clx.log, kubectl exec <pod> -- tail -f /var/log/clx.log) is where the start-up block and the provider / exporter lines are. File: ls the mounted log directory and name what is there. Order: the start-up block (collector log) first — it prints # of enabled providers / # of disabled providers with one line per provider, so it is where DTS reports which providers it enabled and which it disabled or could not find; a provider the user expects that is absent or rejected there is a misspelled name or an unmet prerequisite (layer 4), while a provider that came up followed by an exporter complaining is layer 5. Quote the exact line from the user's log; do not paraphrase it from memory. Steady state: judge steady state from /metrics or the destination, not from log cadence. Verbosity: the verbose= key in the generated dts_config.ini carries its own scale in the inline comment (error / info / debug); raise it for one restart cycle and restore it — it is a config edit, so the shape's restart rule applies. If the generated config shows a commented syslog-and-stream option, that is the documented-in-template way to mirror the log into the host's syslog on shape (B); present it only when it appears in the user's file.

• Prometheus /metrics — the green signal. Scrape <addr>:<port>/metrics twice, at least two update intervals apart (default update=1000 ms) and show a counter or timestamp advancing between the two scrapes. A single 200 response proves only that the endpoint is bound; an advancing value proves providers are collecting. Pair it with the negative side: the target's own networking / SSH unaffected, and no restart loop (crictl ps / docker ps uptime / pod restart count flat across the same window). This is the step-5 evidence of the universal verification contract in TASKS.md ## test.

• Data directory. With output=/data, files appear under the host data/ dir; growth over time is a second, exporter-independent liveness signal (and a retention budget to watch, especially with HFT enabled).

• DPF conditions. kubectl -n dpf-operator-system exec deploy/dpf-operator-controller-manager -- /dpfctl describe all --show-resources=dpuservice/doca-telemetry-service --show-conditions=all reports conditions such as ApplicationPrereqsReconciled, ApplicationsReady, ApplicationsReconciled, DPUServiceInterfaceReconciled (the live page lists more); every condition the command prints being True is the DPF-side precondition before scraping.

• Cross-skill spine. Read-only triple capture and the bounded loop are defined in doca-debug ## Universal debug-loop contract (doca-debug/CAPABILITIES.md#universal-debug-loop-contract); generic command shapes in doca-debug ## Command appendix (doca-debug/TASKS.md#command-appendix).

Safety policy

Overlay on the bundle-wide hardware-safety meta-policy. The rules below are this skill's per-artifact overlay on the cross-cutting rules in doca-hardware-safety CAPABILITIES.md ## Safety policy (doca-hardware-safety/CAPABILITIES.md#safety-policy) (specifically ### Per-artifact overlay pattern (doca-hardware-safety/CAPABILITIES.md#per-artifact-overlay-pattern)). When the two layers disagree, the stricter wins; when either layer says STOP, the agent stops.

DTS itself is read-only telemetry: it reads counters and does not reconfigure firmware, ports, or the network. The safety-relevant surface is everything around it:

• Privilege of the container. The documented host invocation is privileged mode with the host network, UTS, IPC and PID namespaces; the DPF chart exposes a securityContext.privileged key (confirm with helm show values). This is the documented and expected way to run DTS — a root service reading hardware counters — so do not add a confirmation ritual to the documented run line; just name what it grants (root in the host's net/uts/ipc/pid namespaces plus the devices handed in) so the user knows what they are deploying. Gate only what goes beyond the documented flag family (extra capabilities, extra device mappings, mounts the guide does not list) and systemctl start dpe below; and do not remove privileged mode while promising the providers will still work. --gpus all is a shape-(B) host flag only.

• Device exposure. the MST device mapping, the /usr/lib64/mft mount, /dev/fwctl/fwctl*, and --gpus all hand hardware handles to the container. Expose only what the enabled providers need; a provider that is disabled needs no device.

• systemctl start dpe (DOCA Privileged Executor, required for grpc.* remote collection on BlueField) starts a privileged system service on the DPU. Treat it as a hardware-touching change: state the reason, confirm the target identity, and obtain authorization bound to that target (explicit user reply, or an approved-system artifact in unattended runs); otherwise stop with confirmation_required.

• DPF flavor-template / DPUDevice value changes reprovision DPUs per the DPUSet rollout strategy. Editing a level-labels template is therefore not a config-only change; preview with dpfctl flavor-template render first and schedule the rollout consciously.

• Config reset deletes operator configuration. "Delete all files in .../telemetry/config/, restart DTS" also removes hand-edited dts_config.ini, level_labels.ini, and fluent_bit_configs. Back the directory up before resetting; on BlueField, removing /etc/kubelet.d/doca_telemetry_standalone.yaml disables telemetry at the next boot — say so.

• Rollback is cheap: remove the yaml from /etc/kubelet.d, removing the doca-telemetry container, or kubectl delete -f DPUService.yaml (on the DPUDeployment route: remove the dts entry from DPUDeployment.spec.services or revert the DPUServiceConfiguration values and re-apply; reverting a flavor-template / DPUDevice label change reprovisions DPUs again — schedule it like the forward change and preview with dpfctl flavor-template render) — prefer it over a second speculative change once the one-iteration debug budget is spent.

Public-source pointer

The canonical public sources for DTS are:

• DOCA Telemetry Service Guide (docs.nvidia.com): https://docs.nvidia.com/doca/sdk/doca+telemetry+service+guide/index.html — sections quoted by name throughout this skill ("Service Deployment", "DTS Configuration", "Telemetry Providers", "Data Export Options").

• DOCA Container Deployment Guide (kubelet static-pod mechanics on BlueField): https://docs.nvidia.com/doca/sdk/doca+container+deployment+guide/index.html

• NGC container page (tag list, per-version doca_telemetry_standalone.yaml under configs/<version>/, crictl usage notes): https://catalog.ngc.nvidia.com/orgs/nvidia/teams/doca/containers/doca_telemetry

• NGC helm chart page (doca-telemetry chart versions): https://catalog.ngc.nvidia.com/orgs/nvidia/teams/doca/helm-charts/doca-telemetry

• DPF docs: https://docs.nvidia.com/networking/display/dpf/ and https://github.com/NVIDIA/doca-platform (public-main): the DTS page docs/public/advanced-configuration/dpuservices/doca-telemetry-service.md, the level-labels page docs/public/advanced-configuration/telemetry-level-labels.md, and the example dpuservices/dts/DPUService.yaml.

• Developer forum (DOCA category): https://forums.developer.nvidia.com/c/infrastructure/doca/370

Verify that the guide page version matches the DOCA component of the deployed container tag / chart version before quoting option names.