Alert instances view to display data from event log instead of current instances

[mikecote]

We currently display the current alert instances now that #56842 got merged. This issue is the following step which would be to display from history with a start and stop column showing the duration of each instance.

[elasticmachine]

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

[pmuellr]

Seems like an nice "extension" to the current UI would be to show all the alert instances seen over some interval like a day (fixed for now, customizable later) and their most recent start/stop/durations.

Here's the current view:

Changes would be that you would see more instances - every instance that scheduled actions within the last 24 hours. And we'd start seeing inactive instances, not just active ones.

This will likely end up making us add some filtering/sorting - you might want to sort by instance/status/start/duration, and you might want to filter by instance and status, as a separate issue/PR ...

We'll have a semantic issue if we find an instance that was resolved within the time period we query over, but not the start of that instance. For these we're back into an "unknown" state, though we do know the minimum amount of time it has been active (the resolved time - the start time of the query we run) - duration could be something like "at least two hours" or "over two hours", kinda thing.

[mikecote]

@mdefazio to provide latest mockup of what the alert instances look like in the alert details page once data is pulled from event log.

[pmuellr]

I'd be happy to pair with someone on this; I'm very familiar with the event log :-)

[gmmorris]

I took a quick look at the current code to get a mental model of the pieces we need to put together:

1. We currently have a component called AlertInstancesRoute that wraps the AlertInstances and has one job - which is to load the state of the alert and pass it into the AlertInstances when it's mounted. I think it would make sense to start by adding an event-log api to with_bulk_alert_api_operations.
2. Once we have a new api in with_bulk_alert_api_operations we can use it in AlertInstancesRoute to fetch the default events and pass a function through to AlertInstances that will allow us to refresh the events that are passed to the AlertInstances whenever the filtering props are changed.

Hopefully by then we'll have a fresh design and we can change the table in AlertInstances to render the events rather than the state.

One problem we need to address is that we would, presumably, calculate the duration by looking back along the api response at how long an instance persists across execution cycles. The problem here is that if the time window specified by the user dictates how many events we fetch from the API then we can only ever evaluate duration as far back as that time window. This means that if, for example, the user specifies they want to see a time frame of "last 15 minutes" then the longest duration any single instance could have is 15 minutes, even if it has been going off for an hour.

@mdefazio We need to think about how we might want to express that a specific instance runs all the way back to the edge of the time frame... possibly exceeding it. 🤔

[mdefazio]

Sorry I'm a bit late on this. Here's the current-ish mockup. (Not showing Andrea's updates to the top section). Let me know what makes sense to show in the table and we can update the mockup.

[arisonl]

• Should the status values correspond to the states offered by the alert (e.g. ok, warning, minor, major etc.) rather than active/inactive?
• What does Duration show if the selected period from the time picker includes multiple occurrences (start-end) of the same instance (e.g. long selected period)? Are we only showing the last one? Conversely, what does Duration show if it includes a partial occurence of an instance (e.g. short selected period)? Should we have an End field next to Start as well?

[arisonl]

Notes on the chart: #56280 (comment)