-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
c6418b1
commit f5b016e
Showing
5 changed files
with
10 additions
and
36 deletions.
There are no files selected for viewing
This file contains 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 |
---|---|---|
|
@@ -22,40 +22,14 @@ spec: | |
repeatInterval: 2h | ||
``` | ||
The above notification sends at max 1 email notification in a moving 2 hour window. | ||
## Grouping Per Resource per Source Event | ||
## Repeat Group | ||
The `repeatInterval` applies per unique resource per unique event source. This prevents duplicate notifications when the same resource triggers the same event type multiple times within the interval window. It still allows notifications for different event types on the same resource within the window. | ||
|
||
By default, the repeat interval applies to any notification sent for the given notification. | ||
### Example: | ||
|
||
In the example above, if a notification is sent for a `config.healthy` event and then a new notification is to be sent | ||
for a `config.unhealthy` event, then the notification is dropped due to the repeat interval. | ||
With the above notification in place, if a Kubernetes Helm release's health fluctuates between `healthy` and `unhealthy` multiple times within a 2-hour window, the system limits notifications to just two: one for the `config.healthy` event and one for the `config.unhealthy` event. | ||
Check failure on line 31 in mission-control/docs/notifications/concepts/repeat-interval.mdx GitHub Actions / vale[vale] mission-control/docs/notifications/concepts/repeat-interval.mdx#L31
Raw output
|
||
|
||
With grouping, you can apply the repeat interval per source event & per resource ID. | ||
However, if the Helm release health shifts to `warning` during this same period, it triggers an additional notification. This occurs because the warning status is considered a separate event source. | ||
Check warning on line 33 in mission-control/docs/notifications/concepts/repeat-interval.mdx GitHub Actions / vale[vale] mission-control/docs/notifications/concepts/repeat-interval.mdx#L33
Raw output
|
||
|
||
- `source_event` | ||
- `resource_id` | ||
|
||
```yaml title="deployment-updates.yaml" | ||
apiVersion: mission-control.flanksource.com/v1 | ||
kind: Notification | ||
metadata: | ||
name: config-updates | ||
namespace: default | ||
spec: | ||
events: | ||
- config.healthy | ||
- config.unhealthy | ||
- config.warning | ||
- config.unknown | ||
filter: config.type == "Kubernetes::Deployment" | ||
to: | ||
email: [email protected] | ||
repeatInterval: 2h | ||
// highlight-start | ||
repeatGroup: | ||
- source_event | ||
// highlight-end | ||
``` | ||
|
||
With this change, you'll now receive at max 4 notifications for each source event. | ||
The notification throttling mechanism operates independently for each distinct resource. As a result, other Helm releases are not affected by this limitation. |
Submodule canary-checker
updated
77 files
Submodule config-db
updated
62 files
Submodule duty
updated
69 files
Submodule mission-control
updated
71 files