[APM] Service overview - Default to transaction type request and the options and repercussions.

[formgeist]

Summary

We're adding a new Service overview page that will summarize a lot of different metrics about each service. The decision in the design was to not have filtering capabilities at this time, which means the transaction type selection is also removed. This means setting the transaction type to either request or page-load (for RUM services).

Challenges

By not having the transaction type selection, the user will not be able to query their other transaction types for the service. These capabilities will still be available in the Transactions view.

We'll need to design for the following scenarios;

• Describe that the metrics are based on the request transaction type
• If a given service does not have any request transactions, we should show a message to the user that the Overview page is based on request or page-load transaction types.

Alternative strategies;

• Alternatively, we hide the overview page and immediately show the Transactions view.

Lastly, we'll want to always prefer request and page-load in the Transactions view. Currently, we're defaulting to show whichever type has the most documents in the selected time range. I'll put in a request to alter the functionality of the Transactions view.

cc @alex-fedotyev

[elasticmachine]

Pinging @elastic/observability-design (design)

[nehaduggal]

Its important to settle on what metrics we want to surface by default as there are repercussions of showing that data in multiple different UIs.

Today we show average response times(regardless of transaction type) on the service Inventory/List view page. In the Transactions UI(which is what is surfaced when you select a service on the list page) we show you the KPIs that are scoped to a transaction type with filters that allow you to switch. Although, the experience between the two pages can look inconsistent, it really isn't because the Transactions page has a filter that by default selects a transaction type. The filter makes it somewhat clear that you are viewing a subset of transactions for the selected service.

For the new service overview page we decided to not add any filters for the initial versions. As per the initial discussions, we decided that this new page would be scoped to only default transaction types(request/page load). Thinking about the user experience of clicking through a service from the List page and landing on the Overview page, we will have different response times a user will see(if we don't align) on these two pages. This inconsistency will be highly confusing and we should definitely aim for ensuring we show consistent metrics in the curated experience.

If we choose to only show request/page-load transaction type KPIs then we will run into an issue where we will show the service in the Inventory/List page but will not have any KPIs surface unless the customer drills down to the Transactions page for the service. The blank metrics will be a very confusing experience and lead a user to believe that their services are broken(unless they are intimately familiar with their services, transaction types and our UI).

Here is my proposal:

• Default to request/page-load based response times for services by default on all the pages in APM - Service Inventory/List, Service Overview, Service Maps.

• If there are no transactions with those default transaction types, pick the transaction type with the most throughput and surface the response times for that across all mentioned APM pages. Having this second option will allow us to account for cases where the service only has a custom transaction type.

/cc @alex-fedotyev @sqren @graphaelli

[alex-fedotyev]

I like this!

If there are no transactions with those default transaction types, pick the transaction type with the most throughput and surface the response times for that across all mentioned APM pages. Having this second option will allow us to account for cases where the service only has a custom transaction type.

I wonder if this logic leads to inconsistencies.
How about this: If there are no transactions with those default transaction types, use all transactions across all request types?

[alex-fedotyev]

Linking to service overview meta issue

[sorenlouv]

I wonder if this logic leads to inconsistencies.
How about this: If there are no transactions with those default transaction types, use all transactions across all request types?

We talked about this and agreed that it's possible to do what @nehaduggal suggested without inconsistencies, and most likely the simplest to implement.

[formgeist]

@sqren Will you create the relevant Kibana issues for this in relation to the Service overview implementation? Thanks

[sorenlouv]

@formgeist I've created elastic/kibana#82831

Should this be closed now?

[formgeist]

Yup, I think we reached a solution and will implement according to your issue.