Error budget VictoriaMetrics-ში: recording rules, burn-rate ალერტები და ერთი პატიოსანი პანელი

Gambchamp-ში ერთი პროდუქტის პლატფორმის პირველი დონის სერვისებისთვის error budget გვჭირდებოდა — რაღაც, რაც ერთი შეხედვით ჩანს და რაზეც ალერტის დაყენება შეიძლება. შემოგვთავაზეს ჩატში slash-ბრძანება, რომელიც ბიუჯეტს დაბეჭდავდა. ჩვენ Grafana-ს პანელი ავირჩიეთ — მონაცემები უკვე VictoriaMetrics-ში იყო, ახალი ბოტი კი ახალ სერვისს, ახალ ტოკენს და კიდევ ერთ რამეს ნიშნავს, რომელიც ცოცხალი უნდა შეინახო.

SLI და მიზნები

SLI ყველაზე მარტივი და პატიოსანი ავიღეთ: 5xx-ის გარეშე პასუხების წილი. თითოეულ სერვისს თავისი მიზანი აქვს, ჩაწერილი მანამდე, სანამ ერთი წესიც გაჩნდებოდა. წესები ამ პლატფორმისთვის ცალკე ჯგუფში მოვათავსეთ, ამიტომ ალერტების საერთო წესები ხელუხლებელი დარჩა.

სამი recording rule

• slo:target_error:ratio{app,cluster} — შეცდომების დასაშვები წილი (1 − SLO) სერვისის მიხედვით, აწყობილი label_replace(vector(x), ...)-ით, გაერთიანებული or-ით;
• slo:errors:ratio_rate30d — შეცდომების რეალური წილი 30 დღეში, ჩაწერილი როგორც ... or 0 * total, რომ შეცდომების გარეშე სერვისმა 0 აჩვენოს და არა ცარიელი სერია;
• slo:error_budget:remaining_ratio30d = 1 - ratio30d / target — 1 სრულ ბიუჯეტს ნიშნავს, 0 — დახარჯულს, ნულზე ნაკლები — გადახარჯვას.

რადგან მიზანს იგივე {app, cluster} ლეიბლები აქვს, რაც შეცდომების სერიას, ყოველი შედარება სუფთა join-ია ერთი ერთზე.

Burn-rate ალერტები

Multi-window, multi-burn-rate, კლასიკური სქემა SRE workbook-იდან:

• სწრაფი: 14.4× წვა 5 წუთსა და 1 საათში, critical, for: 2m;
• ნელი: 6× წვა 30 წუთსა და 6 საათში, warning, for: 15m.

მათ გვერდით — მარტივი RED-წესები სიმპტომებზე: p99 ლატენტობა წამზე მეტი, მაგრამ მხოლოდ ტრაფიკის ზღვრით (უმოქმედო სერვისის ერთი ნელი მოთხოვნა ინციდენტი არ არის), „ტრაფიკი არ არის“ ნულოვანი დონის სერვისებისთვის და „მეტრიკა გაქრა“.

პანელი

ერთი რიგი: stat თითოეული სერვისისთვის პლუს ტრენდი, ზღვრები — წითელი 0-ზე ქვემოთ, ნარინჯისფერი 0.2-ზე ქვემოთ, მწვანე ზემოთ. რიგი code-first დაშბორდების გენერატორში წავიდა და არა Grafana-ს UI-ში — UI-ში ცვლილებები შემდეგი დეპლოისას გადაიწერება.

ბიუჯეტი −26 % და ყველაფერი რიგზეა

გაშვებისთანავე ერთმა გადახდის სერვისმა −26 % ბიუჯეტი აჩვენა. შემაშფოთებლად გამოიყურებოდა. ეს ყველაფერი გაშვების დღის ერთმა ნახტომმა მისცა: დეპოზიტის დაახლოებით 2 100 შეცდომა 9,5 საათში, რამდენიმე კვირით ადრე. 30-დღიანი ფანჯარა უბრალოდ მას მოიცავდა. ბიუჯეტი თავისით გამოსწორდებოდა, როგორც კი ის დღე ფანჯრიდან გავიდოდა. Burn-rate ალერტები, რომლებიც მოკლე ფანჯრებს უყურებენ, მთელი ამ დროის განმავლობაში დუმდნენ — და ეს სწორია.

წვრილმანები, რომელთა ცოდნაც სასარგებლოა

• Recording rule, რომელიც სხვა recording rule-ებზეა აგებული, რამდენიმე გამოთვლის ციკლით გვიან ჩნდება: შემავალი სერიები ჯერ უნდა ჩაიწეროს და მოთხოვნისთვის ხელმისაწვდომი გახდეს. ეს ბაგი არ არის.
• vmalert-ს -remoteWrite.url სჭირდება, თორემ recording rule-ების შედეგები არსად მიდის.
• დაშბორდი ALERTS სერიას TSDB-დან კითხულობს და არა რომელიმე Alertmanager-იდან, ამიტომ შეტყობინების არხების შემდგომმა გაყოფამ მასზე გავლენა არ მოახდინა.

დასკვნები

• დაიწყეთ უკვე არსებული მეტრიკებით; SLO ახალ სერვისს არ საჭიროებს.
• გააკეთეთ ისე, რომ „შეცდომები არ არის“ შემთხვევამ 0 დააბრუნოს და არა ცარიელი სერია, თორემ ჯაჭვში ქვემოთ ყველა წესი ჩუმად იშლება.
• Burn rate — პეიჯინგისთვის, 30-დღიანი ბიუჯეტი — დაგეგმვისთვის. ისინი სხვადასხვა კითხვას პასუხობენ.
• გაშვებისთანავე 30-დღიანი ფანჯარა გაშვების პერიოდის შეცდომებით არის დამახინჯებული. იცოდეთ, როდის გავლენ ისინი ფანჯრიდან, სანამ პანიკას დაიწყებთ.