Skip to main content
Nous vous recommandons d’utiliser le nouveau flux de travail natif OTel de Weave pour envoyer des spans OTel vers la nouvelle vue Agents de Weave. N’utilisez ce guide que si vous souhaitez ingérer des traces OTLP brutes dans la vue Traces standard de Weave.
Weave prend en charge l’importation de données de trace compatibles OpenTelemetry via un point de terminaison dédié. Ce point de terminaison vous permet d’envoyer des données de trace au format OTLP (OpenTelemetry Protocol) directement vers votre projet Weave. Utilisez cette intégration si vous souhaitez instrumenter votre application selon la norme OpenTelemetry et afficher ces traces aux côtés de vos autres données Weave, sans remplacer votre pipeline d’observabilité existant basé sur OTel. Cette page présente les détails du point de terminaison, l’authentification, des exemples complets en Python et en TypeScript, la manière de transférer des traces via un OpenTelemetry Collector, l’organisation des traces en threads Weave, ainsi que les mappages d’attributs que Weave applique aux spans entrants.
Ce point de terminaison alimente les vues Traces et Threads. Pour envoyer des spans OTel d’un agent sur plusieurs tours de conversation vers la vue Agents, utilisez plutôt le point de terminaison des agents. Voir Envoyer des spans OpenTelemetry vers la vue Agents.

Détails du point de terminaison

  • Chemin : /otel/v1/traces
  • Méthode : POST
  • Content-Type : application/x-protobuf
  • URL de base : l’URL de base du point de terminaison OTel pour les traces dépend de votre type de déploiement W&B :
  • Cloud mutualisé : https://trace.wandb.ai/otel/v1/traces.
  • Instances Cloud dédié et instances autogérées : https://<your-subdomain>.wandb.io/traces/otel/v1/traces.
Remplacez <your-subdomain> par le domaine W&B propre à votre organisation, par exemple acme.wandb.io.

Authentification et acheminement

Weave utilise l’en-tête wandb-api-key pour authentifier les requêtes, et les attributs de ressource de votre TracerProvider pour acheminer les spans vers l’entity et le projet appropriés. Transmettez votre clé API W&B dans l’en-tête wandb-api-key, puis spécifiez les clés suivantes comme attributs Resource OpenTelemetry dans votre classe TracerProvider :
  • wandb.entity : le nom de votre équipe ou de votre utilisateur CoreWeave Forge.
  • wandb.project : le nom du projet auquel envoyer les traces.
L’exemple suivant montre comment configurer l’authentification et l’acheminement vers le projet :
WEAVE_OTLP_ENDPOINT ci-dessous est une variable locale, et non la variable d’environnement OTEL_EXPORTER_OTLP_ENDPOINT du SDK OTel. Elle contient le chemin complet des traces (.../otel/v1/traces) et est transmise explicitement à endpoint=/url: sur l’exportateur, si bien que le SDK envoie les requêtes à cette URL telle quelle. Si vous définissez plutôt une valeur avec export dans la véritable variable OTEL_EXPORTER_OTLP_ENDPOINT et que vous construisez l’exportateur sans arguments (par exemple, OTLPSpanExporter()), le SDK ajoute lui-même /v1/traces. Cette variable doit alors contenir l’URL de base (.../otel), faute de quoi vous obtiendrez un chemin dupliqué (.../otel/v1/traces/v1/traces), une erreur 404 et des spans silencieusement ignorés. Il en va de même pour OTEL_EXPORTER_OTLP_TRACES_ENDPOINT : elle doit elle aussi contenir le chemin complet des traces, car le SDK n’y ajoute pas non plus /v1/traces.

Exemples

Les exemples suivants montrent comment envoyer des traces OpenTelemetry vers Weave avec Python et TypeScript. Chaque exemple illustre une approche différente : la bibliothèque d’instrumentation OpenInference, l’instrumentation OpenLLMetry, ou le SDK OpenTelemetry utilisé directement, sans package d’instrumentation. Avant d’exécuter les exemples de code ci-dessous, définissez les champs suivants :
  • WANDB_API_KEY : vous pouvez l’obtenir dans les Paramètres utilisateur.
  • Entity : vous ne pouvez journaliser des traces que dans un projet appartenant à une équipe/entity à laquelle vous avez accès. Pour trouver le nom de votre entity, accédez à votre tableau de bord W&B et consultez le champ Teams dans la barre latérale gauche.
  • Nom du projet : choisissez un nom.
  • OPENAI_API_KEY : vous pouvez l’obtenir depuis le tableau de bord OpenAI.

Instrumentation OpenInference

OpenInference est une bibliothèque d’instrumentation open source d’Arize AI qui capture les appels LLM sous forme de spans OpenTelemetry. Cet exemple montre comment utiliser l’instrumentation OpenAI. D’autres instrumentations sont disponibles dans le dépôt officiel. Commencez par installer les dépendances requises :
Recommandation relative aux performances : utilisez toujours BatchSpanProcessor plutôt que SimpleSpanProcessor lorsque vous envoyez des traces vers Weave. SimpleSpanProcessor exporte les spans de manière synchrone, ce qui peut nuire aux performances des autres charges de travail. Ces exemples utilisent BatchSpanProcessor, recommandé en production, car il regroupe les spans en lots de manière asynchrone et efficace.
Collez le code suivant dans un fichier Python, par exemple openinference_example.py :
Exécutez le code :

Instrumentation OpenLLMetry

OpenLLMetry est une bibliothèque d’observabilité open source de Traceloop qui fournit une instrumentation OpenTelemetry pour les fournisseurs de LLM et les frameworks les plus répandus. L’exemple suivant montre comment utiliser son instrumentation OpenAI. D’autres exemples sont disponibles dans le dépôt OpenLLMetry. Commencez par installer les dépendances requises :
Collez le code suivant dans un fichier Python, par exemple openllmetry_example.py. Ce code est identique à celui de l’exemple précédent, à ceci près que OpenAIInstrumentor est importé depuis opentelemetry.instrumentation.openai au lieu de openinference.instrumentation.openai :
Exécutez le code :

Sans instrumentation

Si vous préférez utiliser OTel directement plutôt qu’un package d’instrumentation, c’est possible. Cette approche vous donne un contrôle complet sur les attributs définis pour chaque span. Weave analyse les attributs de span conformément aux conventions sémantiques OpenTelemetry décrites à l’adresse https://opentelemetry.io/docs/specs/semconv/gen-ai/gen-ai-spans/. Commencez par installer les dépendances requises :
Collez le code suivant dans un fichier Python, par exemple opentelemetry_example.py :
Exécutez le code :
Weave utilise les préfixes d’attributs de span gen_ai et openinference pour déterminer quelle convention appliquer, le cas échéant, lors de l’interprétation de la trace. Si aucune de ces clés n’est détectée, tous les attributs de span sont visibles dans la vue de trace. Le span complet est disponible dans le panneau latéral lorsque vous sélectionnez une trace.

Utiliser un OpenTelemetry Collector

Les exemples précédents exportent les traces directement depuis votre application vers Weave. En production, vous pouvez placer un OpenTelemetry Collector entre votre application et Weave, en tant qu’intermédiaire. Le collecteur reçoit les traces de votre application, puis les transmet à un ou plusieurs backends. Ce modèle permet de centraliser la logique d’authentification, de traitement par lots et d’acheminement hors du code de votre application, et de répartir les traces vers plusieurs backends d’observabilité à partir d’un pipeline unique.

Configurer un collecteur

Cette section explique comment exécuter un OpenTelemetry Collector local dans Docker et configurer une application pour qu’elle lui envoie des traces. L’exemple suivant montre comment :
  • Créer un fichier de configuration Docker qui déploie un serveur local (collecteur) chargé d’écouter les traces OTLP, de les regrouper par lots et de les transmettre vers Weave.
  • Exécuter le collecteur localement avec Docker.
  • Envoyer un appel de base à OpenAI qui transmet les traces au collecteur exécuté dans le conteneur Docker.
Pour utiliser un collecteur, créez d’abord un fichier collector-config.yaml qui configure le collecteur pour recevoir les traces OTLP et les exporter vers Weave :
collector-config.yaml
Ce fichier de configuration :
  • Écoute les traces OTLP sur le port 4318 (HTTP).
  • Exporte les traces vers le point de terminaison OTLP de Weave à l’aide de l’en-tête wandb-api-key, en lisant l’URL du point de terminaison dans WANDB_OTLP_ENDPOINT et la clé API dans WANDB_API_KEY.
  • Définit wandb.entity et wandb.project comme attributs de ressource à l’aide du processeur resource, en lisant les valeurs dans DEFAULT_WANDB_ENTITY et DEFAULT_WANDB_PROJECT. L’action insert n’injecte ces attributs que si le code de votre application ne les définit pas déjà.
  • Active la file d’attente intégrée sending_queue de l’exportateur, avec traitement par lots, afin de réduire la surcharge réseau.
Après avoir configuré les paramètres du collecteur, mettez à jour les valeurs de la clé API et de l’entity dans la commande Docker suivante, puis exécutez-la :
Une fois le collecteur démarré, configurez votre application pour qu’elle y exporte ses traces en définissant la variable d’environnement OTEL_EXPORTER_OTLP_ENDPOINT. Le SDK OTel lit automatiquement cette variable : vous n’avez donc pas besoin de transmettre le point de terminaison à l’exportateur. Si vous définissez wandb.entity ou wandb.project comme attributs de ressource dans le TracerProvider de votre application, ils priment sur les valeurs par défaut définies dans la configuration du collecteur.
OpenAIInstrumentor encapsule les appels OpenAI, crée des traces et les exporte vers le collecteur. Celui-ci se charge de l’authentification et de l’acheminement vers Weave. Une fois le script exécuté, vous pouvez afficher les traces dans l’interface de Weights & Biases. Pour envoyer les traces vers d’autres backends, ajoutez des exportateurs et incluez-les dans la liste service.pipelines.traces.exporters. Vous pouvez par exemple exporter à la fois vers Weave et vers Jaeger à partir d’une même instance du collecteur.

Organiser les traces OTel en threads

Les threads Weave vous permettent de regrouper des traces liées afin d’analyser des conversations sur plusieurs tours de conversation ou des sessions utilisateur comme un tout. Ajoutez des attributs de span spécifiques pour organiser vos traces OpenTelemetry en threads, puis utilisez l’interface Thread de Weave pour analyser des opérations liées, comme des conversations sur plusieurs tours de conversation ou des sessions utilisateur. Ajoutez les attributs suivants à vos spans OTel pour activer le regroupement en threads :
  • wandb.thread_id : regroupe les spans dans un thread donné.
  • wandb.is_turn : marque un span comme un tour de conversation (il apparaît sous forme de ligne dans la vue du thread).
Les exemples suivants montrent comment organiser des traces OTel en threads Weave. Ils utilisent wandb.thread_id pour regrouper les opérations liées et wandb.is_turn pour marquer les opérations de haut niveau, qui apparaissent sous forme de lignes dans la vue du thread.
Utilisez cette configuration pour exécuter ces exemples :
Une fois ces traces envoyées, vous pouvez les consulter dans l’interface de Weights & Biases, sous l’onglet Threads, où elles sont regroupées par thread_id et où chaque tour de conversation apparaît sur une ligne distincte.

Mappages d’attributs

Weave mappe les attributs de span OpenTelemetry issus de divers frameworks d’instrumentation vers son modèle de données interne. Grâce à ce mappage, vous n’avez pas besoin de renommer ni de transformer les attributs de votre instrumentation existante pour bénéficier d’une vue détaillée dans Weave. Lorsque plusieurs noms d’attributs correspondent au même champ, Weave les applique par ordre de priorité, ce qui permet à plusieurs frameworks de coexister au sein des mêmes traces.

Frameworks pris en charge

Weave prend en charge les conventions d’attributs des frameworks et SDK d’observabilité suivants :
  • OpenTelemetry GenAI : conventions sémantiques standard pour l’IA générative (gen_ai.*).
  • OpenInference : bibliothèque d’instrumentation d’Arize AI (input.value, output.value, llm.*, openinference.*).
  • Vercel AI SDK : attributs de l’AI SDK de Vercel (ai.prompt, ai.response, ai.model.*, ai.usage.*).
  • MLflow : attributs de suivi MLflow (mlflow.spanInputs, mlflow.spanOutputs).
  • Traceloop : instrumentation OpenLLMetry (traceloop.entity.*, traceloop.span.kind).
  • Google Vertex AI : attributs d’agent Vertex AI (gcp.vertex.agent.*).
  • OpenLit : attributs d’observabilité OpenLit (gen_ai.content.completion).
  • Logfire / Pydantic AI : instrumentation Pydantic AI de Logfire (gen_ai.input.messages, gen_ai.output.messages, pydantic_ai.all_messages, final_result).
  • Langfuse : attributs de traçage Langfuse (langfuse.startTime, langfuse.endTime).

Référence des attributs

Limitations

L’interface utilisateur de Weights & Biases ne prend pas en charge le rendu des appels d’outil des traces OTel dans la vue Chat. Ceux-ci s’affichent à la place sous forme de JSON brut.
Dernière modification le 30 septembre 2026