[APM] Discovery - need to re-evaluate implementation of filters and kuery bar across APM UI

[alex-fedotyev]

Describe the feature:
APM already offers various filters on different pages, like environments, hosts, K8s pods, containers, etc.
In 7.8 we started adding cloud metadata to be collected by APM agents.

On top of that some of the filters are used to track integrations across other observability UI into APM.

This issue would be used to perform discovery and design which filters need to be available for each screen, how they would persist when linking from one screen to another, and what would be used when linking from other UI pages into APM.

I suggest we perform this discovery before proceeding with #49153

[elasticmachine]

Pinging @elastic/apm-ui (Team:apm)

[sorenlouv]

Any update on this? If we want to ship this in 7.11 we should have a proposal for a new design ready sometime during 7.10.

[formgeist]

@alex-fedotyev Can you help us determine the next steps here? Are simply reviewing the categories of filters, or do you have something else in mind?

[alex-fedotyev]

@formgeist , @sqren
I suggest we postpone this a little further until we have a better idea about new improved navigation between APM pages (we are going to improve them to enable more investigative workflows).
I see following things to be determined:

1. Document and design flows between APM pages when during troubleshooting analysis from APM down to a root cause.
2. Identify what drill down and filtering capabilities we would need, and how and why users would decide to apply those filters (for example, when looking at the service performance users should be able to identify if problems are caused by certain portion of the underlying infrastructure like bad HOST or bad version and easily apply the filter to drill down).
3. Identify what links across observability would we need and which of them would need filter capabilities (like seeing all service instances running on a HOST when coming from metrics, for example).

Do you have any particular filters in minds which are highly used?
Is there a specific need or a customer commitment why we need to improve experience of existing filters in 7.11?

I would rather prefer to focus on investing into other features like ability to compare performance of an item to historical values as it seems to have higher impact and enables better troubleshooting workflows.

[formgeist]

@alex-fedotyev I definitely see the benefit in thinking in a larger scope and figure out what filtering capabilities make sense going forward. I know that we're looking into these troubleshooting workflows with the service landing page experience, and I think we can include these investigations that you mention in that project. It feels a little more strategic than just implementing the suggested improvements right now.

Re: your questions - we don't have a good sense of which filters are being used. If we want to get some data on this, we can open an issue to track the different filter categories and know when they're being interacted with. Otherwise there's the option to interview a number of existing customers about this.

I don't believe there have been any commitments to improve it to anyone externally and that's obviously also something we should refrain from doing.

[sorenlouv]

@nehaduggal Did we make a decision on the future of ui filters? Getting rid of them would remove a big chunk of technical debt, so we might as well do this sooner rather than later.

[sorenlouv]

Closing since we will be moving forwards with removing the ui filters in 7.12: #84526