Skip to main content

Exporting OTel Traces to Fiddler

Overview

This guide covers the client-side export scenario: your application has already generated OpenTelemetry traces, you manage their storage and processing, and you need to ship them to Fiddler. You are responsible for:
  1. Attribute mapping — translating your OTel span attributes to Fiddler’s schema
  2. Protobuf serialization — building ResourceSpans → ScopeSpans → Span structures
  3. Export — POSTing the compressed payload to Fiddler’s v1/traces endpoint
This differs from live instrumentation, where the OTel SDK exports spans automatically as your agent runs.
When to use this approachUse client-side export when you have:
  • Traces stored in a data warehouse, JSONL files, or a logging pipeline that you want to replay into Fiddler
  • A custom export pipeline that processes spans before sending (e.g., filtering, enrichment, or ID regeneration)
  • Batch backfill of historical trace data
For real-time agent instrumentation, use the OpenTelemetry Integration or a framework SDK instead.

Prerequisites

  • A Fiddler account with a GenAI application created — you will need its Application UUID
  • A valid Fiddler API token (from Settings > Credentials)
  • Python packages:

The v1/traces Endpoint

Send traces as a gzip-compressed protobuf ExportTraceServiceRequest payload:

Protobuf Structure

Fiddler expects the standard OTLP hierarchy:
application.id must be set at the Resource level (not on individual spans):

AnyValue Typing

Each KeyValue in the protobuf structure carries its value in an AnyValue message. AnyValue is a oneof — exactly one typed field must be set. Using the correct field ensures Fiddler classifies the data with the right type (e.g., numeric fields enable aggregation, charting, and alerting).
Use int_value / double_value for numeric attributes. If you wrap a number in string_value (e.g., AnyValue(string_value="150")), Fiddler will treat it as a string column. This means you lose the ability to compute numerical aggregations (sum, average, percentiles) and set alerts on that attribute.
For the full attribute quick overview (all attributes, types, and AnyValue fields), see Span and Resource Attributes — Quick Overview.

Attribute Mapping Reference

Span Structure Fields

The following fields control the span’s structural properties and are not sent as span attributes. Map them to the corresponding protobuf Span fields instead:

Required Span Attributes

Every span sent to Fiddler must include this attribute: application.id is required at the Resource level (see above).

Span Type: Deriving from gen_ai.operation.name

If your spans follow the GenAI semantic conventions and carry gen_ai.operation.name, map it to fiddler.span.type as follows:

LLM Semantic Convention Mappings

Tool Semantic Convention Mappings

Agent and Conversation Attributes

Set agent attributes on every span. If gen_ai.agent.name or gen_ai.agent.id are provided, set both on every span within the trace. Fiddler uses these attributes to attribute spans to the correct agent — spans missing these fields will be unattributed even if other spans in the same trace carry them.

Legacy / Underscore Field Names

If your traces use older underscore-style field names, map them to the Fiddler dotted equivalents before serialization:

Custom User Attributes

To attach business-level metadata to spans, prefix your keys with fiddler.span.user.:
These attributes are indexed and queryable in Fiddler’s Explorer.

Parsing gen_ai.input.messages

The gen_ai.input.messages attribute is a JSON array of chat-style message objects. Fiddler expects it split into two separate attributes: Example input:
Resulting mapping: If no user message is found, all messages are placed in gen_ai.llm.context and gen_ai.llm.input.user is omitted.

Span Kind and Status Mappings

Span kind (SpanKind enum): Status code (StatusCode enum):

Minimal End-to-End Example