[Metrics App] Re-think inventory time picker and workflow

[jasonrhodes]

Currently, the Inventory page uses a single point-in-time value to query for data from "the previous 20 minutes", then we use the data that comes back from that query to group and find the "last minute" of data available for each host/pod/container found in the first query.

How do we expect users to interact with this page, especially in the context of coming from another area in observability while investigating an issue?

For example, say a user is investigating anomalous slow speeds in a series of APM traces that happened over the last 2-3 hours. They've locked the range from 09:00 to 12:00 and want to investigate their host metrics over this time period to see if there is a correlation. With the work set to be done in #79301, we would show the user the host metrics for 11:59-12:00 (having pre-filtered to only show hosts that have data from 11:40-12:00). What would a user expect to find if they arrived at the Inventory page in this scenario? What do we think they want?

Possible alternative workflows:

• When we detect that a time range has been selected by the user, we could open the new timeline feature and have it scoped to the selected time range, and then choose a point in time from that range to show in the waffle map. The point in time could be dictated by a link, e.g. if a user was investigating a range of logs but clicked through from a specific log, the point in time might match the timestamp of the selected log
• We could always direct users to metrics explorer when they are investigating a time range (I'm not sure if this solves the issue, really)
• We can mostly ignore the time range like we are already doing, but this feels like it breaks the investigative experience

I like the first option of these alternates because it immediately presents the user with any other anomalies/alerts/spikes that may have occurred in the range they are investigating but still allows them to click around inside that range -- I'm not sure how this idea squares with the timeline as it is "usually" used, though.

[elasticmachine]

Pinging @elastic/logs-metrics-ui (Team:logs-metrics-ui)

[Zacqary]

When we detect that a time range has been selected by the user, we could open the new timeline feature and have it scoped to the selected time range, and then choose a point in time from that range to show in the waffle map. The point in time could be dictated by a link, e.g. if a user was investigating a range of logs but clicked through from a specific log, the point in time might match the timestamp of the selected log

+1 on this. Maybe we can cache a significant chunk of waffle maps per data point on the timeline, so that the user can click around with minimal reload latency? If we assume the waffle map is a visualization of a single point on the graph, the UX of scrubbing along the graph to investigate values would be really nice to preserve.

Note that we're already fetching 20 buckets for each snapshot request, and just displaying the most recent bucket on the waffle map. If we increase the lookback interval to compose the entirety of the timeline, I don't (think) it would create an too excessive an amount of overhead?

[jasonrhodes]

If we assume the waffle map is a visualization of a single point on the graph, the UX of scrubbing along the graph to investigate values would be really nice to preserve.

Yeah, exactly. This dovetails nicely with the other conversation we need to have about the waffle map re: scaling with lots of hosts and how the UI breaks down at a certain point. If we can solve that it will help us feel more confident about caching other points in time in a timeline as well.

[maggieghamry]

I've gotten a request in addition to standardizing the same date/time picker throughout the Kibana UI, but also to allow/expand time selection, so users aren't limited to only 1 minute or 30 second increments, but have a time selector that can choose a wider custom timeframe, for example, 1 hour, 2 hours, etc. I think it could be valuable to offer additional flexibility, without the ability to exceed a certain threshold that would make the Metrics Inventory app more flexible and useful in certain situations.

[jasonrhodes]

@katefarrar I know we spoke about this a few weeks ago, can you link any ongoing design work to this ticket so we can track? If we move to a new set of tickets, we can close this one in favor of those.

[roshan-elastic]

Great idea - moving out of backlog though as we don't intend to spend significant time on the existing inventory view in the near future (aside from quick wins).

Will pull back in when we decide to focus on the existing inventory.

[roshan-elastic]

Closing this for now as we aren't planning on revisiting inventory right now (will ensure this bubbles up when we do though to save us time)