-
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
[Response Ops][Alerting] Update FAAD AlertsClient
to support AAD payload
#158404
[Response Ops][Alerting] Update FAAD AlertsClient
to support AAD payload
#158404
Conversation
b133daf
to
bcf57ab
Compare
AlertsClient
to support AAD payload
e31e3b7
to
7045165
Compare
import { alertFieldMap } from '@kbn/alerts-as-data-utils'; | ||
import { RuleAlertData } from '../../types'; | ||
|
||
const allowedFrameworkFields: string[] = [ALERT_REASON]; |
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.
kibana.alert.reason
is defined in the alertFieldMap
but the framework does not set it, it is returned by rule types. We may want to set it at a framework level in the future but for now, we add it to this list to allow rule types to override this value.
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.
Is this just for fields defined by the framework but expected to be set by rule - and we don't have any other fields like that yet?
It should probably be a set instead of array, optimize the filter.
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.
@@ -124,11 +124,12 @@ function processAlertsHelper< | |||
// this alert did exist in previous run | |||
// calculate duration to date for active alerts | |||
const state = existingAlerts[id].getState(); | |||
const currentState = activeAlerts[id].getState(); |
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.
This fixes a bug where an ongoing alert that uses replaceState
will have its updated state value overriden.
0ef3711
to
d11c667
Compare
d11c667
to
3b6d2e6
Compare
Pinging @elastic/response-ops (Team:ResponseOps) |
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.
Changes LGTM! Reviewed the code and tested locally with the sample ES Query snippet you shared. I left a bunch of questions but nothing blocking from my perspective 👍
} catch (err) { | ||
this.options.logger.error( | ||
`Error writing ${alertsToIndex.length} alerts to ${this.indexTemplateAndPattern.alias} - ${err.message}` | ||
); | ||
} |
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.
question: Do we need to process the bulk response on success as well (when no errors are thrown)? If an error happens for a specific document, it would return as a success and have the error information in the payload (https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-bulk.html#bulk-api-response-body).
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.
Do you think we should retry the individual documents that fail or just log?
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 think logging for now is ok and if we think it's worth retrying or partially failing the rule execution, we can create a follow up issue to discuss / implement.
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.
Updated in 633dbb1
x-pack/plugins/alerting/server/alerts_client/lib/strip_framework_fields.ts
Outdated
Show resolved
Hide resolved
x-pack/plugins/alerting/server/alerts_client/lib/build_ongoing_recovered_alert.ts
Outdated
Show resolved
Hide resolved
x-pack/plugins/alerting/server/alerts_client/lib/build_ongoing_recovered_alert.ts
Outdated
Show resolved
Hide resolved
type AlertRecord = Record<string, AlertTypes>; | ||
type AlertFields = AlertTypes | AlertRecord; | ||
|
||
const removeEmptyObjects = (data: AlertFields): AlertFields => { |
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.
@mikecote Do you see any gotchas in this function? Using lodash omit
leaves empty objects so we'd be left with fields like
kibana: {
alert: {
duration: {}
}
}
if we had to strip kibana.alert.duration.us
from the payload (for example), so I added this function but maybe it is overkill?
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.
Function looks good to me. To see if the function is necessary, I just did a check on the behaviours when calling the Elasticsearch index and update APIs to update an existing alert document. In both scenarios with empty objects, the call mutated the alert in the exact way as if it didn't have an empty object, so it seems not doing removeEmptyObjects
will work the same.
When creating alerts, the created alert would just contain an empty object but I don't see any issues doing so either. So it seems safe to remove the removeEmptyObjects
function and save an processing step.
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.
Removed in b385e5f
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, noted one optimization
import { alertFieldMap } from '@kbn/alerts-as-data-utils'; | ||
import { RuleAlertData } from '../../types'; | ||
|
||
const allowedFrameworkFields: string[] = [ALERT_REASON]; |
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.
Is this just for fields defined by the framework but expected to be set by rule - and we don't have any other fields like that yet?
It should probably be a set instead of array, optimize the filter.
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.
Detection engine changes LGTM
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.
AO changes LGTM!
…pi-rule-type-payload
💚 Build Succeeded
Metrics [docs]Public APIs missing comments
Public APIs missing exports
Unknown metric groupsAPI count
ESLint disabled line counts
References to deprecated APIs
Total ESLint disabled count
History
To update your PR or re-run it, just comment with: cc @ymao1 |
Resolves #156443, #156445
Summary
AlertsClient
withcreate
API that allows rule executors to report alerts with AAD payload, along with the values foractionGroup
,context
andstate
. This proxies theLegacyAlertsClient
to create alerts via the alerts factory but also saves the reported payloadAlertsClient
services to the rule executors. Note that this PR does not migrate any rule type to use this service.This PR does not opt any rule types into writing the AAD payload or using the AlertsClient API but updates the AAD functional test to do so. To test it out with the ES query rule type, use the following commit: 1b1e139
Followup issues
To Verify
Checklist