DOCA Telemetry Exporter Development
Guides DOCA applications in defining, emitting, and debugging structured telemetry for external consumers.
The documentation clearly scopes the skill to the publisher side, emphasizes same-user permissions, discourages sudo, requires the receiver to start first, recommends dropping or bounded buffering on AGAIN, and describes the one-way data flow. However, it lacks a complete user-confirmation model, rollback procedure, and sensitive-data handling guidance. License and provenance metadata are inconsistent across Apache-2.0, Apache-2.0 AND CC-BY-4.0, and NOASSERTION, so points are deducted.
TASKS.md and CAPABILITIES.md provide configuration, build, run, test, and error-taxonomy paths, usually routing failures to a concrete layer. This review is static only, with no executable reproduction; several API behaviors and transport semantics depend on the installed version or external documentation. The score is therefore conservatively limited below the static-review ceiling.
Triggers, audience, exclusions, and routing against Telemetry Service, doca_log, Prometheus, and doca-comch are fairly clear, and FFI scenarios are acknowledged. However, the skill requires a specific DOCA installation plus BlueField or ConnectX hardware, provides no evidence of Chinese-language support or mainland-China network reachability, and its implicit trigger language may be overly broad, so points are deducted.
The thin SKILL.md loader, CAPABILITIES.md, TASKS.md, and related-skill routing provide useful progressive disclosure, dependencies, workflows, error handling, limitations, and boundaries. However, BENCHMARK.md reports missing recommended Instructions, Examples, and Author sections; SKILLCARD version, signature, and scan fields remain TBD; and changelog and maintenance ownership are not sufficiently explicit, so points are deducted.
The material can guide the core publisher selection, schema-before-emit lifecycle, capability discovery, and AGAIN handling, and it includes an end-to-end testing loop. It does not ship runnable examples or templates, actual code modification is deferred to a future renderer, and key outcomes depend on the user's local installation and receiver. Thus the core value is plausible but direct usability is limited.
The files provide traceable symbols, commands, error mappings, evaluation summaries, and references to official documentation, giving some auditability. However, the evaluation dataset is unavailable, the report is not independent third-party execution evidence, and this review executed nothing. Evidence coverage is therefore thin and the score is deducted.
- License, path, and provenance metadata are inconsistent and should be reconciled before publication.
- Do not treat the PASS verdict or benchmark percentages as independent validation here; the report states that the evaluation dataset was unavailable.
- Core behavior depends on the installed DOCA version, hardware, receiver, and external documentation; verify local headers, pkg-config output, and receiver permissions before use.
- No evidence establishes mainland-China reachability or Chinese-language interaction quality; this requires separate validation for FollowSkills users.
What does this skill do, and when should you use it?
This skill is for external developers whose DOCA applications publish counters, gauges, or events through DOCA Telemetry Exporter. It covers schema and source design, type selection, capability discovery, schema registration, and exporter-specific failure diagnosis. Its workflows cover configuring, building, modifying, running, testing, and debugging an application. The scope is the publisher side, not the DOCA Telemetry Service receiver.
The skill reads the local DOCA installation under /opt/mellanox/doca and checks the doca-telemetry-exporter pkg-config module. It guides users through the installed C API and shipped samples to define schemas, create sources, select counter/gauge/event types, query supported limits, register schemas before the first emit, and follow configure, build, modify, run, test, and debug workflows. It also explains DOCA_ERROR_AGAIN and DOCA_ERROR_NOT_FOUND, per-emit status, permissions, transport behavior, and consumer reachability.
- A DOCA Flow developer wants to publish a packets-processed counter to a downstream collector and needs to choose between the exporter and Telemetry Service.
- A C or C++ developer is emitting a first structured event and needs the correct schema, source, and registration order.
- A high-rate emit loop begins returning DOCA_ERROR_AGAIN and the developer needs a non-blocking response.
- An application reports successful emits but the collector receives nothing and the developer needs an end-to-end troubleshooting path.
- A developer needs to check whether the installed DOCA version supports a gauge or particular schema and event-size limits.
- A Rust, Go, or Python developer is wrapping the exporter C ABI and needs language-neutral lifecycle, permission, and error rules.
What are this skill's strengths and limitations?
- Covers the publisher lifecycle from schema and source design through testing and diagnosis.
- Highlights important operational rules: register schemas before emitting, start the consumer first, and avoid blocking the data path on telemetry.
- Applies to C/C++ and to other languages using FFI or bindings over the C ABI.
- Includes a method for checking capabilities and version compatibility against the local DOCA installation.
- Requires the DOCA SDK at the standard path and a Linux host with a BlueField DPU or ConnectX NIC.
- Does not provide a telemetry consumer, collector, receiving service, or prewritten application source.
- The supplied SKILL.md refers to TASKS.md and CAPABILITIES.md but does not include their detailed contents in the source provided here.
- The source provides no standalone test suite, performance measurements, or platform test matrix.
How do you install this skill?
Install the named skill from the NVIDIA/skills repository with the documented skills CLI command: npx skills add nvidia/skills --skill doca-telemetry-exporter --yes. The README does not specify a fixed destination; the CLI prompts for the skill and installation target. The host must separately have the DOCA SDK installed and meet the documented Linux, BlueField DPU, or ConnectX NIC prerequisites.
How do you use this skill?
On a host with DOCA installed, give the agent a concrete exporter task such as: “Publish a packets_processed counter from my DOCA Flow application and verify schema registration and emit behavior.” For configure, build, modify, run, test, or debug work, load TASKS.md; for capabilities and error semantics, load CAPABILITIES.md. Route missing-DOCA setup to doca-setup, receiver-side work to the relevant public documentation path, and in-application event subscription to doca-comch.
How does this skill compare with similar options?
Unlike the DOCA Telemetry Service, this skill addresses the application publisher, while the service is the receiver. Use doca_log when stdout or structured-log shipping is sufficient, a Prometheus client library for a non-DOCA-aware scrape sink, and doca-comch when the application needs real-time event subscription back into itself.