alertmanager
0.27.0
Der Alertmanager übernimmt Warnungen, die von Client -Anwendungen wie dem Prometheus -Server gesendet werden. Es kümmert sich um das Deduplizieren, Gruppieren und Weiterleiten der richtigen Empfängerintegrationen wie E -Mail, Pagerduty, Opsgenie oder vielen anderen Mechanismen dank des Webhook -Empfängers. Es kümmert sich auch um die Stummschaltung und Hemmung von Warnungen.
Es gibt verschiedene Möglichkeiten, AlertManager zu installieren.
Vorkompilierte Binärdateien für veröffentlichte Versionen finden Sie im Download -Abschnitt über Prometheus.io. Die neueste Produktionsveröffentlichung ist die empfohlene Methode zur Installation von AlertManager.
Docker -Bilder sind auf Quay.io oder Docker Hub verfügbar.
Sie können einen Alertmanager -Container starten, um es auszuprobieren
$ docker run --name alertmanager -d -p 127.0.0.1:9093:9093 quay.io/prometheus/alertmanager
AlertManager ist nun unter http: // localhost: 9093/erreichbar.
Sie können es entweder go get :
$ GO15VENDOREXPERIMENT=1 go get github.com/prometheus/alertmanager/cmd/...
# cd $GOPATH/src/github.com/prometheus/alertmanager
$ alertmanager --config.file=<your_file>
Oder klonen Sie das Repository und erstellen Sie manuell:
$ 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>
Sie können auch nur eines der Binärdateien in diesem Repo erstellen, indem Sie einen Namen an die Build -Funktion übergeben:
$ make build BINARIES=amtool
Dies ist eine Beispielkonfiguration, die die relevantesten Aspekte des neuen YAML -Konfigurationsformats abdecken sollte. Die vollständige Dokumentation der Konfiguration finden Sie hier.
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> Die aktuelle AlertManager -API ist Version 2. Diese API wird vollständig über das OpenAPI -Projekt erzeugt und mit Ausnahme der HTTP -Handler selbst Prahlerei. Die API -Spezifikation finden Sie in API/V2/openAPI.yaml. Auf eine HTML -gerenderte Version kann hier zugegriffen werden. Kunden können für alle Hauptsprachen einfach über jeden OpenAPI -Generator generiert werden.
Mit der Standardkonfiguration werden auf Endpunkte unter A /api/v1 oder /api/v2 -Präfix zugegriffen. Der v2 /status -Endpunkt wäre /api/v2/status . Wenn --web.route-prefix festgelegt ist, werden auch API-Routen vorangestellt, also --web.route-prefix=/alertmanager/ würde sich auf /alertmanager/api/v2/status beziehen.
API V2 steht noch unter starker Entwicklung und unterliegt damit der Veränderung.
amtool ist ein CLI -Werkzeug zum Interaktion mit der Alertmanager -API. Es ist mit allen Veröffentlichungen von Alertmanager gebündelt.
Alternativ können Sie mit:
$ go install github.com/prometheus/alertmanager/cmd/amtool@latest
Zeigen Sie alle derzeit abgefeuerten Warnungen an:
$ 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!
Zeigen Sie alle derzeit abfeuerenden Warnungen mit verlängerter Ausgabe an:
$ 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
Zusätzlich zum Anzeigen von Benachrichtigungen können Sie die von AlertManager bereitgestellte Rich Query -Syntax verwenden:
$ 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
Schweigen Sie eine Warnung:
$ amtool silence add alertname=Test_Alert
b3ede22e-ca14-4aa0-932c-ca2f3445f926
$ amtool silence add alertname="Test_Alert" instance=~".+0"
e48cb58a-0b17-49ba-b734-3585139b1d25
Stille anzeigen:
$ 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
Eine Stille ablehnen:
$ amtool silence expire b3ede22e-ca14-4aa0-932c-ca2f3445f926
Ablauf aller Stille, die einer Abfrage entsprechen:
$ 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"
Ablauf aller Stille:
$ amtool silence expire $(amtool silence query -q)
Probieren Sie heraus, wie eine Vorlage funktioniert. Angenommen, Sie haben dies in Ihrer Konfigurationsdatei:
templates:
- '/foo/bar/*.tmpl'
Dann können Sie testen, wie eine Vorlage mit Beispiel mit diesem Befehl aussehen würde:
amtool template render --template.glob='/foo/bar/*.tmpl' --template.text='{{ template "slack.default.markdown.v1" . }}'
amtool ermöglicht eine Konfigurationsdatei, einige Optionen für die Bequemlichkeit anzugeben. Die Standardkonfigurationsdateipfade sind $HOME/.config/amtool/config.yml oder /etc/amtool/config.yml
Eine Beispielkonfigurationsdatei sieht möglicherweise wie folgt aus:
# 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 können Sie die Routen Ihrer Konfiguration in Form der Textbaumansicht visualisieren. Sie können es auch verwenden, um das Routing zu testen, indem Sie die Kennzeichnung eines Alarms übergeben, und es druckt alle Empfänger aus, die der Alarm übereinstimmt, der geordnet ist und getrennt wird , (Wenn Sie --verify.receivers amtool verwenden, gibt der Fehlercode 1 auf Nichtübereinstimmung zurück)
Beispiel der Nutzung:
# 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
Die hohe Verfügbarkeit von Alertmanager ist in vielen Unternehmen in der Produktion verwendet und ist standardmäßig aktiviert.
WICHTIG: Sowohl UDP als auch TCP werden in Alertmanager 0,15 und höher benötigt, damit der Cluster funktioniert.
- Wenn Sie eine Firewall verwenden, stellen Sie sicher, dass der Clustering -Port für beide Protokolle die Whitelistin für beide Protokolle ist.
- Wenn Sie in einem Container ausführen, stellen Sie sicher, dass der Clustering -Port für beide Protokolle freigelegt wird.
So erstellen Sie einen hoch verfügbaren Cluster des Alertmanagers, die Instanzen müssen konfiguriert werden, um miteinander zu kommunizieren. Dies wird mit den Flags --cluster.* Konfiguriert.
--cluster.listen-address String: Cluster-Listenadresse (Standard "0.0.0.0:9094"; leerer String deaktiviert den HA-Modus)--cluster.advertise-address String: Cluster-Werbungadresse--cluster.peer Value: Erste Kollegen (Wiederholungsflag für jeden zusätzlichen Peer)--cluster.peer-timeout -Wert: Peer Timeout Periode (Standard "15s")--cluster.gossip-interval -Wert: Cluster-Meldungsmeldungsgeschwindigkeit (Standard "200 ms")--cluster.pushpull-interval -Wert: Niedrigere Werte erhöhen die Konvergenzgeschwindigkeiten auf Kosten der Bandbreite (Standard "1M0S").--cluster.settle-timeout -Wert: Maximale Zeit, um auf Clusterverbindungen zu warten, bevor Benachrichtigungen bewertet werden.--cluster.tcp-timeout -Wert: Zeitlimitwert für TCP-Verbindungen, liest und schreibt (Standard "10S").--cluster.probe-timeout -Wert: Zeit zum Warten auf ACK, bevor Sie den Knoten ungesund markieren (Standard "500 ms")--cluster.probe-interval -Wert: Intervall zwischen zufälligen Knotensonden (Standard "1s")--cluster.reconnect-interval -Wert: Intervall zwischen dem Versuch, sich wieder mit verlorenen Kollegen zu verbinden (Standard "10S")--cluster.reconnect-timeout -Wert: Zeitdauer, um zu versuchen, sich mit einem verlorenen Peer zu verbinden (Standard: "6H0M0S")--cluster.label Value: Die Beschriftung ist eine optionale Zeichenfolge, die in jedem Paket und Stream aufgenommen wird. Es identifiziert den Cluster eindeutig und verhindert Kreuzungsfragen beim Senden von Klatschmeldungen (Standard: "") Der ausgewählte Port im Flag cluster.listen-address ist der Port, der im cluster.peer Flag der anderen Kollegen angegeben werden muss.
Das Flag cluster.advertise-address ist erforderlich, wenn die Instanz keine IP-Adresse hat, die Teil von RFC 6890 mit einer Standardroute ist.
Verwenden Sie goreman und das Procfile in diesem Repository, um einen Cluster von drei Kollegen auf Ihrem lokalen Computer zu starten.
goreman start
Konfigurieren Sie sie in Ihrer prometheus.yml -Konfigurationsdatei, um Ihren Prometheus 1.4 oder später auf mehrere Allertmanager zu richten, z. B. in Ihrer Prometheus.yml -Konfigurationsdatei:
alerting :
alertmanagers :
- static_configs :
- targets :
- alertmanager1:9093
- alertmanager2:9093
- alertmanager3:9093WICHTIG: Laden Sie den Gleichgewicht zwischen Prometheus und seinen Allertmanagern nicht aus, sondern zeigen Sie Prometheus auf eine Liste aller Allertmanager. Die Implementierung von Alertmanager erwartet, dass alle Warnungen an alle Allertmanager gesendet werden, um eine hohe Verfügbarkeit zu gewährleisten.
Wenn der Ausführen von AlertManager im hohen Verfügbarkeitsmodus nicht gewünscht wird, verhindert die Einstellung --cluster.listen-address= dass AlertManager eingehende Peer-Anfragen anhören.
Überprüfen Sie die Seite Prometheus beitragen.
Um zur Benutzeroberfläche beizutragen, lesen Sie UI/App/Beitrag.md.md.
Apache -Lizenz 2.0, siehe Lizenz.
