fatigue d'alertes prometheus on est inondés

Question

salut la gang, on est en train de se noyer sous les alertes prometheus/alertmanager. on a des centaines d'alertes par jour. la plupart sont juste du bruit, des seuils trop bas, ou des trucs qui se réparent tout seuls. du coup les équipes commencent à ignorer le pager et c'est dangereux. on a besoin d'un coup de main pour remettre de l'ordre dans tout ça. on est sur un stack prometheus / alertmanager / grafana. on a des alertes pour le cpu, la mémoire, le disque, http 5xx, latence, etc. trop c'est trop.

# Exemple d'alerte qui nous spamme
- alert: HostHighCpuLoad
  expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "Host {{ $labels.instance }} has high CPU load"

lebrun-brigitte · Answer

c le piège classique. première étape : tu identifies les alertes les plus bruyantes. pour chacune, tu te poses la question : est-ce que ça requiert une action humaine immédiate ? si non, c du warning ou de l'info, ou ça doit être corrigé à la source. revoir les seuils pour être plus agressif.

valentine23 · Answer

et utiliser les groupements d'alertes dans alertmanager. regroupe par service ou par type de problème. comme ça un incident = une notification pas 50. et les silences ! utilise-les pour les maintenances ou les problèmes connus temporaires.

sebastien82 · Answer

ok pour les groupements on utilise déjà un peu mais on peut faire mieux. les silences on en fait mais c'est pas proactif. le problème c'est que les seuils sont souvent arbitraires. genre cpu à 80% ça spamme alors que c'est une vm de dev qui fait un batch une fois par jour. comment on gère ça ?

lebrun-brigitte · Answer

pour les seuils arbitraires tu dois passer aux SLOs (Service Level Objectives). plutot que "cpu > 80%", tu fais "latence P99 de mon API > X ms sur 5 min" ou "taux d'erreur > Y% sur 1h". ça alerte sur l'impact utilisateur pas sur une métrique d'infra. ça change tout.

valentine23 · Answer

et une fois que t'as tes SLOs en place tu peux décommissionner pas mal d'alertes d'infra bas niveau si elles sont pas directement corrélées à un SLO. une panne disque qui fait pas tomber un SLO n'est pas forcément une alerte urgente. ça peut être un ticket d'infra à gérer dans la journée.

sebastien82 · Answer

ok les SLOs c'est une grosse refonte mais je vois le point. on va commencer à identifier nos services critiques et leurs objectifs de perf/dispo. ça va prendre du temps mais ça a l'air d'être la seule solution viable à long terme.

lebrun-brigitte · Answer

clairement c'est le game changer pour la fatigue d'alertes. bon courage !

fatigue d'alertes prometheus on est inondés

Commentaires

Laisser une réponse

Créer ses propres images Docker avec le Dockerfile

Maîtrisez les commandes Git indispensables pour GitLab

Introduction du cours pour apprendre la technologie Docker

Rejoindre la communauté