🥇Si e ndërtuam monitorimin me Prometheus, Clickhouse dhe ELK

Më quajnë Anton Baderin. Punoj në Qendrën e Teknologjive të Larta dhe merrem me administrimin e sistemeve. Një muaj më parë përfundoi konferenca jonë korporative, ku ndamë përvojën tonë me komunitetin IT të qytetit tonë. Unë ndava informacion mbi monitorimin e aplikacioneve web. Materiali ishte i destinuar për nivelin junior ose mesatar, që nuk e kishin ndërtuar këtë proces nga e para.

Guri i themelit që qëndron në çdo sistem monitorimi është zgjidhja e problemeve të biznesit. Monitorimi për monitorim nuk është i interesant për askënd. Çfarë dëshiron biznesi? Që gjithçka të funksionojë shpejt dhe pa gabime. Biznesi dëshiron proaktivitet, që ne të zbulojmë vetë problemet në funksionimin e shërbimit dhe t'i zgjidhim ato sa më shpejt. Këto, në thelb, janë problemet që unë kam zgjidhur gjatë gjithë vitit të kaluar në projektin e një prej klientëve tanë.

Për projektin

Projekti është një nga programet e besnikërisë më të mëdha në vend. Ne ndihmojmë rrjetet me pakicë të rrisin frekuencën e shitjeve përmes mjeteve të ndryshme marketingu si kartat e bonusit. Në përgjithësi, projekti përfshin 14 aplikacione që punojnë në dhjetë serverë.

Gjatë procesit të zhvillimit të intervistave kam vënë re disa herë se administratoret nuk i qasen gjithmonë siç duhet monitorimit të aplikacioneve web: ende shumë ndalohen në metrikat e sistemit operativ, duke monitoruar ndonjëherë shërbimet.

Në rastin tim, më parë sistemi i monitorimit të klientit ishte i bazuar në Icinga. Ai nuk zgjidhte asnjë nga problemet e përmendura më parë. Shpesh klienti na raportonte për problemet dhe nuk ishte e pazakontë t'ju mungonin të dhënat për të gjetur shkakun.

Për më tepër, kishte një kuptim të qartë për mosfunksionimin e zhvillimit të mëtejshëm të saj. Mendoj se ata që e njohin Icinga do të më kuptojnë. Pra, ne vendosëm ta ripërpunojmë plotësisht sistemin e monitorimit të aplikacioneve web në projekt.

Prometheus

Ne zgjodhëm Prometheus, duke u bazuar në tri tregues kryesorë:

Një numër të madh metrike të disponueshme. Në rastin tonë janë 60,000. Sigurisht, është e rëndësishme të theksohet se shumica e tyre nuk përdoren (ndoshta rreth 95%). Nga ana tjetër, të gjithë janë relativisht të lirë. Për ne, kjo është një tjetër ekstrem, krahasuar me Icinga, e cila kishte dhimbje të veçantë për shtesat e metrikeve: ato ekzistuese kushtonin shumë (mjafton të shikosh burimet e çdo plugini). Çdo plugin ishte një skript në Bash ose Python, dhe ekzekutimi i tyre nuk është i lirë në aspektin e burimeve të konsumuar.
Ky sistem konsumon një sasi relativisht të vogël burimesh. Për të gjitha metrike tona mjafton 600 MB memorie të përkohshme, 15% e një bërthame dhe disa dhjetëra IOPS. Sigurisht, na duhej të nisim eksportuesit e metrikeve, por të gjithë janë të shkruar në Go dhe gjithashtu nuk dallohen për konsum të madh. Nuk besoj se është një problem në realitetin modern.
Ofron mundësinë e kalimit në Kubernetes. Duke marrë parasysh planet e klientit - zgjedhja është e qartë.

ELK

Më parë nuk mbledhëm dhe nuk përpunonim log-e. Disavantazhet e saj janë të qarta për të gjithëve. Ne zgjodhëm ELK, pasi kemi pasur përvojë me këtë sistem. Atje ruajmë vetëm log-e të aplikacioneve. Kritere kryesore të zgjedhjes ishin kërkimi me tekst të plotë dhe shpejtësia e tij.

Clickhouse

Fillimisht zgjodhëm InfluxDB. Ne e kuptonim nevojën për mbledhjen e log-eve Nginx, statistikave nga pg_stat_statements, dhe ruajtjen e të dhënave historike të Prometheus. Influx nuk na pëlqeu, pasi herë pas here fillonte të konsumonte një sasi të madhe memorie dhe ra. Për më tepër, donim të grumbullojmë kërkesat sipas remote_addr, ndërsa grumbullimi në këtë DB është vetëm sipas etiketave. Etiketat janë të shtrenjta (memorie), numri i tyre është në njëfarë mënyre i kufizuar.

Ne filluam kërkimin nga e para. Kishim nevojë për një bazë analitike me konsum minimal burimesh, preferohet me kompresim të të dhënave në disk.

Clickhouse i përmbush të gjitha këto kritere dhe asnjëherë nuk kemi dashur të ndërronim mendje për zgjedhjen tonë. Ne nuk shkruajmë volume të jashtëzakonshme të të dhënave në të (sasia e inserteve është rreth pesë mijë në minutë).

NewRelic

NewRelic historikisht ka qenë me ne, pasi ishte zgjedhja e klientit. Çmimi i saj përdoret si APM.

Zabbix

Ne përdorim Zabbix vetëm për monitorimin Black Box të API-ve të ndryshme.

Përcaktimi i qasjes ndaj monitorimit

Ne donim të dekompozonim detyrën dhe në këtë mënyrë të sistematizojmë qasjen ndaj monitorimit.

Për këtë ndava sistemin tonë në nivele të mëposhtme:

„hardueri“ dhe VMS;
sistemi operativ;
shërbimet sistemike, stoku i softuerit;
aplikacioni;
logjika e biznesit.

Çfarë është e lehtë me këtë qasje:

ne e dimë se kush është përgjegjës për funksionimin e çdo niveli dhe, duke u bazuar në këtë, mund të dërgojmë alerte;
mund të përdorim strukturën në procesin e zbutjes së alerteve - do të ishte e çuditshme të dërgosh një alerte për papashtyrshmërinë e bazës së të dhënave, kur në tërësi makineria virtuale është e papashtyrshme.

Duke që detyra jonë është të identifikojmë shkeljet në funksionimin e sistemit, ne duhet të përzgjidhim një grup metrikash në çdo nivel që duhet të vëmë re kur shkruajmë rregullat e alarmeve. Më pas do të kalojmë në nivelet "VMS", "Sistemi operativ" dhe "Shërbimet sistemore, stek i softuerit".

Makinat virtuale

Hostim na siguron procesorin, disqin, memories dhe rrjetin. Dhe me dy të parat kishim probleme. Pra, metrikat:

Koha e vjedhjes së CPU - kur blini një virtual server në Amazon (për shembuj, t2.micro), duhen kuptuar se ju jepet jo një bërthamë e plotë procesori, por vetëm një kuotë e kohës së tij. Dhe kur ta konsumoni, CPU do të fillojë t'ju marrë atë.

Kjo metrikë lejon ndjekjen e këtyre momentëve dhe marrjen e vendimeve. Për shembull, a duhet të marrim një plan më të fuqishëm ose të ndajmë përpunimin e detyrave në sfond dhe kërkesave të API në të ndryshme. server.

IOPS + Koha e pritjes së CPU - për ndonjë arsye shumë ofrues të pritjes në re gabojnë duke mos ofruar mjaft IOPS. Për më tepër, grafiku me IOPS të ulëta për ta nuk është argument. Prandaj, është e rëndësishme të mbledhim edhe CPU iowait. Me këtë çift grafikësh - me IOPS të ulëta dhe pritje të lartë I/O - tashmë mund të flasim me ofruesin e pritjes dhe të zgjidhim problemin.

Sistemi operativ

Metrikat e sistemit operativ:

numri i memories së disponueshme në %;
aktiviteti i përdorimit të swap: vmstat swapin, swapout;
numri i inode-ve të disponueshme dhe hapësira e lirë në sistemin e skedarëve në %
ngarkesa mesatare;
numri i lidhjeve në gjendjen tw;
mbushja e tabelës conntrack;
cilësia e funksionimit të rrjetit mund të monitorohet përmes utilitarit ss, paketës iproute2 - duke marrë nga daljet e saj treguesin e RTT të lidhjeve dhe duke i grupuar sipas dest-portit.

Po ashtu në nivelin e sistemit operativ kemi një entitet të tillë si proceset. Është e rëndësishme të përzgjedhim në sistem një grup procesesh që luajnë rol të rëndësishëm në funksionimin e tij. Nëse, për shembull, keni disa pgpool, atëherë është e nevojshme të mbledhim informacion për secilin prej tyre.

Grupi i metrikave është si në vijim:

CPU;
memoria - në radhë të parë, ajo rezidenciale;
IO - idealisht në IOPS;
FileFd - të hapura dhe limit;
dështimet e rëndësishme të faqeve - kështu do të jeni në gjendje të kuptoni se cili proces është duke kaluar në swap.

E gjithë monitorimi ynë është e shpërndarë në Docker, për mbledhjen e të dhënave të metrikave përdorim Cadvisor. Në makinat e tjera përdorim process-exporter.

Shërbimet sistemore, stek i softuerit

Çdo aplikacion ka specifikën e tij, dhe është e vështirë të përzgjedhësh një grup metrikash.

Grupi universal përbëhet nga:

raporti i kërkesave;
numri i gabimeve;
latenca;
saturimi.

Shembujt më të shquar të monitorimit të këtij niveli janë Nginx dhe PostgreSQL.

Shërbimi më i ngarkuar në sistemin tonë është database. Më parë kishim shpesh probleme me të kuptuarit se çfarë po bënte baza e të dhënave.

Kemi parë ngarkesë të lartë në disqe, por logët e ngadalta nuk tregonin asgjë të vlefshme. Këtë problem e zgjidhëm me ndihmën e pg_stat_statements, një pamje në të cilën grumbullohet statistika mbi kërkesat.

Këto janë të gjitha që i nevojiten administratorit.

Ndërtojmë grafika të aktivitetit të kërkesave për lexim dhe shkrim:

E gjitha është e thjeshtë dhe e qartë, çdo kërkesë - me ngjyrën e saj.

Një shembull jo më pak i shquar janë logët e Nginx. Nuk është çudi që pak njerëz i analizojnë ato ose i përmendin në listën e obligimeve. Formati standard nuk është shumë informativ dhe duhet të zgjerrohet.

Personalizova request_time, upstream_response_time, body_bytes_sent, request_length, request_id. Ndërtojmë grafika të kohës së përgjigjes dhe numrit të gabimeve:

Ndërtojmë grafika të kohës së përgjigjes dhe numrit të gabimeve. E mbani mend? Flisja për detyrat e biznesit? Për t'u bërë shpejt dhe pa gabime? Ne tashmë kemi bërë të qarta këto çështje me dy grafikë. Dhe sipas tyre, tashmë mund të telefonojmë administratorët e turnit.

Por mbeti një problem tjetër - të sigurojmë zgjidhjen e shpejtë të shkaqeve të incidentit.

Zgjidhja e incidenteve

I gjithë procesi nga identifikimi deri te zgjidhja e problemit mund të ndahen në disa hapa:

identifikimi i problemewa;
njoftimi i administratorit të turnit;
reaksioni ndaj incidentit;
zhbllokimi i shkaqeve.

Është e rëndësishme që të bëjmë këtë sa më shpejt. Dhe nëse në fazat e identifikimit të problemit dhe dërgimit të njoftimit nuk mund të kursejmë shumë kohë - dy minuta i duhen patjetër, atëherë fazat pasuese janë një fushë e papunuar për përmirësime.

Le të imagjinojmë se telefoni i administratorit të turnit ka rënë. Çfarë do të bëjë ai? Do të kërkojë përgjigje për pyetjet - çfarë është prishur, ku është prishur, si të reagojë? Këtu është si i përgjigjemi këtyre pyetjeve:

Thjesht përfshijmë të gjithë këtë informacion në tekstin e njoftimit, i japim një lidhje në faqen e wiki-së që përshkruan si të reagojmë ndaj këtij problemi, si ta zgjidhim dhe si ta eskalojmë.

Unë ende nuk kam thënë asgjë për nivelin e aplikacionit dhe logjikën e biznesit. Fatkeqësisht, në aplikacionet tona deri tani nuk është realizuar mbledhja e metrikave. Burimi i vetëm i ndonjë informacioni nga këto nivele janë logët.

Disa momente.

Së pari, shkruani log-e të strukturuara. Nuk ka nevojë të përfshini kontekstin në tekstin e mesazhit. Kjo e vështirëson grupimin dhe analizin e tyre. Logstash kërkon shumë kohë për ta normalizuar atë.

Së dyti, përdorni saktë nivelet e severity. Çdo gjuhë ka standardin e saj. Personalish unë i dalloj katër nivele:

nuk ka gabim;
gabim nga ana e klientit;
gabim nga ana jonë, nuk humbasim para, nuk kemi rreziqe;
gabim nga ana jonë, humbasim para.

Përmbledh, duhet të përpiqemi të ndërtojmë monitorimin pikërisht nga logjika e biznesit. Të përpiqemi të monitorojmë vetë aplikacionin dhe të veprojmë me metrikat si numri i shitjeve, numri i regjistrimeve të reja të përdoruesve, numri i përdoruesve aktivë në momentin e tanishëm dhe kështu me radhë.

Nëse e gjithë biznesi juaj është një buton në shfletues, është e nevojshme të monitornoni nëse ai shtypet, nëse funksionon siç duhet. Të gjitha gjërat e tjera nuk kanë rëndësi.

Nëse nuk e keni këtë, mund të përpiqeni ta mbuloni në log-et e aplikacionit, log-et e Nginx-it etj., siç bëmë ne. Duhet të jeni sa më afër aplikacionit.

Metrikat e sistemit operacional natyrisht që janë të rëndësishme, por biznesit ato nuk i interesojnë, ne nuk paguajmë për to.

Burimi: habr.com