Différences

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

Lien vers cette vue comparative

Prochaine révision
Révision précédente
technique:adminsys:monitoring:alerting:alertmanager [2021/09/01 14:12] – créée qduchemitechnique:adminsys:monitoring:alerting:alertmanager [2022/10/19 01:47] (Version actuelle) – ajout lien fichier de conf altermanager ppom
Ligne 2: Ligne 2:
  
 ## Traiter les alertes avec alertmanager ## 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>
  • technique/adminsys/monitoring/alerting/alertmanager.1630498332.txt.gz
  • de qduchemi