Closed pmuellr closed 3 years ago
Pinging @elastic/kibana-alerting-services (Team:Alerting Services)
note: I could swear we already had an issue for this open, after we added the alert duration to the active-instance events
wops - found it - so closing in favor of that one - https://github.com/elastic/kibana/issues/101662
The calculation of the "alert duration", we are doing today is expensive. The relevant code is in this module:
x-pack/plugins/alerting/server/lib/alert_instance_summary_from_event_log.ts
which is called from here: https://github.com/elastic/kibana/blob/946e145e51b201e873a61b2ede05b215ce33b905/x-pack/plugins/alerting/server/rules_client/rules_client.ts#L453-L463Basically, in previous releases, we didn't have the alert duration available directly in active-instance events, so we had to calculate it by finding the closest new-instance event. The date on the new-instance event becomes the
activeStartDate
in the AlertInstanceStatus: https://github.com/elastic/kibana/blob/946e145e51b201e873a61b2ede05b215ce33b905/x-pack/plugins/alerting/common/alert_instance_summary.ts#L28-L34There were problems with this approach anyway, as the query getting the event log docs may not have gone far enough back to find a relevant new-instance event. But the big win will be not having to return all the event log docs, to get the alert duration, we can just get the last active-instance event, which contains the duration.
Another optimization we could make is to move the alert duration into the task manager state, shape here, since I think we already have to get the task manager state whenever we calculate the alert instance summary: https://github.com/elastic/kibana/blob/946e145e51b201e873a61b2ede05b215ce33b905/x-pack/plugins/alerting/common/alert_instance.ts#L11-L21