[Infra] Add 'Show in Hosts list' button in for host anomaly drop-down

[miloszmarcinkowski]

Closes #174856

Summary

This PR adds new 'Show affected Hosts' button in host anomaly drop-down in ML anomaly detection fly out. It applies host.name filer in hosts list and the same date range that user selected in ML fly out.

Testing

1. Go to Inventory or Hosts page
2. Click ML anomaly detection button at the top
3. Select Anomaly tab from the fly out
4. Change date range to make sure it applies to Hosts page
5. Click three dots button (more actions) and click 'Show affected Hosts'
6. User is taken to Hosts page, host.name filters are applied to display relevant hosts and the same date range as in ML fly out is applied

[obltmachine]

:robot: GitHub comments

Expand to view the GitHub comments

Just comment with:

• /oblt-deploy : Deploy a Kibana instance using the Observability test environments.
• run docs-build : Re-trigger the docs validation. (use unformatted text in the comment!)

[elasticmachine]

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

[miloszmarcinkowski]

/oblt-deploy

[miloszmarcinkowski]

/oblt-deploy-serverless

[miloszmarcinkowski]

Nice 💯 Thank you for adding that! I found an issue with the k8s job when clicking on the Show in Inventory

Screen.Recording.2024-08-27.at.19.23.28.mov ( Did you see this error before? it could be something in my env because I am not getting any host anomalies (only k8s) with my oblt cluster I will double-check and recreate it tomorrow)

I added some suggestions/nits as well.

@jennypavlova This was the issue before. I tried to fix it by adding missing context providers, but it didn't help (fixed console errors though). I couldn't come up with an idea for solution so I created a new ticket for it. Thank you the comments, I'll look into that later 🙌

[roshan-elastic]

Looks good 👏! I just left a few comments.

I'm confused with the goal of this change, though.

@roshan-elastic why don't we redirect the user to the asset details instead of the hosts view? IMO, if users see the anomalies table from the top nav on the Inventory UI or Hosts View, we should show the link to hosts, redirecting to the asset details. If they see the table on the asset details, I wonder what benefit redirecting the user back to the hosts view brings.

Sorry guys, absolute brain fail on my part here.

Playing out the scenarios here:

1. Someone is viewing a host view (full screen) and sees an anomaly within the anomaly tab They click 'show in hosts list' and it takes them through to that host in the host list

2. Someone is viewing a host view (fly-out) and sees an anomaly within the anomaly tab (perhaps within Inventory) They click 'show in hosts list' and it takes them through to that host in the host list

3. Someone is viewing the 'anomalies' section in Inventory or the Host List and see a host with an anomaly

• They see the host has an anomaly and want to learn more
• new Maybe we want a 'view host' option here which takes them through to the host view (full screen)

What do you think?

[crespocarlos]

@roshan-elastic

1. Someone is viewing a host view (full screen) and sees an anomaly within the anomaly tab They click 'show in hosts list' and it takes them through to that host in the host list

if someone is already in the hosts details, why would they want to go to the hosts list? Should there even be an option to redirect the user? The host details is where users will find more complete info about a host.

2. Someone is viewing a host view (fly-out) and sees an anomaly within the anomaly tab (perhaps within Inventory) They click 'show in hosts list' and it takes them through to that host in the host list

If someone is viewing the hosts flyout, the anomalies tab will only show anomalies for that host. It's the same question I have for nr. 1 because all info about this host is already found on the flyout

3. Someone is viewing the 'anomalies' section in Inventory or the Host List and see a host with an anomaly

• They see the host has an anomaly and want to learn more
• new Maybe we want a 'view host' option here which takes them through to the host view (full screen)

What do you think?

IMHO, perhaps the "view in hosts" should only be shown when someone views the anomalies within the Anomaly detection top nav. This shows all anomalous hosts, so if someone wants to learn more about problems in a particular host, they can be redirected to see more details.

[miloszmarcinkowski]

@roshan-elastic @crespocarlos

1. Someone is viewing a host view (full screen) and sees an anomaly within the anomaly tab They click 'show in hosts list' and it takes them through to that host in the host list

if someone is already in the hosts details, why would they want to go to the hosts list? Should there even be an option to redirect the user? The host details is where users will find more complete info about a host.

2. Someone is viewing a host view (fly-out) and sees an anomaly within the anomaly tab (perhaps within Inventory) They click 'show in hosts list' and it takes them through to that host in the host list

If someone is viewing the hosts flyout, the anomalies tab will only show anomalies for that host. It's the same question I have for nr. 1 because all info about this host is already found on the flyout

For me, the only situation in which taking users to the 'hosts list' makes sense is when there are multiple hosts in a single anomaly. This allows users to browse them from the 'hosts list'.

Based on my research, this situation is possible only in ML fly-out:

In host 'fullpage' or 'fly-out' views we can display multiple anomalies but with single host:

I support Carlos's opinion about no point for taking users back to 'host list' when browsing host 'fullpage' or 'fly-out' view. But for ML fly-out I suggest:

1. For single host anomaly -> take user to asset detail page (fullpage host view)
2. For multiple host anomaly -> take user to 'hosts list' view

Wdyt?

[miloszmarcinkowski]

Bonus question:

I see some inconsistency in date range between ML anomaly detection (default: last 30 days) and hosts list (default: last 15 mins). This results in users that might not see hosts in hosts list when coming from ML anomaly detection. My suggestion in to apply 'last 30 days' data range when clicking 'Show in Hosts'. Wdyt?

Problem illustration:

[crespocarlos]

Bonus question:

I see some inconsistency in date range between ML anomaly detection (default: last 30 days) and hosts list (default: last 15 mins). This results in users that might not see hosts in hosts list when coming from ML anomaly detection. My suggestion in to apply 'last 30 days' data range when clicking 'Show in Hosts'. Wdyt?

Agree 100%

[roshan-elastic]

if someone is already in the hosts details, why would they want to go to the hosts list? Should there even be an option to redirect the user? The host details is where users will find more complete info about a host.

Sorry @crespocarlos @miloszmarcinkowski - I'm rushing this and making mistakes. Let me slow down :)

For me, the only situation in which taking users to the 'hosts list' makes sense is when there are multiple hosts in a single anomaly. This allows users to browse them from the 'hosts list'.

Nice catch - I didn't even know that was possible. Yes!

For single host anomaly -> take user to asset detail page (fullpage host view)

Agreed. If you're in a host detail view > anomalies - we probably don't need any call to action at all (since you're already in the host)?

To summarise:

1. If in the 'anomalies' section of the overall AD section:

a. If a single host anomaly, give them the option to open the full screen view for that host b. If a multiple hosts for the anomaly, give them the option to open these host list filtered by the host names

2. If in the host view > anomalies section:

a. If a single host anomaly, no option to open in hosts. b. If a multiple hosts for the anomaly, give them the option to open these host list filtered by the host names

Does this make more sense?

[miloszmarcinkowski]

@roshan-elastic

Agreed. If you're in a host detail view > anomalies - we probably don't need any call to action at all (since you're already in the host)?

exactly, we'll display only Open in Anomaly Explorer inside the dropdown

If in the host view > anomalies section: image a. If a single host anomaly, no option to open in hosts. b. If a multiple hosts for the anomaly, give them the option to open these host list filtered by the host names

Not exactly, this is exactly the same view as in host detail view > anomalies. And those are multiple anomalies for the same host, therefore no need for 'Show in Hosts' action button. Can you confirm? :)

[crespocarlos]

Hey @roshan-elastic. Thanks

1. If in the 'anomalies' section of the overall AD section: a. If a single host anomaly, give them the option to open the full screen view for that host b. If a multiple hosts for the anomaly, give them the option to open these host list filtered by the host names

To simplify I would opt for either a. or b. If we want to redirect to the host list, to give users the ability to search for/view other hosts, then let's go for b.

If the purpose is to allow users to drill down the problem for a particular host, then let's go for a.

host list filtered by the host names

The problem is that "view in host" is an action for a single host or row. What would make more sense if we want to do this would be to add another button outside the table that would collect all host names and send them to the hosts view. But that sounds like another feature.

2. If in the host view > anomalies section: a. If a single host anomaly, no option to open in hosts. b. If a multiple hosts for the anomaly, give them the option to open these host list filtered by the host names

In this case, it will never show anomalies for multiple hosts. it's always show anomalies for the host the flyout/page was opened for

[roshan-elastic]

Cheers it @miloszmarcinkowski @crespocarlos

To simplify I would opt for either a. or b.

I think (a) would be a better user experience unless it's for multiple hosts (where 'b' would be better). Are we saying it's easier to make a trade-off by choosing 'a' or 'b' (vs investing in catering for both scenarios)?

If in the host view > anomalies section:

Ah got it. In which case, we don't need to show anything. Is that what you're thinking too?

[crespocarlos]

@roshan-elastic

I think (a) would be a better user experience unless it's for multiple hosts (where 'b' would be better). Are we saying it's easier to make a trade-off by choosing 'a' or 'b' (vs investing in catering for both scenarios)?

"View in host" is an action for a single host, the option is available per row. For b. what would make more sense would be to add another button outside the table that would collect all host names and send them to the hosts view. But that sounds like another feature.

Let's schedule a quick call with @miloszmarcinkowski to sort this out.

[roshan-elastic]

Sounds good - put one in for tomorrow!

[miloszmarcinkowski]

@roshan-elastic @crespocarlos

I'll try to wrap it up:

• There is no point to display 'Show in Hosts' button for 'host full page view' and 'host fly out' because users already see host details. Action: we remove 'Show in Hosts' button for those two views and keep it only in ML anomaly detection fly out view.

• Option 1: For anomalies with single or multiple hosts we always take users to the Hosts page. Pros: Users can browse multiple hosts if this is the case. Cons: It might be confusing for single host anomaly, but users still have an option to click full page view or fly out to see more details.

• Option 2: For anomalies with single host we display 'Show in Host' -> take users to full page host view. For anomalies with multiple hosts we display 'Show in Hosts' -> take users to Hosts list. Pros: handle two cases appropriately. Cons: users can't say if anomaly is single or multiple hosts from ML fly out view. So, it's confusing to them because sometimes are taken to Host full page view and sometimes to Hosts list. Solution would be having a tooltip in ML fly out which shows on hover more hosts in anomaly (credits @crespocarlos). All of this increases scope a lot, so we might consider it Part 2 because it doesn't interfere with Option 1.

• Option 3: For anomalies with single or multiple hosts we always take users to the "Host full page view'. Not an option because it doesn't handle anomalies with multiple hosts.

Sorry if this is chaotic, but I wanted to write it down until I remember it. Let me know what do you think. Thanks!

[miloszmarcinkowski]

Take away from the meeting:

• we stick to option 2
• change button label to "Show affected Hosts"

[miloszmarcinkowski]

@crespocarlos @jennypavlova

PR is still pending CI check, but I think you can go ahead and redo review. Many thanks for your help 🙌

[miloszmarcinkowski]

@crespocarlos

Are the changes in the translation files just to sort the keys alphabetically?

I just run node scripts/i18n_check.js --fix to make sure that nothing gets broken after I updated translation (button label). Yeah, I noticed it, also it happened that none of those changes applies to my translation. However, I decided to keep it because anyway someone will run the script and this will get updated.

But, I'll drop that commit because it causes confusion.

[kibana-ci]

:yellow_heart: Build succeeded, but was flaky

• Buildkite Build
• Commit: 507c2576fdfef193cb54f5dab2be2554a3c791f2
• Kibana Serverless Image: docker.elastic.co/kibana-ci/kibana-serverless:pr-191168-507c2576fdfe

Failed CI Steps

• Jest Tests #12
• Jest Integration Tests #3
• Jest Integration Tests #6

Test Failures

• [job] [logs] Jest Tests #12 / When rendering PolicySettingsLayout and user has Edit permissions should allow updates to be made

Metrics [docs]

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id	before	after	diff
observabilityShared	443	444	+1

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
infra	1.5MB	1.5MB	+701.0B

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
observabilityShared	68.7KB	68.7KB	+62.0B

Unknown metric groups

API count

id	before	after	diff
observabilityShared	448	449	+1

History

• :green_heart: Build #231261 succeeded 833662cac5ade1a57da2da789dd85a24feb515e4
• :yellow_heart: Build #231178 was flaky aa50a783c305d4afa98273b757e02a5c8b3e2d44
• :green_heart: Build #231133 succeeded de9485663b879a4a2216ad50940bc17acd218684
• :yellow_heart: Build #231078 was flaky bb3c556143dad5e09c05952d0fbe253e476aa39e
• :broken_heart: Build #230786 failed ebea83ec3a5d7a71385b2abc660cbf85db42c88a

To update your PR or re-run it, just comment with: @elasticmachine merge upstream