Kibana: [APM] Breakdown graphs design

[felixbarny]

Summary

Adds a chart which breaks down the transaction time by the span.type (db, template, etc) to the service details page and the transaction details page. I'm aware that there's basically no difference between the trace group view and the transaction group view. The MVP does not break down the entire trace but only the root transaction. In upcoming iterations, we can improve that but for now, it should be good enough. There should be a tooltip which explains that, next to a beta marker.

As we already have a graph for the Transaction duration, this graph should not show the duration but rather the percentage. Especially for spikey response times, it makes it easier to get an overview of the relative contribution to response per span.type. By hovering over the breakdown graph and looking at the tooltips from the transaction duration graph, you can still see the total execution time at that particular time.

There is also a special transaction value for span.type which is the time which can't be explained by direct child spans of the transaction (the transaction's self_time). The UI might relabel this special value to "other", "app", "JVM" or similar.

It would be nice if the tooltips for the breakdown would not only show the percentage, but also the average count and average time per span type. This tells users that a particular transaction has 42 db calls on average and that each takes 420 ms on average, for example.

In further iterations, the breakdown might include timings information from asynchronously running threads. That implies that the total time per type may exceed the transaction's duration. The question is whether we should still stack up to 100% (defining 100% as the sum of all self-times per type) or if the graph should go over 100% (defining 100% as transaction duration) in this case.

The graph should also gracefully handle the case if there is no breakdown data available. Either by displaying something like "no data" or by just not showing the graph. Most likely, not all agents will support the breakdown when this feature is first released.

On query bar integration:
The query bar can be used to filter by transaction.name, transaction.type or any other metadata, like service.name, host.hostname etc. If filtered by a specific tag/label or user.id, the graph would just be empty.

Solution

Designs

The breakdown chart will be added to the Transactions overview and detail pages. We're adding it next to the other main graphs above the list and timeline components.

Marvel prototype

Transactions overview

_Example of the collapsed chart component that summarizes the avg. across the time range for all service transactions_

_Uncollapsed state to display the timeseries graph along with tooltip_

Transaction detail

_Example of the collapsed chart component summarizing the average for that particular transaction group_

Tasks

Chart panel

• Add new breakdown chart to Transaction overview and detail pages
• Label the chart "Transactions breakdown"
• Add EuiBetaBadge by the chart title
• Add toggle to show/hide the chart element, hidden by default.

Breakdown chart

• Stacked area chart comprising the span type breakdown.
• Use the type legend colour the subtype (if available) as to group them. Only display the subtype value as label, i.e. "db.elasticsearch" = "elasticsearch".
• Display chart tooltip that details the following data;
  
  
  
  • Time series bucket title (date and time)
  
  
  • For each span type;
  
  
  • Percentage of duration
  
  
  • Count (avg.) in parenthesis
  
  
• Hovering on the chart to activate tooltip, also activates the Transaction duration and Transactions per min. chart tooltip for comparison.

Stats legend

• Sort values alphabetically
• Use the type legend colour the subtype (if available) as to group them.
• Display avg. percentage values and legends together as larger stats-type properties.

[elasticmachine]

Pinging @elastic/kibana-design

[elasticmachine]

Pinging @elastic/apm-ui

[formgeist]

@felixbarny Just a heads up; please use design label instead of the :Design one, because that is for the Kibana design team as a whole 👍

[formgeist]

I've updated the description to feature a first mock of adding the new graph to each view.

[formgeist]

Based on feedback received in yesterday's meeting @nehaduggal and @felixbarny, I've made some additional updates to the designs in the description. Have a look and let me know if there's anymore feedback.

One thing I've not included is the description when viewing a trace via the entry transaction. We discussed having a note or callout that described that the breakdown was limited to the entry transaction. Is this correct? Would we only show it when viewing the entry transaction views (typically coming from the Traces list)?

Thanks,

[formgeist]

@felixbarny can you confirm the following?

One thing I've not included is the description when viewing a trace via the entry transaction. We discussed having a note or callout that described that the breakdown was limited to the entry transaction. Is this correct? Would we only show it when viewing the entry transaction views (typically coming from the Traces list)?

[felixbarny]

Thx for the ping! I'd say we should always show that note as non-entry transactions can have child transactions. Those are not included in the breakdown as well.

[formgeist]

Thanks! I'll make some additions to the Transaction detail page to display a text to explain this explicitly to the user.

[formgeist]

Updated the screenshots and GIF in the description reflecting the minor additions to the Transaction detail page, as discussed above. FYI @nehaduggal - added the copy Limited to the currently selected transaction. on the Transaction breakdown chart (Transaction detail page) as a clear description in the UI.

[felixbarny]

@makwarth could we get some feedback from you? Do you think the tooltips do a good enough job of explaining the differences between total self-time and duration in async scenarios?

[formgeist]

Design update

I've updated the screens to reflect many of the feedback and changes proposed through multiple feedback sessions in the workgroup (incl. @makwarth). Here's a "breakdown" of the changes and additions to the UI elements;

• Moved the breakdown element to the top of the views (overview + detail).
• Added KPI elements to the all charts incl. duration and TPM.
• Added subtype values for each type where available. The entries will carry the type colour assignment and be grouped, sorted by %.
• Overall style adjustments incl. moving the panels closer together to save space but also possibly play around with using flex to align them side-by-side on larger screen displays. Those breakpoints are easier to play around with in the UI implementation.

Marvel prototype

---

_Transactions overview_

_Transaction detail view_

[roncohen]

nice! I wonder if we should start without "span time (avg)" in the breakdown header and counts in the popover? The use-case they solve isn't very common IMO and it adds significant "noise" in the design.

I also think we don't need to show the "type" when we're showing "subtype", e.g. we can just show "postgresql" and not "db.postgresql" IMO.

[roncohen]

sorting: I think i'd rather have them sorted alphabetically. "app" will likely be first still and with alphabetical sorting they will move around much less. As an example: For a specific service, you might be working to reduce the time spent in "template". When you succeed, it moves around and suddenly it takes more time to find what you're looking for in the header

[roncohen]

🤦‍♂

[formgeist]

Thanks for the feedback @roncohen 👍

nice! I wonder if we should start without "span time (avg)" in the breakdown header and counts in the popover? The use-case they solve isn't very common IMO and it adds significant "noise" in the design.

SGTM

I also think we don't need to show the "type" when we're showing "subtype", e.g. we can just show "postgresql" and not "db.postgresql" IMO.

True, only meant to make it explicit in any case. DB's are easy to decode, but maybe not so with external or template subtypes. But it's a thing we can always iterate on later if the feedback is there. Will remove for the 1st iteration.

sorting: I think i'd rather have them sorted alphabetically. "app" will likely be first still and with alphabetical sorting they will move around much less. As an example: For a specific service, you might be working to reduce the time spent in "template". When you succeed, it moves around and suddenly it takes more time to find what you're looking for in the header

Feels a little strange not to sort by % if app is < 1% but something else at > 50% is hidden either in the bottom. Also due to screen size, we might collapse anything more than 6 items in that breakdown, which incidentally could hide important types.

[makwarth]

Looks good @formgeist ! I really like the new KPI element in the panels.

Sorting alphabetically has the advantage of being easier to compare across transaction groups. (Most transactions will likely have similar span types). I agree it's a concern if we high important types though. Maybe we don't hide them, but create an extra row?

[formgeist]

Sorting alphabetically has the advantage of being easier to compare across transaction groups. (Most transactions will likely have similar span types). I agree it's a concern if we high important types though.

Makes sense, I probably just have to see it in action.

Maybe we don't hide them, but create an extra row?

Yeah, we can certainly do that as a start.

[formgeist]

Based on the feedback last week, I've updated the designs in the description above. I suppose we're ready to move this into implementation issues. @sqren @felixbarny Would it make sense to do a sync later this week before I make those issues?

[formgeist]

Closing this design issue in favor of https://github.com/elastic/kibana/issues/36445 and https://github.com/elastic/kibana/issues/36441 issues that are open for implementation.