Table des matières

Traiter les alertes avec alertmanager

Utilité

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 à :

Configuration

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

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.

Envoyer un message sur Mattermost

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.

Utiliser l'interface web

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

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.

Note:

On peut retrouver les labels dans le fichier de configuration où l’on crée les alertes : vmalert-rules.yml