Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente |
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 |
---|
| {{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> |