-
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
[Alerting][Event log] Persisting duration information for active alerts in event log #101387
Conversation
…-log/alert-duration
Pinging @elastic/kibana-alerting-services (Team:Alerting Services) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, posted a few questions though.
I think we should probably open a new issue, given we now have this capability, that we can make the alert details page a little better by showing the REAL alert duration (for alerts that started after the 7.14 migration), rather than trying to calculate it based on previous records. I suspect that means the API we use in the event log will change as well, but we'd need to see.
// Inject start time into instance state of new instances | ||
for (const id of newAlertIds) { | ||
const state = currentAlerts[id].getState(); | ||
currentAlerts[id].replaceState({ ...state, start: currentTime, uuid: uuidv4() }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
side thought, for @YulNaumenko - does this new UUID value for the alert id belong in one of the new rule.
fields we're writing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, makes sense to me. Need to check with @elastic/security-detections-response
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it makes sense to write alert
information into the rule
object?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good philosophical question. An alert is rule-related, so it seems fine to me to. As an example, the process.
fields have a thread.id
- kinda seems like the same kind of relationship. We might be able to get some historic context from the RFC that introduced this.
I guess the RAC field for this value is kibana.rac.alert.uuid
right now? Per previous comment ^^^, I'm hesitant to add kibana.rac
fields right now, especially if it's something that should be in rule.
(or some other existing field). Maybe we need to get a new ECS RFC together to add such a field to rule.
? Let's bring this up with the RAC alerts-as-data folk ...
x-pack/test/alerting_api_integration/spaces_only/tests/alerting/event_log.ts
Show resolved
Hide resolved
…-log/alert-duration
Created this issue: #101662 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@elasticmachine merge upstream |
💚 Build SucceededMetrics [docs]
History
To update your PR or re-run it, just comment with: cc @ymao1 |
…ts in event log (elastic#101387) * WIP * Storing start, duration and end in alert state * Writing to event log * Updating unit tests * Adding unit tests * Fixing uuid in tests * Updating functional test * Adding functional test * Removing console logs * Fixing unit tests * PR fixes * Removing uuid from alert information Co-authored-by: Kibana Machine <[email protected]>
💚 Backport successful
This backport PR will be merged automatically after passing CI. |
…ts in event log (#101387) (#101784) * WIP * Storing start, duration and end in alert state * Writing to event log * Updating unit tests * Adding unit tests * Fixing uuid in tests * Updating functional test * Adding functional test * Removing console logs * Fixing unit tests * PR fixes * Removing uuid from alert information Co-authored-by: Kibana Machine <[email protected]> Co-authored-by: ymao1 <[email protected]>
* master: clarify which parts of TM are experimental (elastic#101757) Add sh scripts with _bulk_action route usage examples (elastic#101736) [Uptime] Only register route in side nav if uptime show capability is true (elastic#101709) Use KIBANA_DOCS in doc link service (elastic#101667) [Alerting][Event log] Persisting duration information for active alerts in event log (elastic#101387) Address design issues in Discover/Graph (elastic#101584) Optimize performance for document table (elastic#101715) Change file data visualizer links to point to new location in home application (elastic#101393) [Fleet] Tighten policy permissions, take II (elastic#97366) [ML] Add debounce to the severity control update (elastic#101581) [Fleet] Fix routing issues with `getPath` and `history.push` (elastic#101658) [APM] Add link-to/transaction route (elastic#101731) [Index Patterns] Runtime fields CRUD REST API (elastic#101164) [ILM] Refactor types and fix missing aria labels (elastic#101518) [Lens] New summary row feature for datatable (elastic#101075) Blocks save event filter with a white space name (elastic#101599) Improve security server types (elastic#101661) [APM] Replace side nav with tabs on Settings page (elastic#101460) [APM] Only register items in side nav if user has permissions to see app (elastic#101707) [Security solution][Endpoint] Add back button when to the event filters list (elastic#101280)
Resolves #93704
Summary
This PR calculates and persists duration information for
alert
(eginstance
) events in the event log. When a new alert is triggered, astart
time is recorded in thenew-instance
event, with an initial duration of0
. Auuid
is also generated. While this alert remains active, eachactive-instance
event log document will be written with thestart
time, theuuid
and an updatedduration
in nanoseconds. When the alert recovers, theend
time will be recorded in therecovered-instance
document in the event log. Theuuid
will remain the same for the active span of an alert but will change if the alert recovers and then becomes active again.Checklist
Delete any items that are not applicable to this PR.