Overview
Use this page as a reference for which attributes Fiddler indexes, how to type their values, and how they map to FQL
attribute() and Span:: filters.- Attributes are present in OpenTelemetry spans.
- Values use the correct type so numeric attributes are aggregatable and alertable (not silently treated as strings).
- Custom attributes follow the naming convention so they appear in the Explorer and are queryable via FQL.
Attribute Levels
Attributes are set at two levels in the OTLP hierarchy:Required Attributes
These must be present on every trace sent to Fiddler. Fiddler rejects traces that omit either field.System Attributes
System attributes are stored under thefiddler.span.system.* prefix internally. They are registered in the attribute catalog and available for FQL custom metrics via attribute('...', type='system', scope='span'). Some are also available as dedicated span columns for fast filtering (via Span:: redirects); the rest are filtered via SpanAttribute::.
Identity Attributes
Identity attributes are stored as metadata internally and materialized into dedicated span columns. They appear as Session ID and Agent ID columns in the Explorer. They are not registered in the attribute catalog and cannot be used in FQL custom metrics.Set agent attributes on every span. If you provide
gen_ai.agent.name or gen_ai.agent.id, set them on every span within the trace. Fiddler uses these to attribute spans to the correct agent — spans missing these fields will be unattributed even if other spans in the same trace carry them.Content Attributes
These attributes are visible in the Explorer but are not registered as queryable attributes — they cannot be used in FQL custom metrics or span filters.LLM Content
Tool Content
Custom User Attributes
Attach business-level metadata to spans using two namespaces:fiddler.span.user.* attributes are indexed, appear as filterable columns in the Explorer, and are available for custom metrics via the FQL attribute() function. fiddler.session.user.* attributes are visible in the trace detail side panel only — they do not appear as columns in the Explorer grid and are not available for custom metrics or filtering.
Attribute Value Types
Under the hood, every attribute value is wrapped in an OTelAnyValue protobuf message. Using the correct typed field is critical — it determines whether Fiddler classifies the attribute as numeric (enabling aggregation, charting, and alerting) or string.
SDK usage (high-level)
When using the Fiddler OTel SDK, LangGraph SDK, or Strands SDK, pass native Python types and the SDK handles typing automatically:Protobuf usage (low-level)
When building protobufSpan objects directly (e.g., for OTel trace export), you must set the correct AnyValue field explicitly:
to_any_value() helper that handles type dispatch automatically, see the OTel Trace Export — AnyValue Typing section.
How Attributes Flow into Fiddler
Once ingested, attributes power several Fiddler features:Querying attributes with FQL
Theattribute() function is the FQL primitive for referencing span data in custom metrics. Only system and user attributes are queryable — see Attribute Quick Overview for the full classification.
System attribute examples:
Attribute Quick Overview
All attributes listed below are visible in the Explorer. The Custom metrics and Explorer filter columns indicate additional availability for FQL and UI filtering respectively. The Explorer filter column shows both the UI column name (what you see in the DataGrid header) and the API filter field (used in programmaticfilter.rules[].field requests). The UI automatically maps column filters to the API syntax.
Upcoming Changes
Thefiddler.span.system.*, fiddler.span.user.*, and fiddler.contents.* prefix conventions described on this page are being phased out. In the new approach, Fiddler stores attribute keys exactly as sent by your application — no prefix transformation or renaming is required.
Instead of relying on prefix conventions, Fiddler uses semantic mappings to resolve raw attribute keys to canonical concepts (like input_tokens, model_name, input) in the backend. This enables cross-framework analytics without requiring any specific key naming conventions from your instrumentation. Fiddler ships with 140+ pre-configured mappings covering 13+ frameworks, and you can add custom mappings for unsupported frameworks or proprietary attribute names.
Existing data stored with fiddler.* prefixes will continue to work — the default mappings include entries for all legacy prefixed keys, so both old and new data resolve to the same semantic concepts.
For more details, see Semantic Mappings.
Related Documentation
- Semantic Mappings — how Fiddler maps raw attribute keys to canonical concepts across frameworks
- OTel Trace Export — protobuf serialization and attribute mapping for client-side export
- OpenTelemetry Integration — live agent instrumentation via the OTel SDK
- Custom Metrics — define FQL metrics over span attributes
- Fiddler OTel SDK —
@tracedecorator andset_attribute()usage - Agentic AI Overview — compare all integration options