[APM] Ability to search tables by specific field

[sorenlouv]

In #126446 we are going to replace the kql bar on the Service Inventory page
EDIT: we should not remove the kql bar entirely - at least this issue is not concerned with that.

We already have the kql bar which can search across any field, and will filter all components on the page. This is both very powerful but also confusing. In addition to the kql bar I suggest that tables should have a search bar that filters by the field that makes sense in the given context.

Having a search bar directly above the table will make it easier for users to filter the data on the page without having to fiddle with kql or learning our schema which is not always self explanatory. For instance, if the user needs to filter the list of errors and want to filter by "Error message" they'll need a kql query like error.exception.message: "search term" OR error.log.message: "search term"

Example mockup (thanks @formgeist)

Three approaches for filtering tabular data

• Client-side filtering. This is fast and simple. Only downside is that since filtering happens on the client, we might miss out on data. Example: if there are more services in ES than already displayed on the screen.
• Server-side filtering. This is more accurate than client side filtering but also less responsive - a lot less responsive in some cases.
• Hybrid: Use client side filtering if we determine that all items have been loaded. Eg. if we know that every available service is already loaded client side, we can filter clientside. And if there are many services (500+), and only a subset have been loaded to the client, we will use server side filtering.

Tables that would benefit from a dedicated search bar:

• Transactions table: Filter by transaction.name
• Errors table: Filter by error.exception.message and error.log.message
• Dependencies table: Filter by dependency.name
• Instances table: Filter by service.node.name

[elasticmachine]

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

[formgeist]

@sqren Just so I understand your suggestion correctly; we would add the ability to filter each of the tables on the Service Overview page? Does this change the current KQL search bar ability in the Overview that allows the user to narrow down all the results on the page to a specific query?

I've illustrated how adding a search bar to each of the table would essentially look

My main worry is that the user would essentially have to manage many separate search bars if they use them unless we make some logic that clears the input upon reload or similar. On top of that, it seems more prudent to ask ourselves what purpose does the current KQL query bar serve. If you add a specific transaction name in the search bar today, you will get results across all entities (transactions, errors, dependencies) that match that endpoint, so that's already a lot of power.

@chrisdistasio @alex-fedotyev Interested in your thoughts here

[chrisdistasio]

i also share a concern over removing kql ability--i expect it is common for customers to search for fields or labels (likely more than by name).

i think the complex naming in instances and dependencies serves as a good example of why it might be difficult to leverage naming for search purposes.

if we were to consider such a change, i would expect we offer the same flexibility to the customer as we implemented for services inventory page--the ability to easily revert to kql query bad AND the telemetry to allow us visibility into how customers are using this.

[sorenlouv]

@chrisdistasio

i also share a concern over removing kql ability--i expect it is common for customers to search for fields or labels (likely more than by name).

Sorry if I wasn't clear. This issue is not about removing kql bar but adding the ability to easily search (filter) data in tables by specific fields. We can do this and still keep the kql search bar at the very top.

if we were to consider such a change, i would expect we offer the same flexibility to the customer as we implemented for services inventory page--the ability to easily revert to kql query bad AND the telemetry to allow us visibility into how customers are using this.

We could do that. But I don't think having an extra kql search bar for each table will add much value since the user already has a kql bar at the very of the page.
My proposal is to add a search component that will make it easy to filter the values in the table without knowing kql or APM field names.

We could start with just adding a search bar for transactions and error tables. They will both have obvious columns (transaction.name and error.*.message) that the user expect to be able to search on.

[sorenlouv]

@formgeist

I've illustrated how adding a search bar to each of the table would essentially look

Thank you for that mockup. That's exactly what I was thinking.

My main worry is that the user would essentially have to manage many separate search bars if they use them unless we

I'm not quite following. The search bar would only filter the table directly below. It won't affect any other components. The inputs will be cleared when navigating away, refreshing etc. We can decide if we also want to clear them when changing time range, or when using the main kql bar.

If you add a specific transaction name in the search bar today, you will get results across all entities (transactions, errors, dependencies) that match that endpoint, so that's already a lot of power

True, the kql search bar is powerfull but it leaves a lot to be desired in terms of UX. Problems:

• If I want to filter a table located below the fold I have to:
  1. Scroll down to see the table
  2. scroll up to find the kql bar
  3. type search query and submit
  4. scroll down to see the results in the table
  5. If I didn't find what I was looking for I have start over. Scroll to the top, do the search, scroll down, rinse and repeat.
  6. A contextual filter bar OTOH wouldn't require the user to scroll up and down, and would be much more responsive (table would be filtered as the user types, and requests would be faster)
• The kql bar doesn't filter the table as the user types. It'll only filter once the user hits enter.
• The kql bar applies to the entire page making every component refetch. This can be very slow.
• The kql bar requires the user to know kql syntax and have knowledge of the fields they need to search by. In you screenshot you search for a value without specifying a field. This will cause a search on every field (slow) and won't work in some cases, eg. try searching for Api::ProductsController#top (invalid kql syntax causing the page to break). And you can't do partial matches like:*::ProductsController#top.

[gbamparop]

@elastic/apm-pm what do you think about this?

[sorenlouv]

This keeps coming up, so now I'm re-opening https://discuss.elastic.co/t/searching-for-apm-services/345599/1

[smith]

Talked through this with @roshan-elastic. I think we can move forward without needing any further product or design input. Moving to ready.

[roshan-elastic]

Hey @sorenlouv - I love your thinking here...adding my feedback so it's not lost:

Hybrid: Use client side filtering if we determine that all items have been loaded. Eg. if we know that every available service is already loaded client side, we can filter clientside. And if there are many services (500+), and only a subset have been loaded to the client, we will use server side filtering.

I think this is my preferred option (c) because of the risks you pointed out of either missing data (client-side only) or slow performance (server-side). I think might have seen you on calls where customers complain when they can't see all of their services.

If I were to use the filter, I'd be frustrated if when searching for 'foo' I didn't find my 'foobar' service just because it wasn't already returned to the client-side.

I love the fast responsiveness of the client-side filter...if we were able to leverage that speed where possible that would be a great advantage.

[sorenlouv]

I think this is my preferred option (c)

@roshan-elastic Great! This is also what I ended up with implementing. WDYT about shipping this soon but behind a feature flag and disabled by default? This way we can get feedback on it and iterate

[roshan-elastic]

@sqren - that's great idea! I was trying to think how we get enough feedback on this without me needing to prioritise this as a focus. This way, if we encounter anyone who complains about it - we can easily tell them to turn it on via the feature flag and get feedback.

BTW I asked Beth (design director) if we could maybe get a little bit of a designers time to get their thoughts...will let you know if we can get someone.

[formgeist]

@autumnbeth is out this week afaik for an offsite, but what specifically do you need feedback on from design to move on?

[roshan-elastic]

@sqren quick question...when I search for a service using the existing search - I do find the service but I need to match it exactly or use * to fill in the gaps:

searching.for.services.mp4

Could you confirm the specific limitations of the existing search that users are complaining about?

It sounds like it may be a few things but wanted to align:

Potential issues

• You must use wildcards to match partial values (not explained to the user)
• You must use exact case
• It's a bit slower than we'd like (i.e. if you only have 20 services and you want to quickly filter those starting with 'checkout' then it needs to do a round trip from the server to limit that list)

Have I captured that correctly?

[roshan-elastic]

@formgeist thanks for jumping on this. We can release it behind a feature flag but we think there might be a wider design pattern that needs to be considered so I wouldn't be comfortable pushing this live for all customers without there being some UX consideration from the design team.

Here is a quick mock of what @sqren is proposing to push out behind a feature flag:

design.mock.-.services.searching.mp4

I'm happy to push this live behind a feature flag but I don't think it's ready to go live for everyone because it looks weird having multiple search bars...I think we'd need to consider the wider design here (for this, I'd want to have this prioritised as a piece of work as it'll need some good design thought I think).

What's the ask?
Right now, I wanted to get a little feedback from design on whether there's way to deliver the above functionality without it being weird for customers...my gut feel is that delivering this in isolation isn't great UX but would love a steer!

Wider pattern?

Here's a quick example of why I think this may be a wider design pattern that needs to be addressed across more of the platform...I have a hunch that there's probably a consistent way to make this good but I don't think we know what that is yet:

design.pattern.-searching.mp4

Note : I don't think we can address this right now without having it prioritised and having the right PM, eng and design resource on it...

[sorenlouv]

@formgeist The kql search bar is not well-equipped to filtering tabular data:

horrible.filtering.experience.mp4