Skip to content
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.

Sign up for GitHub

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

Jump to bottom

OBSDOCS-185: changes-to-sample-code-for-repeat-interval-settings #61754

Merged
merged 1 commit into from
Jun 29, 2023
Merged

OBSDOCS-185: changes-to-sample-code-for-repeat-interval-settings #61754

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
15 changes: 6 additions & 9 deletions modules/monitoring-applying-custom-alertmanager-configuration.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -37,7 +37,7 @@ route:
routes:
- matchers:
- "alertname=Watchdog"
repeat_interval: 5m
repeat_interval: 2m
receiver: watchdog
- matchers:
- "service=<your_service>" <4>
Expand All @@ -53,11 +53,8 @@ receivers:
----
<1> The `group_wait` value specifies how long Alertmanager waits before sending an initial notification for a group of alerts.
This value controls how long Alertmanager waits while collecting initial alerts for the same group before sending a notification.
The default value is 30 seconds (`30s`).
<2> The `group_interval` value specifies how much time must elapse before Alertmanager sends a notification about new alerts added to a group of alerts for which an initial notification was already sent.
The default is five minutes (`5m`).
<3> The `repeat_interval` value specifies the minimum amount of time that must pass before an alert notification is repeated.
The default is four hours (`4h`).
If you want a notification to repeat at each group interval, set the `repeat_interval` value to less than the `group_interval` value.
However, the repeated notification can still be delayed, for example, when certain Alertmanager pods are restarted or rescheduled.
<4> The `service` value specifies the service that fires the alerts.
Expand All @@ -75,7 +72,7 @@ Do not use the `target_match`, `target_match_re`, `source_match`, or `source_mat
+
The following Alertmanager configuration example configures PagerDuty as an alert receiver:
+
[source,yaml,subs=quotes]
[source,yaml]
----
global:
resolve_timeout: 5m
Expand All @@ -87,9 +84,9 @@ route:
routes:
- matchers:
- "alertname=Watchdog"
repeat_interval: 5m
repeat_interval: 2m
receiver: watchdog
*- matchers:
- matchers:
- "service=example-app"
routes:
- matchers:
Expand All @@ -98,9 +95,9 @@ route:
receivers:
- name: default
- name: watchdog
*- name: team-frontend-page
- name: team-frontend-page
pagerduty_configs:
- service_key: "_your-key_"*
- service_key: "_your-key_"
----
+
With this configuration, alerts of `critical` severity that are fired by the `example-app` service are sent using the `team-frontend-page` receiver. Typically these types of alerts would be paged to an individual or a critical response team.
Expand Down