[Infra] Comparing Hosts within a Service

[roshan-elastic]

Problem

When SREs debug problems with a Host which are running services, it is often important to check whether the issue is specific to the host or if it is common to other hosts running the same service. This helps them figure out if they need to dig further into the Host itself or whether they should start investigating the service:

Example flow

Currently, we allow users to filter by a service in the Hosts List an compare them:

Comparing all hosts running a service

Tip! Users want to compare aggregates and trends per host to figure out if the problem is to do with the host or the service

😢 Pain-point

Our pain-point is that if a user is viewing a single host via the fly-out or the full screen detail view, they either:

(a) may not find this functionality
(b) have to find spend a few clicks to do the comparison

For example:

Viewing fly-out-screen view of a host

Viewing full-screen view of a host

This is slightly challenging as the user isn't in the Host List at the moment, so we can't simply apply a filter to the host list running in the background.

Solution Proposal

Can we allow users to simply click on something in the host fly-out/detail views which will take them directly to the Host List filtered by the service they selected?

Users should be able to easily compare all the hosts that a service is running on

🎨 Latest Designs

Figma designs.

✔️ Acceptance criteria

TBC

[roshan-elastic]

@smith - Do you think this is something we should consider with the on-going work in the APM <> Hosts project or should we prioritise this for another project?

(cc @neptunian)

[elasticmachine]

Pinging @elastic/obs-ux-infra_services-team (Team:obs-ux-infra_services)

[roshan-elastic]

@smith I've moved this issue to the Hosts to GA phase 2 so we don't add to the scope of the APM <> Hosts project.

[roshan-elastic]

@smith - was just discussing this with @neptunian (coincidentally) and she thought it made sense to do this as part of the APM <> Services project (i.e. whilst she's doing it now).

Do you think you could have a chat and see if it's more efficient to tackle this now? I'd prefer to try and do it now if it's more efficient to do it now (rather than later) - I'm hoping this can be part of getting to Hosts to GA (so doing it in the most time efficient way is my preference)

[neptunian]

Since this is basically just adding the option to filter back to the hosts page on service.name, i'd rather at least get the final design for this going so i'm not building the UI as a list of pills and then having to change it immediately to a table or something. I think it makes sense to have it in the same project.

[roshan-elastic]

@kkurstak - see @neptunian's comment above.

Just to add on our brief discussion on this, I think it's important that the user can quickly filter to see all hosts the services running on without needing to click through to the service.

For example, if you see the CPU is high on a host - one task would be to quickly check how this is running across all hosts without needing to go into the service...especially if you're a user who focuses on infrastructure:

• If you see that only a particular host has high CPU...
  • you may dig into the host in more detail.
• If you see that all hosts with this service have a consistently high CPU...
  you could hypothesise there is a problem with the service (and then start looking into the service and checking if there has been a release - something like 80% of problems with services are due to new releases)

I think there should be an option for a user to get to a list of the hosts the service is running on and compare metrics (i.e. the host list) without needing to go through other screens first.

Does this make sense?

[roshan-elastic]

Update

cc @neptunian @kkurstak @smith

After speaking with @smith yesterday, we agreed to include this within the project scope of the Seamless Hosts <> APM as it saves time overall. Here are the main points:

• It's on-week so we need to be mindful of @neptunian's time
• @kkurstak is on holiday next week so we have this week to get the designs completed
• It's relatively design heavy so @kkurstak and @roshan-elastic will work on it primarily (but any support @neptunian can lend to collaborate would be greatly appreciated!)
• Given it's on-week, we'll limit @neptunian's time to one or two time-boxed calls (but we'll take any time we can get!)

@neptunian - Will that be OK for you?

If @kkurstak needs to reach out to collaborate with you on it - do you think that would be OK if it's a light touch?

[roshan-elastic]

Update

Hey @neptunian (cc @smith),

@kkurstak and I have been looking at some possible designs on this and would love your help refining these.

Karolina is away from Wednesday (and there is no overlap for a call) so she will share the design ideas here for collaboration.

Could we work async on this Mon/Tue to see what makes the most sense?

[kkurstak]

Hey Team, the designs are available to review under this link. They are not perfect, a quick hi-fi sketch of what we were thinking of.

[roshan-elastic]

Hey @kkurstak (cc @neptunian),

I walked through the designs with @smith and although I loved the designs, we agreed that the scope is a little to big to try and tackle...it would be more work than can be justified right now.

Updated scope

Based on the engineering feedback, we'd like to reduce the scope down significantly to:

• Keep the 'service' badges design but have a simple icon to allow users to filter the host list by the service name*
• When the user clicks on the filtering icon, it will take them to the host list but filter by that service (if the host list is in the background, it'll just apply the filter and remove the fly-out)

*this is because Sandra will actually be delivering the existing 'badge' design before we work on this issue so it's simplest just to add a simple filtering mechanism to it

@kkurstak - Do you think you could propose a new design based on the badge design but with some kind of filtering icon?

I'm wondering whether we should think about adopting the same kind of icons users are used to in Discover (given almost all users will be familiar with filtering in Discover):

Filtering in Discover

Filtering in Dashboards

Either way, I think we probably want to follow the same design pattern between the metadata tab filtering and this new functionality in the service filtering we're proposing here so users know what to expect.

The only problem here is that the Discover functionality doesn't align with how we're filtering in the metadata tab:

Metadata tab

Do you think we should continue the same filtering pattern we see in the metadata tab in this new functionality or do you think we should re-think whether we want to adopt the discover pattern both in this new service issue and updating the metadata filtering pattern too?

My thinking here is that users should see familiar patterns around the whole UI where we can facilitate this.

What do you think?

[roshan-elastic]

Hey @smith - I moved this to hosts MVP phase 2 so that we can close the Hosts <> APM project to simplify things...hope that's OK:

• https://github.com/elastic/observability-dev/issues/2868

[crespocarlos]

@roshan-elastic , I have some questions about this feature

Viewing fly-out-screen view of a host

What happens when we start using the flyout in other pages? Will we disable this feature or redirect the user to the hosts view? Applying filters to the Hosts View from the flyout can create an undesired dependency between them, that will make it harder to reuse the flyout elsewhere. Besides, it doesn't seem like too much effort for users to close the flyout and use the Service Name filter in the Hosts view.

Viewing full-screen view of a host

Instead of showing just a count, why don't we show a table similar to what APM shows?

This got me thinking whether we could reuse APM functionality in the flyout. Or even if we should just redirect the user to APM and improve the navigation flow. Showing other instances that are running a giving service sounds like APM's domain

[roshan-elastic]

Hey @crespocarlos - good thinking.

Maybe we should take a step back on this and wait to see how we show the relationships between services, containers and hosts?

We'll want to update the host view to show the container and the services per container too...Karolina will be doing some design on this at some point so perhaps we should defer until then?

We may find we close this ticket as a result.

WDYT?

[kkurstak]

Hey @roshan-elastic - I'm going to get to this now. This issue was missing the Design project badge and I was not seeing this on my board, apologies.

[roshan-elastic]

Closing this as it is superseded by the following parent ticket:

• https://github.com/elastic/observability-dev/issues/3295

Helpful as a reference to the above issue though.