Différences

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

Lien vers cette vue comparative

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] qduchemitechnique:adminsys:monitoring:alerting:alertmanager [2022/10/19 01:47] (Version actuelle) – ajout lien fichier de conf altermanager ppom
Ligne 23: Ligne 23:
 ### Configuration ### Configuration
  
-<bootnote web>Les fichiers utilisés pour déployer `alertmanager` se trouvent [sur Gitlab](https://gitlab.utc.fr/picasoft/projets/dockerfiles/-/tree/master/pica-metrologie/alertmanager).</bootnote>+<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> <bootnote learn>Les explications complètes pour configurer `alertmanager` sont [sur la documentation Prometheus](https://www.prometheus.io/docs/alerting/latest/configuration/).</bootnote>
Ligne 41: Ligne 41:
  
 - Le `receiver` pour Mattermost est configuré à part - 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:metrologie: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.+- 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_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). - `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).
Ligne 75: Ligne 75:
 ### Utiliser l'interface web ### Utiliser l'interface web
  
-`alertmanager` expose une interface web à l'adresse [alertmanager.picasoft.net](https://alertmanager.picasoft.net). Les identifiants sont dans le [[technique:tips:password_store:start|pass]].+`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.  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. 
Ligne 83: Ligne 83:
 <bootnote> <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. 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> </bootnote>
  • technique/adminsys/monitoring/alerting/alertmanager.1630611974.txt.gz
  • de qduchemi