mirror of
https://github.com/elastic/kibana.git
synced 2025-06-27 18:51:07 -04:00
cd727fa190
resolves https://github.com/elastic/kibana/issues/142874 The alerting framework now generates an alert UUID for every alert it creates. The UUID will be reused for alerts which continue to be active on subsequent runs, until the alert recovers. When the same alert (alert instance id) becomes active again, a new UUID will be generated. These UUIDs then identify a "span" of events for a single alert. The rule registry plugin was already adding these UUIDs to it's own alerts-as-data indices, and that code has now been changed to make use of the new UUID the alerting framework generates. - adds property in the rule task state `alertInstances[alertInstanceId].meta.uuid`; this is where the alert UUID is persisted across runs - adds a new `Alert` method getUuid(): string` that can be used by rule executors to obtain the UUID of the alert they just retrieved from the factory; the rule registry uses this to get the UUID generated by the alerting framework - for the event log, adds the property `kibana.alert.uuid` to `*-instance` event log events; this is the same field the rule registry writes into the alerts-as-data indices - various changes to tests to accommodate new UUID data / methods - migrates the UUID previous stored with lifecycle alerts in the alert state, via the rule registry *INTO* the new `meta.uuid` field in the existing alert state. |
||
|---|---|---|
| .. | ||
| alerting | ||
| commands | ||
| dashboard | ||
| graph | ||
| images | ||
| introduction/images | ||
| ml | ||
| monitoring | ||
| production-considerations | ||
| reporting | ||
| security | ||
| troubleshooting | ||
| api.asciidoc | ||
| canvas.asciidoc | ||
| dev-tools.asciidoc | ||
| discover.asciidoc | ||
| index.asciidoc | ||
| introduction.asciidoc | ||
| management.asciidoc | ||
| plugins.asciidoc | ||
| setup.asciidoc | ||
| whats-new.asciidoc | ||