From 0c27b08a056a1877431666c2ac148dc6ee9031fe Mon Sep 17 00:00:00 2001 From: Fabian Reinartz Date: Thu, 12 Nov 2015 15:15:12 +0100 Subject: [PATCH] Add example config file --- doc/examples/simple.yml | 117 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 117 insertions(+) create mode 100644 doc/examples/simple.yml diff --git a/doc/examples/simple.yml b/doc/examples/simple.yml new file mode 100644 index 00000000..2dbd6627 --- /dev/null +++ b/doc/examples/simple.yml @@ -0,0 +1,117 @@ +global: + # The smarthost and SMTP sender used for mail notifications. + smarthost: 'localhost:25' + smtp_sender: 'alertmanager@example.org' + +# The directory from which notification templates are read. +templates: +- '/etc/alertmanager/template/*.tmpl' + +# The root route on which each incoming alert enters. +route: + # 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. + group_by: ['alertname', 'cluster', 'service'] + + # 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 + # notification. + group_wait: 30s + + # When the first notification was sent, wait 'group_interval' to send a betch + # of new alerts that started firing for that group. + group_interval: 5m + + # If an alert has successfully been sent, wait 'repeat_interval' to + # resend them. + repeat_interval: 3h + + # If 'continue' is false, the first sub-route that matches this alert will + # terminate the search and the alert will be inserted at that routing node. + # If true, the alert is inserted to sibling nodes as well if there is a + # match. + # This allows to do first-match semantics (=false) in smaller scopes (e.g. team-level), + # while avoiding accidental shadowing (=true) at alerts at larger scopes (e.g. company-level) + continue: true + + # All the above attributes are inherited by all child routes and can + # overwritten on each. + + # The child route trees. + routes: + # This routes performs a regular expression match on alert labels to + # catch alerts that are related to a list of services. + - match_re: + service: ^(foo1|foo2|baz)$ + receiver: team-X-mails + # 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' + routes: + - match: + severity: critical + receiver: team-X-pager + - match: + service: files + receiver: team-Y-mails + + routes: + - match: + severity: critical + receiver: team-Y-pager + + # This route handles all alerts coming from a database service. If there's + # no team to handle it, it defaults to the DB team. + - match: + service: database + receiver: team-DB-pager + # Also group alerts by affected database. + group_by: [alertname, cluster, database] + continue: false + routes: + - match: + owner: team-X + receiver: team-X-pager + - match: + owner: team-Y + receiver: team-Y-pager + + +# Inhibition rules allow to mute a set of alerts given that another alert is +# firing. +# We use this to mute any warning-level notifications if the same alert is +# already critical. +inhibit_rules: +- source_match: + severity: 'critical' + target_match: + severity: 'warning' + # Apply inhibition if the alertname is the same. + equal: ['alertname', 'cluster', 'service'] + + +receivers: +- name: 'team-X-mails' + email_configs: + - email: 'team-X+alerts@example.org' + +- name: 'team-X-pager' + email_configs: + - email: 'team-X+alerts-critical@example.org' + pagerduty_configs: + - service_key: + +- name: 'team-Y-mails' + email_configs: + - email: 'team-Y+alerts@example.org' + +- name: 'team-Y-pager' + pagerduty_configs: + - service_key: + +- name: 'team-DB-pager' + pagerduty_configs: + - service_key: \ No newline at end of file