Moje ime je Anton Baderin. Radim u Centru za visoke tehnologije i bavim se sistemskom administracijom. Prije mjesec dana završila je naša korporativna konferencija na kojoj smo svoje stečeno iskustvo podijelili s IT zajednicom našeg grada. Govorio sam o nadzoru web aplikacija. Materijal je bio namijenjen nižoj ili srednjoj razini, koji ovaj proces nisu gradili od nule.
Temelj svakog nadzornog sustava je rješavanje poslovnih problema. Monitoring radi monitoringa nikoga ne zanima. Što posao želi? Tako da sve radi brzo i bez grešaka. Poduzeća žele biti proaktivna, kako bismo sami prepoznali probleme u servisu i riješili ih što je brže moguće. To su, zapravo, problemi koje sam cijelu prošlu godinu rješavao na projektu za jednog našeg kupca.
oko
Projekt je jedan od najvećih programa vjernosti u zemlji. Trgovačkim lancima pomažemo povećati učestalost prodaje kroz razne marketinške alate poput bonus kartica. Ukupno, projekt uključuje 14 aplikacija koje rade na deset poslužitelja.
Tijekom procesa intervjua, opetovano sam primijetio da administratori ne pristupaju uvijek ispravno praćenju web aplikacija: mnogi se i dalje usredotočuju na metriku operativnog sustava i povremeno prate usluge.
U mom slučaju, sustav praćenja korisnika prethodno se temeljio na Icingi. Ni na koji način nije riješio gore navedene probleme. Često nas je klijent sam obavijestio o problemima, a češće jednostavno nismo imali dovoljno podataka da dođemo do dna razloga.
Osim toga, postojalo je jasno razumijevanje besmisla njegovog daljnjeg razvoja. Mislim da će me razumjeti oni koji poznaju Icingu. Stoga smo odlučili potpuno redizajnirati sustav nadzora web aplikacija za projekt.
Prometej
Odabrali smo Prometheus na temelju tri glavna pokazatelja:
- Ogroman broj dostupnih metrika. Kod nas ih je 60 tisuća. Naravno, vrijedi napomenuti da mi ne koristimo veliku većinu njih (vjerojatno oko 95%). S druge strane, svi su relativno jeftini. Za nas je to druga krajnost u odnosu na prethodno korištenu Icingu. U njemu je dodavanje metrika bila posebna muka: postojeće su bile skupe (samo pogledajte izvorni kod bilo kojeg dodatka). Svaki dodatak bio je skripta u Bashu ili Pythonu, čije je pokretanje skupo u smislu utrošenih resursa.
- Ovaj sustav troši relativno malu količinu resursa. 600 MB RAM-a, 15% jedne jezgre i nekoliko desetaka 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 jako gladni energije. Ne mislim da je to problem u suvremenoj stvarnosti.
- Pruža mogućnost migracije na Kubernetes. S obzirom na planove kupca, izbor je očit.
LOS
Ranije nismo prikupljali niti obrađivali zapisnike. Nedostaci su svima jasni. Odabrali smo ELK jer smo već imali iskustva s ovim sustavom. Tamo pohranjujemo samo zapisnike aplikacija. Glavni kriterij odabira bili su pretraživanje cijelog teksta i njegova brzina.
Slickhouse
U početku je izbor pao na InfluxDB. Shvatili smo potrebu prikupljanja Nginx zapisa, statistike iz pg_stat_statements i pohranjivanja povijesnih podataka Prometheusa. Influx nam se nije svidio jer je povremeno počeo trošiti veliku količinu memorije i rušio se. Osim toga, želio sam grupirati upite prema remote_addr, ali grupiranje u ovom DBMS-u je samo prema oznakama. Oznake su skupe (memorija), njihov broj je uvjetno ograničen.
Ponovno smo krenuli u potragu. Potrebna je bila analitička baza podataka s minimalnim utroškom resursa, po mogućnosti s kompresijom podataka na disku.
Clickhouse ispunjava sve te kriterije i nikada nismo požalili što smo odabrali. U njega ne upisujemo neke izvanredne količine podataka (broj umetanja je samo oko pet tisuća u minuti).
NewRelic
NewRelic je kroz povijest bio s nama jer je to bio izbor kupaca. Koristimo ga kao APM.
Zabbix
Zabbix koristimo isključivo za praćenje crne kutije raznih API-ja.
Definiranje pristupa praćenju
Željeli smo dekomponirati zadatak i time sistematizirati pristup praćenju.
Da bih to učinio, podijelio sam naš sustav na sljedeće razine:
- hardver i VMS;
- operacijski sustav;
- usluge sustava, softverski skup;
- primjena;
- poslovna logika.
Zašto je ovaj pristup prikladan:
- znamo tko je odgovoran za rad svake razine i na temelju toga možemo slati upozorenja;
- strukturu možemo koristiti kada potiskujemo upozorenja - bilo bi čudno slati upozorenje o nedostupnosti baze podataka kada je virtualni stroj kao cjelina nedostupan.
Budući da je naš zadatak identificirati kršenja u radu sustava, moramo na svakoj razini istaknuti određeni skup metrika na koje vrijedi obratiti pozornost prilikom pisanja pravila upozoravanja. Zatim prođimo kroz razine "VMS", "Operacijski sustav" i "Usluge sustava, softverski skup".
Virtualni strojevi
Hosting nam dodjeljuje procesor, disk, memoriju i mrežu. I s prva dva smo imali problema. Dakle, metrika:
CPU stolen time - kada kupite virtualni stroj na Amazonu (t2.micro, na primjer), trebali biste shvatiti da vam nije dodijeljena cijela jezgra procesora, već samo kvota njegovog vremena. A kad ga iscrpiš, oduzet će ti se i procesor.
Ova metrika vam omogućuje praćenje takvih trenutaka i donošenje odluka. Na primjer, je li potrebno uzeti deblju tarifu ili distribuirati obradu pozadinskih zadataka i API zahtjeva na različite poslužitelje?
IOPS + CPU iowait time - iz nekog razloga mnogi hostingi u oblaku griješe ne pružajući dovoljno IOPS-a. Štoviše, raspored s niskim IOPS-om im nije argument. Stoga vrijedi prikupiti CPU iowait. S ovim parom grafikona - s niskim IOPS-om i velikim I/O čekanjem - već možete razgovarati s hostingom i riješiti problem.
Operativni sustav
Mjerni podaci operativnog sustava:
- količina raspoložive memorije u %;
- aktivnost korištenja swapa: vmstat swapin, swapout;
- broj dostupnih inodea i slobodnog prostora na datotečnom sustavu u %
- prosječno opterećenje;
- broj veza u tw stanju;
- conntrack punina stola;
- Kvaliteta mreže može se pratiti pomoću uslužnog programa ss, paketa iproute2 - uzmite indikator RTT veza iz njegovog izlaza i grupirajte ga prema odredišnom portu.
Također na razini operacijskog sustava imamo takav entitet kao što su procesi. Važno je u sustavu identificirati skup procesa koji igraju važnu ulogu u njegovom radu. Ako, na primjer, imate nekoliko pgpoola, tada trebate prikupiti informacije za svaki od njih.
Skup metrika je sljedeći:
- procesori;
- memorija je prvenstveno rezidentna;
- IO - po mogućnosti u IOPS;
- FileFd - otvori i ograniči;
- značajni kvarovi stranica - na ovaj način možete razumjeti koji se proces mijenja.
Cijeli nadzor implementiramo u Dockeru i koristimo Advisor za prikupljanje metričkih podataka. Na ostalim strojevima koristimo procesni izvoznik.
Sistemske usluge, softverski skup
Svaka aplikacija ima svoje specifičnosti, te je teško izdvojiti određeni skup metrika.
Univerzalni skup je:
- stopa zahtjeva;
- broj grešaka;
- latencija;
- zasićenje.
Naši najupečatljiviji primjeri praćenja na ovoj razini su Nginx i PostgreSQL.
Najopterećeniji servis u našem sustavu je baza podataka. U prošlosti smo često imali problema s otkrivanjem što baza podataka radi.
Vidjeli smo veliko opterećenje na diskovima, ali spori dnevnici zapravo nisu ništa pokazali. Riješili smo ovaj problem pomoću pg_stat_statements, prikaza koji prikuplja statistiku upita.
To je sve što administrator 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. Ne čudi da ih malo tko raščlanjuje ili spominje na popisu must-have stvari. Standardni format nije jako informativan i treba ga proširiti.
Osobno sam dodao request_time, upstream_response_time, body_bytes_sent, request_length, request_id. Iscrtavamo vrijeme odgovora i broj grešaka:
Gradimo grafikone vremena odgovora i broja grešaka. Zapamtiti? Jesam li govorio o poslovnim ciljevima? Brzo i bez grešaka? Već smo pokrili ova pitanja s dva grafikona. A pomoću njih već možete nazvati dežurne administratore.
Ali ostaje još jedan problem - osigurati brzo uklanjanje uzroka incidenta.
Rješavanje incidenata
Cijeli proces od identificiranja do rješavanja problema može se podijeliti u nekoliko koraka:
- identificiranje problema;
- obavijest dežurnom administratoru;
- odgovor na incident;
- otklanjanje uzroka.
Važno je da to moramo učiniti što je brže moguće. I ako u fazama utvrđivanja problema i slanja obavijesti ne možemo dobiti puno vremena - dvije minute će u svakom slučaju biti potrošene na njih, onda su sljedeće jednostavno neobrano polje za poboljšanja.
Zamislimo samo da je dežurnom zazvonio telefon. Što će učiniti? Potražite odgovore na pitanja – što je puklo, gdje je puklo, kako reagirati? Evo kako odgovaramo na ova pitanja:
Jednostavno uključimo sve ove informacije u tekst obavijesti i dajemo poveznicu na wiki stranicu 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 metričkih podataka. Jedini izvor bilo kakvih informacija s ovih razina su zapisi.
Nekoliko bodova.
Prvo napišite strukturirane dnevnike. Nema potrebe za uključivanjem konteksta u tekst poruke. Zbog toga ih je teško grupirati i analizirati. Logstashu treba dosta vremena da sve to normalizira.
Drugo, ispravno koristite razine ozbiljnosti. Svaki jezik ima svoj standard. Osobno razlikujem četiri razine:
- nema greške;
- greška na strani klijenta;
- greška je na našoj strani, ne gubimo novac, ne snosimo rizike;
- Greška je na našoj strani, gubimo novac.
Da rezimiram. Morate pokušati izgraditi nadzor temeljen na poslovnoj logici. Pokušajte nadzirati samu aplikaciju i raditi s metrikama kao što su broj prodaja, broj registracija novih korisnika, broj trenutno aktivnih korisnika i tako dalje.
Ako je cijeli vaš posao jedan gumb u pregledniku, morate pratiti klika li i radi li ispravno. Sve ostalo nije bitno.
Ako to nemate, možete pokušati to nadoknaditi u zapisima aplikacija, zapisima Nginxa i tako dalje, kao što smo mi učinili. Trebali biste biti što bliže aplikaciji.
Mjerila operativnog sustava su naravno važna, ali posao ne zanimaju, nismo plaćeni za njih.
Izvor: www.habr.com