Différences

Ci-dessous, les différences entre deux révisions de la page.

--- technique:adminsys:monitoring:alerting:alertmanager [2021/09/02 21:46] – qduchemi
+++ technique:adminsys:monitoring:alerting:alertmanager [2022/10/19 01:47] (Version actuelle) – ajout lien fichier de conf altermanager ppom
@@ Ligne 1: / Ligne 1: @@
+{{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>