-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RAC][Rule Registry] Add unique ID field for identifying all alerts created during a specific Rule execution #110135
Comments
Pinging @elastic/kibana-alerting-services (Team:Alerting Services) |
Pinging @elastic/security-solution (Team: SecuritySolution) |
++ for this enhancement 👍 I have a few random thoughts:
|
That sounds good to me! Note that within the AAD schema the
All the better! 🙂 We'll still need to add it to the alert(s) being written within the RuleRegistry abstractions, but agree it makes most sense to have the alerting framework generate and inject this value. |
It should be fairly easy to make the alerting framework provide such uuid (PRs welcome! 🙂). I think adding some code here is all that is necessary. At the same time, if you want to add alert uuids to the framework (to align with alert as data ids), it can be done in this file. Probably somewhere in the |
## Summary Resolves: #110135 This PR is for introducing a new UUID (`kibana.alert.rule.execution.uuid` as defined in the AAD schema) for identifying individual rule executions. This id is introduced as a `private readonly` member of the [alerting server task_manager](https://github.com/elastic/kibana/blob/a993668663dd4fc25d3336e2d474101ed8d1b74d/x-pack/plugins/alerting/server/task_runner/task_runner.ts#L123), and plumbed through the `executionHandler` and to all appropriate alert event and event-log touch points. For persistence when writing alerts within the RuleRegistry, `kibana.alert.rule.execution.uuid` is plumbed through [`getCommonAlertFields()`](https://github.com/elastic/kibana/blob/c81341c325edcb0eaca1dab2521b2a86fea18389/x-pack/plugins/rule_registry/server/utils/get_common_alert_fields.ts#L52) so it is grouped with like fields and is picked up by both the [`createPersistenceRuleTypeWrapper`](https://github.com/elastic/kibana/blob/c81341c325edcb0eaca1dab2521b2a86fea18389/x-pack/plugins/rule_registry/server/utils/create_persistence_rule_type_wrapper.ts#L38) used by Security Solution, and [`createLifecycleExecutor`](https://github.com/elastic/kibana/blob/d152ca5b6bf7f56fcba1d1d8c2cfee5404a821de/x-pack/plugins/rule_registry/server/utils/create_lifecycle_executor.ts#L157) used by Observability rules. Additionally on the Security Solution side, `kibana.alert.rule.execution.uuid` was plumbed through the `RuleExecutionLog` so that all events written to the event-log will now include this id so individual rule status events/metrics can be correlated with specific rule executions. No UI facing changes were made, however `kibana.alert.rule.execution.uuid` is now available within the Alerts Table FieldBrowser, and can be toggled and viewed alongside alerts: <p align="center"> <img width="500" src="https://user-images.githubusercontent.com/2946766/149594433-b16e369b-adf4-4ae3-b6e9-98189b214d51.png" /> </p> As visible when exploring `event-log` in Discover: <p align="center"> <img width="500" src="https://user-images.githubusercontent.com/2946766/149595237-155d25d7-8324-4981-9ec2-faf0af8e7bd7.png" /> </p> ### Checklist Delete any items that are not applicable to this PR. - [ ] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - Will need to sync with Doc folks on updates here. - [X] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios
This enhancement is for adding a new field to the global Alerts as Data schema for identifying all alerts created during a specific rule execution. This unique ID can also be logged out via the Rule Execution log to enable the ability to query for all alerts generated from that execution cycle. This is also useful for segmenting alerts within the UI when investigating further or debugging/tuning rules.
Currently, the closest field we have to this are the following two
group
fields:kibana.alert.group.id
kibana.alert.group.index
However they're currently used exclusively by EQL rules within Security. In our last schema sync, @marshallmain mentioned we could potentially move off of using these fields in favor of leveraging the evaluation event concept, so it's possible we could just go ahead and repurpose these fields for this enhancement (populating
kibana.alert.group.id
and removingkibana.alert.group.index
). Alternatively, we could create a new field, e.g.kibana.alert.rule_execution_id
.At this time I don't think there's any need to encode any additional information in this ID, so should be fine to generate a UUID during each Rule execution and set it on all alerts (at a healthy abstraction away from specific rule types so that each rule writer doesn't need to implement this functionality, i.e. when
getWriter()
is first called).If there's any useful information to encode here, or additional
group
sub-fields that may be useful, please do comment 🙂The text was updated successfully, but these errors were encountered: