Skip to main content

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 key-value pairs attached to OpenTelemetry spans and resources. They carry the data that powers Fiddler’s dashboards, alerts, evaluators, and custom metrics. Getting attributes right means:
  • 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.
This page is the single reference for how attributes work across all Fiddler integrations.

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 the fiddler.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 OTel AnyValue 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.
Use int_value / double_value for numeric attributes. If you wrap a number in string_value (e.g., AnyValue(string_value="150")), Fiddler treats it as a string column. You lose the ability to compute aggregations (sum, average, percentiles) and set numeric alerts on that attribute.

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 protobuf Span objects directly (e.g., for OTel trace export), you must set the correct AnyValue field explicitly:
For a copy-pastable 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

The attribute() 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:
User attribute examples:
See Custom Metrics for the full FQL reference and more 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 programmatic filter.rules[].field requests). The UI automatically maps column filters to the API syntax.
Only system and user attributes support custom metrics. Content fields (like gen_ai.llm.output, gen_ai.request.model) are visible in the Explorer but cannot be used in FQL attribute() expressions or aggregations. Identity fields (gen_ai.agent.id, gen_ai.conversation.id) are filter-only. If you need to compute metrics over a non-queryable field, attach it as a fiddler.span.user.* custom attribute instead.

Upcoming Changes

The fiddler.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.