1global:
2 # The smarthost and SMTP sender used for mail notifications.
3 smtp_smarthost: 'localhost:25'
4 smtp_from: 'alertmanager@example.org'
5 smtp_auth_username: 'alertmanager'
6 smtp_auth_password: 'password'
7
8# The directory from which notification templates are read.
9templates:
10 - '/etc/alertmanager/template/*.tmpl'
11
12# The root route on which each incoming alert enters.
13route:
14 # The labels by which incoming alerts are grouped together. For example,
15 # multiple alerts coming in for cluster=A and alertname=LatencyHigh would
16 # be batched into a single group.
17 #
18 # To aggregate by all possible labels use '...' as the sole label name.
19 # This effectively disables aggregation entirely, passing through all
20 # alerts as-is. This is unlikely to be what you want, unless you have
21 # a very low alert volume or your upstream notification system performs
22 # its own grouping. Example: group_by: [...]
23 group_by: ['alertname', 'cluster', 'service']
24
25 # When a new group of alerts is created by an incoming alert, wait at
26 # least 'group_wait' to send the initial notification.
27 # This way ensures that you get multiple alerts for the same group that start
28 # firing shortly after another are batched together on the first
29 # notification.
30 group_wait: 30s
31
32 # When the first notification was sent, wait 'group_interval' to send a batch
33 # of new alerts that started firing for that group.
34 group_interval: 5m
35
36 # If an alert has successfully been sent, wait 'repeat_interval' to
37 # resend them.
38 repeat_interval: 3h
39
40 # A default receiver
41 receiver: team-X-mails
42
43 # All the above attributes are inherited by all child routes and can
44 # overwritten on each.
45
46 # The child route trees.
47 routes:
48 # This routes performs a regular expression match on alert labels to
49 # catch alerts that are related to a list of services.
50 - matchers:
51 - service=~"foo1|foo2|baz"
52 receiver: team-X-mails
53 # The service has a sub-route for critical alerts, any alerts
54 # that do not match, i.e. severity != critical, fall-back to the
55 # parent node and are sent to 'team-X-mails'
56 routes:
57 - matchers:
58 - severity="critical"
59 receiver: team-X-pager
60 - matchers:
61 - service="files"
62 receiver: team-Y-mails
63
64 routes:
65 - matchers:
66 - severity="critical"
67 receiver: team-Y-pager
68
69 # This route handles all alerts coming from a database service. If there's
70 # no team to handle it, it defaults to the DB team.
71 - matchers:
72 - service="database"
73 receiver: team-DB-pager
74 # Also group alerts by affected database.
75 group_by: [alertname, cluster, database]
76 routes:
77 - matchers:
78 - owner="team-X"
79 receiver: team-X-pager
80 continue: true
81 - matchers:
82 - owner="team-Y"
83 receiver: team-Y-pager
84
85
86# Inhibition rules allow to mute a set of alerts given that another alert is
87# firing.
88# We use this to mute any warning-level notifications if the same alert is
89# already critical.
90inhibit_rules:
91 - source_matchers: [severity="critical"]
92 target_matchers: [severity="warning"]
93 # Apply inhibition if the alertname is the same.
94 # CAUTION:
95 # If all label names listed in `equal` are missing
96 # from both the source and target alerts,
97 # the inhibition rule will apply!
98 equal: [alertname, cluster, service]
99
100
101receivers:
102 - name: 'team-X-mails'
103 email_configs:
104 - to: 'team-X+alerts@example.org'
105
106 - name: 'team-X-pager'
107 email_configs:
108 - to: 'team-X+alerts-critical@example.org'
109 pagerduty_configs:
110 - service_key: <team-X-key>
111
112 - name: 'team-Y-mails'
113 email_configs:
114 - to: 'team-Y+alerts@example.org'
115
116 - name: 'team-Y-pager'
117 pagerduty_configs:
118 - service_key: <team-Y-key>
119
120 - name: 'team-DB-pager'
121 pagerduty_configs:
122 - service_key: <team-DB-key>
View as plain text