Moje ime je Anton Baderin. Radim u Centru visoke tehnologije i bavim se sistemskom administracijom. Prije mjesec dana završila je naša korporativna konferencija na kojoj smo stečeno iskustvo podijelili sa IT zajednicom našeg grada. Govorio sam o nadgledanju web aplikacija. Materijal je bio namijenjen nižim ili srednjim nivoima, koji ovaj proces nisu gradili od nule.
Kamen temeljac u osnovi svakog sistema praćenja je rješavanje poslovnih problema. Praćenje radi monitoringa nikoga ne zanima. Šta biznis želi? Tako da sve radi brzo i bez grešaka. Preduzeća žele biti proaktivna, kako bismo i sami prepoznali probleme u servisu i otklonili ih što je prije moguće. To su, zapravo, problemi koje sam cijelu prošlu godinu rješavao na projektu za jednog od naših kupaca.
O projektu
Projekat je jedan od najvećih programa lojalnosti u zemlji. Pomažemo maloprodajnim lancima da povećaju učestalost prodaje kroz različite marketinške alate kao što su bonus kartice. Ukupno, projekat uključuje 14 aplikacija koje rade na deset servera.
Tokom procesa intervjua, više puta sam primijetio da administratori ne pristupaju uvijek ispravno nadgledanju web aplikacija: mnogi se i dalje fokusiraju na metriku operativnog sistema i povremeno prate usluge.
U mom slučaju, sistem praćenja korisnika je ranije bio baziran na Icingi. Ni na koji način nije riješio gore navedene probleme. Često nas je klijent sam informisao o problemima, a najčešće jednostavno nismo imali dovoljno podataka da bismo došli do dna razloga.
Osim toga, postojalo je jasno razumijevanje uzaludnosti njegovog daljeg razvoja. Mislim da će me oni koji poznaju Icingu razumjeti. Stoga smo odlučili u potpunosti redizajnirati sistem za praćenje web aplikacija za projekat.
Prometej
Izabrali smo Prometeja na osnovu tri glavna indikatora:
- Ogroman broj dostupnih metrika. U našem slučaju ih je 60 hiljada. Naravno, vrijedi napomenuti da ih ne koristimo veliku većinu (vjerovatno oko 95%). S druge strane, svi su relativno jeftini. Za nas je ovo druga krajnost u odnosu na prethodno korištenu Icingu. U njemu je dodavanje metrike predstavljalo poseban problem: postojeći su bili skupi (samo pogledajte izvorni kod bilo kojeg dodatka). Svaki dodatak je bio skript u Bashu ili Python-u, čije je pokretanje skupo u smislu utrošenih resursa.
- Ovaj sistem troši relativno malu količinu resursa. 600 MB RAM-a, 15% jedne jezgre i nekoliko desetina IOPS-a dovoljno je za sve naše metrike. Naravno, morate pokrenuti izvoznike metrike, ali svi su oni napisani u Go-u i također nisu mnogo gladni energije. Ne mislim da je to u modernoj stvarnosti problem.
- Pruža mogućnost migracije na Kubernetes. S obzirom na planove kupca, izbor je očigledan.
ELK
Ranije nismo prikupljali niti obrađivali dnevnike. Nedostaci su svima jasni. Odabrali smo ELK jer smo već imali iskustva sa ovim sistemom. Tamo pohranjujemo samo dnevnike aplikacija. Glavni kriteriji odabira bili su pretraživanje cijelog teksta i njegova brzina.
Slickhouse
U početku je izbor pao na InfluxDB. Shvatili smo potrebu za prikupljanjem Nginx dnevnika, statistike iz pg_stat_statements i pohranjivanja historijskih podataka Prometheusa. Nije nam se dopao Influx jer je periodično počeo da troši veliku količinu memorije i rušio se. Osim toga, želio sam grupirati upite po remote_addr, ali grupisanje u ovom DBMS-u je samo po oznakama. Oznake su skupe (memorija), njihov broj je uslovno ograničen.
Ponovo smo započeli potragu. Ono što je bilo potrebno je analitička baza podataka sa minimalnom potrošnjom resursa, po mogućnosti sa kompresijom podataka na disku.
Clickhouse ispunjava sve ove kriterijume i nikada nismo požalili zbog svog izbora. U njega ne upisujemo neke vanredne količine podataka (broj umetanja je samo oko pet hiljada u minuti).
NewRelic
NewRelic je kroz istoriju bio sa nama jer je to bio izbor kupca. Koristimo ga kao APM.
Zabbix
Zabbix koristimo isključivo za praćenje crne kutije različitih API-ja.
Definiranje pristupa praćenju
Željeli smo dekomponirati zadatak i na taj način sistematizirati pristup praćenju.
Da bih to uradio, podelio sam naš sistem na sledeće nivoe:
- hardver i VMS;
- operativni sistem;
- sistemske usluge, softverski stog;
- primjena;
- poslovne logike.
Zašto je ovaj pristup pogodan:
- znamo ko je odgovoran za rad svakog nivoa i na osnovu toga možemo slati upozorenja;
- možemo koristiti strukturu kada suzbijamo upozorenja - bilo bi čudno poslati upozorenje o nedostupnosti baze podataka kada je virtuelna mašina kao celina nedostupna.
Pošto je naš zadatak da identifikujemo kršenja u radu sistema, moramo na svakom nivou istaći određeni skup metrika na koje vredi obratiti pažnju prilikom pisanja pravila upozorenja. Dalje, idemo kroz nivoe "VMS", "Operativni sistem" i "Sistemske usluge, softverski stog".
Virtuelne mašine
Hosting nam dodjeljuje procesor, disk, memoriju i mrežu. I imali smo problema sa prva dva. Dakle, metrika:
CPU ukradeno vrijeme - kada kupujete virtuelnu mašinu na Amazonu (t2.micro, na primjer), treba da shvatite da vam nije dodijeljeno cijelo procesorsko jezgro, već samo kvota njegovog vremena. A kada ga iscrpite, procesor će vam biti oduzet.
Ova metrika vam omogućava da pratite takve trenutke i donosite odluke. Na primjer, da li je potrebno uzeti veću tarifu ili distribuirati obradu pozadinskih zadataka i API zahtjeva na različite servere?
IOPS + CPU vrijeme čekanja - iz nekog razloga, mnogi hostingi u oblaku griješe jer ne pružaju dovoljno IOPS. Štaviše, raspored sa niskim IOPS-om nije argument za njih. Stoga, vrijedi prikupiti CPU iowait. Sa ovim parom grafikona - sa niskim IOPS-om i visokim I/O čekanjem - već možete razgovarati sa hostingom i riješiti problem.
operativni sistem
metrika operativnog sistema:
- količina raspoložive memorije u %;
- aktivnost swap upotrebe: vmstat swapin, swapout;
- broj dostupnih inoda i slobodnog prostora na sistemu datoteka u %
- prosječno opterećenje;
- broj priključaka u tw stanju;
- popunjenost stola conntrack;
- Kvalitet mreže se može pratiti pomoću ss uslužnog programa, iproute2 paketa - dobiti indikator RTT konekcija iz njegovog izlaza i grupirati ga prema odredišnom portu.
Takođe na nivou operativnog sistema imamo takav entitet kao procesi. Važno je identifikovati u sistemu skup procesa koji igraju važnu ulogu u njegovom radu. Ako, na primjer, imate nekoliko pgpoolova, tada morate prikupiti informacije za svaki od njih.
Skup metrika je sljedeći:
- CPU;
- memorija je prvenstveno rezidentna;
- IO - poželjno u IOPS;
- FileFd - otvaranje i ograničenje;
- značajne greške stranica - na ovaj način možete razumjeti koji proces se zamjenjuje.
Mi implementiramo sav nadzor u Docker-u, a koristimo Advisor za prikupljanje metričkih podataka. Na ostalim mašinama koristimo proces-izvoznik.
Sistemske usluge, softverski stog
Svaka aplikacija ima svoje specifičnosti i teško je izdvojiti određeni skup metrika.
Univerzalni set je:
- stopa zahtjeva;
- broj grešaka;
- latencija;
- zasićenje.
Naši najupečatljiviji primjeri praćenja na ovom nivou su Nginx i PostgreSQL.
Najopterećenija usluga u našem sistemu je baza podataka. U prošlosti smo često imali problema da shvatimo šta baza podataka radi.
Vidjeli smo veliko opterećenje na diskovima, ali spori zapisi nisu baš ništa pokazali. Ovaj problem smo riješili pomoću pg_stat_statements, pogleda koji prikuplja statistiku upita.
To je sve što administratoru treba.
Gradimo grafikone aktivnosti zahtjeva za čitanje i pisanje:
Sve je jednostavno i jasno, svaki zahtjev ima svoju boju.
Jednako upečatljiv primjer su Nginx zapisi. Nije iznenađujuće da ih malo ljudi analizira ili spominje na listi must-have. Standardni format nije previše informativan i treba ga proširiti.
Lično sam dodao request_time, upstream_response_time, body_bytes_sent, request_length, request_id. Ucrtavamo vrijeme odgovora i broj grešaka:
Pravimo grafikone vremena odgovora i broja grešaka. Sećaš se? Jesam li govorio o poslovnim ciljevima? Da brzo i bez grešaka? Ova pitanja smo već pokrili sa dva grafikona. A preko njih već možete pozvati dežurne administratore.
Ali ostaje još jedan problem - osigurati brzo otklanjanje uzroka incidenta.
Rješavanje incidenata
Cijeli proces od identifikacije do rješavanja problema može se podijeliti u nekoliko koraka:
- identifikovanje problema;
- obavještenje dežurnom administratoru;
- odgovor na incident;
- otklanjanje uzroka.
Važno je da to uradimo što je pre moguće. A ako u fazama identifikacije problema i slanja obavještenja ne možemo dobiti puno vremena - na njih će u svakom slučaju biti utrošeno dvije minute, onda su naredni jednostavno neoran teren za poboljšanja.
Zamislimo samo da je dežurnom zazvonio telefon. Šta će on uraditi? Potražite odgovore na pitanja – šta se pokvarilo, gde se pokvarilo, kako reagovati? Evo kako odgovaramo na ova pitanja:
Jednostavno uključujemo sve ove informacije u tekst obavještenja i pružamo vezu do wiki stranice koja opisuje kako odgovoriti na ovaj problem, kako ga riješiti i eskalirati.
Još uvijek nisam rekao ništa o sloju aplikacije i poslovnoj logici. Nažalost, naše aplikacije još ne implementiraju prikupljanje metrika. Jedini izvor bilo kakvih informacija sa ovih nivoa su dnevnici.
Par poena.
Prvo, napišite strukturirane dnevnike. Nema potrebe za uključivanjem konteksta u tekst poruke. Zbog toga ih je teško grupirati i analizirati. Logstash-u je potrebno dosta vremena da sve ovo normalizuje.
Drugo, pravilno koristite nivoe ozbiljnosti. Svaki jezik ima svoj standard. Lično razlikujem četiri nivoa:
- nema greške;
- greška na strani klijenta;
- greška je na našoj strani, mi ne gubimo novac, ne snosimo rizike;
- Greška je na našoj strani, gubimo novac.
Dozvolite mi da sumiram. Morate pokušati izgraditi praćenje zasnovano na poslovnoj logici. Pokušajte pratiti samu aplikaciju i raditi s takvim metrikama kao što su broj prodaja, broj registracija novih korisnika, broj trenutno aktivnih korisnika i tako dalje.
Ako je cijelo vaše poslovanje jedno dugme u pretraživaču, morate pratiti da li klikne i radi li ispravno. Sve ostalo nije bitno.
Ako nemate ovo, možete ga pokušati sustići u zapisnicima aplikacija, Nginx zapisnicima i tako dalje, kao što smo mi to učinili. Trebali biste biti što bliže aplikaciji.
metrika operativnog sistema je naravno bitna, ali posao za njih ne zanima, mi za njih nismo plaćeni.
izvor: www.habr.com