alertmanager/README.md

340 lines
12 KiB
Markdown
Raw Normal View History

# Alertmanager [![Build Status](https://travis-ci.org/prometheus/alertmanager.svg?branch=master)][travis]
[![CircleCI](https://circleci.com/gh/prometheus/alertmanager/tree/master.svg?style=shield)][circleci]
2016-05-13 19:48:57 +00:00
[![Docker Repository on Quay](https://quay.io/repository/prometheus/alertmanager/status)][quay]
[![Docker Pulls](https://img.shields.io/docker/pulls/prom/alertmanager.svg?maxAge=604800)][hub]
2015-10-22 12:56:55 +00:00
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.
* [Documentation](http://prometheus.io/docs/alerting/alertmanager/)
2015-10-22 12:56:55 +00:00
## Install
2015-10-22 12:56:55 +00:00
There are various ways of installing Alertmanager.
### Precompiled binaries
2016-01-07 14:15:21 +00:00
Precompiled binaries for released versions are available in the
[*download* section](https://prometheus.io/download/)
on [prometheus.io](https://prometheus.io). Using the latest production release binary
is the recommended way of installing Alertmanager.
2016-01-07 14:15:21 +00:00
### Docker images
2016-01-07 14:15:21 +00:00
Docker images are available on [Quay.io](https://quay.io/repository/prometheus/alertmanager).
2016-01-07 14:15:21 +00:00
### Compiling the binary
2015-10-22 12:56:55 +00:00
You can either `go get` it:
```
2016-09-25 11:34:13 +00:00
$ GO15VENDOREXPERIMENT=1 go get github.com/prometheus/alertmanager/cmd/...
2015-10-22 13:25:18 +00:00
# cd $GOPATH/src/github.com/prometheus/alertmanager
$ alertmanager --config.file=<your_file>
2015-10-22 12:56:55 +00:00
```
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>
2015-10-22 12:56:55 +00:00
```
You can also build just one of the binaries in this repo by passing a name to the build function:
```
$ make build BINARIES=amtool
```
2015-10-22 13:25:18 +00:00
## 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](https://prometheus.io/docs/alerting/configuration/).
2015-10-22 13:25:18 +00:00
```yaml
2015-10-22 13:25:18 +00:00
global:
# The smarthost and SMTP sender used for mail notifications.
smtp_smarthost: 'localhost:25'
smtp_from: 'alertmanager@example.org'
2015-10-22 13:25:18 +00:00
# The root route on which each incoming alert enters.
route:
2016-01-28 13:02:15 +00:00
# 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'
2015-10-22 13:25:18 +00:00
# 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']
2015-10-22 13:25:18 +00:00
# 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
2015-10-22 13:25:18 +00:00
# notification.
group_wait: 30s
2016-01-28 12:25:09 +00:00
# When the first notification was sent, wait 'group_interval' to send a batch
2015-10-22 13:25:18 +00:00
# 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
2015-10-22 13:25:18 +00:00
# All the above attributes are inherited by all child routes and can
2015-10-22 13:25:18 +00:00
# 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)$
2015-11-10 13:08:20 +00:00
receiver: team-X-mails
2015-10-22 12:56:55 +00:00
2015-10-22 13:25:18 +00:00
# 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
2015-11-10 13:08:20 +00:00
receiver: team-X-pager
2015-10-22 13:25:18 +00:00
- match:
service: files
2015-11-10 13:08:20 +00:00
receiver: team-Y-mails
2015-10-22 13:25:18 +00:00
routes:
- match:
severity: critical
2015-11-10 13:08:20 +00:00
receiver: team-Y-pager
2015-10-22 13:25:18 +00:00
# This route handles all alerts coming from a database service. If there's
2015-10-22 13:29:36 +00:00
# no team to handle it, it defaults to the DB team.
2015-10-22 13:25:18 +00:00
- match:
service: database
2015-11-10 13:08:20 +00:00
receiver: team-DB-pager
2015-10-22 13:25:18 +00:00
# Also group alerts by affected database.
group_by: [alertname, cluster, database]
routes:
- match:
owner: team-X
2015-11-10 13:08:20 +00:00
receiver: team-X-pager
2015-10-22 13:25:18 +00:00
- match:
owner: team-Y
2015-11-10 13:08:20 +00:00
receiver: team-Y-pager
2015-10-22 13:25:18 +00:00
# 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
2015-10-22 13:25:18 +00:00
# already critical.
inhibit_rules:
- source_match:
severity: 'critical'
target_match:
severity: 'warning'
# Apply inhibition if the alertname is the same.
equal: ['alertname']
2015-11-10 13:08:20 +00:00
receivers:
2015-10-22 13:25:18 +00:00
- name: 'team-X-mails'
email_configs:
- to: 'team-X+alerts@example.org, team-Y+alerts@example.org'
2015-10-22 13:25:18 +00:00
- name: 'team-X-pager'
email_configs:
- to: 'team-X+alerts-critical@example.org'
2015-10-22 13:25:18 +00:00
pagerduty_configs:
- routing_key: <team-X-key>
2015-10-22 13:25:18 +00:00
- name: 'team-Y-mails'
email_configs:
- to: 'team-Y+alerts@example.org'
2015-10-22 13:25:18 +00:00
- name: 'team-Y-pager'
pagerduty_configs:
- routing_key: <team-Y-key>
2015-10-22 13:25:18 +00:00
- name: 'team-DB-pager'
pagerduty_configs:
- routing_key: <team-DB-key>
2015-10-22 13:25:18 +00:00
```
2015-10-22 12:56:55 +00:00
## Amtool
`amtool` is a cli tool for interacting with the alertmanager api. It is bundled with all releases of alertmanager.
### Install
Alternatively you can install with:
```
go get github.com/prometheus/alertmanager/cmd/amtool
```
### Examples
View all currently firing alerts
```
$ amtool alert
Alertname Starts At Summary
Test_Alert 2017-08-02 18:30:18 UTC This is a testing alert!
Test_Alert 2017-08-02 18:30:18 UTC This is a testing alert!
Check_Foo_Fails 2017-08-02 18:30:18 UTC This is a testing alert!
Check_Foo_Fails 2017-08-02 18:30:18 UTC This is a testing alert!
```
View all currently firing alerts with extended output
```
$ amtool -o extended alert
Labels Annotations Starts At Ends At Generator URL
alertname="Test_Alert" instance="node0" link="https://example.com" summary="This is a testing alert!" 2017-08-02 18:31:24 UTC 0001-01-01 00:00:00 UTC http://my.testing.script.local
alertname="Test_Alert" instance="node1" link="https://example.com" summary="This is a testing alert!" 2017-08-02 18:31:24 UTC 0001-01-01 00:00:00 UTC http://my.testing.script.local
alertname="Check_Foo_Fails" instance="node0" link="https://example.com" summary="This is a testing alert!" 2017-08-02 18:31:24 UTC 0001-01-01 00:00:00 UTC http://my.testing.script.local
alertname="Check_Foo_Fails" instance="node1" link="https://example.com" summary="This is a testing alert!" 2017-08-02 18:31:24 UTC 0001-01-01 00:00:00 UTC http://my.testing.script.local
```
In addition to viewing alerts you can use the rich query syntax provided by alertmanager
```
$ amtool -o extended alert query alertname="Test_Alert"
Labels Annotations Starts At Ends At Generator URL
alertname="Test_Alert" instance="node0" link="https://example.com" summary="This is a testing alert!" 2017-08-02 18:31:24 UTC 0001-01-01 00:00:00 UTC http://my.testing.script.local
alertname="Test_Alert" instance="node1" link="https://example.com" summary="This is a testing alert!" 2017-08-02 18:31:24 UTC 0001-01-01 00:00:00 UTC http://my.testing.script.local
$ amtool -o extended alert query instance=~".+1"
Labels Annotations Starts At Ends At Generator URL
alertname="Test_Alert" instance="node1" link="https://example.com" summary="This is a testing alert!" 2017-08-02 18:31:24 UTC 0001-01-01 00:00:00 UTC http://my.testing.script.local
alertname="Check_Foo_Fails" instance="node1" link="https://example.com" summary="This is a testing alert!" 2017-08-02 18:31:24 UTC 0001-01-01 00:00:00 UTC http://my.testing.script.local
$ amtool -o extended alert query alertname=~"Test.*" instance=~".+1"
Labels Annotations Starts At Ends At Generator URL
alertname="Test_Alert" instance="node1" link="https://example.com" summary="This is a testing alert!" 2017-08-02 18:31:24 UTC 0001-01-01 00:00:00 UTC http://my.testing.script.local
```
Silence an alert
```
$ amtool silence add alertname=Test_Alert
b3ede22e-ca14-4aa0-932c-ca2f3445f926
$ amtool silence add alertname="Test_Alert" instance=~".+0"
e48cb58a-0b17-49ba-b734-3585139b1d25
```
View silences
```
$ amtool silence query
ID Matchers Ends At Created By Comment
b3ede22e-ca14-4aa0-932c-ca2f3445f926 alertname=Test_Alert 2017-08-02 19:54:50 UTC kellel
$ amtool silence query instance=~".+0"
ID Matchers Ends At Created By Comment
e48cb58a-0b17-49ba-b734-3585139b1d25 alertname=Test_Alert instance=~.+0 2017-08-02 22:41:39 UTC kellel
```
Expire a silence
```
$ amtool silence expire b3ede22e-ca14-4aa0-932c-ca2f3445f926
```
Expire all silences matching a query
```
$ amtool silence query instance=~".+0"
ID Matchers Ends At Created By Comment
e48cb58a-0b17-49ba-b734-3585139b1d25 alertname=Test_Alert instance=~.+0 2017-08-02 22:41:39 UTC kellel
$ amtool silence expire $(amtool silence -q query instance=~".+0")
$ amtool silence query instance=~".+0"
```
Expire all silences
```
$ amtool silence expire $(amtool silence query -q)
```
### Config
Amtool allows a config file to specify some options for convenience. The default config file paths are `$HOME/.config/amtool/config.yml` or `/etc/amtool/config.yml`
An example configfile might look like the following:
```
# Define the path that amtool can find your `alertmanager` instance at
alertmanager.url: "http://localhost:9093"
# Override the default author. (unset defaults to your username)
author: me@example.com
# Force amtool to give you an error if you don't include a comment on a silence
comment_required: true
# Set a default output format. (unset defaults to simple)
output: extended
```
2016-09-09 12:48:35 +00:00
## High Availability
> Warning: High Availability is under active development
2016-09-09 12:48:35 +00:00
To create a highly available cluster of the Alertmanager the instances need to
be configured to communicate with each other. This is configured using the
`-mesh.*` flags.
- `--mesh.peer-id` string: mesh peer ID (default "&lt;hardware-mac-address&gt;")
- `--mesh.listen-address` string: mesh listen address (default "0.0.0.0:6783")
- `--mesh.nickname` string: mesh peer nickname (default "&lt;machine-hostname&gt;")
- `--mesh.peer` value: initial peers (repeat flag for each additional peer)
2016-09-09 12:48:35 +00:00
The `mesh.peer-id` flag is used as a unique ID among the peers. It defaults to
the MAC address, therefore the default value should typically be a good option.
The same applies to the default of the `mesh.nickname` flag, as it defaults to
the hostname.
The chosen port in the `mesh.listen-address` flag is the port that needs to be
specified in the `mesh.peer` flag of the other peers.
2016-09-09 12:48:35 +00:00
To start a cluster of three peers on your local machine use `goreman` and the
Procfile within this repository.
goreman start
To point your Prometheus 1.4, or later, instance to multiple Alertmanagers, configure them
in your `prometheus.yml` configuration file, for example:
2016-09-09 12:48:35 +00:00
```yaml
alerting:
alertmanagers:
- static_configs:
- targets:
- alertmanager1:9093
- alertmanager2:9093
- alertmanager3:9093
```
2016-09-09 12:48:35 +00:00
> Important: Do not load balance traffic between Prometheus and its Alertmanagers, but instead point Prometheus to a list of all Alertmanagers. The Alertmanager implementation expects all alerts to be sent to all Alertmanagers to ensure high availability.
2017-03-31 15:49:50 +00:00
## Contributing to the Front-End
Refer to [ui/app/CONTRIBUTING.md](ui/app/CONTRIBUTING.md).
2017-03-31 15:49:50 +00:00
2015-10-26 14:11:14 +00:00
## Architecture
![](https://raw.githubusercontent.com/prometheus/alertmanager/4e6695682acd2580773a904e4aa2e3b927ee27b7/doc/arch.jpg)
2015-10-22 12:56:55 +00:00
[travis]: https://travis-ci.org/prometheus/alertmanager
[hub]: https://hub.docker.com/r/prom/alertmanager/
[circleci]: https://circleci.com/gh/prometheus/alertmanager
2016-05-13 19:48:57 +00:00
[quay]: https://quay.io/repository/prometheus/alertmanager