Prometheus fait trop de bruit les alerts sont n'importe quoi

check tes `for:` clauses dans tes alert rules c'est la base si tu veux pas d'alertes pour des événements transitoires un `for: 5m` ça fait des miracles pour les alertes non critiques

c'est ça `for` c'est clé. ensuite regarde comment tes alerts sont groupées dans alertmanager si tu as `group_by: [alertname, cluster]` ça peut faire beaucoup de bruit

grave le grouping c'est essentiel. essaie `group_by: [alertname, service, namespace]` et augmente le `group_wait` et `group_interval` dans alertmanager pour éviter le burst d'alertes sur un même problème

aussi tes seuils sont ptete trop bas une instance cpu à 70% pendant 30s c'est pas une alerte si c'est normal pour ton app revoit les seuils et mets-les plus haut ou plus longs

j'ai bien des `for` sur certaines mais pas toutes et le grouping je l'ai laissé par défaut. je vais regarder `group_wait` et `group_interval` merci

pense aux inhibitions dans alertmanager aussi si une alerte critique est levée (genre cluster down) tu peux inhiber des alertes moins importantes (genre pod down) pour pas avoir les deux en même temps

et relabeling des métriques avant qu'elles arrivent à prometheus ça peut aider à uniformiser les noms pour le grouping et éviter des alertes dupliquées si tes labels sont un peu n'importe quoi

un truc con mais tu monitorer quoi exactement. si tu monitors la santé des pods en soi c'est normal que ça spam quand k8s les redémarre. vaut mieux monitorer la santé du service au global derrière un ingress par exemple

utilise des blackbox exporters pour monitorer tes endpoints externes ça simule l'expérience utilisateur et t'alertes que si un service est vraiment inaccessible et pas juste un pod qui tousse

ok je vois le tableau je vais refaire un passe sur les `for` sur toutes les alertes les seuils aussi et surtout le `group_by` et `group_wait` dans alertmanager. les inhibitions ça a l'air super utile aussi pour les alertes critiques. merci les gars ça me sauve la vie