nemo-relay-plugin-observability

作成者: nvidia

NeMo Relay 0.6または0.7のオブザーバビリティを、組み込みプラグイン、サブスクライバー、またはエクスポーターを通じて選択または設定する際にこのスキルを使用します。生のATOF…を含みます。

npx skills add https://github.com/nvidia/skills --skill nemo-relay-plugin-observability

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.

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.

nvidiaのその他のスキル

compileiq-debug
nvidia
何かがおかしいときに使用:Search()がハングする、すべての評価がINVALID_SCOREを返す、スコアが改善しない、すべての設定が同じ数値を返す、ptxasエラー…
create-github-pr
nvidia
gh CLIを使用してGitHubのプルリクエストを作成します。ユーザーが新しいPRを作成したい、コードをレビューに提出したい、またはプルリクエストを開きたい場合に使用します。トリガーキーワード -…
nemoclaw-maintainer-cross-issue-sweep
nvidia
他のオープンなIssueをスキャンし、特定のPRが修正する可能性があるものや、誤って壊す可能性があるものを見つけます。隣接修正の機会や矛盾リスクをfile:line…と共に出力します。
fhir-basics
nvidia
エージェントにFHIR R4 APIの動作方法、利用可能なリソース、検索パラメータを使ったクエリ方法、およびすべてのレスポンス形式を正しく解析する方法を教えます…
compileiq-validate-result
nvidia
検索が完了した後、かつスピードアップの申請やACFの発送の前に使用します。dump_results CSVを読み込み、トップK候補(単一目的)を抽出します…
changelog-audit
nvidia
リリース前にWarp CHANGELOG.mdを監査:失われたエントリを復元、ユーザー影響で並べ替え、エントリの文言を洗練、行折り返し、および(リリースブランチモードで)比較をバンプ…
maintain-dynamic-plugins
nvidia
NeMo Relayの動的プラグインローダー、マニフェスト、RustネイティブSDK、gRPCワーカープロトコル、PythonワーカーSDK、ドキュメント、テスト、およびリリースワークフローのカバレッジを維持する
dgx-diagnose
nvidia
一般的なDGX Station GB300の問題(CUDAクラッシュ、誤ったGPUターゲット、vLLM/SGLangコンテナのバグ、MIG状態の問題、NVLink/Fabric Managerエラーなど)を診断します。