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 common cross-framework concepts (tokens, agent and tool names, span type) that Fiddler recognizes automatically. They are registered in the attribute catalog and can be referenced in FQL custom metrics — by semantic_name (the recommended, framework-independent form) or by their verbatim key. 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. Reference an attribute by its verbatim key (exactly as your application emits it) or by its semantic_name (a canonical concept that Fiddler resolves across frameworks). See Attribute Quick Overview for the full classification.
As of release 26.16, you provide exactly one of name or semantic_name, and the scope and type arguments are optional — they default to 'span' and 'user'. The value argument filters to spans where the attribute equals a given string, for categorical breakdowns. See Custom Metrics for Agentic Applications for the full parameter reference and the supported semantic concepts. System attribute examples — reference recognized concepts by semantic_name, so the metric works regardless of which framework emitted the trace:
User attribute examples — reference custom fiddler.span.user.* attributes by their verbatim key:
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.

Deprecated Prefix Conventions

The fiddler.* prefix conventions on this page predate semantic mappings. They still work, but they are no longer the recommended way to instrument new applications.
The fiddler.span.system.*, fiddler.span.user.*, and fiddler.contents.* prefix conventions described on this page are deprecated. Semantic mappings are now the default mechanism for resolving span attributes and are the recommended approach for all new instrumentation.
In the semantic mapping 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 continues to work — the default mappings include entries for all legacy prefixed keys, so both old and new data resolve to the same semantic concepts. New instrumentation should send attribute keys in their native framework format and rely on semantic mappings rather than adopting the fiddler.* prefixes. For more details, see Semantic Mappings.