-
Notifications
You must be signed in to change notification settings - Fork 8.6k
[Alerting V2] Register "assign episode" workflow trigger #268915
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
Open
adcoelho
wants to merge
26
commits into
elastic:main
Choose a base branch
from
adcoelho:alerting-v2-workflow-trigger-assign-episode
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from 18 commits
Commits
Show all changes
26 commits
Select commit
Hold shift + click to select a range
c6ff65f
Introduce an event bus
cnasikas 6d07213
Event bus improvements
cnasikas 4eaaa3c
Add unit tests
cnasikas 80ac903
Merge branch 'main' into alerting_v2_event_bus
cnasikas c09ec2d
Changes from make api-docs
kibanamachine cd3fefd
Merge branch 'main' into alerting_v2_event_bus
cnasikas e43a1b4
Switch to setImmediate and EventEmitterAsyncResource
cnasikas 9afde85
PR feedback
cnasikas 28a9188
Create alert action publisher
cnasikas 0f8e5c0
Fix TS errors
cnasikas 068fedd
Merge branch 'alerting_v2_event_bus' into alerting-v2-workflow-trigge…
cnasikas 2714f6f
Create the alert action pub/sub
cnasikas 0c4978c
Adapting to the new bus.
adcoelho 1dd5101
Merge remote-tracking branch 'upstream/main' into alerting-v2-workflo…
adcoelho 94de798
Changes from node scripts/check
kibanamachine c06e33b
Type fixes
adcoelho 741b21f
Merge branch 'main' into alerting-v2-workflow-trigger-assign-episode
adcoelho e7a671b
fix test
adcoelho fe5bd86
Add logger.
adcoelho ee0a69f
Merge branch 'main' into alerting-v2-workflow-trigger-assign-episode
adcoelho 3aafc90
updating limits
adcoelho 7a15f24
Merge branch 'main' into alerting-v2-workflow-trigger-assign-episode
adcoelho a6569f5
Merge branch 'main' into alerting-v2-workflow-trigger-assign-episode
cnasikas a45ed7f
Fix limits
cnasikas 0a9a061
PR feedback
cnasikas 19b1d78
Merge branch 'main' into alerting-v2-workflow-trigger-assign-episode
elasticmachine File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
69 changes: 69 additions & 0 deletions
69
x-pack/platform/plugins/shared/alerting_v2/common/workflows/triggers/episode_assigned.ts
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,69 @@ | ||
| /* | ||
| * Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one | ||
| * or more contributor license agreements. Licensed under the Elastic License | ||
| * 2.0; you may not use this file except in compliance with the Elastic License | ||
| * 2.0. | ||
| */ | ||
|
|
||
| import { i18n } from '@kbn/i18n'; | ||
| import { z } from '@kbn/zod/v4'; | ||
| import type { CommonTriggerDefinition } from '@kbn/workflows-extensions/common'; | ||
|
|
||
| export const EPISODE_ASSIGNED_TRIGGER_ID = 'alertingV2.episodeAssigned' as const; | ||
|
|
||
| export const episodeAssignedPayloadSchema = z | ||
| .object({ | ||
| occurredAt: z.string().describe( | ||
|
|
||
| i18n.translate('xpack.alertingVTwo.triggers.episodeAssigned.schema.occurredAt', { | ||
| defaultMessage: 'ISO timestamp of when the assignment occurred.', | ||
| }) | ||
| ), | ||
| groupHash: z.string().describe( | ||
|
|
||
| i18n.translate('xpack.alertingVTwo.triggers.episodeAssigned.schema.groupHash', { | ||
| defaultMessage: 'Stable hash of the alert grouping the episode belongs to.', | ||
| }) | ||
| ), | ||
| episodeId: z.string().describe( | ||
|
|
||
| i18n.translate('xpack.alertingVTwo.triggers.episodeAssigned.schema.episodeId', { | ||
| defaultMessage: 'Identifier of the alerting episode whose assignee changed.', | ||
| }) | ||
| ), | ||
| ruleId: z.string().describe( | ||
|
|
||
| i18n.translate('xpack.alertingVTwo.triggers.episodeAssigned.schema.ruleId', { | ||
| defaultMessage: 'Identifier of the alerting rule the episode belongs to.', | ||
| }) | ||
| ), | ||
| spaceId: z.string().describe( | ||
|
|
||
| i18n.translate('xpack.alertingVTwo.triggers.episodeAssigned.schema.spaceId', { | ||
| defaultMessage: 'Kibana space the episode lives in.', | ||
| }) | ||
| ), | ||
| actorUid: z | ||
| .string() | ||
|
Comment on lines
+41
to
+42
|
||
| .nullable() | ||
| .describe( | ||
| i18n.translate('xpack.alertingVTwo.triggers.episodeAssigned.schema.actorUid', { | ||
| defaultMessage: | ||
| 'User-profile uid of the actor who changed the assignee, or null when performed by an internal/system context.', | ||
| }) | ||
| ), | ||
| assigneeUid: z | ||
| .string() | ||
|
Comment on lines
+50
to
+51
|
||
| .nullable() | ||
| .describe( | ||
| i18n.translate('xpack.alertingVTwo.triggers.episodeAssigned.schema.assigneeUid', { | ||
| defaultMessage: | ||
| 'User-profile uid of the new assignee, or null when the episode was unassigned.', | ||
| }) | ||
| ), | ||
| }) | ||
| .strict(); | ||
|
|
||
| export type EpisodeAssignedPayload = z.infer<typeof episodeAssignedPayloadSchema>; | ||
|
|
||
| export const episodeAssignedTriggerCommonDefinition: CommonTriggerDefinition< | ||
| typeof episodeAssignedPayloadSchema | ||
| > = { | ||
| id: EPISODE_ASSIGNED_TRIGGER_ID, | ||
| eventSchema: episodeAssignedPayloadSchema, | ||
| }; | ||
|
cnasikas marked this conversation as resolved.
|
||
13 changes: 13 additions & 0 deletions
13
x-pack/platform/plugins/shared/alerting_v2/common/workflows/triggers/index.ts
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,13 @@ | ||
| /* | ||
| * Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one | ||
| * or more contributor license agreements. Licensed under the Elastic License | ||
| * 2.0; you may not use this file except in compliance with the Elastic License | ||
| * 2.0. | ||
| */ | ||
|
|
||
| export { | ||
| EPISODE_ASSIGNED_TRIGGER_ID, | ||
| episodeAssignedPayloadSchema, | ||
| episodeAssignedTriggerCommonDefinition, | ||
| } from './episode_assigned'; | ||
| export type { EpisodeAssignedPayload } from './episode_assigned'; |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
54 changes: 54 additions & 0 deletions
54
...rm/plugins/shared/alerting_v2/public/lib/workflow_extensions/triggers/episode_assigned.ts
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,54 @@ | ||
| /* | ||
| * Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one | ||
| * or more contributor license agreements. Licensed under the Elastic License | ||
| * 2.0; you may not use this file except in compliance with the Elastic License | ||
| * 2.0. | ||
| */ | ||
|
|
||
| import { EuiIcon } from '@elastic/eui'; | ||
| import { i18n } from '@kbn/i18n'; | ||
| import React from 'react'; | ||
| import type { PublicTriggerDefinition } from '@kbn/workflows-extensions/public'; | ||
| import { | ||
| EPISODE_ASSIGNED_TRIGGER_ID, | ||
| episodeAssignedTriggerCommonDefinition, | ||
| } from '../../../../common/workflows/triggers'; | ||
|
|
||
| const EpisodeAssignedIcon = () => React.createElement(EuiIcon, { type: 'user' }); | ||
|
cnasikas marked this conversation as resolved.
Outdated
|
||
|
|
||
| export const episodeAssignedTriggerPublicDefinition: PublicTriggerDefinition = { | ||
| ...episodeAssignedTriggerCommonDefinition, | ||
| icon: EpisodeAssignedIcon, | ||
|
cnasikas marked this conversation as resolved.
Outdated
|
||
| title: i18n.translate('xpack.alertingVTwo.workflowTriggers.episodeAssigned.title', { | ||
| defaultMessage: 'Alerting - Episode assigned', | ||
| }), | ||
| description: i18n.translate('xpack.alertingVTwo.workflowTriggers.episodeAssigned.description', { | ||
| defaultMessage: 'Emitted when an alerting episode is assigned to a user.', | ||
| }), | ||
| documentation: { | ||
| details: i18n.translate( | ||
| 'xpack.alertingVTwo.workflowTriggers.episodeAssigned.documentation.details', | ||
| { | ||
| defaultMessage: | ||
| 'Emitted after an episode assign action is persisted with a non-null assignee. The payload includes event.episodeId, event.ruleId, event.spaceId, and event.assigneeUid for trigger conditions.', | ||
| } | ||
| ), | ||
| examples: [ | ||
| i18n.translate('xpack.alertingVTwo.workflowTriggers.episodeAssigned.documentation.example', { | ||
| defaultMessage: `## Run for a specific rule | ||
| \`\`\`yaml | ||
| triggers: | ||
| - type: {triggerId} | ||
| on: | ||
| condition: 'event.ruleId: "my-rule-id"' | ||
| \`\`\``, | ||
| values: { | ||
| triggerId: EPISODE_ASSIGNED_TRIGGER_ID, | ||
|
adcoelho marked this conversation as resolved.
Outdated
|
||
| }, | ||
| }), | ||
| ], | ||
| }, | ||
| snippets: { | ||
| condition: 'event.assigneeUid: "user-profile-uid"', | ||
| }, | ||
| }; | ||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 we really need to specify
V2here? isn't that an implementation detail?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.
We want to distinguish between the existing alerting and the new one (v2) in case we want to introduce triggers for the v1 alerting in the future. Any suggestions?
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.
don't have any suggestions atm, maybe @tinnytintin10 could help
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.
Discussed briefly this one with @tinnytintin10, suggestion is to remove
V2from name, as it also felt a bit as implementation detail. The next step will be for us to offer extra metadata for supportingV1andV2if you decide to ship something for alerting V1. Also you can explicitly put in the description that this one is related toV2if that could help users further, wdyt?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.
@tiamliu based on our recent conversations around how to cater to "mixed experiences" effectively, please check my thinking here?
I think we should call these kinds of events/triggers "alerting.[event_name]" and as much as possible make them version-agnostic. For events that apply to both, we can send them through the same flow, and include "version" as a payload discriminator for people who only want to handle one or the other for some reason (likely suggested by a consultant, support, etc).
Very rough examples:
for
alerting.ruleSnoozedpayload might be
{ "rule.id": "some-id-for-rule", "alerting.version": 2, "timestamp": //... // ...etc }for
alerting.alertAssignedandalerting.alertAcknowledged, maybe only v2 alerts have these features, but that's still okay.Thoughts?
Uh oh!
There was an error while loading. Please reload this page.
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.
Thank you both for the suggestions, and really appreciate being thorough here, as the trigger ID is not an internal name, but it is part of the public contract users put in their workflow YAML. For events that genuinely exist in both V1 and V2 with the same schemas, a common payload makes a lot of sense, and it will avoid users from having to configure the same workflow twice, one for V1 and one for V2. Where I would like to push back is that V2 has a totally different philosophy, for example, episodes. V1 has alert instances and recoveries with a different lifecycle, so for a lot of V2 events, there is no conceptually equivalent V1 event to merge with. For these V2 events, the version is always going to be 2, never anything else, and presenting a V2-only trigger as if it were version-agnostic is exactly the confusing mixed experience we're trying to prevent. We move the version from the trigger ID to the payload, which is still user-facing.
Some technical concerns when/if the payload diverges between versions on the same events: When we register a trigger, we need to provide a
zodschema. We need to construct the schema with a discriminated union based onalerting.versionhaving one schema per version. Workflow authors will have to know which fields to use and how to branch between different versions. We would also need to document which field is on which version. Also, if in the future we need to introduce versioning on the schema of the v2 payload (I hope we will never have to do this 🙂 ), we would need to have a second discriminator (alerting.v2.version) for the new schema. Separating the events based on its top level discriminator (the trigger ID) eliminates these issues, especially if each one's schemas want to evolve differently. Lastly, if we namespace on the trigger ID, it will be easier to deprecate v1 triggers in the future while we are deprecating the alerting v1, telemetry, and audit become a bit easier (not scanning the payload to figure out the version), and discoverability in the workflows UI is unambiguous (a user browsing their trigger catalog knows immediately which alerting world it belongs to).On the leaking implementation detail in the trigger ID, I hear the concern, but all of our APIs already have the V2 in their path and are exposed to the users. I would suggest keeping the distinction of v1 and v2 in the trigger ID level (maybe rename it to
alerting.v2.episodeAssignedor something very different) when the events are different, and keep the common event framework agnostic if the events are the same with the same payload.Very happy to be wrong about specific cases, though, and if you got an event in mind where the shared-id pattern works even for V2-only features, I would love to talk it through.