File alertmanager.yml of Package golang-github-prometheus-alertmanager
# Sample configuration.
# See https://prometheus.io/docs/alerting/configuration/ for documentation.
# The smarthost and SMTP sender used for mail notifications.
# The root route on which each incoming alert enters.
# The root route must not have any matchers as it is the entry point for
# all alerts. It needs to have a receiver configured so alerts that do not
# match any of the sub-routes are sent to someone.
# The labels by which incoming alerts are grouped together. For example,
# multiple alerts coming in for cluster=A and alertname=LatencyHigh would
# be batched into a single group.
# To aggregate by all possible labels use '...' as the sole label name.
# This effectively disables aggregation entirely, passing through all
# alerts as-is. This is unlikely to be what you want, unless you have
# a very low alert volume or your upstream notification system performs
# its own grouping. Example: group_by: [...]
group_by: ["alertname", "cluster"]
# When a new group of alerts is created by an incoming alert, wait at
# least 'group_wait' to send the initial notification.
# This way ensures that you get multiple alerts for the same group that start
# firing shortly after another are batched together on the first
# When the first notification was sent, wait 'group_interval' to send a batch
# of new alerts that started firing for that group.
# If an alert has successfully been sent, wait 'repeat_interval' to
# resend them.
# All the above attributes are inherited by all child routes and can
# overwritten on each.
# The child route trees.
# This routes performs a regular expression match on alert labels to
# catch alerts that are related to a list of services.
# The service has a sub-route for critical alerts, any alerts
# that do not match, i.e. severity != critical, fall-back to the
# parent node and are sent to 'team-X-mails'
# This route handles all alerts coming from a database service. If there's
# no team to handle it, it defaults to the DB team.
# Also group alerts by affected database.
group_by: [alertname, cluster, database]
# Inhibition rules allow to mute a set of alerts given that another alert is
# We use this to mute any warning-level notifications if the same alert is
# already critical.
# Apply inhibition if the alertname is the same.
# If all label names listed in `equal` are missing
# from both the source and target alerts,
# the inhibition rule will apply!
- name: "team-X-mails"
- to: "team-Xemail@example.com, team-Yfirstname.lastname@example.org"
- name: "team-X-pager"
- to: "team-Xemail@example.com"
- routing_key: <team-X-key>
- name: "team-Y-mails"
- to: "team-Yfirstname.lastname@example.org"
- name: "team-Y-pager"
- routing_key: <team-Y-key>
- name: "team-DB-pager"
- routing_key: <team-DB-key>