From f5b016eef0285276f3cbc610aaeddb227501192b Mon Sep 17 00:00:00 2001 From: Aditya Thebe Date: Wed, 4 Sep 2024 10:01:53 +0545 Subject: [PATCH] fix: notification repeat interval --- .../concepts/repeat-interval.mdx | 38 +++---------------- modules/canary-checker | 2 +- modules/config-db | 2 +- modules/duty | 2 +- modules/mission-control | 2 +- 5 files changed, 10 insertions(+), 36 deletions(-) diff --git a/mission-control/docs/notifications/concepts/repeat-interval.mdx b/mission-control/docs/notifications/concepts/repeat-interval.mdx index 225eb453..4c1a0d75 100644 --- a/mission-control/docs/notifications/concepts/repeat-interval.mdx +++ b/mission-control/docs/notifications/concepts/repeat-interval.mdx @@ -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. -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. -- `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: alerts@acme.com - repeatInterval: 2h - // highlight-start - repeatGroup: - - source_event - // highlight-end -``` - -With this change, you'll now receive at max 4 notifications for each source event. \ No newline at end of file +The notification throttling mechanism operates independently for each distinct resource. As a result, other Helm releases are not affected by this limitation. \ No newline at end of file diff --git a/modules/canary-checker b/modules/canary-checker index 71273e2e..fc4fe619 160000 --- a/modules/canary-checker +++ b/modules/canary-checker @@ -1 +1 @@ -Subproject commit 71273e2e8ab6e843e64b550282762115db63e202 +Subproject commit fc4fe6193f2e1434f261bb60d655ce474b06481c diff --git a/modules/config-db b/modules/config-db index 646ea613..a01efcb7 160000 --- a/modules/config-db +++ b/modules/config-db @@ -1 +1 @@ -Subproject commit 646ea613f0be21b0a2bf85421fd281254f05dbec +Subproject commit a01efcb73d5a414b5b57094b7523b1acf93b04f9 diff --git a/modules/duty b/modules/duty index 31f7d431..92e292b7 160000 --- a/modules/duty +++ b/modules/duty @@ -1 +1 @@ -Subproject commit 31f7d43133caac8e9ceebb888fcaa99e901d8102 +Subproject commit 92e292b7d59e7c2077233309c60f42461a3d8fbd diff --git a/modules/mission-control b/modules/mission-control index e6faec47..c98d307b 160000 --- a/modules/mission-control +++ b/modules/mission-control @@ -1 +1 @@ -Subproject commit e6faec47f209bc6cb5e961d37a2ae63205194132 +Subproject commit c98d307bd84641fdd1284871a90055e263e93998