[APM] Dedicated UI filters

[makwarth]

Motivation

In 6.6, we fixed the APM service navigation hierarchy, so that we now have "Transactions", "Errors" and "Metrics" as top-level sibling navigation items per service.

One negative consequence of that change was that we had to introduce a temporary dropdown for when a user has multiple transaction types:

As it is now, we need to have this transaction type dropdown on both the Transactions and Metrics tabs. It's not great UX and takes up precious vertical space.

Proposal (phase 1)

This proposal introduces the transaction type as a dedicated UI filter in extension of the query bar. The filter will default to "All", and the user can click to select one or multiple types to filter on.

I think it makes sense to store the filter configuration in local storage so it's persistent per user, while also being part of the URL for sharing.

@formgeist Note on the date picker: Instead of moving it down to the right of the search bar, I'd place it to the right of the page title. This is similar to the uptime app (gif).

Proposal (phase 2)

Extending on phase 1, we could also add filters for other commonly used fields, like environment and host/pod/container.

Regarding environment, we currently support setting an environment variable in the agents, but we don't support it in the UI. Until now, the proposed solution to users has been to really disregard the environment variable and append environment name to the service name, like <servicename>-<env-var>, which creates a service per environment.

Adding a dedicated UI environment filter will enable users to have just one service in the UI, independently of amount of environments, and use the filter to jump between environments. I suspect users will be looking at their production environment 90% of the time, but one downside to this solution is that you don't have side-by-side environment comparison of response times in the services list. However, that response time comparison is likely not very useful given the difference in traffic on e.g. staging vs production

cc @elastic/apm-agent-devs @elastic/apm-ui

[formgeist]

In general I think it makes absolute sense to add these permanent filter options for users and solve the current transaction type selector just floating around the content area. As suggested, we're moving the date picker down into the app content - the next part could be to replace our current search bar implementation with the KQL bar, which has been redesigned and implemented to work alongside the date picker i.e. for Discover, Dashboards and more. The redesigned search bar allows the user to more seemingly add filters in a flow that allows for multiple options.

These filters are currently only controlled by the user, but after speaking with the design team, we might be able to leverage those same capabilities and add permanent app filters with the search bar. This makes our implementation more consistent with the rest of Kibana, so less friction for the end user to work with the controls.

I've made some quick mocks and a prototype, which I'll run by the design team to get their input, and hopefully we can land on a unified solution.

Design proposal

We'll adapt the KQL bar and add the ability to add fixed filter options alongside the search input.

The transaction type and environment selectors will be single select popovers that allow the user to select a single value. We will default to transaction type request in order to show data in the views. Both transaction type and environment selectors read their value in the selector.
The host filter is a multi-selector where the user is able to select multiple values. We want to display the selected values, so in order to keep from squishing the search bar, the values will be added as a user defined filter in the filters row. Here's a screen recording of how it works:

I have explored multiple other ways to add these permanent filters, but IMO they very quickly become either cluttered or their labels become so long that they will immediately push everything else on another row. Thoughts?

[formgeist]

Had a chat with @makwarth about the designs above, and we came up with some simple changes to how the filter options are displayed and used.

We're removing the specific filter option for host for now, users will still be able to use the KQL filter option to filter by hostname if they want to. So we're focusing on two filter options; transaction type and environment which are primary filters for analyzing the data appropriately.

The above screen recording captures the changes, but also shows how we intend to display that either filter are selected. By using the SuperSelect EUI component, we're able to very easily implement both filtering within the selector and have multi-select and remove options. The filter options themselves will display the number of values selected, and by default the filters are passive, so all types and environments are shown in the data if user. We're choosing not to default to a single value.

Again this solution came from multiple passes and mocks, so I'm happy to share any of the other options, or take feedback to how it works and how we might tweak it. Will be going over these with the design team to ensure that we have a consistent and generic enough solution that will also work for other solutions in Kibana that will have specific permanent filters.

[jasonrhodes]

My first reaction is that the transaction type/environment display here isn't scalable because it seems rather likely that another important filter will eventually make itself known, and there won't be any place to put it. It also feels confusing to me that those filters work differently than the others, at first glance anyway.

Could we make the word "Filters" be a drop down with various common filters, so transaction type and environment can be in there with a multi-state popover/context menu, and then when you select something to filter by it can add the filter to the UI the same way the regular KQL filters are added? That also makes the answer to "what am I currently viewing" easier to see (rather than just the "(1)" that doesn't tell you what you're filtering by).

The GitHub issue filter works kind of like this -- the end result for them is to add the syntax into the input but in our case the end result is adding the filter tags below the input, but otherwise the same idea.

Also: just a reminder that the UI makes a lot of assumptions about transaction type always being present and a few other things, so we have a good amount of work to do to unwind those assumptions and figure out how to handle this global filtering if it's going to persist across all views. Examples of this off the top of my head:

1. What does the transactions tab show if no type is selected, and what should the default view be on this tab if the filters are usually passive/off by default?
2. Can the errors tab show errors filtered by transaction type?
3. What does the metrics tab show for certain graphs that can't be filtered by something like transaction type (CPU and memory, plus upcoming agent-specific graphs)?
4. Should we support creating an ML job without a transaction type (service-wide job)?
   • Do we show the ML graph annotation on the "all transaction types" view if a person has the service-wide job set up?
5. Can all of these views filter by environment / what do we do for views that can't or shouldn't?

[makwarth]

My first reaction is that the transaction type/environment display here isn't scalable because it seems rather likely that another important filter will eventually make itself known

It doesn't scale horizontally, but we can always merge multiple filters into a single UI element, as you mentioned. These filters apply universally across all transaction types, and I'm not sure we'll have many, many more of those going forward.

It also feels confusing to me that those filters work differently than the others, at first glance anyway.

I don't see how they're different - can you elaborate?

That also makes the answer to "what am I currently viewing" easier to see (rather than just the "(1)" that doesn't tell you what you're filtering by).

Agree! At first also had host/pod/container as an UI filter and therefore couldn't populate the query bar with the filters as it would take up too much space if you selected eg. multiple hosts. But now that hosts are not part of the predefined UI filters, populating the query bar with the filters sounds good. (eg. service.environment:"prod"

1. What does the transactions tab show if no type is selected, and what should the default view be on this tab if the filters are usually passive/off by default?

Good question. We discussed either all or default to request

2. Can the errors tab show errors filtered by transaction type?

Yes

3. What does the metrics tab show for certain graphs that can't be filtered by something like transaction type (CPU and memory, plus upcoming agent-specific graphs)?

They wouldn't change

4. Should we support creating an ML job without a transaction type (service-wide job)?

I wouldn't change it from today

5. Can all of these views filter by environment / what do we do for views that can't or shouldn't?

Not sure I follow. Can you give example?

[sorenlouv]

By using the SuperSelect EUI component, we're able to very easily implement both filtering within the selector and have multi-select and remove options.
@formgeist

Unless we are very certain users need multiselect I think we should stick to a single select dropdown. This will both make the implementation simpler (since we currently assume that transaction type is a single value), and it will make it easier for the user to see what they have selected instead of the select just showing (1)).

[formgeist]

Been letting this simmer a little while I was focused on other projects on-going. There's been some developments that change perhaps the initial constellation of the filter options.

1. It's not entirely clear when we apply the option to filter for transaction type. It's mentioned in the latest Metrics workgroup update, that the transaction type filter does not make sense for Metrics. The question then becomes in which views are we (a) dependent on a transaction type to be selected and (b) intending to let the user filter by transaction type.

2. Do we think it makes sense to have transaction type and environment filtering on Services and Traces list views. That means showing all types in one selector which could be very large and for environments probably not possible because the service.environment is on the service. Then it becomes a simple text search of "production" and leaving it to the customer to have consistent naming.

Agree! At first also had host/pod/container as an UI filter and therefore couldn't populate the query bar with the filters as it would take up too much space if you selected eg. multiple hosts. But now that hosts are not part of the predefined UI filters, populating the query bar with the filters sounds good. (eg. service.environment:"prod"

3. Host/pod/container filter is not included in this iteration. If service.environment filter will be a Github-like populate the query bar selector, that leaves the transaction.type filter to its own separate selector that is required to display data in the transaction views, but it's optional in the errors views.

Would be great to clear up these questions and update the issue description or even create a new issue so we can design an appropriate solution. We can conceptualize more on how to solve additional dedicated filters in the future, but it feels like we have to make a revised temporary solution to solve the immediate needs.

[makwarth]

1. Can you elaborate on why transaction type doesn't make sense for the metrics tab? I get that it's somewhat confusing that host-level metrics don't change as a result of applying transaction type filter. However, I think it's clear that users often need to apply a transaction type to make the non-host-level metrics useful. Example:
   

2. I see I wrote service.environment, but the environment is set on the transaction/error, so not sure I follow?

[formgeist]

Can you elaborate on why transaction type doesn't make sense for the metrics tab?

DM'ing you a reference.

I see I wrote service.environment, but the environment is set on the transaction/error, so not sure I follow?

Probably my comment that was confusing. I'm indicating that if we enable dedicated filters for transaction.type and service.environment on the Services and Traces list views, the options will most likely be quite noisy. Maybe that's an accepted consequence of filtering across all transactions and errors.

[formgeist]

Here comes updated screens and Marvel prototype to show off the new concept. So we made some significant changes to the fundamental layout in the header to add global filters (service environment, host) and moved the search bar below the tab navigation to have "local" search for all views. We're already filtering search results for transaction and errors, and it makes sense to make this more apparent to users when searching. Other local filters i.e. the transaction type are added along that search bar.

🖼 Marvel prototype

The Marvel prototype also shows the interaction with the environment and host filters when applied.

Services list

Traces list

Transactions list

Metrics

[makwarth]

Looks good @formgeist. I don't think environment should be multi-select though. I would like to discuss a common environment naming across agent documentation, e.g. prod, dev, staging and <custom-name>. If successful, we can use the colored labels in the environment dropdown (and grey for custom labels) to clearly indicate what env the user is looking at.

[makwarth]

As per our convo just now, once we have more "local" filters like, transaction type, it probably makes sense to move them to a sidebar filter - but let's wait with that till we have more local filters.

[formgeist]

Closing this in favor of the proposed design solution described in the Dedicated Filters design document and the implementation issues for phase 1.