Koja metrika upozorava na kvar
Internet banka je pala u podne, drugi put za nedelju dana. Na analizi dežurni otvara grafikone: tri sata pre havarije opterećenje procesora baze podataka već je rastom puzalo. Grafikoni su postojali, alarma nije bilo. Poznato?
Monitoring prikuplja stotine metrika, ali niko ne zna koja od njih zaista upozorava na kvar, a koja samo pravi šum. Nije potreban još jedan dashboard, već odgovor iz vaše sopstvene istorije: koja metrika i koliko sati pre kvara počinje da se ponaša neobično.
Zadatak metoda
Uporediti dnevnik incidenata sa metrikama monitoringa za isti period i odgovoriti na tri pitanja:
- Koja metrika se menja pre kvarova? Procesor, memorija, saobraćaj, disk - ili čvor uopšte prestaje da šalje podatke.
- Koliko pre kvara? 15 minuta, nekoliko sati ili dan.
- Da li je to upozorenje ili poklapanje? Koliko često se isto dešava u uobičajene dane kada kvara nema.
Šta poslati: dnevnik incidenata i izvoz metrika (Zabbix, Grafana, Prometheus) za isti period - od 14 dana i od 8 kvarova. Oba fajla jednim slanjem.
Kako se računa
- 1. Dva fajla na istoj vremenskoj osi
Sistem spaja vreme prijava i metrika, uzima u obzir vremensku zonu i pronalazi čvor monitoringa po imenu objekta u prijavi.
- 2. „Uobičajeno“ za svaki sat
Procesor u 10 ujutru ima jednu normu, u 3 noću drugu. Sistem pamti uobičajeni nivo svake metrike za svaki sat u danu, radne dane i vikende posebno. Noćna rezervna kopija ne računa se kao čudnovatost.
- 3. Prozori pre kvara
Gledamo šta je bilo 15 minuta - 1 sat, 1-6 sati i 6-24 sata pre prijave: da li je metrika bila primetno viša ili niža od uobičajene.
- 4. Poređenje sa običnim danima
Isti sati u druge dane kada kvara nije bilo. Ako je u običan dan procesor tako visok u 1 slučaju od 100, a pre kvarova u polovini slučajeva, to nije poklapanje.
- 5. Zaštita od slučajnih nalaza
Metrika ima stotine i neka će „pogoditi“ kvarove prosto slučajno. Sistem pravi korekciju za broj metrika i zahteva da se poklapanja dešavaju u različite dane.
Važno: metrika koja raste pre kvara još nije njegov uzrok. Izveštaj navodi moguće uzroke i koji podaci bi ih razlikovali.
Šta metod vidi u stvarnim podacima i od čega je zaštićen
- Alarm je sam otvorio prijavuMonitoring je video „procesor iznad 90%“ i minut kasnije napravio prijavu. To je isti događaj, a ne upozorenje: sistem ne gleda bliže od 15 minuta pre prijave, a prijave oblika „High CPU on db-01“ prepoznaje kao eho alarma.
- Prijava je otvorena kasnije nego što je kvar počeoServis je pao u 12:00, prijava je otvorena u 12:40 - i metrika je „rasla 40 minuta pre kvara“. Porast manje od sat vremena pre prijave izveštaj naziva „rani znak ili početak kvara“, a ne predznak.
- Čvor je zaćutao u trenutku kvaraTo je znak samog kvara. Izveštaj će reći „čvor je zaćutao u trenutku kvara u 12 slučajeva od 15“, ali to neće nazvati upozorenjem.
- Metrika raste posle kvaraPosle restarta servis raščišćava red i opterećenje se drži par sati. Ako se sledeći kvar desio u te sate, takav porast se ne računa kao predznak.
- Dan masovne havarijeJedan loš dan sa dvadeset prijava ne stvara nalaz: poklapanja su potrebna u različite dane.
- Satni podaci za godinuZabbix čuva minutnu istoriju mesec dana, dalje - proseke po satu. Na satnim podacima prednost manja od sat vremena nije vidljiva, i izveštaj to kaže.
- Malo podatakaManje od 14 dana zajedničkog perioda ili manje od 8 kvarova - metod ne donosi zaključke i piše zašto.
Pouzdanost provere: metod je proveren na veštačkim mesecima i godinama monitoringa - 12 servera po tri metrike, dnevni ritam opterećenja, noćne kopije, šum. Pravi predznak 3-6 sati unapred pronađen je u 40 meseci od 40, pri samo 8 kvarova - u 35 od 40. U običnim mesecima lažnih nalaza nije bilo nijednom, pri 105 metrika - u 2 meseca od 40.
Šta raditi sa pronađenom metrikom
| Scenario | Mogući uzroci | Kako proveriti | Šta raditi |
|---|---|---|---|
| Metrika raste satima pre kvara (procesor baze 3-5 sati unapred) | Resurs se iscrpljuje pod opterećenjem; težak zadatak po rasporedu; rast broja zahteva | Otvoriti grafikon metrike za dan pre poslednja tri kvara i raspored zadataka za te sate | Upozorenje dežurnom na ovom nivou; razraditi zadatak ili opterećenje u okviru Problem tiketa |
| Metrika pada pre kvara (slobodna memorija 2-6 sati unapred) | Curenje memorije, zakucan proces, ponestalo prostora | Kako se metrika menja između restarta servisa | Privremeno - planirani restart pre opasnog nivoa; u suštini - ispraviti curenje |
| Porast manji od sat vremena unapred | Najverovatnije je to već početak kvara koji nije odmah primećen | Da li u prijavi postoji vreme početka ili otkrivanja kvara | Početi beležiti vreme otkrivanja; postaviti alarm na ovu metriku, da se saznaje pre korisnika |
| Metrika zajedničkog resursa pre kvarova različitih sistema (kanal jezgra mreže) | Sistemi zavise od jednog čvora | Šema zavisnosti: preko čega ovi sistemi rade | Monitoring i rezerva zajedničkog čvora umesto popravke svakog sistema |
| Eho alarma (prijavu je otvorio monitoring po istoj ovoj metrici) | Prag je već podešen | - | Ako alarm reaguje prekasno - sniziti prag ili dodati trajanje |
Primer. Baza podataka internet banke
Polazni podaci: banka, 12 servera internet banke, po tri metrike po serveru (procesor, slobodna memorija, dolazni saobraćaj) za mesec sa korakom od 5 minuta i dnevnik incidenata - oko 130 kvarova u istom mesecu.
Situacija: server baze podataka pada otprilike jednom u dan i po. Svaki put prijava „Servis nedostupan“, inženjeri restartuju servis i sve radi do sledećeg puta.
Šta je pokazao izveštaj:
- Procesor servera baze podataka bio je iznad uobičajenog za taj sat otprilike 4.5 sata pre kvara - u 11 slučajeva od 22. U iste sate drugih dana - u manje od 1% slučajeva.
- Ostalih 35 metrika ponašalo se pre kvarova kao uobičajeno.
U čemu je korist takvog rezultata:
- Upozorenje unapred. Dežurni dobija signal nekoliko sati pre verovatnog kvara, a ne poziv od klijenata.
- Gde tražiti uzrok. Ne „sve redom“, već šta opterećuje bazu u te sate: izveštaj po rasporedu, teški upiti, rast broja korisnika.
- Argument za odluku. „Pre polovine kvarova procesor baze bio je iznad norme 4 sata unapred“ je razumljiv argument za optimizaciju ili snažniji server.
- Provera rezultata. Posle mesec dana ponovo izvesti podatke i videti da li je porast pre kvarova nestao.
Crvena linija - u kom udelu kvarova je procesor bio iznad uobičajenog toliko sati pre prijave; siva - isto u iste sate drugih dana. Gde se crvena linija odvoji od sive, metrika upozorava na kvar.
Kako primeniti ove podatke u radu
- DežurstvaKvar za koji se zna nekoliko sati ranije je planirani posao, a ne noćna uzbuna. Smena stiže da prebaci opterećenje ili restartuje servis u mirnom trenutku.
- Monitoring bez šumaPostaje vidljivo koje metrike zaista upozoravaju, a koje samo bude dežurnog. Alarme na prve vredi pojačati, na druge - oslabiti.
- Budžet i SLAArgument „pre polovine kvarova baza se opirala o procesor“ razumljiv je rukovodstvu bez tehničkih detalja. Unapred najavljen kvar može se sprečiti, a to znači da manje zastoja ide u račun dostupnosti obećane klijentima.