[Actions] Connector Adapters MVP#166101
Conversation
|
Pinging @elastic/response-ops (Team:ResponseOps) |
| params: RuleActionParams; | ||
| frequency?: RuleActionFrequency; | ||
| alertsFilter?: AlertsFilter; | ||
| type?: typeof RuleActionTypes.DEFAULT; |
There was a problem hiding this comment.
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.
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.
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.
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.
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.
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.
ymao1
left a comment
There was a problem hiding this comment.
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. |
ymao1
left a comment
There was a problem hiding this comment.
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 |
mikecote
left a comment
There was a problem hiding this comment.
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.
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.
question: do we need to extend or can we pass-through SanitizedRule<RuleTypeParams>?
|
|
||
| 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.
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.
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