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/11/22 22:35] – ↷ Liens modifiés en raison d'un déplacement. qduchemi | technique:adminsys:monitoring:alerting:alertmanager [2022/10/19 01:47] (Version actuelle) – ajout lien fichier de conf altermanager ppom |
---|
### 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> |
| |
- 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). |
### 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:adminsys:secu: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. |
<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> |