
Nemo Relay Plugin Observability
OfficialFreeConfigure observability for NeMo Relay easily.
Free · Opens the source repo
What Nemo Relay Plugin Observability does
The Nemo Relay Plugin Observability skill is designed to assist users in configuring observability for NeMo Relay versions 0.6 and 0.7. It provides a structured approach to setting up observability through built-in plugins, subscribers, and exporters. Users can select from various output options, including raw ATOF events, ATIF trajectories, and OpenTelemetry, allowing for tailored telemetry that meets their specific needs. This skill is particularly useful for developers and data scientists who require visibility into the activities captured by NeMo Relay.
To get started, users are guided to select a single exporter managed by the built-in Observability plugin, which is recommended as the best first step for most applications. The skill emphasizes the importance of choosing the appropriate Relay version and output type based on the user's immediate inspection target. It also details how to utilize manual subscriber or exporter APIs when more control over event registration and collection is needed.
The skill includes a comprehensive framework for managing event streams, allowing multiple subscribers to observe the same stream for various purposes such as logging and diagnostics. It outlines a shared lifecycle for creating and managing exporters and subscribers, ensuring that users can effectively capture and export events within their processes. This structured approach is beneficial for those looking to implement observability in their machine learning workflows.
Overall, this skill serves as a practical resource for configuring observability in NeMo Relay applications, making it an essential tool for developers and data scientists focused on monitoring and improving their machine learning models' performance.
When to use it
Use this skill when setting up observability for NeMo Relay applications, particularly when needing to capture and analyze event data.
When not to use it
This skill may not be suitable for users who do not work with NeMo Relay or those seeking observability solutions outside the specified versions.
What you can build with it
Setting Up Basic Observability
Quickly configure a single exporter using the built-in Observability plugin to monitor NeMo Relay activities.
Debugging with ATOF Events
Use ATOF JSONL output for local debugging and offline inspection of event streams.
Implementing OpenTelemetry Tracing
Select the appropriate OpenTelemetry exporter to integrate tracing into your NeMo Relay application.
How to install Nemo Relay Plugin Observability
View source1. Install with the skills CLI
npx skills add nvidia/skills/nemo-relay-plugin-observability --agent claude-code2. Or install it manually
Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.
Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs
Inside SKILL.md
Written by nvidiaConfigure Observability Plugins
Start with one exporter managed by the built-in Observability plugin. This is the default for reusable process configuration and the best first plugin for most users because it makes Relay's captured activity visible. Choose one proof output before layering additional telemetry destinations.
Use manual subscriber or exporter APIs only when a test, script, or application needs direct control over registration names, collection windows, or flush timing. Both paths consume the same canonical event stream.
Select The Relay Version
Determine whether the application uses NeMo Relay 0.6 or 0.7 before proposing configuration or binding APIs. Prefer the installed package version, lockfile, or manifest. Ask the user when the version cannot be established; do not mix the two surfaces in one example.
- 0.6 uses observability configuration version 2. OpenTelemetry and
OpenInference are separate exporters with
OpenTelemetryConfig/OpenTelemetrySubscriberandOpenInferenceConfig/OpenInferenceSubscriber. - 0.7 uses observability configuration version 3. One typed OpenTelemetry
exporter provides
full,gen_ai, andopeninferenceprojections.
Choose The Output
Select the output that best matches the user's immediate inspection target:
- Console or custom event handling Use a manual subscriber for short-lived in-process inspection.
- Raw canonical lifecycle events
Use ATOF JSONL; read
references/atof.md. - Portable execution trajectories
Use ATIF; read
references/atif.md. - OTLP tracing
For 0.6, choose the separate OpenTelemetry or OpenInference exporter. For
0.7, choose a typed OpenTelemetry endpoint (
full,gen_ai, oropeninference). Readreferences/opentelemetry.mdand, for an OpenInference-aware backend,references/openinference.md.
Choose one output first and verify it before adding another. ATOF is the default local proof because it preserves the raw event stream with the least translation. Use synthetic, non-sensitive payloads for the first proof. Add and verify sanitization before exporters receive production payloads, and never display complete event records while validating an exporter.
Embedded Event And Subscriber Model
Use this model when explaining how capture and export relate:
- NeMo Relay emits one canonical event stream from scopes, marks, managed tool calls, managed LLM calls, middleware, and manual lifecycle APIs.
- Subscribers consume events without defining the event model. Multiple subscribers can observe the same stream for logging, export, analytics, or diagnostics.
- Global subscribers remain active process-wide until removed.
- Scope-local subscribers are owned by one active scope and disappear when that scope closes.
- Plugin-installed subscribers are reusable, configuration-driven runtime components.
- Exporter-oriented subscribers preserve raw ATOF or translate the event stream into ATIF or the version-appropriate OpenTelemetry/OpenInference form.
- Event payloads reflect sanitized post-guardrail input and output when calls use managed helpers or manual lifecycle params provide those fields.
- LLM annotations follow the freshness rules:
- Each owning agent scope starts fresh, and a
compactionmark refreshes it. - The first subsequent LLM start retains complete annotation history. Later starts retain system instructions, the latest user message, and every following assistant or tool message.
- When a request codec supplies an annotation, Relay applies the same event-only projection to provider-shaped event input without changing provider execution.
- Each owning agent scope starts fresh, and a
- Event fields include semantic input/output through the ATOF
datafield, typed profile data such asmodel_nameandtool_call_id, and codec-provided annotated LLM request/response data for in-process subscribers and exporters. - First-class skill tools and the requests to read a complete
SKILL.mdautomatically emitskill.loadmarks under the tool span. The payload contains onlyskill_name; metadata records the load source and tool name. Partial reads do not count, and ambiguous slash-command expansions use the separateskill.load.inferredname. The eager mark remains present if tool execution later fails.
Shared Lifecycle
- Create the exporter or subscriber.
- Register it with a unique name before the relevant scoped work.
- Run NeMo Relay-instrumented work inside scopes.
- Flush and deregister in the exporter-specific reference's documented order.
- Shut it down when the process or subsystem is done.
Binding Names
Use the names exported by the selected language binding and Relay version:
- Python 0.6:
nemo_relay.subscribers.register(...),AtofExporter,AtifExporter,OpenTelemetrySubscriber, andOpenInferenceSubscriber - Python 0.7: the same registration and file exporters, plus
OpenTelemetrySubscriberfor all three typed projections - Node.js follows the same 0.6/0.7 split through its root exports
- Rust:
nemo_relay::api::subscriberandnemo_relay::observability::* - Go: source-first wrappers expose equivalent register, exporter, and subscriber lifecycle methods
Load A Reference When
Load only the reference required by the selected output:
- Load
references/atof.mdfor raw JSONL events used in local debugging or offline inspection. - Load
references/atif.mdfor ATIF trajectories. - Load
references/opentelemetry.mdfor OTLP/OpenTelemetry traces. - Load
references/openinference.mdfor the standalone 0.6 OpenInference exporter or the 0.7openinferenceOpenTelemetry projection.
Use Another Skill When
Choose another skill when the task belongs to an adjacent workflow:
- Use
nemo-relay-plugin-buildto package subscriber-based export behavior as a reusable plugin. - Use
nemo-relay-get-startedornemo-relay-instrument-callswhen no scope, tool call, or LLM call has been instrumented. - Use
nemo-relay-debug-runtime-integrationto diagnose missing telemetry.
Related Skills
Use these skills for adjacent workflows:
- Instrument application calls with
nemo-relay-instrument-calls. - Add typed wrappers with
nemo-relay-instrument-typed-wrappers. - Package reusable behavior with
nemo-relay-plugin-build. - Diagnose missing events with
nemo-relay-debug-runtime-integration.
Frequently asked questions about Nemo Relay Plugin Observability
Similar skills
Turborepo
Optimized build system for JavaScript/TypeScript monorepos.
Azure Pipelines Validation
Streamline your Azure DevOps pipeline changes locally.
Azure Developer CLI
Streamline your Azure project workflows with best practices.
Azure Container Registry CLI
Manage Azure Container Registry resources with ease.
Aspire
Build and orchestrate polyglot distributed applications seamlessly.
Vercel CLI
Manage and deploy Vercel projects from the command line.
