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.
# The root route on which each incoming alert enters. route: group_by: ['instance', 'alertname'] group_wait: 30s group_interval: 5m repeat_interval: 24h
receiver
pour Mattermost est configuré à partgroup_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.
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 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