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.

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

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.

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.

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.