[Feature]: Allow enhancing span names with "summary fields" overlays

[JnRouvignac]

Requirement

As a person troubleshooting traces with hundreds of thousands of spans, I find it hard to spot patterns when span names follow OpenTelemetry best practices of low-cardinality.
I want span names in the UI to be overlaid with "summary fields"
so that I can investigate large traces AND follow OpenTelemetry best practices for span naming

Problem: High Cardinality in span names vs. UI Observability

When investigating large traces containing hundreds of spans with the same name, it is incredibly difficult to distinguish between them or spot patterns.
Because OpenTelemetry best practices require low-cardinality span names (e.g., get_user instead of get_user/314159), critical identifying data (like customerId or orderId) must be set as span attributes.
This creates friction when investigating large traces:

• When there are many spans in a trace, it can be hard to get the information you are looking for out of span attributes.
• Users must click on dozens of individual spans, expand the attributes panel, and hunt for the specific ID to find the one they need.

Using high-cardinality span names (e.g., appending customerId or orderId) would fix the UI issue, but it violates OpenTelemetry standards and duplicates data already stored in attributes.

References:

• OpenTelemetry best practices
  • HTTP span names: https://opentelemetry.io/docs/specs/semconv/http/http-spans/#name
  • General span names: https://github.com/open-telemetry/opentelemetry-specification/blob/v1.56.0/specification/trace/api.md#span

Proposal: "Summary Fields"

A feature similar to Google Cloud Logs Explorer's "Summary Fields" may solve the problem.

This feature would allow users to dynamically select a span attribute (like customerId) and append or overlay that attribute value next to the span names across the entire trace view.
This way users can quickly scan for patterns or specific IDs across hundreds of spans at a glance, without bloating index data or breaking OpenTelemetry low-cardinality best practices.

References:

• Google logs explorer "summary fields":
  • doc: https://docs.cloud.google.com/logging/docs/view/logs-explorer-interface#add_summary_fields
  • demo: https://storage.googleapis.com/gweb-cloudblog-publish/original_images/11.logs_explorer_simple_query_mode_hide_default_summary_fields.gif

Open questions

No response

[udita-0707]

Hi! @JnRouvignac I'd like to work on this issue.

After reviewing the OpenTelemetry span naming guidelines and the Google Logs Explorer "Summary Fields" feature referenced in the issue, I understand the challenge of investigating large traces where many spans share the same low-cardinality name. While identifiers such as customerId or orderId belong in span attributes rather than span names, repeatedly expanding spans to inspect attributes can make trace analysis cumbersome.

The Summary Fields approach appears to address this by allowing users to select one or more span attributes and surface their values directly alongside span names in the trace view. Similar to Logs Explorer, this would improve discoverability and pattern recognition across large traces without introducing high-cardinality span names or duplicating data.

I'd like to investigate the current trace UI and work on implementing a configurable summary fields experience, including attribute selection and display within the trace visualization. Please assign this issue to me if it's available. Thanks!

[JnRouvignac]

Hi @udita-0707,

Great ! I am not part of the Jaeger project so I can't help you.

However, before starting any meaningful work, I would highly recommend you get in touch with members of the Jaeger community to see if they are interested in this feature. If that's the case, you will get code reviews and support.

See https://www.jaegertracing.io/get-in-touch/ on how to get in touch with them.

Thanks

[jkowall]

I think it's a good idea @JnRouvignac but I'd like to see the mockup of the UX you intent to implement in your issue (or here).

[jkowall]

Here is the UX mockup I had in mind. This is the actual timeline view rendered from a dev build with the proposed feature injected, using a sample trace where two payment: charge spans share the same low-cardinality name:

Proposed design:

• Summary fields picker in a bar between the minimap and the timeline header: a searchable multi-select over the attribute keys present in the trace, with per-key coverage counts (customer.id 5/7 spans) so you know whether a key is worth pinning. Capped at ~3 selected fields to protect horizontal space and bound per-row render cost.
• Inline chips after the operation name in each span row: dimmed key, monospace value, so values can be scanned vertically across hundreds of rows. Spans that lack the attribute render nothing (no placeholder noise). The existing column resizer already lets users make room.
• Second entry point mirroring Google Logs Explorer: an "Add to summary fields" action on any attribute row in the span detail panel, since that is where you typically discover the attribute you then want to see everywhere.
• State and shareability: selection persisted in the existing layout preferences (localStorage), plus a ?summaryFields=customer.id,http.status_code URL param following the uiFind pattern, so a shared link reproduces the same overlay. URL wins over localStorage on load.
• Performance: a memoized spanID -> value lookup built once per (trace, selection), so each row does O(selected fields) work instead of scanning span.attributes per render. Key enumeration for the picker is one O(total attributes) pass, computed lazily on first open. This matters since the timeline needs to stay usable at tens of thousands of spans.
• Light semantic styling for a small allowlist of well-known semconv keys (e.g. 5xx http.status_code rendered in red), as shown in the mockup.

Deliberately out of scope for a v1: event/link attributes (span and resource attributes only), per-service field selections, and user-defined value coloring rules.

Feedback welcome; if the direction looks right this decomposes cleanly into picker, row rendering, and state/URL plumbing.

[udita-0707]

This is a really clear spec @jkowall, thank you! The checkbox bar between the minimap and timeline header is an elegant solution to the screen real estate problem, and the coverage counts (customer.id 5/7) are a great touch for discoverability.

I'd like to implement this. One clarifying question before I start — for the memoized spanID -> value lookup, should this live as a selector alongside the existing trace redux store, or computed locally inside the timeline component on trace load?

Planning to decompose it as you suggested: picker + row rendering first, then URL/localStorage plumbing following the uiFind pattern, and the span detail panel entry point as a follow-up.

[jkowall]

Thanks @udita-0707, that decomposition sounds right.

For the spanID -> value lookup, I’d prefer a memoized selector / selector helper rather than storing the derived map in Redux state or computing it ad hoc inside each row. The selected summary field keys are UI state, but the lookup itself is derived from (trace, selectedFields), so keeping it as a pure memoized derivation should make it easier to test, reuse for the picker counts, and avoid per-row attribute scans.

A good v1 shape would be:

• build the available field list and coverage counts from the trace once per trace;
• build the selected-field lookup once per (trace, selectedFields);
• keep row rendering to O(selectedFields) with no scan over span attributes during render;
• avoid putting the lookup map itself into persisted state.

I’m also fine with doing picker + row rendering first, then URL/localStorage plumbing, then the span detail “Add to summary fields” action as a follow-up. That sequence should keep the first PR reviewable.

[udita-0707]

Makes sense! @jkowall Memoized helpers outside Redux, reusable for both the picker counts and row rendering. Will open a draft PR once the picker and row rendering are in shape.

[jkowall]

@udita-0707 Computed locally, not in Redux. The timeline is mid-migration off Redux, so don't add new selectors there. Two pieces:

1. The selection (which attribute keys are pinned) is state: put it in the Zustand useLayoutPrefsStore (packages/jaeger-ui/src/components/TracePage/TraceTimelineViewer/store.layout.ts), alongside things like spanNameColumnWidth, so it persists the same way.
2. The spanID -> value lookup is derived data, not state: a useMemo keyed on (trace, selectedFields) in the TraceTimelineViewer layer (e.g. a small useSummaryFields(trace, fields) hook), with the per-row value passed into SpanBarRow as a prop. Same for the picker's key enumeration: one memoized pass over the trace, computed lazily when the picker first opens.

Your build order works. One request: include a test with a large generated trace (10k+ spans) to confirm there's no per-row attribute scan on render; that's the main perf trap here. Happy to review the PR.

[udita-0707]

@jkowall PR1 for this feature is ready for review when you have a moment: #4063

Scope (PR1):

• Summary fields bar between minimap and timeline header (max 3 fields, search, coverage counts)
• Memoized buildAvailableFields / buildSummaryLookup; lookup built via useMemo in TraceTimelineViewer and passed into SpanBarRow
• Selection in useLayoutPrefsStore with localStorage persistence
• Inline value chips on span rows (5xx http.status_code styling)
• Unit/component tests, including a 15k-span perf/memoization test

Follow-ups (planned as separate PRs):

• PR2: URL sync (?summaryFields=...) via a useSummaryFields-style hook
• PR3: Span detail panel entry point

I also addressed review-bot feedback on persisted state normalization and search input styling.