Doca Telemetry Traceback Application

NVIDIAOfficialCreated by NVIDIA

Skill
Tool integration
Cloud and DevOps
Apache-2.0
Medium risk

From the author

Use this skill when the operator is driving the DOCA Telemetry Traceback application to monitor telemetry data locally on a BlueField DPU or ConnectX NIC, detect long-term trends and threshold breaches with user-defined rules, and capture pre-event history plus active-event data to a log file. Trigger even when the user does not explicitly mention "DOCA Telemetry Traceback" — typical implicit phrasings include "monitor telemetry trends on the DPU without streaming all raw data", "log the samples before and after a threshold breach", "set up a rule that triggers when rx bytes/s exceeds 1M", "differential greater than rule on a data ID", "circular buffer of telemetry samples", or "traceback event log". Refuse and route elsewhere: the DOCA Telemetry Diag programming API and raw counter reads to doca-telemetry, DOCA install/bring-up to doca-setup, and version questions to doca-version.

— the description by NVIDIA

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The DOCA Telemetry Traceback application is a tool for monitoring telemetry data locally on BlueField DPUs or ConnectX NICs. It allows users to define rules for detecting trends and threshold breaches, capturing both pre-event history and active-event data into a log file. This skill provides guidance on configuring the application via JSON, compiling it from source, and executing it on hardware, while maintaining clear boundaries with other DOCA components like the Telemetry Diag API or installation procedures.

What it does

Configures telemetry monitoring rules and data IDs via JSON.
Supports compilation of the application from source code.
Executes the application on BlueField DPU or ConnectX NIC hardware.
Captures pre-event and active-event telemetry data to log files.
Provides troubleshooting steps for empty logs or configuration mismatches.

When to use it

When you need to monitor telemetry trends locally on a DPU without streaming raw data.
When you need to set up rules to trigger logs based on threshold breaches.
When you need to compile the Telemetry Traceback application from source.
When you are diagnosing issues like empty event logs or unsupported data IDs.

Advantages

Enables local telemetry processing and traceback logging on supported hardware.
Provides structured guidance for rule definition and application execution.
Maintains clear separation between application usage and low-level API programming.
Integrates with standard DOCA development workflows.

Usage examples

“How do I set up local telemetry monitoring for port_0_rx_bytes on my DPU?”: The agent provides the necessary JSON configuration structure and rule definitions to monitor the specified data ID and log history around threshold breaches.
“Why is my differential_greater_than rule not triggering in the event log?”: The agent explains the requirement for sample history depth and delta logic, guiding you to verify your configuration parameters.

Install

Download the skill as a ZIP:
https://autogineer.com/agent-skills/nvidia/doca-telemetry-traceback-application/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip doca-telemetry-traceback-application.zip -d .agents/skills

Documentation by NVIDIA

DOCA Telemetry Traceback Application

Scope boundaries

These requests are out of scope: say so, name the skill that owns the request, and stop.

the DOCA Telemetry Diag programming API and raw counter reads: doca-telemetry/SKILL.md.
DOCA install and bring-up: doca-setup/SKILL.md.
which DOCA version is installed, version consistency: doca-version/SKILL.md.
general DOCA orientation and documentation lookup: doca-public-knowledge-map/SKILL.md.

Examples

“Can I monitor telemetry trends on the DPU without streaming all raw data?” — in scope. Configure rules and sample history depth; do not use the DOCA Telemetry Diag API directly here.
“The event log is empty even though a threshold was crossed.” — check rule comparison_type and sample_history_depth; differential rules require depth samples before functioning.
“How do I build only this application?” — use the Meson isolation flags; see the tasks companion.
“I'm writing my own C code against the DOCA Telemetry Diag library to read counters.” — that part is doca-telemetry's: the application uses Diag internally, but programming the Diag API is not this skill. Name doca-telemetry for it and do not write Diag API code here; handle every other part of the request as this skill describes (for example, --force-ownership still goes through doca-hardware-safety).

Quick facts

The authoritative source for the binary name, flags, and paths is the public DOCA Telemetry Traceback guide for the release; confirm them with the installed tool's --help before quoting any of them. As that guide describes it:

Standalone application on a BlueField DPU or ConnectX NIC; four components: DOCA Telemetry Diag instance, sample history circular buffer, rule collection, and events log file.
Configuration JSON fields: diag_sample_period_ns, sample_history_depth, data-ids array, and rules array. Rule types are incremental_greater_than (inc_gt), differential_greater_than (dt_gt), differential_less_than (dt_lt), greater_than (gt), and less_than (lt).
The circular buffer size is automatically doubled based on the requested depth to ensure equal historical and active event data.
Requires sudo/root privileges; mandatory -d PCIe address and -r rules JSON; optional --event-log and --force-ownership.
Unsupported data IDs are reported; adjust inputs accordingly.
The application stops if the actual sample size or period does not match the requested parameters.
--force-ownership changes diag domain ownership; route any use of it through doca-hardware-safety/SKILL.md.

Instructions

Follow Loading order below. Open the tasks companion for configure / build / run / debug. Open the capabilities companion for what the application monitors and logs. Do not open every companion file.

Where to start: This is a tool skill for invoking the DOCA Telemetry Traceback application — the local telemetry monitoring and traceback logging service that processes telemetry data on the device and writes event logs when user-defined rules trigger. Open the tasks companion and start at ## configure for the JSON configuration and rule definitions, then ## run for compile and execution. Open the capabilities companion when the question is what data can be monitored, what rules evaluate, and what the event log contains. If the user has not installed DOCA yet, route to doca-setup/SKILL.md first. If the user asks about version, route to doca-version/SKILL.md. If any step changes hardware or firmware state (e.g., --force-ownership), route to doca-hardware-safety/SKILL.md.

How to use this skill. Read this file, then search the companion file for the ## <name> heading the question needs and read that whole section. Answer completely from it, quoting only its symbols and commands. Do not browse docs; use the entry points in doca-public-knowledge-map. Give environment checks as commands for the user's DOCA host. For out-of-scope requests, name the skill that owns them and stop.

Compile and run commands are documented in the tasks companion; the authoritative source is the public guide. The application is distributed as source and must be compiled before execution. The source is located at /opt/mellanox/doca/applications/telemetry/traceback/.

Example questions this skill answers well

The CLASSES of telemetry-traceback 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.

“How do I set up local telemetry monitoring with traceback logging?” — worked example: “I want to monitor port_0_rx_bytes on the DPU and log history before and after it exceeds 1 MB/s”. Answered by the JSON configuration and rule definitions in the tasks companion.
“What rule types are available and when do they activate/deactivate?” — worked example: “I need a rule that triggers each time a counter increases by a threshold, not just when it exceeds a fixed value”. Answered by the rule definitions in the capabilities companion.
“Why is my differential rule not triggering?” — worked example: “I configured differential_greater_than but the event log stays empty”. Answered by the depth requirement and delta logic in the capabilities companion.
“How do I compile and run only this application?” — worked example: “I want to build just the Telemetry Traceback app, not all DOCA applications”. Answered by the Meson isolation flags in the tasks companion.
“What does the event log contain when multiple events overlap?” — worked example: “Two rules trigger at the same time; how are begin/end markers written?”. Answered by the event log lifecycle in the capabilities companion.
“How do I know if my device supports the data IDs I configured?” — worked example: “The application reports unsupported IDs; what do I do?”. Answered by the unsupported data ID handling in the tasks companion.

When to load this skill

Load this skill when the user is — or the agent needs to — drive the DOCA Telemetry Traceback application on a real host or BlueField Arm with DOCA installed (or inside the public NGC DOCA container with the right device passthrough). Concretely:

Configuring JSON rules and data IDs for local telemetry monitoring.
Compiling the application from source.
Running the application with a PCIe address and rules file.
Diagnosing an empty event log, unsupported data IDs, or sample size/period mismatch.
Understanding rule activation/deactivation semantics.
Cross-checking event log output against configured rules.

Do not load this skill for general DOCA orientation, the DOCA Telemetry Diag programming API, raw telemetry collection, DOCA install, or version questions. For those, route to doca-public-knowledge-map/SKILL.md, doca-setup/SKILL.md, or doca-version/SKILL.md.

What this skill provides

This is a thin loader. Substantive material lives in two companion files:

the capabilities companion — what the application monitors and logs: the four components, configuration schema, rule definitions with activation/deactivation triggers, event log lifecycle, unsupported data ID behavior, version overlay that redirects to doca-version/SKILL.md, and the safety policy for --force-ownership.
the tasks companion — step-by-step workflows for the in-scope task verbs: configure (JSON config, rule selection), build (Meson compile all or only this app), run (execution syntax, root, PCIe address), debug (empty log, unsupported IDs, sample mismatch), plus a Command appendix that honors the bundle's doca-structured-tools-contract/SKILL.md preamble.

The skill assumes a host or BlueField where DOCA is already installed (or the public NGC DOCA container is running with the right device passthrough) and the operator has root privileges as required by the public guide.

What this skill deliberately does not ship

This skill is agent guidance, not a samples or scripts bundle. To keep the boundary clean, it deliberately does not contain — and pull requests should not add:

Verbatim flag inventories, subcommand names, or output column names. The public DOCA Telemetry Traceback guide and the installed --help on the user's version are the joint source of truth; copying them here pins the skill to one release and silently rots when the application evolves. The skill routes the agent at those sources instead.
Pre-baked example output. Output is install-, version-, and device-specific. A captured example will mislead an operator on a different platform / state.
Wrappers, parsers, or scripts in any language that consume the application's output. The output format is documented; users who want to script against it should read the live guide and write the parser against their installed version.
A samples/ or reference/ subtree. This is a thin loader for a documented DOCA artifact; substantive material lives on the public page and in --help.

Loading order

Read this skill first to confirm the user's question is in scope (the user wants to monitor telemetry data locally and capture traceback event logs, not use the DOCA Telemetry Diag programming API directly).
For what the application monitors, the configuration schema, rule definitions, event log lifecycle, unsupported data ID behavior, version availability, and safety posture, see the capabilities companion.
For the documented invocations and workflows — configure, build, run, debug, plus the Command appendix — see the tasks companion.

doca-hardware-safety/SKILL.md — the bundle's hardware/firmware state-change gate. The Telemetry Traceback application is read-only for telemetry data, but the --force-ownership flag changes diag domain ownership; route any use of that flag through this skill before execution.
doca-version/SKILL.md — canonical DOCA version-handling rules. The ## Version compatibility section in the capabilities companion is a concise overlay that redirects here for the body.
doca-setup/SKILL.md — env preparation, install verification, and the I have no install yet path with the public NGC DOCA container. This skill assumes its preconditions are satisfied.
doca-public-knowledge-map/SKILL.md — routing to the public DOCA Telemetry Traceback guide and the rest of the public DOCA documentation set. The canonical URL is reached via doca-public-knowledge-map ## DOCA tools (doca-public-knowledge-map/SKILL.md#doca-tools).
doca-structured-tools-contract/SKILL.md — the bundle's detect → prefer → fall back → report contract for structured helper tools. The Command appendix in the tasks companion honors this contract.

Files

ATTRIBUTION.mdAdded by AutoGineer966 B
BENCHMARK.md10.8 KiB
CAPABILITIES.md15.9 KiB
LICENSELicence file added by AutoGineer11.2 KiB
SKILL.md12.4 KiB
SKILLCARD.yaml2.6 KiB
TASKS.md19.5 KiB
evals/evals.json3.6 KiB
skill-card.md5.0 KiB
skill.oms.sig5.2 KiB

CAPABILITIES.md

DOCA Telemetry Traceback Application — Capabilities

Where to start: The Telemetry Traceback application is a single DOCA artifact that can be deployed in more than one shape; the pattern overview below names the recurring traceback-class questions. Pick the pattern first, then drill into the H2 that owns the substance. For the how of executing each pattern, jump to TASKS.md. For the host ↔ DPU control-plane sibling whose channels coordinate the endpoints the relay carries traffic between, see doca-comch/CAPABILITIES.md.

This file is loaded by SKILL.md. It documents what the application monitors and logs, which deployment shapes are documented, what versions it ships in, the layered error and observability surfaces, and the high-stakes safety policy that gates the data-path pieces. For step-by-step invocations and the smoke-before-bulk workflow, see TASKS.md.

Pattern overview

Every Telemetry Traceback question this skill teaches resolves into one of SIX patterns. The patterns are CLASSES — they apply across every DOCA install that ships the application, not just one platform.

Traceback pattern	Class shape	Where the substance lives
1. Configure local telemetry monitoring with traceback logging	Define `diag_sample_period_ns`, `sample_history_depth`, `data-ids`, and `rules` in the JSON configuration file so the application samples device telemetry locally and writes event logs when rules trigger	`## Capabilities and modes` configuration model + TASKS.md ## configure
2. Select rule type and understand hysteresis	Choose among `incremental_greater_than`, `differential_greater_than`, `differential_less_than`, `greater_than`, and `less_than`; each has distinct activation and deactivation triggers	`## Capabilities and modes` rule definitions + TASKS.md ## configure step 2
3. Build only this application	Isolate the Telemetry Traceback application from the full DOCA Meson build using `-Denable_all_applications=false -Denable_telemetry=true -Denable_telemetry_traceback=true` or by editing `meson_options.txt`	TASKS.md ## build
4. Run the application with correct PCIe address and root	Execute `doca_telemetry_traceback` with mandatory `-d` PCIe address and `-r` rules JSON, plus optional `--event-log` and `--force-ownership`; requires sudo/root privileges	TASKS.md ## run
5. Diagnose empty event log / unsupported IDs / sample mismatch	Map the symptom (no events logged, application reports unsupported data IDs, application stops due to sample size/period mismatch) to the right layer of the error taxonomy before any state-changing intervention	`## Error taxonomy` + TASKS.md ## debug
6. Handle overlapping events and log lifecycle	Understand how the events log captures history, event start/end markers, and simultaneous rule activations/deactivations	`## Capabilities and modes` event log lifecycle + `## Observability`

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

The application is read-only for telemetry data, but --force-ownership changes diag domain ownership. A misconfigured rule, an unsupported data ID, or a sample size/period mismatch produces a silent break — the operator observes an empty event log or an application stop whose root cause is the configuration, not the device. The agent must say so before any state-changing operation, and must route any use of --force-ownership through ## Safety policy before execution.
Differential rules require depth before functioning. dt_gt and dt_lt require at least sample_history_depth values in the buffer before they can evaluate; gt and lt require sample_history_depth consecutive samples on the correct side of the threshold. An agent that diagnoses an empty event log without naming this depth requirement is missing the load-bearing constraint documented in ## Capabilities and modes.

Capabilities and modes

The DOCA Telemetry Traceback application is a documented DOCA artifact that ships on installs which include it. The exact installed location, binary name, packaging shape, and per-platform availability live in the public DOCA Telemetry Traceback guide reachable via doca-public-knowledge-map ## DOCA tools (doca-public-knowledge-map/SKILL.md#doca-tools) and on the installed --help; the skill deliberately does not pin them — see SKILL.md ## What this skill deliberately does not ship.

Use case — what the application is for. The Telemetry Traceback application provides a framework for monitoring telemetry data to identify long-term trends locally on the device. Because funneling massive volumes of raw telemetry data to a centralized data store can overwhelm network resources at data-center scale, this application processes data directly on the NVIDIA BlueField DPU or NVIDIA ConnectX NIC. It gathers telemetry data into a circular buffer, retaining the last N samples from the device. This historical data is continuously evaluated against user-defined rules to detect specific events (anomalies or notable threshold breaches). When an event triggers, the application writes the preceding historical data and all subsequent active event data to a log file. The included rules are purposefully simplistic, as this application is intended to serve as a reference traceback model rather than a fully featured data processing engine.

Four-component architecture — the load-bearing concept. Every Telemetry Traceback deployment commits to this structure; omitting any component produces an ambiguous answer the agent must flag back to the user.

Component	What it does	Why the agent must name it
DOCA Telemetry Diag instance	The underlying data provider, configured using parameters from the application's JSON configuration file (e.g., sample period, data IDs) alongside hardcoded application values	The application stops if the actual sample size or period does not match the requested parameters
Sample history circular buffer	A contiguous block of memory storing telemetry samples as `timestamp, data_id[0], ... data_id[N]`; buffer size is automatically doubled based on the requested depth to ensure equal historical and active event data	Differential rules require at least `sample_history_depth` values in the buffer before functioning
Rule collection	A set of logical monitors; each rule monitors a specific `data_id` against defined logic, triggering event start/end	Rule type determines activation and deactivation hysteresis
Events log file	Output destination for event data; logs configuration header, history, event start/end markers, and active event data	Overlapping events insert individual begin/end rows to track lifecycles

Configuration model. The application retrieves its operational parameters from a JSON configuration file. The fields are:

Field	Type	Notes
`diag_sample_period_ns`	Integer	Sampling interval in nanoseconds; passed directly to the diag instance via `doca_telemetry_diag_get_sample_period`
`sample_history_depth`	Integer	Number of historical records a rule evaluates; the application automatically provisions a circular buffer double this size
`data-ids`	Array	Collection of data ID definitions
`data-ids[N].name`	String	Friendly name for the `data_id`, used as column header in the events log
`data-ids[N].data_id`	String	16-character hexadecimal value, format `0x[0-9a-fA-F]{16}`
`rules`	Array	Collection of rule definitions
`rules[N].name`	String	Friendly name used to identify the rule in the events log
`rules[N].data_id`	String	16-character hexadecimal `data_id` this rule monitors; must match an ID defined in the `data-ids` array
`rules[N].comparison_type`	String	Defines the rule's operational logic; acceptable values: `incremental_greater_than` (`inc_gt`), `differential_greater_than` (`dt_gt`), `differential_less_than` (`dt_lt`), `greater_than` (`gt`), `less_than` (`lt`)
`rules[N].comparison_value`	Integer	Numerical threshold utilized when evaluating the rule

Rule definitions. The application supports five distinct rule types. Each rule establishes its own hysteresis logic, defining precisely when an event activates and deactivates.

Rule type	Activation trigger	Deactivation trigger
`incremental_greater_than` (`inc_gt`)	Activates if the sampled value exceeds the calculated setpoint (Initial Setpoint = First Sampled Value + `comparison_value`)	Deactivates immediately once any new sampled value exceeds the current setpoint, and a new setpoint is calculated. Rapid data spikes exceeding the setpoint multiple times simultaneously will only activate the rule once
`differential_greater_than` (`dt_gt`)	Activates if the delta between the newest sample and the sample at `[N-(sample_history_depth-1)]` exceeds `comparison_value`; requires at least `sample_history_depth` values in the buffer before functioning	Deactivates only after `sample_history_depth` consecutive samples are acquired where each new delta remains below `comparison_value`
`differential_less_than` (`dt_lt`)	Operates using the identical historical delta logic as `dt_gt`, but activates when the delta is less than `comparison_value`	Same as `dt_gt` deactivation, but for deltas above `comparison_value`
`greater_than` (`gt`)	Activates when the sampled value explicitly exceeds `comparison_value` for `sample_history_depth` times consecutively; designed strictly for values that can fluctuate (increase and decrease), not suitable for metrics that only increment	Deactivates only after `sample_history_depth` consecutive samples fall below `comparison_value`
`less_than` (`lt`)	Operates using the identical fluctuation logic as `gt`, but activates when the sampled value remains below `comparison_value` for the required consecutive depth	Deactivates only after `sample_history_depth` consecutive samples rise above `comparison_value`

Event log lifecycle. Upon execution, the application logs its configuration to ensure absolute certainty regarding the parameters that triggered an event. When an event starts, the log captures the available history, an "event started" marker, all data collected during the event, and an "event end" marker. If multiple events activate simultaneously, individual begin/end rows are inserted to track their respective lifecycles. Data logging pauses once all events conclude and resumes upon the next activation.

Unsupported data IDs. It is not guaranteed that all data IDs supported by the application are supported by your specific device. The application will report any unsupported IDs, requiring administrators to adjust their inputs accordingly.

Sample size/period validation. The application calls doca_telemetry_diag_get_sample_size() and doca_telemetry_diag_get_sample_period() to confirm the hardware accepted the requested parameters. If the actual sample size or period does not match the requested parameters, the application explicitly stops. While this could be worked around, the codebase relies on these assumptions for simplicity and requires them to be correct.

Version compatibility

This skill documents the DOCA Telemetry Traceback application as described in the DOCA 3.5.0 archive guide. Version-specific availability, changes, and compatibility questions route to doca-version/SKILL.md. The application is distributed as source code and must be compiled prior to execution; the source is located at /opt/mellanox/doca/applications/telemetry/traceback/. For any question about which DOCA release ships a given rule type, flag, or behavior, consult doca-version/SKILL.md rather than assuming from this skill.

Error taxonomy

Map the symptom to the right layer before any state-changing intervention.

Symptom	Likely layer	What to check
Event log is empty even though a threshold was crossed	Rule configuration	Verify `comparison_type` and `sample_history_depth`; differential rules require depth samples before functioning; `gt`/`lt` require consecutive samples on the correct side
Application reports unsupported data IDs	Device capability	The specific device may not support all data IDs the application supports; adjust inputs accordingly
Application stops immediately after start	Sample size/period mismatch	The hardware did not accept the requested `diag_sample_period_ns` or sample size; the application explicitly stops
Application fails to access telemetry data	Privileges	The application strictly requires sudo (root privileges) to access hardware-level telemetry data
Application cannot find the device	PCIe addressing	Ensure the `-d` parameter exactly matches the physical PCIe address of the target device
Diag domain ownership conflict	Firmware domain mode	`--force-ownership` forces ownership of the diag domain; only applies when the device firmware is in single domain mode; route through `doca-hardware-safety/SKILL.md`

Observability

The application's primary observability surface is the events log file. The log captures:

Configuration header — written immediately upon execution via log_app_start_header(), ensuring absolute certainty regarding the parameters that triggered an event.
Historical data dump — when the first rule activates, the application writes the data column headers and dumps the historical buffer to the events log.
Event start/end markers — for all rule activations, an "event started" message is explicitly written; for deactivations, an "event completed" marker is written.
Active event data — data received while any rule is active is logged strictly before the rules processing step for each sample, continuing until all rules deactivate.
Overlapping event tracking — if multiple events activate simultaneously, individual begin/end rows are inserted to track their respective lifecycles.

The application also logs its configuration to ensure certainty regarding the parameters that triggered an event. For runtime diagnostics, the application supports standard DOCA logging flags (-l, --sdk-log-level, --log-filter) as documented in the public guide and the installed --help.

Safety policy

The Telemetry Traceback application is read-only for telemetry data — it samples device telemetry and writes event logs, but does not modify hardware or firmware state. The one exception is the --force-ownership flag, which forces ownership of the diag domain and only applies when the device firmware is in single domain mode. Any use of --force-ownership changes diag domain ownership and must be routed through doca-hardware-safety/SKILL.md before execution.

The application strictly requires sudo (root privileges) to access hardware-level telemetry data. The agent must state this requirement before any run command. The application also stops if the actual sample size or period does not match the requested parameters; this is a deliberate safety check, not a bug, and the agent must not recommend workarounds that bypass it.

Public-source pointer

The source code for this application is located at:

/opt/mellanox/doca/applications/telemetry/traceback/

The authoritative public guide is the DOCA Telemetry Traceback application documentation at:

https://docs.nvidia.com/doca/archive/3-5-0/doca-telemetry-traceback-application/index.html

For extended capability details of the underlying DOCA Telemetry Diag library, refer to its official programming guide. For any issue encountered with compilation, installation, or execution of the DOCA applications, refer to the NVIDIA BlueField Platform Software Troubleshooting Guide.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

The author says: Requires DOCA SDK installed at /opt/mellanox/doca on Linux with a BlueField DPU or ConnectX NIC, plus root privileges to access hardware-level telemetry data. The application is distributed as source code and must be compiled before execution; the source is located at /opt/mellanox/doca/applications/telemetry/traceback/. Validation steps require a live DOCA install.

Security

What our scanner noticed· Medium risk

Large base64-encoded blobs

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by

NVIDIA

Publisher

NVIDIA (Official)

Source

NVIDIA/skills · skills/doca-telemetry-traceback-application · commit fce3cca

Licence

Apache License 2.0 (redistribution allowed)

LICENSE (added by AutoGineer from LICENSE-APACHE)
ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-09

AutoGineer is not affiliated with or endorsed by NVIDIA or NVIDIA.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download doca-telemetry-traceback-application.zip