[Infra Monitoring UI] Investigate differences between metric values in the Metrics UI

[miltonhultgren]

In the aftermath of adding the metrics tables I'm left with many doubts about the data we present in the Metrics UI. Mainly questions around which fields we use for what (and if those are correct), how those fields are aggregated (timespan, bucketing logic, post processing) and how they are then displayed (which chart we use, where auto scaling of values happen and where not).

From a simple look, comparing values in the Inventory page and the Node details page we can see simply that values are reported differently, this may primarily be due to the unique timeframe that the Inventory page uses.

The outcome I would like from this issue is a list of which fields are used for what when we describe hosts/container/pods in the Inventory page and the Node details page, and how we arrange the timespan/buckets/aggregations for those fields and any possible post processing we apply before showing these values, in order to understand where differences may exist.

In follow up we can discuss if any changes need to be made or if it's enough that we can explain what happens and why things differ, and further if we need to account for the Metrics Explorer and Infrastructure metrics tables in this evaluation as well.

[elasticmachine]

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

[miltonhultgren]

For example, the Container metrics table uses values from the Kubernetes Metricbeat module, but the Inventory page writes "Docker containers" which hints at using the Docker Metricbeat module as it's source.

[roshan-elastic]

@miltonhultgren - I'm wondering when would best to prioritise this? Do you get a sense that a lot of stuff needs to be looked at or is it just a complete unknown at the moment?

@smith - If we had this list (output of this issue), do you think these issues might be best tackled as we address each asset type (e.g. if we migrate the existing 'pod' view to use the new detail view/fly-out) or do you think distinct pieces of work would be needed to 'fix' issues?

Trying to get a sense of when it makes sense to prioritise this (and also how much effort it might be)?

[smith]

@roshan-elastic I think we'll need these values for every asset type, and it would be good to have transparency into what the UI was doing. Not sure about prioritization.

[roshan-elastic]

Cheers @smith,

Perhaps it makes sense to tackle each asset at a time (e.g. when we start looking at containers...we'd audit them)? If that works, I think we could incorporate a task like this each time.

[elasticmachine]

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

[botelastic[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[smith]

We're not prioritizing this at this time.