{{indexmenu_n>20}}

## Traiter les alertes avec alertmanager

### Utilité 

[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.

Sur Mattermost, les alertes ressemblent à :

{{ :technique:adminsys:monitoring:alerting:alert_mattermost_example.png |}}

### Configuration

<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)
</bootnote>