Skip to main content

Overview

Weave supports ingestion of OpenTelemetry compatible trace data through a dedicated endpoint. This endpoint allows you to send OTLP (OpenTelemetry Protocol) formatted trace data directly to your Weave project.

Endpoint details

Path: /otel/v1/traces Method: POST Content-Type: application/x-protobuf Base URL: The base URL for the OTel trace endpoint depends on your W&B deployment type:
  • Multi-tenant Cloud:
    https://trace.wandb.ai/otel/v1/traces
  • Dedicated Cloud and Self-Managed instances:
    https://<your-subdomain>.wandb.io/traces/otel/v1/traces
Replace <your-subdomain> with your organization’s unique W&B domain, e.g., acme.wandb.io.

Authentication and routing

Pass your W&B API key in the wandb-api-key header, then specify the following keys as OpenTelemetry Resource attributes in your TracerProvider class:
  • wandb.entity: Your W&B team or user name.
  • wandb.project: The project name to send traces to.
The following example shows how to configure authentication and project routing:

Examples

The following examples show how to send OpenTelemetry traces to Weave using Python and TypeScript. Before running the code samples below, set the following fields:
  1. WANDB_API_KEY: You can get this from User Settings.
  2. Entity: You can only log traces to the project under an entity that you have access to. You can find your entity name by visiting your W&B dashboard at [https://wandb.ai/home], and checking the Teams field in the left sidebar.
  3. Project Name: Choose a fun name!
  4. OPENAI_API_KEY: You can obtain this from the OpenAI dashboard.

OpenInference Instrumentation

This example shows how to use the OpenAI instrumentation. There are many more available which you can find in the official repository. First, install the required dependencies:
Performance Recommendation: Always use BatchSpanProcessor instead of SimpleSpanProcessor when sending traces to Weave. SimpleSpanProcessor exports spans synchronously, potentially impacting the performance of other workloads. These examples illustrate BatchSpanProcessor, which is recommended in production because it batches spans asynchronously and efficiently.
Paste the following code into a Python file such as openinference_example.py:
Run the code:

OpenLLMetry Instrumentation

The following example shows how to use the OpenAI instrumentation. Additional examples are available in the OpenLLMetry repository. First, install the required dependencies:
Paste the following code into a Python file such as openllmetry_example.py. Note that this is the same code as above, except the OpenAIInstrumentor is imported from opentelemetry.instrumentation.openai instead of openinference.instrumentation.openai:
Run the code:

Without instrumentation

If you would prefer to use OTel directly instead of an instrumentation package, you may do so. Span attributes will be parsed according to the OpenTelemetry semantic conventions described at https://opentelemetry.io/docs/specs/semconv/gen-ai/gen-ai-spans/. First, install the required dependencies:
Paste the following code into a Python file such as opentelemetry_example.py:
Run the code:
The span attribute prefixes gen_ai and openinference are used to determine which convention to use, if any, when interpreting the trace. If neither key is detected, then all span attributes are visible in the trace view. The full span is available in the side panel when you select a trace.

Use an OpenTelemetry Collector

The examples above export traces directly from your application to Weave. In production, you can use an OpenTelemetry Collector as an intermediary between your application and Weave. The collector receives traces from your app, then forwards them to one or more backends.

Set up a collector

The following example shows how to:
  • Set up a Docker configuration file that deploys a local server (collector) that listens for OTLP traces, batches them, and forwards them to Weave.
  • Locally run the collector using Docker.
  • Send a basic call to OpenAI that forwards traces to the collector running in the Docker container.
To use a collector, first create a collector-config.yaml file that configures the collector to receive OTLP traces and export them to Weave:
collector-config.yaml
This configuration file:
  • Listens for OTLP traces on port 4318 (HTTP).
  • Exports traces to Weave’s OTLP endpoint using the wandb-api-key header, reading the endpoint URL from WANDB_OTLP_ENDPOINT and the API key from WANDB_API_KEY.
  • Sets wandb.entity and wandb.project as resource attributes using the resource processor, reading values from DEFAULT_WANDB_ENTITY and DEFAULT_WANDB_PROJECT. The insert action injects these attributes only if your application code does not already set them.
  • Enables the exporter’s built-in sending_queue with batching to reduce network overhead.
After configuring the collector’s settings, update the API and entity values in the following Docker command and run it:
Once the collector is running, configure your application to export traces to it by setting the OTEL_EXPORTER_OTLP_ENDPOINT environment variable. The OTel SDK reads this variable automatically, so you do not need to pass the endpoint to the exporter. If you set wandb.entity or wandb.project as resource attributes in your application’s TracerProvider, they take precedence over the defaults defined in the collector config.
The OpenAIInstrumentor automatically wraps OpenAI calls, creates traces, and exports them to the collector. The collector handles authentication and routing to Weave. After running the script, you can view the traces in the Weave UI. To send traces to additional backends, add more exporters and include them in the service.pipelines.traces.exporters list. For example, you can export to both Weave and Jaeger from the same Collector instance.

Organize OTel traces into threads

Add specific span attributes to organize your OpenTelemetry traces into Weave threads, then use Weave’s Thread UI to analyze related operations like multi-turn conversations or user sessions in Weave’s thread UI. Add the following attributes to your OTel spans to enable thread grouping:
  • wandb.thread_id: Groups spans into a specific thread
  • wandb.is_turn: Marks a span as a conversation turn (appears as a row in the thread view)
The following examples show how to organize OTel traces into Weave threads. They use wandb.thread_id to group related operations and wandb.is_turn to mark high-level operations that appear as rows in the thread view.
Use this configuration to run these examples:
After sending these traces, you can view them in the Weave UI under the Threads tab, where they’ll be grouped by thread_id and each turn will appear as a separate row.

Attribute mappings

Weave automatically maps OpenTelemetry span attributes from various instrumentation frameworks to its internal data model. When multiple attribute names map to the same field, Weave applies them in priority order, allowing frameworks to coexist in the same traces.

Supported frameworks

Weave supports attribute conventions from the following observability frameworks and SDKs:
  • OpenTelemetry GenAI: Standard semantic conventions for generative AI (gen_ai.*)
  • OpenInference: Arize AI’s instrumentation library (input.value, output.value, llm.*, openinference.*)
  • Vercel AI SDK: Vercel’s AI SDK attributes (ai.prompt, ai.response, ai.model.*, ai.usage.*)
  • MLflow: MLflow tracking attributes (mlflow.spanInputs, mlflow.spanOutputs)
  • Traceloop: OpenLLMetry instrumentation (traceloop.entity.*, traceloop.span.kind)
  • Google Vertex AI: Vertex AI agent attributes (gcp.vertex.agent.*)
  • OpenLit: OpenLit observability attributes (gen_ai.content.completion)
  • Langfuse: Langfuse tracing attributes (langfuse.startTime, langfuse.endTime)

Attribute reference

Limitations

  • The Weave UI does not support rendering OTel trace tool calls the Chat view. They appear as raw JSON instead.