[alertmanager](https://www.prometheus.io/docs/alerting/latest/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 [[technique:adminsys:monitoring:alerting:vmalert|vmalert]].
+
+
Son rôle est simple : décider quand envoyer un signal à l'équipe technique, par exemple sur Mattermost ou par mail.
+
+
<bootnote question>
+
Pourquoi ne pas directement envoyer les alertes générées par `vmalert` ?
+
</bootnote>
+
+
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.
<bootnote web>Les fichiers utilisés pour déployer `alertmanager` se trouvent [sur Gitlab](https://gitlab.utc.fr/picasoft/projets/services/monitoring/-/tree/master/alertmanager).</bootnote>
+
+
<bootnote learn>Les explications complètes pour configurer `alertmanager` sont [sur la documentation Prometheus](https://www.prometheus.io/docs/alerting/latest/configuration/).</bootnote>
+
+
`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.
+
+
```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 [[technique:adminsys:monitoring:collect:blackbox|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.
+
+
```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.
+
+
<bootnote>
+
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.
+
</bootnote>
+
+
### Envoyer un message sur Mattermost
+
+
`alertmanager` est fait pour fonctionner avec Slack, mais Mattermost est compatible. Les messages sont envoyés via un [[technique:adminserv:mattermost:hooks_commands|webhook entrant]].
+
+
Une fois l'URL du webhook connu, il suffit de suivre la [configuration Slack](https://www.prometheus.io/docs/alerting/latest/configuration/#slack_config).
+
+
<bootnote warning>
+
À 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.
+
</bootnote>
+
+
### Utiliser l'interface web
+
+
`alertmanager` expose une interface web à l'adresse [alertmanager.picasoft.net](https://alertmanager.picasoft.net). Les identifiants sont dans le [[asso:tuto:vaultwarden|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.
+
+
<bootnote>
+
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.
+
</bootnote>
+
+
<bootnote>
+
On peut retrouver les labels dans le fichier de configuration où l'on crée les alertes : [vmalert-rules.yml](https://gitlab.utc.fr/picasoft/projets/services/monitoring/-/blob/master/vmalert-rules.yml)