Generated banner for Nemo Relay Plugin Observability
Generated logo for Nemo Relay Plugin Observability

Nemo Relay Plugin Observability

NVIDIAOfficialCreated by NVIDIA Corporation and Affiliates

  • Skill
  • Tool integration
  • Cloud and DevOps
  • Apache-2.0
  • Medium risk

From the author

Use this skill when choosing or configuring NeMo Relay 0.6 or 0.7 observability through the built-in plugin, subscribers, or exporters, including raw ATOF events, ATIF trajectories, OpenTelemetry, OpenInference, or custom event handling.
— the description by NVIDIA Corporation and Affiliates

AutoGineer summary

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

This skill provides guidance on configuring observability for NeMo Relay 0.6 and 0.7. It covers the setup of built-in plugins, subscribers, and exporters to capture the canonical event stream. Users can choose between raw ATOF JSONL events for debugging, ATIF trajectories for execution analysis, or OTLP-based tracing via OpenTelemetry and OpenInference. The skill details the lifecycle management of these components, including registration, flushing, and shutdown procedures, while emphasizing version-specific configuration requirements.

What it does

  • Configures built-in observability plugins for NeMo Relay 0.6 and 0.7.
  • Supports raw ATOF event export for local debugging and offline inspection.
  • Enables ATIF trajectory generation for structured execution analysis.
  • Integrates OpenTelemetry and OpenInference for OTLP tracing.
  • Manages subscriber and exporter lifecycles for custom event handling.
  • Provides version-specific guidance for observability configuration schemas.

When to use it

  • When you need to monitor or debug the execution flow of a NeMo Relay application.
  • When you need to export execution traces to external observability platforms.
  • When you are setting up local logging for raw lifecycle events.
  • When you need to capture structured agent trajectories for evaluation.
  • When you need to configure custom telemetry sinks for specific process requirements.

Advantages

  • Standardized approach to event capture across different Relay versions.
  • Flexible output options ranging from raw logs to structured traces.
  • Supports both plugin-managed and manual API-driven observability.
  • Ensures consistent event stream handling for logging, analytics, and diagnostics.

Usage examples

“How do I configure ATOF event logging for NeMo Relay 0.7?”
The agent will provide the TOML configuration structure using version 3 observability settings, specifying the file or stream sinks required for ATOF output.
“Show me how to register an AtifExporter in Python.”
The agent will provide a code snippet demonstrating the creation, registration, and lifecycle management of an AtifExporter for capturing execution trajectories.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/nvidia/nemo-relay-plugin-observability/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip nemo-relay-plugin-observability.zip -d .agents/skills

Documentation by NVIDIA Corporation and Affiliates

Configure 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 / OpenTelemetrySubscriber and OpenInferenceConfig / OpenInferenceSubscriber.

  • 0.7 uses observability configuration version 3. One typed OpenTelemetry exporter provides full, gen_ai, and openinference projections.

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, or openinference). Read references/opentelemetry.md and, 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 compaction mark 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.

  • Event fields include semantic input/output through the ATOF data field, typed profile data such as model_name and tool_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.md automatically emit skill.load marks under the tool span. The payload contains only skill_name; metadata records the load source and tool name. Partial reads do not count, and ambiguous slash-command expansions use the separate skill.load.inferred name. The eager mark remains present if tool execution later fails.

Shared Lifecycle

  1. Create the exporter or subscriber.

  2. Register it with a unique name before the relevant scoped work.

  3. Run NeMo Relay-instrumented work inside scopes.

  4. Flush and deregister in the exporter-specific reference's documented order.

  5. 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, and OpenInferenceSubscriber

  • Python 0.7: the same registration and file exporters, plus OpenTelemetrySubscriber for all three typed projections

  • Node.js follows the same 0.6/0.7 split through its root exports

  • Rust: nemo_relay::api::subscriber and nemo_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.md for raw JSONL events used in local debugging or offline inspection.

  • Load references/atif.md for ATIF trajectories.

  • Load references/opentelemetry.md for OTLP/OpenTelemetry traces.

  • Load references/openinference.md for the standalone 0.6 OpenInference exporter or the 0.7 openinference OpenTelemetry projection.

Use Another Skill When

Choose another skill when the task belongs to an adjacent workflow:

  • Use nemo-relay-plugin-build to package subscriber-based export behavior as a reusable plugin.

  • Use nemo-relay-get-started or nemo-relay-instrument-calls when no scope, tool call, or LLM call has been instrumented.

  • Use nemo-relay-debug-runtime-integration to diagnose missing telemetry.

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.

Files

references/opentelemetry.md

<!-- SPDX-FileCopyrightText: Copyright (c) 2026, NVIDIA CORPORATION & AFFILIATES. All rights reserved. SPDX-License-Identifier: Apache-2.0 -->

Export OpenTelemetry Traces

Use this reference when the destination is an OTLP/OpenTelemetry backend such as an OpenTelemetry Collector, Jaeger, Tempo, or Honeycomb.

Default Path

  • Confirm the installed NeMo Relay version before selecting configuration.

  • For 0.6, build OpenTelemetryConfig with an endpoint. OpenInference uses its separate exporter described in openinference.md.

  • For 0.7, build OpenTelemetryConfig with a required projection type (full, gen_ai, or openinference) and endpoint.

  • Set service identity; add authentication only when the collector requires it

  • Construct the subscriber

  • Register it before running scoped work

  • Deregister, flush, and shut down when the process or subsystem is done

Embedded OpenTelemetry Semantics

  • In 0.6, the Observability plugin uses configuration version 2, OpenTelemetrySubscriber is separate from OpenInferenceSubscriber, attribute_mappings can alias projected attributes, and native gRPC requires an active Tokio runtime.

  • In 0.7, the plugin uses configuration version 3. Each configured endpoint creates an OpenTelemetrySubscriber for exactly one typed projection: full, gen_ai, or openinference.

  • OpenTelemetry export maps NeMo Relay runtime events into OTLP traces for tracing backends and collectors.

  • Set transport, endpoint, and service_name, then add a namespace, version, instrumentation scope, headers, resource attributes, or timeout when needed.

  • NeMo Relay projects start, end, handle, and mark payload fields to typed OTLP attributes with dotted names. Start and end metadata use nemo_relay.start.metadata and nemo_relay.end.metadata.

  • NeMo Relay emits a top-level object or array field as a JSON string, omits a top-level null field, and no longer emits the old aggregate *_json payload attributes.

  • In 0.7, mark_projection, mark_exclude_names, and attribute_mappings apply to full and openinference endpoints. The gen_ai endpoint ignores those controls. semantic_selector and capture_content are unsupported.

  • In 0.6, attribute_mappings remains available on the separate exporters.

  • The gen_ai projection emits no nemo_relay.* fields and omits messages, tool payloads, retrieval content, marks, rerankers, and unsupported scopes.

  • Although gen_ai does not emit guardrail or reranker spans, it retains their parent context so supported descendant spans preserve their trace parentage.

  • The gen_ai projection follows the pinned OpenTelemetry GenAI semantic-conventions v1.42-era snapshot at commit 43633a68ef8f8ed87a1d5eb205990311ca708bf1.

  • NeMo Relay deterministically derives compliant trace and span IDs from Relay lifecycle UUIDs. Endpoints that receive the same events therefore share native IDs and parentage.

  • Start with http_binary transport and an OTLP traces endpoint such as a local collector on port 4318 unless deployment requirements differ.

  • In 0.7, the subscriber owns the Tokio runtime needed by grpc, including for synchronous direct construction. In 0.6, use grpc only with an active Tokio runtime.

  • Use explicit config objects for non-secret application behavior. In 0.7 plugin configuration, map authentication header names to secret-bearing environment variables with opentelemetry.endpoints[].header_env; Relay snapshots those values when the plugin activates. In 0.6, construct headers in memory from the deployment's secret injection and pass them to the exporter. Never place resolved credential values in source code, committed configuration, command-line arguments, prompts, examples, or diagnostics.

  • Prefer an unauthenticated loopback collector for the first local proof. For a remote collector, require TLS certificate verification and reject endpoints that embed credentials in URL user information or query parameters.

  • Register before the first instrumented request, use stable service identity, flush during graceful shutdown, and redact sensitive payloads before production export.

  • Validate export by checking subscriber construction, collector requests, backend spans for synthetic scopes/tools/LLMs, and span grouping by root scope. Report header names and response status only; never print header values.

Things To Confirm

  • Transport: http_binary vs grpc

  • Endpoint, TLS verification, and required authentication header names

  • Service naming and resource attributes

  • Whether deterministic flush-before-exit is required

  • Whether the chosen binding and target support the desired transport

Troubleshooting Focus

  • No spans visible

  • Wrong endpoint or authentication: inspect response status and redacted header names without logging credential values

  • Events emitted outside active scopes

  • For 0.6, grpc selected without an active Tokio runtime; for 0.7, gRPC endpoint, TLS, or authentication mismatch

  • Forgetting register/deregister or flush/shutdown steps

  • nemo-relay-plugin-observability

  • nemo-relay-debug-runtime-integration

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.

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 Corporation and Affiliates
Publisher
NVIDIA (Official)
Source
NVIDIA/skills · skills/nemo-relay-plugin-observability · commit fce3cca
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE-APACHE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by NVIDIA Corporation and Affiliates or NVIDIA.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download nemo-relay-plugin-observability.zip