-
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
[Actions] Connector Adapters MVP #166101
[Actions] Connector Adapters MVP #166101
Conversation
Pinging @elastic/response-ops (Team:ResponseOps) |
@@ -116,6 +129,7 @@ export interface RuleAction { | |||
params: RuleActionParams; | |||
frequency?: RuleActionFrequency; | |||
alertsFilter?: AlertsFilter; | |||
type?: typeof RuleActionTypes.DEFAULT; |
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.
The system action will be
export interface RuleSystemAction {
uuid: string;
id: string;
actionTypeId: string;
params: RuleActionParams;
type: typeof RuleActionTypes.SYSTEM;
}
|
||
type ActionTypeParams = Record<string, unknown>; | ||
|
||
type Rule = Pick<SanitizedRule<RuleTypeParams>, 'id' | 'name' | 'tags'>; |
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.
For the MVP this should be enough. If a connector adapter needs more attributes from the rule we can extend it in the future.
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 extend or can we pass-through SanitizedRule<RuleTypeParams>
?
params: { spaceId, alertId: ruleId }, | ||
}, | ||
} = this; | ||
if (executables.length === 0) { |
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 the outer if and returned early. Better to view it with "Hide white spaces" enabled.
ruleRunMetricsStore.incrementNumberOfTriggeredActionsByConnectorType(actionTypeId); | ||
|
||
if (summarizedAlerts && !isSystemAction(action)) { | ||
const { actionsToEnqueueForExecution, actionsToLog } = await this.runSummarizedAction({ |
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.
Small refactor. I create one run*Action
method for each possible execution and I move the logic inside the dedicated functions. The logic is the same as before.
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 moved the logic of running each action in a separate function. Each runner returns the actions to be bulk executed and the logged messages. Also, I moved the logic of bulk executing and logging into separate functions.
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.
Left a few questions. Also wondering if we should be merging into a feature branch instead of main
?
x-pack/plugins/alerting/server/connector_adapters/connector_adapter_registry.ts
Show resolved
Hide resolved
If fine with both. Whatever you think is best 🙂 |
I think since we're treating main as prod now, this probably makes more sense to merge into a feature branch and only merge the feature branch when it is feature complete. |
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. Mostly reviewed code changes in alerting execution handler.
💚 Build Succeeded
Metrics [docs]Public APIs missing comments
Public APIs missing exports
Page load bundle
Unknown metric groupsAPI count
History
To update your PR or re-run it, just comment with: cc @cnasikas |
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 managed to go through this PR as discussed. Below are the questions I had and nitpicks.
export const RuleActionTypes = { | ||
DEFAULT: 'default' as const, | ||
SYSTEM: 'system' as const, | ||
} as const; |
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 have a follow up issue / task for the feature branch to split DEFAULT into two? (something that associates with each alert and something that associates with summaries).
|
||
type ActionTypeParams = Record<string, unknown>; | ||
|
||
type Rule = Pick<SanitizedRule<RuleTypeParams>, 'id' | 'name' | 'tags'>; |
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 extend or can we pass-through SanitizedRule<RuleTypeParams>
?
@@ -69,6 +91,10 @@ export const isSummaryActionThrottled = ({ | |||
}; | |||
|
|||
export const generateActionHash = (action?: RuleAction) => { | |||
if (action != null && isSystemAction(action)) { | |||
return `system-action:${action?.actionTypeId || 'no-action-type-id'}:summary`; |
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.
nit: No need for action?.actionTypeId || 'no-action-type-id'
as it can be action.actionTypeId
.
this.logger.warn( | ||
`Rule "${this.taskInstance.params.alertId}" skipped scheduling action "${action.id}" because it is disabled` | ||
`Rule "${this.taskInstance.params.alertId}" skipped scheduling system action "${action.id}" because no connector adapter is configured` | ||
); |
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: should we throw an error instead similar to when a connector doesn't exist?
Summary
This PR implements Connector Adapters. Integrations tests will follow on this PR #161726 as we cannot create system actions through the API at the moment.
Issue: #160367
POC: #159866
Checklist
Delete any items that are not applicable to this PR.
For maintainers