11 commentaires
ok le FOR c'est une bonne base. mais même avec FOR 5m, si un service tombe 6 minutes, remonte 2 minutes, retombe 6 minutes, ça continue de spammer. je cherche un truc un peu plus intelligent
tu peux utiliser sum_over_time ou avg_over_time avec un threshold. par exemple, si tu veux alerter si le service est down plus de 50% du temps sur les 30 dernières minutes :
- alert: ServiceFlappingTooMuch
expr: |
avg_over_time(up{job="mon-service"}[30m]) < 0.5
for: 5m
labels:
severity: warning
annotations:
summary: "Service {{ $labels.job }} is flapping too much"
ça prend en compte l'historique récent
bonne idée le avg_over_time ! tu peux aussi jouer sur les agrégations. si tu as plusieurs instances pour ton service, tu peux alerter si un certain pourcentage des instances sont down, pas juste une seule qui fait des siennes
# Alerte si plus de 20% des instances sont down sur un job
- alert: ServicePartiallyDown
expr: |
(count by (job) (up{job="mon-service"} == 0) / count by (job) (up{job="mon-service"})) > 0.2
for: 10m
labels:
severity: critical
pour les services vraiment chiants qui flappent mais finissent toujours par remonter, tu peux aussi regarder predict_linear. ça te permet d'alerter si une métrique (genre up ou le nombre d'erreurs) prédit qu'elle va passer sous un seuil dans X minutes. un peu plus avancé mais ça aide pour les tendances
wow predict_linear j'avais jamais pensé à ça c'est une piste intéressante. et l'approche avec avg_over_time est super pour les services flappants, ça me parle bien. je vais essayer ça sur nos services les plus bruyants
n'oublie pas les recording rules aussi si tes expressions sont trop complexes ou si tu veux réutiliser des calculs. tu peux pré-calculer avg_over_time dans une recording rule et ensuite tes alertes sont plus simples
# Recording rule
- record: service_up_ratio:30m
expr: |
avg_over_time(up{job="mon-service"}[30m])
ensuite ton alerte devient :
- alert: ServiceFlappingTooMuch
expr: service_up_ratio:30m < 0.5
for: 5m
excellent ! recording rules c'est une très bonne idée pour pas alourdir le moteur d'alerte. je vais mettre en place une combinaison de for plus long, avg_over_time via une recording rule et peut-être explorer predict_linear pour les cas critiques. un énorme merci pour toutes ces pistes c'est top !
Laisser une réponse
Vous devez être connecté pour poster un message !
Salut la team SRE ! On a pas mal de services qui sont un peu flappants, genre ils tombent et remontent plusieurs fois dans la journée. Du coup nos alertes Prometheus nous spamment H24, même pour des trucs qui se réparent tout seuls en 2-3 minutes. J'ai un alert rule de base qui check si
up{job="mon-service"} == 0. Comment on peut rendre ça moins bruyant mais sans louper un truc vraiment down longtemps ?