Emri im është Anton Baderin. Unë punoj në Qendrën e Teknologjisë së Lartë dhe bëj administrim sistemi. Një muaj më parë përfundoi konferenca jonë e korporatës, ku ndamë përvojën tonë të akumuluar me komunitetin e IT të qytetit tonë. Unë fola për monitorimin e aplikacioneve në internet. Materiali ishte i destinuar për nivel të ri ose të mesëm, të cilët nuk e ndërtuan këtë proces nga e para.
Guri i themelit që qëndron në themel të çdo sistemi monitorimi është zgjidhja e problemeve të biznesit. Monitorimi për hir të monitorimit nuk i intereson askujt. Çfarë kërkon biznesi? Kështu që gjithçka funksionon shpejt dhe pa gabime. Bizneset duan të jenë proaktive, në mënyrë që ne vetë të identifikojmë problemet në shërbim dhe t'i rregullojmë ato sa më shpejt të jetë e mundur. Këto, në fakt, janë problemet që kam zgjidhur gjatë gjithë vitit të kaluar në një projekt për një nga klientët tanë.
O projekte
Projekti është një nga programet më të mëdha të besnikërisë në vend. Ne i ndihmojmë zinxhirët e shitjeve me pakicë të rrisin frekuencën e shitjeve përmes mjeteve të ndryshme të marketingut si kartat e bonusit. Në total, projekti përfshin 14 aplikacione që funksionojnë në dhjetë serverë.
Gjatë procesit të intervistës, kam vërejtur në mënyrë të përsëritur se administratorët nuk i qasen gjithmonë saktë monitorimit të aplikacioneve në internet: shumë ende fokusohen në matjet e sistemit operativ dhe herë pas here monitorojnë shërbimet.
Në rastin tim, sistemi i monitorimit të klientit bazohej më parë në Icinga. Nuk i zgjidhi në asnjë mënyrë problemet e mësipërme. Shpesh vetë klienti na informonte për problemet, dhe më shpesh, thjesht nuk kishim të dhëna të mjaftueshme për të kuptuar arsyen.
Për më tepër, kishte një kuptim të qartë të kotësisë së zhvillimit të saj të mëtejshëm. Unë mendoj se ata që janë të njohur me Icinga do të më kuptojnë. Kështu, ne vendosëm të ridizajnojmë plotësisht sistemin e monitorimit të aplikacioneve në internet për projektin.
Prometeu
Ne zgjodhëm Prometheun bazuar në tre tregues kryesorë:
- Një numër i madh i metrikave të disponueshme. Në rastin tonë janë 60 mijë të tillë. Sigurisht, vlen të përmendet se ne nuk përdorim shumicën dërrmuese të tyre (ndoshta rreth 95%). Nga ana tjetër, ato janë të gjitha relativisht të lira. Për ne, ky është ekstremi tjetër në krahasim me Icinga-n e përdorur më parë. Në të, shtimi i metrikave ishte një dhimbje e veçantë: ato ekzistuese ishin të shtrenjta (thjesht shikoni kodin burimor të çdo shtojce). Çdo shtojcë ishte një skenar në Bash ose Python, lëshimi i të cilit është i shtrenjtë për sa i përket burimeve të konsumuara.
- Ky sistem konsumon një sasi relativisht të vogël burimesh. 600 MB RAM, 15% e një bërthame dhe disa duzina IOPS janë të mjaftueshme për të gjitha metrikat tona. Sigurisht, ju duhet të drejtoni eksportues të metrikës, por ata janë të gjithë të shkruar në Go dhe gjithashtu nuk janë shumë të uritur për energji. Unë nuk mendoj se në realitetet moderne ky është një problem.
- Ofron mundësinë për të migruar në Kubernetes. Duke marrë parasysh planet e klientit, zgjedhja është e qartë.
ELK
Më parë, ne nuk mbledhim apo përpunonim regjistrat. Mangësitë janë të qarta për të gjithë. Ne zgjodhëm ELK-në sepse tashmë kishim përvojë me këtë sistem. Ne ruajmë vetëm regjistrat e aplikacioneve atje. Kriteret kryesore të përzgjedhjes ishin kërkimi në tekst të plotë dhe shpejtësia e tij.
Сlickhouse
Fillimisht, zgjedhja ra në InfluxDB. Kuptuam nevojën për të mbledhur regjistrat e Nginx, statistika nga pg_stat_statements dhe ruajtjen e të dhënave historike të Prometheus. Nuk na pëlqeu Influx sepse periodikisht filloi të konsumonte një sasi të madhe memorie dhe u rrëzua. Për më tepër, doja të grupoja pyetjet sipas remote_addr, por grupimi në këtë DBMS bëhet vetëm me etiketa. Etiketat janë të shtrenjta (memoria), numri i tyre është i kufizuar me kusht.
Ne filluam përsëri kërkimin tonë. Ajo që duhej ishte një bazë të dhënash analitike me konsum minimal burimesh, mundësisht me kompresim të të dhënave në disk.
Clickhouse i plotëson të gjitha këto kritere dhe ne kurrë nuk jemi penduar për zgjedhjen tonë. Ne nuk shkruajmë ndonjë sasi të jashtëzakonshme të dhënash në të (numri i futjeve është vetëm rreth pesë mijë në minutë).
NewRelic
NewRelic ka qenë historikisht me ne sepse ishte zgjedhja e klientit. Ne e përdorim atë si një APM.
Zabbix
Ne përdorim Zabbix ekskluzivisht për të monitoruar kutinë e zezë të API-ve të ndryshme.
Përcaktimi i një qasjeje monitorimi
Ne donim të zbërthejmë detyrën dhe në këtë mënyrë të sistemojmë qasjen ndaj monitorimit.
Për ta bërë këtë, unë e ndava sistemin tonë në nivelet e mëposhtme:
- harduer dhe VMS;
- sistemi operativ;
- shërbimet e sistemit, steka softuerësh;
- aplikacion;
- logjika e biznesit.
Pse kjo qasje është e përshtatshme:
- ne e dimë se kush është përgjegjës për punën e secilit nivel dhe, bazuar në këtë, ne mund të dërgojmë alarme;
- ne mund ta përdorim strukturën kur shtypim sinjalizimet - do të ishte e çuditshme të dërgonim një alarm për padisponueshmërinë e bazës së të dhënave kur makina virtuale në tërësi është e padisponueshme.
Meqenëse detyra jonë është të identifikojmë shkeljet në funksionimin e sistemit, në çdo nivel duhet të theksojmë një grup të caktuar metrikash që ia vlen t'i kushtojmë vëmendje kur shkruajmë rregullat e alarmit. Më pas, le të kalojmë nëpër nivelet "VMS", "Sistemi operativ" dhe "Shërbimet e sistemit, grumbulli i softuerit".
Makinat virtuale
Hosting na ndan një procesor, disk, memorie dhe rrjet. Dhe ne kishim probleme me dy të parat. Pra, metrikat:
Koha e vjedhur e CPU - kur blini një makinë virtuale në Amazon (t2.micro, për shembull), duhet të kuptoni se nuk ju ndahet një bërthamë e tërë procesori, por vetëm një kuotë e kohës së tij. Dhe kur ta shteroni, procesori do t'ju hiqet.
Kjo metrikë ju lejon të gjurmoni momente të tilla dhe të merrni vendime. Për shembull, a është e nevojshme të merrni një tarifë më të trashë ose të shpërndani përpunimin e detyrave në sfond dhe kërkesave API në serverë të ndryshëm?
Koha e pritjes IOPS + CPU - për disa arsye, shumë hoste në cloud mëkatojnë duke mos ofruar IOPS të mjaftueshëm. Për më tepër, një orar me IOPS të ulët nuk është një argument për ta. Prandaj, ia vlen të mbledhësh CPU iowait. Me këtë palë grafikësh - me IOPS të ulët dhe pritje të lartë I/O - tashmë mund të flisni me hostin dhe ta zgjidhni problemin.
Sistem operativ
Metrikat e sistemit operativ:
- sasia e memories së disponueshme në %;
- Aktiviteti i përdorimit të shkëmbimit: vmstat swapin, swapout;
- numri i inodeve të disponueshme dhe hapësira e lirë në sistemin e skedarëve në %
- ngarkesa mesatare;
- numri i lidhjeve në dy gjendje;
- kontrolloni plotësinë e tabelës;
- Cilësia e rrjetit mund të monitorohet duke përdorur programin ss, paketën iproute2 - merrni një tregues të lidhjeve RTT nga dalja e tij dhe gruponi atë sipas portit destin.
Gjithashtu në nivelin e sistemit operativ kemi një entitet të tillë si procese. Është e rëndësishme të identifikohen në sistem një grup procesesh që luajnë një rol të rëndësishëm në funksionimin e tij. Nëse, për shembull, keni disa pgpool, atëherë duhet të grumbulloni informacion për secilën prej tyre.
Grupi i metrikës është si më poshtë:
- CPU;
- kujtesa është kryesisht rezidente;
- IO - mundësisht në IOPS;
- FileFd - hap dhe kufi;
- dështime të rëndësishme të faqeve - në këtë mënyrë mund të kuptoni se çfarë procesi po ndërrohet.
Ne vendosim të gjithë monitorimin në Docker dhe përdorim Këshilltarin për të mbledhur të dhëna metrike. Në makinat e tjera ne përdorim proces-eksportues.
Shërbimet e sistemit, grumbulli i softuerit
Çdo aplikacion ka specifikat e veta, dhe është e vështirë të veçosh një grup specifik metrikash.
Kompleti universal është:
- norma e kërkesës;
- numri i gabimeve;
- latente;
- ngopje.
Shembujt tanë më të mrekullueshëm të monitorimit në këtë nivel janë Nginx dhe PostgreSQL.
Shërbimi më i ngarkuar në sistemin tonë është baza e të dhënave. Në të kaluarën, ne shpesh kishim vështirësi të kuptonim se çfarë po bënte baza e të dhënave.
Ne pamë një ngarkesë të lartë në disqe, por regjistrat e ngadaltë nuk treguan asgjë. Ne e zgjidhëm këtë problem duke përdorur pg_stat_statements, një pamje që mbledh statistikat e pyetjeve.
Kjo është e gjitha që administratori ka nevojë.
Ne ndërtojmë grafikët e aktivitetit të kërkesave për lexim dhe shkrim:
Gjithçka është e thjeshtë dhe e qartë, çdo kërkesë ka ngjyrën e vet.
Një shembull po aq i mrekullueshëm janë regjistrat e Nginx. Nuk është për t'u habitur që pak njerëz i analizojnë ose i përmendin në listën e gjërave që duhet t'i keni. Formati standard nuk është shumë informues dhe duhet të zgjerohet.
Personalisht, kam shtuar request_time, upstream_response_time, body_bytes_sent, request_length, request_id. Ne grafikojmë kohën e përgjigjes dhe numrin e gabimeve:
Ne ndërtojmë grafikët e kohës së përgjigjes dhe numrit të gabimeve. E mbani mend? A fola për detyrat e biznesit? Të shpejt dhe pa gabime? Ne i kemi mbuluar tashmë këto çështje me dy tabela. Dhe tashmë mund të telefononi administratorët në detyrë duke i përdorur ato.
Por mbetet një problem tjetër - të sigurohet eliminimi i shpejtë i shkaqeve të incidentit.
Zgjidhja e incidentit
I gjithë procesi nga identifikimi deri te zgjidhja e një problemi mund të ndahet në disa hapa:
- identifikimi i problemit;
- njoftimin e administratorit të detyrës;
- reagimi ndaj një incidenti;
- eliminimi i shkaqeve.
Është e rëndësishme që ne duhet ta bëjmë këtë sa më shpejt të jetë e mundur. Dhe nëse në fazat e identifikimit të një problemi dhe dërgimit të një njoftimi nuk mund të fitojmë shumë kohë - në çdo rast do të shpenzohen dy minuta për to, atëherë ato të mëvonshme janë thjesht fushë e paploruar për përmirësime.
Le të imagjinojmë se ka rënë telefoni i oficerit të shërbimit. Çfarë do të bëjë ai? Kërkoni përgjigje për pyetjet - çfarë u prish, ku u prish, si të reagoni? Ja si u përgjigjemi këtyre pyetjeve:
Ne thjesht përfshijmë të gjithë këtë informacion në tekstin e njoftimit, i japim një lidhje me një faqe wiki që përshkruan se si t'i përgjigjemi këtij problemi, si ta zgjidhim atë dhe ta përshkallëzojmë atë.
Ende nuk kam thënë asgjë për shtresën e aplikimit dhe logjikën e biznesit. Fatkeqësisht, aplikacionet tona nuk zbatojnë ende mbledhjen e matjeve. Burimi i vetëm i çdo informacioni nga këto nivele janë regjistrat.
Nja dy pika.
Së pari, shkruani regjistrat e strukturuar. Nuk ka nevojë të përfshihet konteksti në tekstin e mesazhit. Kjo e bën të vështirë grupimin dhe analizimin e tyre. Logstash kërkon shumë kohë për të normalizuar të gjitha këto.
Së dyti, përdorni saktë nivelet e ashpërsisë. Çdo gjuhë ka standardin e vet. Personalisht, unë dalloj katër nivele:
- asnjë gabim;
- gabim nga ana e klientit;
- gabimi është në anën tonë, ne nuk humbasim para, nuk marrim rreziqe;
- Gabimi është në anën tonë, ne humbasim para.
Më lejoni të përmbledh. Ju duhet të përpiqeni të ndërtoni monitorim bazuar në logjikën e biznesit. Përpiquni të monitoroni vetë aplikacionin dhe të veproni me metrikë të tillë si numri i shitjeve, numri i regjistrimeve të përdoruesve të rinj, numri i përdoruesve aktualisht aktivë, etj.
Nëse i gjithë biznesi juaj është një buton në shfletues, duhet të monitoroni nëse ai klikon dhe funksionon siç duhet. Të gjitha të tjerat nuk kanë rëndësi.
Nëse nuk e keni këtë, mund të përpiqeni ta kapni atë në regjistrat e aplikacioneve, regjistrat e Nginx, e kështu me radhë, siç bëmë ne. Duhet të jeni sa më afër aplikacionit.
Metrikat e sistemit operativ janë sigurisht të rëndësishme, por biznesi nuk është i interesuar për to, ne nuk paguhemi për to.
Burimi: www.habr.com