technique:adminsys:monitoring:alerting:alertmanager

alertmanager est un outil de l’écosystème Prometheus qui traite les alertes générées par le système de monitoring. Chez nous, alertmanager reçoit les alertes depuis vmalert.

Son rôle est simple : décider quand envoyer un signal à l’équipe technique, par exemple sur Mattermost ou par mail.

Question:

Pourquoi ne pas directement envoyer les alertes générées par vmalert ?

Dans le cas de Picasoft, on pourrait. Pour les plus grosses infrastructures, il y a un vrai besoin de filtrage des alertes. Par exemple, dans une grosse infrastructure où 10 services utilisent une base de données, si celle-ci tombe en panne, les services généreraient 10 alertes. C’est trop, ça n’ajoute pas d’information ; il faut grouper les 10 alertes dans une seule et n’envoyer qu’un message.

On peut aussi vouloir utiliser différents canaux en fonction du type d’alerte : par mail, sur Mattermost, sur un système de ticketing… alertmanager prend en charge tous ces cas.

Sur Mattermost, les alertes ressemblent à :

Lien:

Les fichiers utilisés pour déployer alertmanager se trouvent sur Gitlab.

A Savoir:

Les explications complètes pour configurer alertmanager sont sur la documentation Prometheus.

alertmanager est déployé via Docker. On se base sur l’image officielle, à laquelle on ajoute un entrypoint personnalisé qui sert à injecter les secrets dans le fichier de configuration. En effet, alertmanager n’offre aucun moyen d’utiliser les variables d’environnement pour récupérer des secrets.

Notre configuration est assez simple. D’abord, les alertes passent toutes par la même route, c’est-à-dire qu’elles seront envoyées au même endroit.

snippet.yaml
# The root route on which each incoming alert enters.
route:
  group_by: ['instance', 'alertname']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 24h
  • Le receiver pour Mattermost est configuré à part
  • Les alertes sont groupées par instance et nom d’alerte. En pratique, ça ne groupe que les mêmes alertes, qui seraient envoyées rapidement. On peut se le permettre car on a peu de machines et peu d’alertes différentes qui peuvent se déclencher simultanément (sauf perte totale d’une machine). On pourrait tout à fait décider de faire plus sophistiqué et de créer une route spéciale pour les alertes liées aux services web, qui groupent seulement par nom d’alerte. De fait, si une machine s’éteint, une seule alerte sera produite pour prévenir que les services web ne fonctionnent plus.
  • group_wait correspond au temps avant d’envoyer une notification à partir de la réception d’une alerte. Typiquement, ça permet d’attendre que des alertes très similaires arrivent et de les grouper avant envoi. Typiquement inférieur à une minutes.
  • group_interval correspond au délai avant d’envoyer des alertes qui appartiennent à un groupe dont les alertes sont déjà parties. Dans notre cas, c’est insignifiant puisque seules les alertes identiques sont groupées (voir prochain point).
  • repeat_interval correspond au délai avant de renvoyer une alerte. Pour ne pas spammer l’équipe technique, une journée est raisonnable.

Deuxièmement, on peut configurer des inhibitions, c’est-à-dire des règles qui indiquent quand ignorer une alerte lorsqu’une autre alerte est déjà en cours.

snippet.yaml
inhibit_rules:
- source_matchers:
  - severity="critical"
  target_matchers:
  - severity="warning"
  equal: ['alertname']

Notre configuration est plutôt basique : on ignore les alertes avec un niveau de criticité warning si une alerte avec un niveau de criticité critical portant le même nom est déjà en cours.

Note:

Un exemple typique est celui d’une alerte sur disque : on peut envoyer un warning à 80% et un critical à 95% de remplissage. Passé 95%, les deux alertes (avec le même nom) seront envoyées, mais seule la critical sera reportée grâce à l’inhibition, et c’est bien elle qui porte l’information principale.

alertmanager est fait pour fonctionner avec Slack, mais Mattermost est compatible. Les messages sont envoyés via un webhook entrant.

Une fois l’URL du webhook connu, il suffit de suivre la configuration Slack.

Attention:

À ce jour (septembre 2021), les actions Slack ne sont plus compatibles avec Mattermost ; il est donc impossible de rajouter des boutons dans les messages. On a mis des liens pour le moment.

alertmanager expose une interface web à l’adresse alertmanager.picasoft.net. Les identifiants sont dans le pass.

Cette interface est très pratique, car elle permet de voir toutes les alertes qui sont toujours en cours, chose qui est difficile à savoir en se basant sur l’heure de la notification.

Aussi, en cliquant sur Silence the alert dans la notification, on peut configurer un délai pendant lequel une alerte n’émettra plus de notification.

Note:

Par exemple, si on sait qu’un serveur va être éteint pendant deux jours, on va rendre silencieuses les alertes liées à ce serveur pour éviter de spammer inutilement l’équipe technique.

  • technique/adminsys/monitoring/alerting/alertmanager.txt
  • de qduchemi