Nire izena Anton Baderin da. Goi Teknologia Zentroan lan egiten dut eta sistemaren administrazioa egiten dut. Duela hilabete, gure konferentzia korporatiboa amaitu zen, non pilatutako esperientzia gure hiriko IT komunitatearekin partekatu genuen. Web aplikazioen monitorizazioari buruz hitz egin nuen. Materiala junior edo erdi mailakoentzat pentsatua zegoen, prozesu hori hutsetik eraiki ez zutenak.
Edozein monitorizazio sistemaren oinarrian negozio-arazoak konpontzea da. Jarraipena egiteagatik ez du inorentzat interesik. Zer nahi du negozioak? Dena azkar eta akatsik gabe funtziona dezan. Enpresek proaktiboa izan nahi dute, guk geuk zerbitzuan arazoak identifikatu eta ahalik eta azkarren konpontzeko. Horiek dira, hain zuzen ere, iaz gure bezeroetako baten proiektu batean konpondu nituen arazoak.
Proiektuari buruz
Proiektua herrialdeko leialtasun programa handienetako bat da. Txikizkako kateei salmenten maiztasuna handitzen laguntzen diegu marketin-tresna ezberdinen bidez, hala nola bonus txartelak. Guztira, hamar zerbitzaritan exekutatzen diren 14 aplikazio biltzen ditu proiektuak.
Elkarrizketa prozesuan zehar, behin eta berriz ohartu nintzen administratzaileak ez direla beti behar bezala hurbiltzen web aplikazioak monitorizatzera: askok oraindik sistema eragilearen neurketetan jartzen dute arreta eta noizean behin zerbitzuak kontrolatzen dituzte.
Nire kasuan, bezeroaren jarraipen-sistema lehenago Icingan oinarritzen zen. Ez zituen inola ere konpondu aurreko arazoak. Askotan bezeroak berak arazoen berri ematen zigun, eta, askotan, ez genuen arrazoiaren sakonera iristeko datu nahikorik.
Horrez gain, bere garapenaren alferrikakoa argi eta garbi ulertzen zen. Icinga ezagutzen dutenek ulertuko nautela uste dut. Beraz, proiekturako web aplikazioen monitorizazio sistema guztiz birdiseinatzea erabaki genuen.
Prometeo
Hiru adierazle nagusitan oinarrituta aukeratu dugu Prometheus:
- Eskuragarri dauden neurketa kopuru handi bat. Gure kasuan 60 mila dira. Jakina, azpimarratzekoa da ez ditugula gehien erabiltzen (%95 inguru ziurrenik). Bestalde, denak nahiko merkeak dira. Guretzat, hau da lehen erabilitako Icinga-rekin alderatuta beste muturra. Bertan, metrikak gehitzea min berezia zen: zeudenak garestiak ziren (begiratu besterik ez dago edozein pluginren iturburu-kodea). Edozein plugin Bash edo Python-en script bat zen, eta horren abiarazte garestia da kontsumitutako baliabideei dagokienez.
- Sistema honek baliabide kopuru nahiko txikia kontsumitzen du. 600 MB RAM, nukleo baten % 15 eta dozena pare bat IOPS nahikoak dira gure metrika guztietarako. Jakina, metrika-esportatzaileak exekutatu behar dituzu, baina guztiak Go-n idatzita daude eta, gainera, ez dute energia-gose handirik. Ez dut uste errealitate modernoetan hori arazo bat denik.
- Kubernetesera migratzeko gaitasuna eskaintzen du. Bezeroaren planak kontuan hartuta, aukera nabaria da.
ELK
Aurretik, ez genuen erregistrorik bildu edo prozesatu. Gabeziak denontzat argiak dira. ELK aukeratu genuen sistema honekin esperientzia geneukalako. Aplikazioen erregistroak bakarrik gordetzen ditugu bertan. Hautapen irizpide nagusiak testu osoko bilaketa eta bere abiadura izan ziren.
Π‘lickhouse
Hasieran, aukeraketa InfluxDBren esku geratu zen. Nginx erregistroak, pg_stat_statements-en estatistikak eta Prometheus-en datu historikoak gordetzeko beharraz jabetu ginen. Influx ez zitzaigun gustatu, aldian-aldian memoria asko kontsumitzen hasi eta huts egiten zuelako. Horrez gain, kontsultak remote_addr-en arabera taldekatu nahi nituen, baina DBMS honetan taldekatzea etiketen bidez baino ez da. Etiketak garestiak dira (memoria), haien kopurua baldintzatuta dago.
Gure bilaketari ekin genion berriro. Behar zena datu-base analitiko bat zen, baliabide gutxien kontsumitzen zuena, ahal izanez gero, diskoan datuak konpresioarekin.
Clickhousek irizpide horiek guztiak betetzen ditu, eta ez gara inoiz damutu gure aukeraketa. Ez dugu aparteko datu kopururik idazten bertan (txertatze-kopurua minutuko bost mila ingurukoa da).
Erlikia berria
NewRelic historikoki gurekin egon da, bezeroaren aukera izan delako. APM gisa erabiltzen dugu.
Zabbix
Zabbix esklusiboki erabiltzen dugu hainbat APIren Kutxa Beltza kontrolatzeko.
Jarraipen-ikuspegia zehaztea
Ataza deskonposatu nahi genuen eta, horrela, monitorizazioaren ikuspegia sistematizatu.
Horretarako, gure sistema maila hauetan banatu dut:
- hardwarea eta VMSa;
- sistema eragilea;
- sistema zerbitzuak, software pila;
- aplikazio;
- negozio-logika.
Zergatik da komenigarria ikuspegi hau:
- maila bakoitzeko lanaren arduraduna dakigu eta, horretan oinarrituta, alertak bidal ditzakegu;
- alertak kentzerakoan egitura erabil dezakegu - arraroa izango litzateke datu-basearen erabilgarritasunari buruzko alerta bat bidaltzea makina birtuala bere osotasunean erabilgarri ez dagoenean.
Gure zeregina sistemaren funtzionamenduan urraketak identifikatzea denez, maila bakoitzean alerta-arauak idazterakoan arreta jartzea merezi duten metrika multzo jakin bat nabarmendu behar dugu. Jarraian, joan gaitezen "VMS", "Sistema eragilea" eta "Sistema zerbitzuak, software pila" mailak.
Makina birtualak
Hosting-ak prozesadorea, diskoa, memoria eta sarea esleitzen dizkigu. Eta lehen biekin arazoak izan genituen. Beraz, neurketak:
CPU lapurtutako denbora - Amazon-en makina birtual bat erosten duzunean (t2.micro, adibidez), ulertu behar duzu ez zaizula prozesadorearen nukleo osoa esleitzen, bere denboraren kuota bat baizik. Eta agortzen duzunean, prozesadorea kenduko zaizu.
Neurri honi esker, horrelako uneak jarraitzeko eta erabakiak hartzeko aukera ematen dizu. Esaterako, beharrezkoa al da tarifa gizenagoa hartzea edo atzeko planoko zereginen eta API eskaerak prozesatzea zerbitzari desberdinetara banatzea?
IOPS + CPU iowait denbora - arrazoiren batengatik, hodeiko ostalaritza askok IOPS nahikoa ematen ez dutelako egiten dute huts. Gainera, IOPS baxuko egutegia ez da beraientzat argudio bat. Horregatik, merezi du CPU iowait biltzea. Grafiko pare honekin - IOPS baxuarekin eta I/O itxaron handiarekin - dagoeneko ostalaritzarekin hitz egin dezakezu eta arazoa konpondu.
Sistema eragilea
Sistema eragilearen neurketak:
- eskuragarri dagoen memoria kopurua %-tan;
- trukatu erabilera jarduera: vmstat swapin, swapout;
- erabilgarri dauden inodo kopurua eta fitxategi-sisteman espazio librea %-tan
- batez besteko karga;
- tw egoeran konexio kopurua;
- contrack taula betetasuna;
- Sarearen kalitatea kontrolatu daiteke ss utilitatea erabiliz, iproute2 paketea - lortu RTT konexioen adierazle bat bere irteeratik eta taldekatu dest atakaren arabera.
Sistema eragilearen mailan ere prozesu gisako entitate bat dugu. Garrantzitsua da sisteman bere funtzionamenduan zeresan handia duten prozesu multzo bat identifikatzea. Esaterako, hainbat pgpool badituzu, orduan horietako bakoitzaren informazioa bildu behar duzu.
Neurri multzoa honako hau da:
- PUZ;
- memoria nagusiki egoiliarra da;
- IO - hobe IOPS-n;
- FileFd - ireki eta mugatu;
- orrialdeen hutsegite esanguratsuak - horrela zer prozesu trukatzen ari den uler dezakezu.
Monitorizazio guztia Docker-en zabaltzen dugu, eta Advisor erabiltzen dugu metrika datuak biltzeko. Beste makinetan prozesu-esportatzailea erabiltzen dugu.
Sistema zerbitzuak, software pila
Aplikazio bakoitzak bere berezitasunak ditu, eta zaila da metrika multzo zehatz bat bereiztea.
Multzo unibertsala hau da:
- eskaera tasa;
- akats kopurua;
- latentzia;
- saturazioa.
Maila honetako monitorizazioaren adibiderik deigarrienak Nginx eta PostgreSQL dira.
Gure sisteman gehien kargatutako zerbitzua datu-basea da. Iraganean, askotan arazoak izan genituen datu-baseak zer egiten zuen jakiteko.
Diskoetan karga handia ikusi genuen, baina erregistro geldoek ez zuten ezer erakusten. Arazo hau pg_stat_statements erabiliz konpondu dugu, kontsulta-estatistikak biltzen dituen ikuspegia.
Hori da administratzaileak behar duen guztia.
Irakurtzeko eta idazteko eskaeren jardueraren grafikoak eraikitzen ditugu:
Dena sinplea eta argia da, eskaera bakoitzak bere kolorea du.
Adibide bezain deigarria Nginx erregistroak dira. Ez da harritzekoa jende gutxik aztertzea edo ezinbesteko zerrendan aipatzea. Formatu estandarra ez da oso informatiboa eta zabaldu egin behar da.
Pertsonalki, request_time, upstream_response_time, body_bytes_sent, request_length, request_id gehitu ditut. Erantzun denbora eta errore-kopurua marraztu ditugu:
Erantzun denboraren eta errore kopuruaren grafikoak eraikitzen ditugu. Gogoratzen? Enpresa-zereginez hitz egin al dut? Azkar eta akatsik gabe? Dagoeneko gai hauek bi diagramekin landu ditugu. Eta dagoeneko dei diezaiekezu guardiako administratzaileei haiek erabiliz.
Baina beste arazo bat geratzen da: gertakariaren arrazoiak azkar ezabatzea bermatzea.
Gorabeheren ebazpena
Arazo bat identifikatzetik ebatzi arte prozesu osoa hainbat urratsetan bana daiteke:
- arazoa identifikatzea;
- betebehar-administratzaileari jakinaraztea;
- gertakari bati erantzuna;
- kausak ezabatzea.
Garrantzitsua da hori ahalik eta azkarren egin behar dugula. Eta arazo bat identifikatzeko eta jakinarazpen bat bidaltzeko faseetan denbora asko irabazi ezin badugu - bi minutu igaroko dira, edozein kasutan, ondorengoak hobekuntzarako landu gabeko eremua besterik ez da.
Pentsa dezagun guardiako ofizialaren telefonoak jo zuela. Zer egingo du? Bilatu galderei erantzunak: zer apurtu zen, non hautsi zen, nola erreakzionatu? Hona hemen galdera hauei nola erantzuten diegun:
Besterik gabe, informazio hori guztia jakinarazpenaren testuan sartzen dugu, arazo honi nola erantzun, nola konpondu eta areagotu deskribatzen duen wiki orri baterako esteka bat ematen diogu.
Oraindik ez dut ezer esan aplikazio-geruza eta negozio-logikari buruz. Zoritxarrez, gure aplikazioek oraindik ez dute inplementatzen metrika-bilketa. Maila hauetako informazio iturri bakarra erregistroak dira.
Puntu pare bat.
Lehenik eta behin, idatzi erregistro egituratuak. Ez dago mezuaren testuan testuingurua sartu beharrik. Horrek zaildu egiten ditu taldekatzea eta aztertzea. Logstash-ek denbora asko behar du hau guztia normalizatzeko.
Bigarrenik, larritasun mailak behar bezala erabili. Hizkuntza bakoitzak bere estandarra du. Pertsonalki, lau maila bereizten ditut:
- akatsik ez;
- bezeroaren alboko errorea;
- akatsa gure alde dago, ez dugu dirurik galtzen, ez dugu arriskurik hartzen;
- Akatsa gure alde dago, dirua galtzen dugu.
Utzidazu laburbiltzen. Negozio-logikan oinarritutako monitorizazioa eraikitzen saiatu behar duzu. Saiatu aplikazioa bera kontrolatzen eta salmenten kopurua, erabiltzaile berrien erregistro kopurua, une honetan aktibo dauden erabiltzaileen kopurua, etab.
Zure negozio osoa arakatzailean botoi bat bada, klik egiten duen eta ondo funtzionatzen duen kontrolatu behar duzu. Gainerako guztiak ez du axola.
Hau ez baduzu, aplikazioen erregistroetan, Nginx erregistroetan eta abarretan harrapatzen saia zaitezke, guk egin genuen bezala. Aplikaziotik ahalik eta gertuen egon beharko zenuke.
Sistema eragilearen neurketak garrantzitsuak dira noski, baina enpresari ez zaie interesatzen, ez gaituzte ordaintzen.
Iturria: www.habr.com