Go to file
2016-09-09 08:29:12 +02:00
api allow CORS for api GET and OPTIONS 2016-09-04 17:43:25 +02:00
cmd/alertmanager Merge pull request #489 from prometheus/timeout 2016-09-06 14:17:53 +02:00
config config: check overflow in global section 2016-09-05 11:30:07 +02:00
dispatch *: consider mesh wait in notification timeouts 2016-09-05 13:21:28 +02:00
doc Fix a typo in simple.yml 2016-04-20 22:10:28 -04:00
examples example: fix config typo 2016-09-06 11:10:29 +02:00
inhibit *: restructure package tree 2016-08-09 14:24:52 +02:00
nflog *: remove go-kit logging 2016-09-06 11:56:57 +02:00
notify add retry flag for notify providers 2016-09-06 16:21:56 +02:00
provider provider: delete old silence provider 2016-08-30 12:01:24 +02:00
scripts silence: add protobuf-based silence package. 2016-08-24 17:48:31 +02:00
silence *: remove go-kit logging 2016-09-06 11:56:57 +02:00
template Merge branch 'slack_enhance' of https://github.com/dmclain/alertmanager into dmclain-slack_enhance 2016-08-09 14:46:39 +02:00
test *: integrate new silence package 2016-08-30 12:15:23 +02:00
types Merge pull request #481 from prometheus/fabxc-meshsil 2016-08-30 16:53:34 +02:00
ui Merge pull request #454 from prometheus/fabxc-restruct2 2016-08-09 15:20:23 +02:00
vendor *: remove go-kit logging 2016-09-06 11:56:57 +02:00
.dockerignore New release process using docker, circleci and a centralized 2016-04-22 21:46:53 +02:00
.gitignore New release process using docker, circleci and a centralized 2016-04-22 21:46:53 +02:00
.promu.yml Use promu default go version + use 1.6 tag for cicleci tests 2016-08-30 09:23:02 +02:00
.travis.yml Update Travis Go versions 2016-07-27 11:58:56 -07:00
AUTHORS.md Update Fabian's email address 2016-03-24 17:02:42 +01:00
CHANGELOG.md *: cut 0.3.0 2016-07-07 11:53:47 +02:00
circle.yml Use golang-builder base image for tests in CircleCI 2016-09-09 08:29:12 +02:00
CONTRIBUTING.md License cleanup. 2015-01-22 15:45:23 +01:00
Dockerfile New release process using docker, circleci and a centralized 2016-04-22 21:46:53 +02:00
LICENSE License cleanup. 2015-01-22 15:45:23 +01:00
Makefile New release process using docker, circleci and a centralized 2016-04-22 21:46:53 +02:00
NOTICE License cleanup. 2015-01-22 15:45:23 +01:00
Procfile examples: add Go logging webhook 2016-08-19 12:13:39 +02:00
README.md readme: point to prometheus.io download section 2016-09-07 14:30:57 +02:00
VERSION *: cut 0.3.0 2016-07-07 11:53:47 +02:00

Alertmanager Build Status

CircleCI Docker Repository on Quay Docker Pulls

The Alertmanager handles alerts sent by client applications such as the Prometheus server. It takes care of deduplicating, grouping, and routing them to the correct receiver integrations such as email, PagerDuty, or OpsGenie. It also takes care of silencing and inhibition of alerts.

Install

There are various ways of installing Alertmanager.

Precompiled binaries

Precompiled binaries for released versions are available in the download section on prometheus.io. Using the latest production release binary is the recommended way of installing Alertmanager.

Docker images

Docker images are available on Quay.io.

Compiling the binary

You can either go get it:

$ GO15VENDOREXPERIMENT=1 go get github.com/prometheus/alertmanager
# cd $GOPATH/src/github.com/prometheus/alertmanager
$ alertmanager -config.file=<your_file>

Or checkout the source code and build manually:

$ mkdir -p $GOPATH/src/github.com/prometheus
$ cd $GOPATH/src/github.com/prometheus
$ git clone https://github.com/prometheus/alertmanager.git
$ cd alertmanager
$ make build
$ ./alertmanager -config.file=<your_file>

Example

This is an example configuration that should cover most relevant aspects of the new YAML configuration format. The full documentation of the configuration can be found here.

global:
  # The smarthost and SMTP sender used for mail notifications.
  smtp_smarthost: 'localhost:25'
  smtp_from: 'alertmanager@example.org'

# The root route on which each incoming alert enters.
route:
  # 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.
  receiver: 'team-X-mails'
  
  # 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']

  # 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 batch
  # 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

  # 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]

    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']


receivers:
- name: 'team-X-mails'
  email_configs:
  - to: 'team-X+alerts@example.org'

- name: 'team-X-pager'
  email_configs:
  - to: 'team-X+alerts-critical@example.org'
  pagerduty_configs:
  - service_key: <team-X-key>

- name: 'team-Y-mails'
  email_configs:
  - to: 'team-Y+alerts@example.org'

- name: 'team-Y-pager'
  pagerduty_configs:
  - service_key: <team-Y-key>

- name: 'team-DB-pager'
  pagerduty_configs:
  - service_key: <team-DB-key>

Architecture