[Metrics UI] Rename "Metrics" to "Infrastructure" in appropriate places

[jasonrhodes]

Summary

The existing Observability navigation is a mixture of monitoring role-based views (APM, Uptime, User Experience) and signal-based views (Logs, Metrics). We want to focus on monitoring roles, so we need to provide an "Infrastructure" view as a top-level sibling of APM, Uptime, and User Experience.

Acceptance criteria

• Change the heading in the top-level Kibana navigation from "Metrics" to "Infrastructure"

📸 Screenshot

• Change the heading in the Observability navigation from "Metrics" to "Infrastructure"

📸 Screenshot

• Change the observability overview widget title from "Metrics" to "Infrastructure" Already renamed to "Hosts"

📸 Screenshot

Other notes:

• Do we want to also change the URL route from /metrics to /infrastructure ? How do we make sure to redirect the old path?
• Can we change the URL path while also leaving the "metrics" feature control untouched to avoid complicated migrations with RBAC?

FAQ

Why are we doing this?

We want to cater to users who are looking for an infrastructure view alongside their application view. The inventory is our most infrastructure-focused page—it doesn't focus on metrics as much as nodes. Each node can be opened to show logs, metrics, and (one day) APM services running on that host, among other things.

We also want to keep the changes as minimal and safe as possible, so a simple rename of a few things should be enough for the change we want.

Who is driving this change?

@jasonrhodes, @katrin-freihofner, @katefarrar, @cyrille-leclerc, and @mukeshelastic had a meeting to discuss this possibility, and together we decided this makes the most sense for catering to an infrastructure-based view.

What about the Metrics Explorer?

The Metrics Explorer allows users to view any number of metrics organized across several layers of grouping and filtering. This has a lot of overlap with the Exploratory View that is under active development, and which leverages Lens visualizations instead of custom charts. Because of this overlap, we intend to investigate the possibility of replacing the Metrics Explorer and directing users who want this functionality to the Exploratory View page at the top level of the Observability app.

Because of this, and to keep these changes as simple as possible, we will leave the Metrics Explorer where it is today (inside the newly renamed Infrastructure section). The default metrics selected for this view are infrastructure metrics (system CPU and system memory).

Why will the Logs UI still be a top-level page and not part of Infrastructure?

The existing Logs UI (by default) contains all logs that can be found in the filebeat-* or logs-* indices/data streams. This includes application logs, infrastructure logs, security logs, and any other logs being ingested for any reason into those general purpose streams. This view is not currently infrastructure-focused or application-focused (in fact it may not even be observability-focused as-is).

Many Elastic customers use Elastic primarily for Logs of all types, so we intend to leave this signal-based view in the top level of the Observability page for now. At a later date, we may rethink this placement altogether.

How does this affect APM and its relationship to Infra/Metrics/Logs?

By making this change, we end up with clear, role-based siblings inside of observability, e.g. "Application Monitoring" | "Digital Experience Monitoring" | "Infrastructure Monitoring". We also gain a more understandable two-way connection between Infrastructure Monitoring and Application Monitoring.

For example, in APM, each service has a tab for "Metrics", "Logs", and "Infrastructure":

As a user, I expect to find:

• Logs tab: application logs for this service
• Metrics tab: application metrics for this service
• Infrastructure: related information about any infrastructure that this service is running on (metrics, logs, etc)

In the Infrastructure view within the inventory, when you expand a given node, it shows tabs for "Metrics", "Logs", and "APM".

At the moment, the "APM" tab is just a link into the APM app, but in the future, we can more easily do something like this:

• Logs tab: infrastructure logs for this node
• Metrics tab: infrastructure metrics for this node
• Applications: a list of services running on this node

[elasticmachine]

Pinging @elastic/infra-monitoring-ui (Team:Infra Monitoring UI)

[miltonhultgren]

Why will the Logs UI still be a top-level page and not part of Infrastructure?
The existing Logs UI (by default) contains all logs that can be found in the filebeat-* or logs-* indices/data streams. This includes application logs, infrastructure logs, security logs, and any other logs being ingested for any reason into those general purpose streams. This view is not currently infrastructure-focused or application-focused (in fact it may not even be observability-focused as-is).
Many Elastic customers use Elastic primarily for Logs of all types, so we intend to leave this signal-based view in the top level of the Observability page for now. At a later date, we may rethink this placement altogether.

This makes me think of this recent Discuss thread.

Is it possible we would promote Discover for general log use cases and focus Observability -> Logs on, well, Observability? And further split this into Infra Logs and Application logs under APM and Infrastructure? (similar, putting Security logs under the Security solution).

How to slice those streams is a key question, and if we should exclude them from Discover in some smart way? I imagine that maybe one option is to not provide the (too wide) filebeat-, logs- data views (since Beats ship things more narrowly?)

[katrin-freihofner]

@miltonhultgren thanks for linking this discussion, this is super interesting.

[miltonhultgren]

@weltenwort and I have discussed the Log stream settings while talking about #120920 (enabling curated views) but we didn't have an issue for it so I made one #124011

[jasonrhodes]

Is it possible we would promote Discover for general log use cases and focus Observability -> Logs on, well, Observability?

Yes and no. The idea of the Logs UI is that it is a UX catered to Logs in a way that Discover was, in theory, not. I think the options are probably:

• Merge the log stream back into Discover, but as a separate mode of exploration
• Move the log stream back into the Kibana stack as a sibling of Discover, and make it wrap the Discover components and add functionality specific to log stream viewing, etc.
• Move the log stream as-is up to a higher level in Kibana, not wrapping Discover but not living inside of Observability

So I don't think we'd promote Discover as it is today for general log use cases. But whichever of these options we move forward with, I believe this general purpose Logs UI should export components for more focused use. Those are the components we would incorporate more fully into observability user flows. Maybe that's a full log stream page with an embedded log stream component that is focused on observability logs, maybe it's smaller components that are sprinkled throughout the observability UIs, maybe it's other things or all of these things. I think the possibilities are broad and pretty exciting!

[matschaffer]

Noting that the Observability Overview Widget was already renamed to "Hosts" in

https://github.com/elastic/kibana/pull/124702/files#diff-37ba1cdc92c54dac789cbf86c05d19f7ccbbacac2967e86d756d80adc7d40548R205

cc @formgeist for awareness of this issue since I can't readily find the issue regarding the change from Metrics -> Hosts

[matschaffer]

Responding to some points that @jasonrhodes had in the description

Do we want to also change the URL route from /metrics to /infrastructure ? How do we make sure to redirect the old path?

Thinking no

Can we change the URL path while also leaving the "metrics" feature control untouched to avoid complicated migrations with RBAC?

N/A based on above.

---

Also looks like most of the thread above is related to the balance between Logs UI & Discover which I'm considering out of scope for this issue. #134412 is probably the place to look for updates on that topic.