Më quajnë Anton Baderin. Punoj në Qendrën e Teknologjive të Larta dhe merrem me administrimin e sistemeve. Një muaj më parë përfunduam konferencën tonë korporative, ku ndamë përvojën e akumuluar me komunitetin IT të qytetit tonë. Folëm për monitorimin e aplikacioneve web. Materiali ishte i destinuar për nivelin junior ose mesatar, ata që nuk e kishin ndërtuar këtë proces nga zero.
Guri i themelit, qĂ« qĂ«ndron nĂ« bazĂ« tĂ« çdo sistemi monitorimi â zgjidhja e problemeve tĂ« biznesit. Monitorimi pĂ«r monitorimin nuk i intereson askĂ«nd. ĂfarĂ« dĂ«shiron biznesi? QĂ« gjithçka tĂ« funksionojĂ« shpejt dhe pa gabime. Biznesi dĂ«shiron proaktivitet, qĂ« ne vetĂ« tĂ« identifikojmĂ« problemet nĂ« funksionimin e shĂ«rbimit dhe t'i zgjidhim ato sa mĂ« shpejt tĂ« jetĂ« e mundur. KĂ«to, nĂ« thelb, janĂ« detyrat qĂ« kam zgjidhur gjatĂ« gjithĂ« vitit tĂ« kaluar nĂ« projektin e njĂ« nga klientĂ«ve tanĂ«.
PĂ«r projektin
Projekti â njĂ« nga programet mĂ« tĂ« mĂ«dha tĂ« besnikĂ«risĂ« nĂ« vend. NdihmojmĂ« rrjetet me pakicĂ« tĂ« rrisin frekuencĂ«n e shitjeve pĂ«rmes mjeteve tĂ« ndryshme marketingu si kartat bonus. NĂ« total, projekti pĂ«rfshin 14 aplikacione, tĂ« cilat funksionojnĂ« nĂ« dhjetĂ« servera.
Gjatë procesit të intervistave, kam vënë re se administratoret nuk e qasen gjithmonë si duhet monitorimin e aplikacioneve web: ende shumë ndalen te metriku i sistemit operativ, herë pas here monitorojnë shërbimet.
Në rastin tim, më parë, në bazën e sistemit të monitorimit të klientit ishte Icinga. Ajo nuk zbulonte ashtu siç duhej problemet e përmendura më parë. Shpesh, klienti vetë na informonte për problemet dhe jo më pak na mungonin të dhënat për të kuptuar shkakun.
Përveç kësaj, kishte një kuptim të qartë për pamundësinë e zhvillimit të saj të mëtejshëm. Mendoj, ata që janë të njohur me Icinga do të më kuptojnë. Kështu, vendosëm të riparojmë plotësisht sistemin e monitorimit të aplikacioneve web në projekt.
Prometheus
Zgjedhëm Prometheus, duke u bazuar në tri tregues të rëndësishëm:
- NjĂ« numĂ«r i madh metricash tĂ« disponueshme. NĂ« rastin tonĂ«, ato janĂ« 60 mijĂ«. Sigurisht, vlen tĂ« theksohet se shumica dĂ«rrmuese e tyre nuk pĂ«rdoren (ndoshta rreth 95%). NĂ« anĂ«n tjetĂ«r, tĂ« gjitha janĂ« relativisht tĂ« lira. Kjo Ă«shtĂ« njĂ« tjetĂ«r ekstrem pĂ«r ne, krahasuar me Icinga, qĂ« kemi pĂ«rdorur mĂ« parĂ«. Atje, shtimi i metricave ishte veçanĂ«risht i dhimbshĂ«m: ato qĂ« kishim ishin tĂ« shtrenjta (mjafton tĂ« shikosh burimet e çdo plugin). Ădo plugin ishte njĂ« skritp nĂ« Bash ose Python, qasja e tĂ« cilit ishte e shtrenjtĂ« nĂ« terma tĂ« burimeve tĂ« konsumuar.
- Ky sistem konsumon një sasi relativisht të vogël burimesh. Për të gjitha metricat tona, mjaftojnë 600 Mb RAM, 15% e një bërthame dhe disa dhjetëra IOPS. Sigurisht, duhet të aktivizojmë eksportuesit e metricave, por të gjithë janë shkruar në Go dhe gjithashtu nuk janë të uritur. Nuk mendoj se në realitetet moderne kjo është një problem.
- Ofron mundĂ«sinĂ« e kalimit nĂ« Kubernetes. Duke marrĂ« parasysh planet e klientit â zgjedhja Ă«shtĂ« e qartĂ«.
ELK
Më parë, ne nuk mbledhim dhe nuk përpunojmë logët. Disavantazhet janë të qarta për të gjithë. Ne zgjodhëm ELK, pasi kishim eksperiencë të mëparshme me këtë sistem. Atje ruajmë vetëm logët e aplikacioneve. Kriteret kryesore për përzgjedhjen ishin kërkimi në tekst të plotë dhe shpejtësia e tij.
Clickhouse
Fillimisht, zgjedhja ra mbi InfluxDB. Ne e dinim nevojën për mbledhjen e logëve Nginx, statistikat nga pg_stat_statements, ruajtjen e të dhënave historike të Prometheus. Influx nuk na pëlqeu, pasi nga koha në kohë filloi të konsumonte shumë memorje dhe rrëzohej. Për më tepër, ne do të doja të grumbulloja 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ë mënyrë të kushtëzuar i kufizuar.
Ne filluam kërkimin nga fillimi. Na nevojitej një bazë analitike me konsum minimal burimesh, idealisht me kompresimin e të dhënave në disk.
Clickhouse plotëson të gjitha këto kritere, dhe në asnjë rast nuk kemi penduar për zgjedhjen. Ne nuk shkruajmë ndonjë volum të jashtëzakonshëm të dhënash (numri i futjeve është rreth pesë mijë në minutë).
NewRelic
NewRelic historikisht ka qenë me ne, pasi ishte zgjedhja e klientit. Ajo përdoret si APM.
Zabbix
Ne përdorim Zabbix ekskluzivisht për monitorimin e Black Box të API-ve të ndryshme.
PĂ«rcaktimi i qasjes ndaj monitorimit
Na pëlqente të dekompozonim detyrën dhe kështu të sistematizonim qasjen ndaj monitorimit.
Për këtë arsye, unë e kam ndarë sistemin tonë në nivele të ndryshme:
- âhardueriâ dhe VMS;
- sistemi operativ;
- shërbimet sistemore, staku i softuerit;
- aplikacioni;
- logjika e biznesit.
Pse është i dobishëm ky qasje:
- ne dimë kush është përgjegjës për funksionimin e secilit nivel dhe, duke u bazuar në këtë, mund të dërgojmë alarme;
- mund tĂ« pĂ«rdorim strukturĂ«n pĂ«r tĂ« shuar alarmet â do tĂ« ishte e çuditshme tĂ« dĂ«rgonim njĂ« alarm pĂ«r mosfunksionimin e bazĂ«s sĂ« tĂ« dhĂ«nave, kur nĂ« pĂ«rgjithĂ«si makina virtuale nuk Ă«shtĂ« nĂ« dispozicion.
Duke pasur parasysh se detyra jonĂ« Ă«shtĂ« tĂ« identifikojmĂ« shkeljet nĂ« funksionimin e sistemit, duhet tĂ« evidentojmĂ« njĂ« set metricash nĂ« çdo nivel, tĂ« cilat ia vlen tĂ« merren parasysh gjatĂ« shkruarjes sĂ« rregullave tĂ« alarmin. MĂ« poshtĂ« do tĂ« kalojmĂ« nĂ« nivelet âVMSâ, âSistemi Operativâ dhe âShĂ«rbimet Sistemore, Staku i Softueritâ.
Makinat virtuale
Hosting na ndan procesorin, disku, memorjen dhe rrjetin. Dhe për dy të parat patëm disa probleme. Pra, metricat:
Koha e vjedhur e CPU â kur blini njĂ« virtual si nĂ« Amazon (p.sh. t2.micro), duhet tĂ« kuptoni se ju jepet jo njĂ« bĂ«rthamĂ« tĂ« plotĂ« tĂ« procesorit, por vetĂ«m njĂ« kuotĂ« tĂ« kohĂ«s sĂ« tij. Dhe kur ta shpenzoni, procesori do tĂ« fillojĂ« tĂ« merret nga ju.
Kjo metrikë lejon të monitoroni këto momente dhe të merrni vendime. Për shembull, a duhet të merrni një tarifë më të madhe apo të ndajmë përpunimin e detyrave pasive dhe kërkesat në API në të ndryshme serverë.
IOPS + Koha e pritjes sĂ« CPU iowait â pĂ«r ndonjĂ« arsyetim, shumĂ« hoste nĂ« re shpesh dĂ«shtojnĂ« nĂ« dhĂ«nien e IOPS. MĂ« shumĂ«, njĂ« grafik me IOPS tĂ« ulĂ«t pĂ«r ta nuk Ă«shtĂ« njĂ« argument. Prandaj Ă«shtĂ« e rĂ«ndĂ«sishme tĂ« grumbullojmĂ« edhe CPU iowait. Me kĂ«tĂ« çift grafikĂ«sh â me IOPS tĂ« ulĂ«t dhe pritje tĂ« lartĂ« tĂ« hyrjeve-daljeve â mund tĂ« flasim me hostin dhe tĂ« zgjidhim problemin.
Sistemi operativ
Metricat e sistemit operativ:
- numri i memories së disponueshme në %;
- aktiviteti i përdorimit të swap: vmstat swapin, swapout;
- numri i inode-ve të disponueshëm dhe hapësira e lirë në sistemin e skedarëve në %
- ngarkesa mesatare;
- numri i lidhjeve në gjendje tw;
- mbushja e tabelës conntrack;
- cilĂ«sia e funksionimit tĂ« rrjetit mund tĂ« monitorohet me ndihmĂ«n e utilitetit ss, me paketĂ«n iproute2 â duke marrĂ« nga dalja e saj treguesin e RTT-lidhjeve dhe grupuar sipas portit destinacion.
Po ashtu, nĂ« nivelin e sistemit operativ kemi njĂ« entitet tĂ« tillĂ«, si proceset. ĂshtĂ« e rĂ«ndĂ«sishme tĂ« evidentojmĂ« njĂ« set procesesh nĂ« sistem qĂ« luajnĂ« njĂ« rol tĂ« rĂ«ndĂ«sishĂ«m nĂ« funksionimin e tij. NĂ«se, pĂ«r shembull, keni disa pgpool, Ă«shtĂ« e nevojshme tĂ« grumbulloni informacion pĂ«r secilin prej tyre.
Seti i metricave është si më poshtë:
- CPU;
- memoria â nĂ« radhĂ« tĂ« parĂ«, rezidente;
- IO â idealisht nĂ« IOPS;
- FileFd â hapjet dhe kufiri;
- dĂ«shtimet e rĂ«ndĂ«sishme tĂ« faqeve â kĂ«shtu do tĂ« mund tĂ« kuptoni se cili proces Ă«shtĂ« duke swap-uar.
E gjithë monitorimi ynë është e vendosur në Docker; për mbledhjen e të dhënave të metrikave përdorim Cadvisor. Në makinat e tjera përdorim process-exporter.
Shërbimet sistemor, staku i softuerit
Ădo aplikacion ka specifikĂ«n e vet, dhe Ă«shtĂ« e vĂ«shtirĂ« tĂ« veçosh njĂ« grup tĂ« caktuar metrikash.
Grupi universale është:
- norma e kërkesave;
- numri i gabimeve;
- latenca;
- saturation.
Shembujt mĂ« tĂ« dukshĂ«m tĂ« monitorimit nĂ« kĂ«tĂ« nivel janĂ« â Nginx dhe PostgreSQL.
Shërbimi më i ngarkuar në sistemin tonë është databaza. Më parë, ne kishim probleme mjaft shpesh për të zbuluar çfarë po bënte databaza.
Ne pamë një ngarkesë të lartë në disqe, por log-et e ngadalta nuk tregonin asgjë në të vërtetë. Këtë problem e zgjidhëm me ndihmën e pg_stat_statements, një paraqitje ku grumbullohet statistika mbi kërkesat.
Kjo është gjithçka që i nevojitet administratorit.
Ndërtojmë grafike aktiviteti të kërkesave për lexim dhe shkrim:
E gjithë kjo është e thjeshtë dhe e qartë, çdo kërkesë ka ngjyrën e saj.
NjĂ« shembull po ashtu i dukshĂ«m â log-et e Nginx. Nuk Ă«shtĂ« e habitshme qĂ« pak kush i pĂ«rpunon ato ose i pĂ«rmend nĂ« listĂ«n e detyrueshme. Formati standard nuk Ă«shtĂ« shumĂ« informues dhe Ă«shtĂ« e nevojshme qĂ« tĂ« zgjerohet.
Personalizova aq, sa shtova request_time, upstream_response_time, body_bytes_sent, request_length, request_id. Ndërtojmë grafike të kohës së përgjigjes dhe numrit të gabimeve:
Ndërtojmë grafike të kohës së përgjigjes dhe numrit të gabimeve. A e mbani mend? Unë fola për detyrat e biznesit? Të gjitha shpejt dhe pa gabime? Ne tashmë i kemi mbyllur këto pyetje me dy grafikë. Dhe mbi ta, tani është e mundur të telefonosh administratorët e shërbimit.
Por ka mbetur njĂ« problem tjetĂ«r â tĂ« sigurojmĂ« eliminimin e shpejtĂ« tĂ« shkaqeve tĂ« incidentit.
Eliminimi i incidenteve
E gjithëProcedura nga identifikimi deri në zgjidhjen e problemit mund të ndahet në disa hapa:
- identifikimi i problemit;
- njoftimi i administratorit të shërbimit;
- reaksioni ndaj incidentit;
- eliminimi i shkaqeve.
ĂshtĂ« e rĂ«ndĂ«sishme qĂ« ne tĂ« bĂ«jmĂ« kĂ«tĂ« sa mĂ« shpejt tĂ« jetĂ« e mundur. Dhe nĂ«se nĂ« etapet e identifikimit tĂ« problemit dhe dĂ«rgimin e njoftimit nuk mund tĂ« fitojmĂ« shumĂ« kohĂ« â dy minuta do tĂ« shkojnĂ« nĂ« çdo rast, atĂ«herĂ« etapet e mĂ«passhme janĂ« thjesht njĂ« fushĂ« e paprekur pĂ«r pĂ«rmirĂ«sime.
Le tĂ« imagjinomĂ« se telefoni i rojĂ«s sĂ« shĂ«rbimit ka rĂ«nĂ«. ĂfarĂ« do tĂ« bĂ«jĂ« ai? Do tĂ« kĂ«rkojĂ« pĂ«rgjigje pĂ«r pyetje â çfarĂ« Ă«shtĂ« prishur, ku Ă«shtĂ« prishur, si tĂ« reagojĂ«? KĂ«shtu pĂ«rgjigjemi nĂ« kĂ«to pyetje:
Ne thjesht përfshijmë të gjitha këto informacione në tekstin e njoftimit dhe i japim një lidhje për faqen në wiki, ku përshkruhet se si të reagoni për këtë problem, si ta zgjidhni dhe ta eskaloni atë.
Unë ende nuk kam thënë asgjë për nivelin e aplikacionit dhe logjikën e biznesit. Fatkeqësisht, në aplikacionet tona ende nuk është implementuar mbledhja e metrikave. Burimi i vetëm i jakëson ndonjë informacion nga këto nivele janë loget.
Disa pika.
Së pari, shkruani loge të strukturuara. Mos e përfshini kontekstin në tekstin e mesazhit. Kjo e vështirëson grupimin dhe analizën e tyre. Logstash kërkon shumë kohë për t'i normalizuar të gjitha këto.
SĂ« dyti, pĂ«rdorni saktĂ«sisht nivelet e rĂ«ndĂ«sisĂ«. Ădo gjuhĂ« ka standardin e saj. Personalisht, ndaj 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.
Në përmbledhje. Duhet të përpiqemi të ndërtojmë monitorimin pikërisht nga logjika e biznesit. Të përpiqemi të monitorojmë vetë aplikacionin dhe të operojmë me metrika si numri i shitjeve, numri i regjistrimeve të reja të përdoruesve, numri i përdoruesve aktivë në këtë moment dhe kështu me radhë.
Nëse e gjithë biznesi juaj është një buton në shfletues, duhet të monitoroni nëse ai klikohet, nëse funksionon siç duhet. Gjithçka tjetër nuk ka rëndësi.
Nëse nuk e keni këtë, mund të përpiqeni ta rikuperoni këtë në loget e aplikacionit, loget Nginx dhe kështu me radhë, siç kemi bërë ne. Duhet të jeni sa më afër aplikacionit.
Metrit e sistemit operativ sigurisht që janë të rëndësishme, por biznesi nuk është i interesuar për to, ne nuk paguhet për to.
Burimi: habr.com
