Passer au contenu principal
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 directement vers votre projet Weave des données de trace au format OTLP (OpenTelemetry Protocol). Utilisez cette intégration si vous souhaitez instrumenter votre application selon le standard OpenTelemetry et faire apparaître 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 TypeScript, comment transférer des traces via un OpenTelemetry Collector, comment organiser les traces en threads Weave, ainsi que les mappages d’attributs que Weave applique aux spans entrants.

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 de trace OTel dépend de votre type de déploiement W&B :
  • Cloud mutualisé : https://trace.wandb.ai/otel/v1/traces.
  • Instances Cloud dédié et Autogéré : https://<your-subdomain>.wandb.io/traces/otel/v1/traces.
Remplacez <your-subdomain> par le domaine W&B unique de 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 définis dans votre TracerProvider pour acheminer les spans vers la bonne entité et le bon projet. Transmettez votre clé API W&B dans l’en-tête wandb-api-key, puis spécifiez les clés suivantes comme attributs de ressource OpenTelemetry dans votre classe TracerProvider :
  • wandb.entity : le nom de votre équipe W&B ou de votre utilisateur.
  • 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 est définie avec le chemin complet des traces (.../otel/v1/traces). Elle est transmise explicitement à endpoint=/url: sur l’exporter, de sorte que le SDK envoie les requêtes vers cette URL telle quelle. Si, à la place, vous export une valeur comme véritable variable OTEL_EXPORTER_OTLP_ENDPOINT et construisez l’exporter sans argument (par exemple, OTLPSpanExporter()), le SDK ajoute lui-même /v1/traces. Dans ce cas, cette variable doit donc contenir l’URL de base (.../otel) à la place, sinon vous obtenez un chemin dupliqué (.../otel/v1/traces/v1/traces), une 404 et des spans ignorés silencieusement. Il en va de même pour OTEL_EXPORTER_OTLP_TRACES_ENDPOINT : elle doit également contenir le chemin complet des traces, puisque le SDK ne lui ajoute pas non plus /v1/traces.

Exemples

Les exemples suivants montrent comment envoyer des traces OpenTelemetry vers Weave à l’aide de Python et de TypeScript. Chaque exemple présente une approche différente : utiliser la bibliothèque d’instrumentation OpenInference, utiliser l’instrumentation OpenLLMetry ou utiliser directement le SDK OpenTelemetry sans package d’instrumentation. Avant d’exécuter les exemples de code suivants, définissez les champs suivants :
  • WANDB_API_KEY : vous pouvez l’obtenir dans les Paramètres utilisateur.
  • Entité : vous pouvez journaliser des traces dans le projet uniquement sous une équipe/entité à laquelle vous avez accès. Pour trouver le nom de votre entité, accédez à votre tableau de bord W&B et vérifiez le champ Teams dans la barre latérale gauche.
  • Nom du projet : choisissez un nom.
  • OPENAI_API_KEY : vous pouvez l’obtenir dans 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. Des instrumentations supplémentaires sont disponibles dans le dépôt officiel. Installez d’abord les dépendances requises :
Recommandation relative aux performances : utilisez toujours BatchSpanProcessor plutôt que SimpleSpanProcessor lors de l’envoi de traces vers Weave. SimpleSpanProcessor exporte les spans de manière synchrone, ce qui peut affecter les performances des autres charges de travail. Ces exemples illustrent BatchSpanProcessor, recommandé en production, car il regroupe les spans de façon 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 courants. L’exemple suivant montre comment utiliser l’instrumentation OpenAI. D’autres exemples sont disponibles dans le dépôt OpenLLMetry. Installez d’abord les dépendances requises :
Collez le code suivant dans un fichier Python, par exemple openllmetry_example.py. Il s’agit du même code que dans l’exemple précédent, sauf 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 sur chaque span. Weave analyse les attributs de span conformément aux conventions sémantiques d’OpenTelemetry décrites à l’adresse https://opentelemetry.io/docs/specs/semconv/gen-ai/gen-ai-spans/. Installez d’abord 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’attribut de span gen_ai et openinference pour déterminer la convention à utiliser, 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 alors visibles dans la vue de trace. Le span complet est disponible dans le panneau latéral lorsque vous sélectionnez une trace.

Utiliser un collecteur OpenTelemetry

Les exemples précédents exportent les traces directement depuis votre application vers Weave. En production, vous pouvez utiliser un OpenTelemetry Collector comme intermédiaire entre votre application et Weave. Le collecteur reçoit les traces de votre application, puis les transmet à un ou plusieurs backends. Cette approche centralise l’authentification, le traitement par lots et la logique d’acheminement en dehors du code de votre application, et vous permet de répartir les traces vers plusieurs backends d’observabilité à partir d’un seul pipeline.

Configurer un collecteur

Cette section explique comment exécuter un OpenTelemetry Collector local dans Docker et configurer une application pour lui envoyer des traces. L’exemple suivant montre comment :
  • Configurer un fichier de configuration pour Docker qui déploie un serveur local (collecteur) à l’écoute des traces OTLP, les regroupe par lots et les achemine vers Weave.
  • Exécuter localement le collecteur avec Docker.
  • Envoyer une requête simple à OpenAI qui transfère 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 des 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 depuis WANDB_OTLP_ENDPOINT et la clé API depuis WANDB_API_KEY.
  • Définit wandb.entity et wandb.project comme attributs de ressource à l’aide du processeur resource, en lisant les valeurs depuis DEFAULT_WANDB_ENTITY et DEFAULT_WANDB_PROJECT. L’action insert injecte ces attributs uniquement si le code de votre application ne les définit pas déjà.
  • Active la sending_queue intégrée de l’exportateur avec le 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 l’API et de l’entité dans la commande Docker suivante, puis exécutez-la :
Une fois le collecteur démarré, configurez votre application pour y exporter les 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 fournir 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 intercepte les appels OpenAI, crée des traces et les exporte vers le collecteur. Le collecteur gère l’authentification et l’acheminement vers Weave. Après avoir exécuté le script, vous pouvez consulter les traces dans l’interface Weave. Pour envoyer des traces vers des backends supplémentaires, ajoutez d’autres exportateurs et incluez-les dans la liste service.pipelines.traces.exporters. Par exemple, vous pouvez exporter vers Weave et Jaeger depuis la même instance du Collector.

Organiser les traces OTel en threads

Les threads Weave vous permettent de regrouper des traces associées afin d’analyser des conversations sur plusieurs tours de conversation ou des sessions utilisateur comme une seule unité. Ajoutez des attributs de span spécifiques pour organiser vos traces OpenTelemetry en threads, puis utilisez l’interface Thread de Weave pour analyser les opérations associées, comme les conversations à plusieurs tours de conversation ou les 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 de conversation (il apparaît comme une ligne dans la vue thread).
Les exemples suivants montrent comment organiser des traces OTel en threads Weave. Ils utilisent wandb.thread_id pour regrouper les opérations associées et wandb.is_turn pour marquer les opérations de haut niveau qui apparaissent comme des lignes dans la vue thread.
Utilisez cette configuration pour exécuter ces exemples :
Après l’envoi de ces traces, vous pouvez les consulter dans l’interface Weave, sous l’onglet Threads : elles y sont regroupées par thread_id, et chaque tour de conversation apparaît sur une ligne distincte.

Correspondance des attributs

Weave associe les attributs de span OpenTelemetry issus de divers frameworks d’instrumentation à son modèle de données interne. Cette correspondance signifie que vous n’avez pas besoin de renommer ou de transformer les attributs de votre instrumentation existante pour obtenir une vue détaillée dans Weave. Lorsque plusieurs noms d’attributs sont associés au même champ, Weave les traite par ordre de priorité, ce qui permet aux frameworks de coexister dans les mêmes traces.

Frameworks pris en charge

Weave prend en charge les conventions d’attributs des frameworks d’observabilité et SDK 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 du SDK d’IA de Vercel (ai.prompt, ai.response, ai.model.*, ai.usage.*).
  • MLflow: attributs de tracking de MLflow (mlflow.spanInputs, mlflow.spanOutputs).
  • Traceloop: instrumentation OpenLLMetry (traceloop.entity.*, traceloop.span.kind).
  • Google Vertex AI: attributs d’agent de Vertex AI (gcp.vertex.agent.*).
  • OpenLit: attributs d’observabilité d’OpenLit (gen_ai.content.completion).
  • Langfuse: attributs de tracing de Langfuse (langfuse.startTime, langfuse.endTime).

Référence des attributs

Limites

L’interface Weave ne prend pas en charge le rendu des appels d’outil de trace OTel dans la vue Chat. Ils s’affichent à la place sous forme de JSON brut.