AlertManagerは、Prometheus Serverなどのクライアントアプリケーションによって送信されたアラートを処理します。 Webhookレシーバーのおかげで、電子メール、Pagerduty、Opsgenie、またはその他の多くのメカニズムなど、それらを容赦、グループ化、およびルーティングに処理します。また、アラートのサイレンシングと抑制にも対応しています。
AlertManagerをインストールするさまざまな方法があります。
リリースされたバージョン用のプリコンパイルされたバイナリは、prometheus.ioのダウンロードセクションで入手できます。最新の生産リリースバイナリを使用することは、AlertManagerをインストールする推奨方法です。
docker画像はquay.ioまたはdockerハブで入手できます。
アラートマネージャーコンテナを起動するためのアラートマネージャーコンテナを起動できます
$ docker run --name alertmanager -d -p 127.0.0.1:9093:9093 quay.io/prometheus/alertmanager
AlertManagerはhttp:// localhost:9093/で到達可能になります。
あなたはそれをgo getことができます:
$ GO15VENDOREXPERIMENT=1 go get github.com/prometheus/alertmanager/cmd/...
# cd $GOPATH/src/github.com/prometheus/alertmanager
$ alertmanager --config.file=<your_file>
または、リポジトリをクローンして手動で構築します。
$ 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>
また、このリポジトリのバイナリの1つだけを構築することもできます。名前をビルド関数に渡すこともできます。
$ make build BINARIES=amtool
これは、新しいYAML構成形式の最も関連性の高い側面をカバーする必要がある構成の例です。構成の完全なドキュメントはこちらをご覧ください。
global :
# The smarthost and SMTP sender used for mail notifications.
smtp_smarthost : ' localhost:25 '
smtp_from : ' [email protected] '
# 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.
#
# 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
# 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 route performs a regular expression match on alert labels to
# catch alerts that are related to a list of services.
- matchers :
- 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 :
- matchers :
- severity="critical"
receiver : team-X-pager
- matchers :
- service="files"
receiver : team-Y-mails
routes :
- matchers :
- 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.
- matchers :
- service="database"
receiver : team-DB-pager
# Also group alerts by affected database.
group_by : [alertname, cluster, database]
routes :
- matchers :
- owner="team-X"
receiver : team-X-pager
- matchers :
- 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_matchers :
- severity="critical"
target_matchers :
- severity="warning"
# Apply inhibition if the alertname is the same.
# CAUTION:
# If all label names listed in `equal` are missing
# from both the source and target alerts,
# the inhibition rule will apply!
equal : ['alertname']
receivers :
- name : ' team-X-mails '
email_configs :
- to : ' [email protected], [email protected] '
- name : ' team-X-pager '
email_configs :
- to : ' [email protected] '
pagerduty_configs :
- routing_key : <team-X-key>
- name : ' team-Y-mails '
email_configs :
- to : ' [email protected] '
- name : ' team-Y-pager '
pagerduty_configs :
- routing_key : <team-Y-key>
- name : ' team-DB-pager '
pagerduty_configs :
- routing_key : <team-DB-key> 現在のAlertManager APIはバージョン2です。このAPIは、HTTPハンドラー自体を除き、Openapiプロジェクトを介して完全に生成され、Swaggerになります。 API仕様は、API/V2/OpenAPI.YAMLにあります。 HTMLレンダリングバージョンにアクセスできます。クライアントは、すべての主要言語の任意のOpenAPIジェネレーターを介して簡単に生成できます。
デフォルトの構成を使用すると、エンドポイントはA /api/v1または/api/v2プレフィックスでアクセスされます。 V2 /statusエンドポイントは/api/v2/statusです。 --web.route-prefixが設定されている場合、APIルートにはそれも付いているため、 --web.route-prefix=/alertmanager/ /alertmanager/api/v2/statusに関連します。
API V2は依然として激しい開発中であり、それによって変更される可能性があります。
amtool 、AlertManager APIと対話するためのCLIツールです。 AlertManagerのすべてのリリースにバンドルされています。
または、次のようにインストールできます。
$ go install github.com/prometheus/alertmanager/cmd/amtool@latest
現在発生しているすべてのアラートを表示します。
$ 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!
拡張出力で現在発生しているすべてのアラートを表示します。
$ 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
アラートの表示に加えて、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
アラートを沈黙させる:
$ amtool silence add alertname=Test_Alert
b3ede22e-ca14-4aa0-932c-ca2f3445f926
$ amtool silence add alertname="Test_Alert" instance=~".+0"
e48cb58a-0b17-49ba-b734-3585139b1d25
沈黙を見る:
$ 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
沈黙を期限切れにする:
$ amtool silence expire b3ede22e-ca14-4aa0-932c-ca2f3445f926
クエリに一致するすべてのサイレンスを期限切れにします:
$ 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 query -q instance=~".+0")
$ amtool silence query instance=~".+0"
すべての沈黙を期限切れにします:
$ amtool silence expire $(amtool silence query -q)
テンプレートの仕組みを試してみてください。構成ファイルにこれを持っているとしましょう。
templates:
- '/foo/bar/*.tmpl'
次に、このコマンドを使用して、例でテンプレートがどのように見えるかをテストできます。
amtool template render --template.glob='/foo/bar/*.tmpl' --template.text='{{ template "slack.default.markdown.v1" . }}'
amtool使用すると、構成ファイルが便利なオプションを指定できます。デフォルトの構成ファイルパスは、 $HOME/.config/amtool/config.ymlまたは/etc/amtool/config.ymlです
構成ファイルの例は、次のように見える場合があります。
# Define the path that `amtool` can find your `alertmanager` instance
alertmanager.url: "http://localhost:9093"
# Override the default author. (unset defaults to your username)
author: [email protected]
# 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
# Set a default receiver
receiver: team-X-pager
amtool使用すると、テキストツリービューの形で構成のルートを視覚化できます。また、アラートのラベルセットを渡すことにより、ルーティングをテストすることもできます。また、アラートが順序付けおよび分離されたすべての受信機を印刷することもできます, (使用する場合--verify.receivers amtoolは、ミスマッチでエラーコード1を返します)
使用例:
# View routing tree of remote Alertmanager
$ amtool config routes --alertmanager.url=http://localhost:9090
# Test if alert matches expected receiver
$ amtool config routes test --config.file=doc/examples/simple.yml --tree --verify.receivers=team-X-pager service=database owner=team-X
AlertManagerの高可用性は、多くの企業での生産使用において、デフォルトで有効になっています。
重要:UDPとTCPの両方が、AlertManager 0.15以上で、クラスターが動作するために必要です。
- ファイアウォールを使用している場合は、両方のプロトコルのクラスタリングポートをホワイトリストに登録してください。
- コンテナで実行している場合は、両方のプロトコルのクラスタリングポートを露出してください。
AlertManagerの非常に利用可能なクラスターを作成するには、相互に通信するためにインスタンスを構成する必要があります。これは--cluster.*フラグを使用して構成されています。
--cluster.listen-address String:クラスターリッスンアドレス(デフォルト "0.0.0.0:9094";空の文字列はHAモードを無効にします)--cluster.advertise-address文字列:クラスター広告アドレス--cluster.peer Value:初期ピア(追加のピアごとにフラグを繰り返す)--cluster.peer-timeout値:ピアタイムアウト期間(デフォルト "15s")--cluster.gossip-interval値:クラスターメッセージ伝播速度(デフォルト "200ms")--cluster.pushpull-interval値:値が低いと、帯域幅を犠牲にして収束速度が向上します(デフォルト "1m0s")--cluster.settle-timeout値:通知を評価する前に、クラスター接続が解決するのを待つ最大時間。--cluster.tcp-timeout値:TCP接続、読み取り、および書き込みのタイムアウト値(デフォルト "10s")--cluster.probe-timeout値:ノードを不健康にマークする前にACKを待つ時間(デフォルト "500ms")--cluster.probe-interval値:ランダムノードプローブ間の間隔(デフォルト "1s")--cluster.reconnect-interval値:紛失したピアに再接続しようとする間の間隔(デフォルト "10s")--cluster.reconnect-timeout値:失われたピアに再接続しようとする時間の長さ(デフォルト: "6h0m0s")--cluster.label値:ラベルは、各パケットとストリームに含めるオプションの文字列です。クラスターを独自に識別し、ゴシップメッセージを送信するときに相互コミュニケーションの問題を防ぎます(デフォルト: "") cluster.listen-addressフラグの選択されたポートは、 cluster.peer Flagで指定する必要があるポートです。
インスタンスにデフォルトのルートを備えたRFC 6890の一部であるIPアドレスがない場合、 cluster.advertise-addressフラグが必要です。
地元のマシンで3人のピアのクラスターを開始するには、 goremanとこのリポジトリ内のProcfileを使用してください。
goreman start
Prometheus 1.4以降を指定するには、複数のAlertManagersにインスタンスを表示するには、 prometheus.yml構成ファイルでそれらを構成します。たとえば
alerting :
alertmanagers :
- static_configs :
- targets :
- alertmanager1:9093
- alertmanager2:9093
- alertmanager3:9093重要:プロメテウスとそのアラートマネージャー間のトラフィックのバランスをロードしないでください。代わりに、プロメテウスにすべてのアラートマネージャーのリストを指してください。 AlertManagerの実装では、すべてのアラートがすべてのアラートマネージャーに送信され、高可用性を確保することが期待されています。
高可用性モードでAlertManagerを実行していない場合、 --cluster.listen-address=設定は、AlertManagerが着信ピアリクエストを聞くことを防ぎます。
Prometheus寄付ページを確認してください。
ユーザーインターフェイスに貢献するには、UI/APP/CONTRIBUTING.MDを参照してください。
Apacheライセンス2.0、ライセンスを参照してください。