10 commentaires
les recording rules c'est la vie. si tu calcules un truc complexe ou qui demande du cpu, tu le pré-agrèges dans une recording rule. ça allège les query alertes et ça peut lisser des petits pics. par exemple un sum_over_time ou avg_over_time sur 1m ou 5m.
étiquette tes alertes avec des niveaux de sévérité. severity: critical, severity: warning, severity: info. et tu routes les critiques vers pagerduty, les warnings vers slack et les infos vers un dashboard. ça filtre le bruit et les gens savent quoi regarder.
quand tu fais du rate() sur des compteurs, assure-toi d'utiliser des intervalles suffisamment longs pour lisser les pics. rate(http_requests_total[5m]) est souvent mieux que [1m]. et les métriques de type histogram pour bien comprendre la distribution des latences.
ok merci pour les tips ! les recording rules j'y avais pas pensé pour le lissage et le for clause je vais revoir tous mes alertes critiques avec ça. et le SLO based alerting c'est clairement la direction à prendre. good job la commu !
Laisser une réponse
Vous devez être connecté pour poster un message !
putain mais ras le bol des alertes prometheus qui sonnent pour rien ! on a une tonne d'alertes "service down" ou "high latency" qui sont des faux positifs parce que la métrique a fait un petit pic une seconde. ca rend les ops fous et on finit par ignorer. comment vous faites pour tuner vos alerts sans rater les vrais trucs ?