Configurer les plugins d'observabilité

Commencez par un exporteur géré par le plugin d'observabilité intégré. C'est la valeur par défaut pour la configuration de processus réutilisables et le meilleur premier plugin pour la plupart des utilisateurs, car il rend visible l'activité capturée par Relay. Choisissez une sortie de preuve avant d'ajouter des destinations de télémétrie supplémentaires.

Utilisez les API manuelles de subscriber ou d'exporteur uniquement quand un test, un script ou une application a besoin d'un contrôle direct sur les noms d'enregistrement, les fenêtres de collecte ou le timing du flush. Les deux chemins consomment le même flux d'événements canonique.

Choisir la sortie

Sélectionnez la sortie qui correspond le mieux à la cible d'inspection immédiate de l'utilisateur :

Console ou traitement d'événements personnalisé Utilisez un subscriber manuel pour l'inspection intra-processus de courte durée.
Événements de cycle de vie canoniques bruts Utilisez ATOF JSONL ; consultez references/atof.md.
Trajectoires d'exécution portables Utilisez ATIF ; consultez references/atif.md.
Traçage OTLP général Utilisez OpenTelemetry ; consultez references/opentelemetry.md.
Backends compatibles OpenInference Utilisez OpenInference ; consultez references/openinference.md.

Choisissez d'abord une sortie et vérifiez-la avant d'en ajouter une autre. ATOF est la preuve locale par défaut car elle préserve le flux d'événements brut avec la moins de traduction. Utilisez des payloads synthétiques et non sensibles pour la première preuve. Ajoutez et vérifiez l'assainissement avant que les exporteurs ne reçoivent des payloads de production, et n'affichez jamais les enregistrements d'événements complets lors de la validation d'un exporteur.

Modèle d'événement intégré et de subscriber

Utilisez ce modèle pour expliquer comment la capture et l'export se rapportent :

NeMo Relay émet un flux d'événements canonique unique à partir de scopes, de marks, d'appels d'outils gérés, d'appels LLM gérés, de middleware et d'API de cycle de vie manuelles.
Les subscribers consomment les événements sans définir le modèle d'événement. Plusieurs subscribers peuvent observer le même flux pour la journalisation, l'export, l'analytique ou les diagnostics.
Les subscribers globaux restent actifs à l'échelle du processus jusqu'à leur suppression.
Les subscribers locaux à la scope sont possédés par une scope active et disparaissent quand cette scope se ferme.
Les subscribers installés par plugin sont des composants runtime réutilisables, pilotés par la configuration.
Les subscribers orientés exporteur préservent le brut ATOF ou traduisent le flux d'événements en sortie ATIF, OpenTelemetry ou OpenInference.
Les payloads d'événements reflètent l'entrée et la sortie assainies après guardrail quand les appels utilisent des helpers gérés ou que les params de cycle de vie manuels fournissent ces champs.
Les annotations LLM suivent les règles de fraîcheur :
- Chaque scope d'agent propriétaire recommence zéro, et un mark compaction la rafraîchit.
- Le premier démarrage LLM suivant conserve l'historique d'annotation complet. Les démarrages ultérieurs conservent les instructions système, le dernier message utilisateur et chaque message assistant ou outil suivant.
- Quand un codec de requête fournit une annotation, Relay applique la même projection d'événement uniquement à l'entrée d'événement de forme provider sans modifier l'exécution provider.
Les champs d'événement incluent l'entrée/sortie sémantique via le champ ATOF data, les données de profil typées comme model_name et tool_call_id, et les données LLM de requête/réponse annotées fournies par le codec pour les subscribers intra-processus et les exporteurs.
Les outils skill de première classe et les requêtes de lecture d'un fichier SKILL.md complet émettent automatiquement des marks skill.load sous la span d'outil. Le payload ne contient que skill_name ; les métadonnées enregistrent la source de chargement et le nom de l'outil. Les lectures partielles ne comptent pas, et les expansions de slash-command ambiguës utilisent le nom séparé skill.load.inferred. Le mark eager reste présent si l'exécution d'outil échoue plus tard.

Cycle de vie partagé

Créez l'exporteur ou le subscriber.
Enregistrez-le avec un nom unique avant le travail scopé pertinent.
Exécutez le travail instrumenté par NeMo Relay à l'intérieur des scopes.
Flush si une livraison déterministe est nécessaire et que la liaison la supporte.
Désenregistrez-le, puis arrêtez-le quand le processus ou le sous-système est terminé.

Noms de liaisons

Utilisez les noms exportés par la liaison de langage sélectionnée :

Python : nemo_relay.subscribers.register(...), AtofExporter, AtifExporter, OpenTelemetrySubscriber, et OpenInferenceSubscriber
Node.js : les exports racine registerSubscriber(...), AtofExporter, AtifExporter, OpenTelemetrySubscriber, et OpenInferenceSubscriber
Rust : nemo_relay::api::subscriber et nemo_relay::observability::*
Go : les wrappers source-first exposent les méthodes de cycle de vie register, exporter et subscriber équivalentes

Charger une référence quand

Chargez uniquement la référence requise par la sortie sélectionnée :

Chargez references/atof.md pour les événements JSONL bruts utilisés dans le débogage local ou l'inspection hors ligne.
Chargez references/atif.md pour les trajectoires ATIF.
Chargez references/opentelemetry.md pour les traces OTLP/OpenTelemetry.
Chargez references/openinference.md pour les traces sémantiques OpenInference.

Utiliser une autre skill quand

Choisissez une autre skill quand la tâche appartient à un workflow adjacent :

Utilisez nemo-relay-plugin-build pour empaqueter le comportement d'export basé sur subscriber comme un plugin réutilisable.
Utilisez nemo-relay-get-started ou nemo-relay-instrument-calls quand aucune scope, appel d'outil ou appel LLM n'a été instrumenté.
Utilisez nemo-relay-debug-runtime-integration pour diagnostiquer la télémétrie manquante.

Skills connexes

Utilisez ces skills pour les workflows adjacents :

Instrumentez les appels d'application avec nemo-relay-instrument-calls.
Ajoutez des wrappers typés avec nemo-relay-instrument-typed-wrappers.
Empaquetez le comportement réutilisable avec nemo-relay-plugin-build.
Diagnostiquez les événements manquants avec nemo-relay-debug-runtime-integration.

nemo-relay-plugin-observability