alertmanager
0.27.0
L'AlertManager gère les alertes envoyées par les applications client telles que le serveur PromEtheus. Il s'occupe de les dédupliquer, de les regrouper et de les acheminer vers les intégrations du récepteur correctes telles que le courrier électronique, PagerDuty, Opsgenie ou de nombreux autres mécanismes grâce au récepteur WebHook. Il s'occupe également du silence et de l'inhibition des alertes.
Il existe différentes façons d'installer AlertManager.
Des binaires précompilés pour les versions publiées sont disponibles dans la section de téléchargement sur prometheus.io. L'utilisation du dernier binaire de version de production est le moyen recommandé d'installer AlertManager.
Les images Docker sont disponibles sur Quay.io ou Docker Hub.
Vous pouvez lancer un conteneur alertManager pour l'essayer avec
$ docker run --name alertmanager -d -p 127.0.0.1:9093:9093 quay.io/prometheus/alertmanager
AlertManager sera désormais accessible sur http: // localhost: 9093 /.
Vous pouvez soit go get :
$ GO15VENDOREXPERIMENT=1 go get github.com/prometheus/alertmanager/cmd/...
# cd $GOPATH/src/github.com/prometheus/alertmanager
$ alertmanager --config.file=<your_file>
Ou cloner le référentiel et construire manuellement:
$ 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>
Vous pouvez également construire un seul des binaires de ce dépôt en passant un nom à la fonction de construction:
$ make build BINARIES=amtool
Il s'agit d'un exemple de configuration qui devrait couvrir les aspects les plus pertinents du nouveau format de configuration YAML. La documentation complète de la configuration peut être trouvée ici.
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> L'API AlertRanager actuelle est la version 2. Cette API est entièrement générée via le projet OpenAPI et GO Swagger à l'exception des gestionnaires HTTP eux-mêmes. La spécification de l'API peut être trouvée dans API / V2 / OpenAPI.yaml. Une version HTML rendue est accessible ici. Les clients peuvent être facilement générés via n'importe quel générateur OpenAPI pour toutes les principales langues.
Avec la configuration par défaut, les points de terminaison sont accessibles sous le préfixe A /api/v1 ou /api/v2 . Le point de terminaison V2 /status serait /api/v2/status . Si --web.route-prefix est défini, les routes API sont également préfixées avec cela, donc --web.route-prefix=/alertmanager/ serait lié à /alertmanager/api/v2/status .
L'API V2 est toujours en cours de développement intense et est ainsi soumise à un changement.
amtool est un outil CLI pour interagir avec l'API AlertManager. Il est emballé avec toutes les versions d'AlertManager.
Vous pouvez également installer avec:
$ go install github.com/prometheus/alertmanager/cmd/amtool@latest
Afficher toutes les alertes en cours de tir:
$ 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!
Afficher toutes les alertes actuellement tirant avec une sortie étendue:
$ 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
En plus de visualiser les alertes, vous pouvez utiliser la syntaxe de requête riche fournie par 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
Tituler une alerte:
$ amtool silence add alertname=Test_Alert
b3ede22e-ca14-4aa0-932c-ca2f3445f926
$ amtool silence add alertname="Test_Alert" instance=~".+0"
e48cb58a-0b17-49ba-b734-3585139b1d25
Voir les 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
Expirer un silence:
$ amtool silence expire b3ede22e-ca14-4aa0-932c-ca2f3445f926
Expirer tous les silences correspondant à une requête:
$ 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"
Expirer tous les silences:
$ amtool silence expire $(amtool silence query -q)
Essayez comment un modèle fonctionne. Disons que vous l'avez dans votre fichier de configuration:
templates:
- '/foo/bar/*.tmpl'
Ensuite, vous pouvez tester à quoi ressemblerait un modèle avec l'exemple en utilisant cette commande:
amtool template render --template.glob='/foo/bar/*.tmpl' --template.text='{{ template "slack.default.markdown.v1" . }}'
amtool permet à un fichier de configuration de spécifier certaines options de commodité. Les chemins de fichier de configuration par défaut sont $HOME/.config/amtool/config.yml ou /etc/amtool/config.yml
Un exemple de fichier de configuration peut ressembler à ce qui suit:
# 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 vous permet de visualiser les itinéraires de votre configuration sous forme de vue d'arborescence de texte. Vous pouvez également l'utiliser pour tester le routage en le faisant passer un ensemble d'étiquettes d'une alerte et il imprime tous les récepteurs que l'alerte correspondrait commandée et séparée par , . (Si vous utilisez --verify.receivers Amtool renvoie le code d'erreur 1 sur l'inadéquation)
Exemple d'utilisation:
# 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
La haute disponibilité d'AlertManager est dans l'utilisation de la production dans de nombreuses entreprises et est activée par défaut.
IMPORTANT: UDP et TCP sont nécessaires dans AlertManager 0,15 et plus pour que le cluster fonctionne.
- Si vous utilisez un pare-feu, assurez-vous de la liste blanche du port de clustering pour les deux protocoles.
- Si vous utilisez un conteneur, assurez-vous d'exposer le port de clustering pour les deux protocoles.
Pour créer un cluster hautement disponible de l'AlertManager, les instances doivent être configurées pour communiquer entre elles. Ceci est configuré à l'aide de --cluster.* Flags.
--cluster.listen-address String: Adresse d'écoute en cluster (par défaut "0.0.0.0:9094"; La chaîne vide désactive le mode HA)--cluster.advertise-address String: Adresse de publicité en cluster--cluster.peer Valeur: pairs initiaux (indicateur de répétition pour chaque pair supplémentaire)--cluster.peer-timeout Valeur: Période de temps d'attente des pairs (par défaut "15s")--cluster.gossip-interval Valeur: vitesse de propagation du message en cluster (par défaut "200 ms")--cluster.pushpull-interval : les valeurs inférieures augmenteront les vitesses de convergence aux dépens de la bande passante (par défaut "1m0s")--cluster.settle-timeout Valeur: Temps maximum pour attendre que les connexions de cluster se réglaient avant d'évaluer les notifications.--cluster.tcp-timeout Valeur: Valeur de tempsout pour les connexions, lectures et écritures TCP (par défaut "10s")--cluster.probe-timeout Valeur: Il est temps d'attendre ACK avant de marquer le nœud malsain (par défaut "500 ms")--cluster.probe-interval Valeur: intervalle entre les sondes de nœud aléatoire (par défaut "1s")--cluster.reconnect-interval Valeur: Intervalle entre tenter de se reconnecter aux pairs perdus (par défaut "10s")--cluster.reconnect-timeout Valeur: durée pour tenter de se reconnecter à un homologue perdu (par défaut: "6H0M0S")--cluster.label Valeur: L'étiquette est une chaîne facultative à inclure sur chaque paquet et flux. Il identifie de manière unique le cluster et empêche les problèmes de communication entre communication lors de l'envoi de messages de potins (par défaut: "") Le port choisi dans l'indicateur cluster.listen-address est le port qui doit être spécifié dans le drapeau cluster.peer des autres pairs.
L'indicateur cluster.advertise-address est requis si l'instance n'a pas d'adresse IP qui fait partie de RFC 6890 avec un itinéraire par défaut.
Pour démarrer un cluster de trois pairs sur votre machine locale, utilisez goreman et le Profile dans ce référentiel.
goreman start
Pour pointer votre promesse 1.4, ou version ultérieure, sur plusieurs alertRanagers, configurez-les dans votre fichier de configuration prometheus.yml , par exemple:
alerting :
alertmanagers :
- static_configs :
- targets :
- alertmanager1:9093
- alertmanager2:9093
- alertmanager3:9093IMPORTANT: Ne pas équilibrer le trafic entre Prometheus et ses alertmanagers, mais pointe plutôt Prométhée vers une liste de tous les alertmanagers. L'implémentation AlertManager s'attend à ce que toutes les alertes soient envoyées à tous les alertmanagers pour garantir une grande disponibilité.
Si l'exécution d'AlertManager en mode haute disponibilité n'est pas souhaité, le réglage --cluster.listen-address= empêche AlertManager d'écouter les demandes de pairs entrantes.
Vérifiez la page de contribution de Prometheus.
Pour contribuer à l'interface utilisateur, reportez-vous à l'interface utilisateur / app / contributing.md.
Licence Apache 2.0, voir Licence.
