Erregistroak sistemaren zati garrantzitsu bat dira, espero bezala funtzionatzen duela (edo ez dabilela) ulertzeko aukera ematen dizute. Mikrozerbitzuen arkitektura batean, erregistroekin lan egitea diziplina berezi bat bihurtzen da Olinpiada berezi baterako. Galdera pila bat aldi berean konpondu behar dira:
- nola idatzi erregistroak aplikazio batetik;
- non idatzi erregistroak;
- nola entregatu erregistroak biltegiratzeko eta prozesatzeko;
- erregistroak nola prozesatu eta gorde.
Gaur egun ezagunak diren edukiontzien teknologien erabilerak harea gehitzen dio arrastelaren gainean arazoa konpontzeko aukeren eremuari.
Horixe da, hain zuzen ere, Yuri Bushmelev-en "Map of rains in the field of collecting and delivery logs" txostenaren transkripzioa.
Nori axola zaio, mesedez, katuaren azpian.
Nire izena Yuri Bushmelev da. Lazadan egiten dut lan. Gaur gure erregistroak nola egin genituen, nola bildu genituen eta bertan idazten dugunari buruz hitz egingo dut.
Nongoak gara? Nor gara gu? Lazada Hego-ekialdeko Asiako sei herrialdetako lineako 1. denda da. Herrialde hauek guztiak gure datu-zentroen artean banatzen dira. Gaur egun 4 datu-zentro daude guztira. Zergatik da garrantzitsua? Zentroen artean oso lotura ahula dagoelako erabaki batzuk izan zirelako. Mikrozerbitzuen arkitektura dugu. Harrituta geratu nintzen dagoeneko 80 mikrozerbitzu ditugula. Erregistroekin zeregina hasi nintzenean, 20 besterik ez zeuden. Gainera, PHP ondarearen zati handi samarra dago, eta hori ere bizi eta jasan behar dut. Horrek guztiak une honetan 6 milioi mezu baino gehiago sortzen ditu sistema osorako minutuko. Jarraian, hau nola bizitzen saiatzen garen erakutsiko dut, eta zergatik den horrela.
Nolabait bizi behar duzu 6 milioi mezu hauekin. Zer egin behar dugu haiekin? Behar dituzun 6 milioi mezu:
- bidali aplikaziotik
- entregatzeko onartu
- analisi eta biltegiratzeko entregatu.
- aztertu
- gorde ezazu nolabait.
Hiru milioi mezu agertu zirenean, itxura bera ikusi nuen. Zentimo gutxirekin hasi ginelako. Argi dago aplikazioen erregistroak bertan idazten direla. Adibidez, ezin izan dut datu-basera konektatu, datu-basera konektatu ahal izan naiz baina ezin izan dut ezer irakurri. Baina honetaz gain, gure mikrozerbitzu bakoitzak sarbide-erregistro bat ere idazten du. Mikrozerbitzura iristen den eskaera bakoitza erregistroan erregistratzen da. Zergatik ari gara hau? Garatzaileek trazatu ahal izan nahi dute. Sarbide-erregistro bakoitzak trazeid eremu bat dauka, eta, horren bidez, interfaze berezi batek kate osoa askatzen du eta arrastoa ederki bistaratzen du. Aztarnak eskaera nola joan den erakusten du, eta honek gure garatzaileei laguntzen die identifikatu gabeko zaborrei azkar aurre egiten.
Nola bizi honekin? Orain aukeren eremua labur deskribatuko dut, arazo hau orokorrean nola konpontzen den. Erregistroak bildu, transmititu eta gordetzearen arazoa nola konpondu.
Nola idatzi aplikazio batetik? Argi dago modu desberdinak daudela. Bereziki, praktika onak daude, modan dauden burkideek esaten digutenez. Bi eskola zahar mota daude, gure aitonak esan zigun bezala. Beste modu batzuk daude.
Erregistroak biltzearen egoera gutxi gorabehera berdina da. Ez dago zati zehatz hau konpontzeko aukera asko. Dagoeneko gehiago dira, baina oraindik ez hainbeste.
Baina entrega eta ondorengo analisiarekin, aldakuntza kopurua lehertzen hasten da. Orain ez dut aukera bakoitza deskribatuko. Uste dut aukera nagusiak ezagunak direla gaian interesa duen ororentzat.
Lazadan nola egin genuen erakutsiko dizuet, eta nola hasi zen dena.
Duela urtebete Lazadara etorri nintzen eta enborrei buruzko proiektu batera bidali ninduten. Horrelako zerbait zen. Aplikazioaren erregistroa stdout eta stderr-en idatzi zen. Dena modan egin zen. Baina, ondoren, garatzaileek fluxu estandarretik bota zuten, eta, nolabait, azpiegitura espezialistek asmatuko dute. Azpiegituren espezialisten eta garatzaileen artean, badaude kaleratzaileak ere esaten dutenak: "uh... tira, bil ditzagun shell batekin fitxategi batean, eta kito". Eta hori guztia edukiontzi batean zegoenez, edukiontzian bertan bildu, barruan katalogoa mapatu eta bertan jarri zuten. Uste dut guztiontzat nahiko nabaria dela hortik ateratakoa.
Ikus dezagun oraingoz pixka bat gehiago. Nola entregatu ditugu erregistro hauek? Norbaitek td-agent aukeratu zuen, hau da, egia esan, jarioa, baina ez nahikoa. Oraindik ez dut ulertzen bi proiektu hauen arteko harremana, baina gauza bera dela dirudi. Eta Ruby-n idatzitako jario honek erregistro-fitxategiak irakurri zituen, JSON-n analizatu zituen nolabaiteko erregulartasuna erabiliz. Gero Kafkara bidali nituen. Gainera, Kafkan API bakoitzeko 4 gai bereizi genituen. Zergatik 4? Zuzenekoa dagoelako, eszenaratzea dagoelako eta stdout eta stderr daudelako. Garatzaileek sortzen dituzte, eta azpiegitura garatzaileek Kafkan sortu behar dituzte. Gainera, Kafka beste sail batek kontrolatzen zuen. Horregatik, txartel bat sortzea beharrezkoa zen api bakoitzeko 4 gai sortuko zituzten. Denek ahaztu zuten. Oro har, zaborra eta zalaparta zegoen.
Zer egin dugu honetaz gero? Kafkari bidali genion. Ondoren, Kafka-ren enbor erdiak Logstashera joan ziren hegan. Enborren beste erdia banatuta zegoen. Batzuk Graylog batera hegan egin zuten, besteak beste Graylog batera. Ondorioz, hori guztia Elasticsearch kluster batean sartu zen. Hau da, nahaspila hori guztia hor amaitu zen. Ez egin hori!
Hauxe da goitik begiratuz gero. Ez egin hori! Hemen arazo-eremuak berehala markatzen dira zenbakiekin. Egia esan, gehiago daude, baina 6 benetan arazotsuak dira, zerbait egin behar dutenak. Bereiz kontatuko dizkizut orain.
Hemen (1,2,3) fitxategiak idazten ditugu eta, horren arabera, hiru arrasto daude hemen aldi berean.
Lehenengoa (1) nonbait idatzi behar ditugula da. Ez litzateke beti desiragarria izango APIari fitxategi batean zuzenean idazteko gaitasuna ematea. Desiragarria da APIa edukiontzi batean isolatzea, edo are hobeto, irakurtzeko soilik izatea. Sistemaren administratzailea naiz, beraz, gauza hauen ikuspegi alternatibo bat daukat.
Bigarren puntua (2,3) APIra eskaera asko iristen garela da. APIak datu asko idazten ditu fitxategi batean. Fitxategiak hazten ari dira. Biratu behar ditugu. Zeren bestela ezingo baituzu han inolako diskorik hornitu. Biratzea txarra da, shell bidez direktoriora birbideratuz egiten direlako. Ezin dugu berrikusi. Ezin diozu aplikazioari esan heldulekuak berriro irekitzeko. Garatzaileek ergel bat balitz bezala begiratuko zaituztelako: “Zer deskribatzaileak? Orokorrean stdout-era idazten dugu». Azpiegitura garatzaileek copytruncate egin zuten logrotate-ra, eta horrek fitxategiaren kopia bat egiten du eta jatorrizkoa transkribatzen du. Horren arabera, kopiatze prozesu horien artean diskoko espazioa agortu ohi da.
(4) API ezberdinetan formatu desberdinak genituen. Zertxobait desberdinak ziren, baina adierazpen erregularra ezberdin idatzi behar zen. Hau guztia Puppet-ek kontrolatzen zuenez, klase mordoa zegoen beren labezomorroekin. Gainera, gehienetan td-agent-ek memoria jan zezakeen, ergela izan, funtzionatzen ari zela itxurak egin zezakeen eta ezer egin gabe. Kanpotik ezinezkoa zen ulertzea ezer egiten ez zuela. Onenean, eroriko da eta gero norbaitek jasoko du. Zehatzago esanda, alerta bat iritsiko da, eta norbait joango da eskuekin altxatzera.
(6) Eta zabor eta hondakin gehien elastikoa izan zen. Bertsio zaharra zelako. Garai hartan ez baikenuen maisu dedikaturik. Erregistro heterogeneoak genituen, zeinen eremuak gainjar litezkeen. Aplikazio ezberdinetako erregistro desberdinak eremu-izen berdinekin idatz daitezke, baina barruan datu desberdinak egon daitezke. Hau da, erregistro bat Integer dator eremuan, adibidez, maila. Beste erregistro bat String batekin dator maila eremuan. Mapping estatikorik ezean, gauza zoragarria da hau. Elastsearch-en indizea biratu ondoren, kate bat duen mezu bat iristen bada lehenik, orduan normal bizi gara. Baina lehenengoa Integer-etik iritsi bada, String-etik heldu diren ondorengo mezu guztiak baztertu besterik ez dira egiten. Eremu mota ez datorrelako bat.
Galdera hauek egiten hasi ginen. Errudunen bila ez bilatzea erabaki genuen.
Baina zerbait egin behar da! Gauza jakina da estandarrak ezarri behar ditugula. Dagoeneko bagenituen estandar batzuk. Pixka bat beranduago hasi ginen batzuk. Zorionez, ordurako onartua zegoen API guztien erregistro-formatu bakarra. Zerbitzuen arteko elkarrekintzarako estandarretan zuzenean idatzita dago. Horren arabera, erregistroak jaso nahi dituztenek formatu honetan idatzi behar dituzte. Norbaitek erregistroak formatu honetan idazten ez baditu, ez dugu ezer bermatzen.
Ondoren, estandar bateratu bat sortu nahiko nuke erregistroak grabatzeko, entregatzeko eta biltzeko metodoetarako. Egia esan, non idatzi, eta nola entregatu. Egoera aproposa proiektuek liburutegi bera erabiltzen dutenean da. Go-rako erregistro-liburutegi bereizia dago eta PHP-rako liburutegi bereizia. Guk ditugun guztiek erabili beharko lituzkete. Momentuz, esango nuke %80an arrakasta dugula horretan. Baina batzuek kaktusak jaten jarraitzen dute.
Eta hor (diapositiban) "Egunak entregatzeko SLA" ia ez da agertzen. Oraindik ez da existitzen, baina lanean ari gara. Oso erosoa delako azpiegiturak esaten duenean halako eta halako formatuan idazten baduzu halako edo halako leku batean eta ez N mezu baino gehiago segundoko, orduan ziurrenik halako edo halako leku batera entregatuko ditugula. Horrek buruko min asko arintzen ditu. SLA bat badago, hau guztiz zoragarria da!
Nola hasi ginen arazoa konpontzen? Arazo nagusia td-agent-arekin izan zen. Ez zegoen argi nora zihoazen gure erregistroak. Entregatu al dira? Ba al dira? Non daude hala ere? Hori dela eta, lehen puntua td-agent ordezkatzea erabaki zen. Laburki azaldu ditut hemen ordezkatu beharreko aukerak.
Fluxua. Lehenik eta behin, aurreko lan batean egin nuen topo, eta aldian-aldian ere bertan erortzen zen. Bigarrenik, hau gauza bera da, profila bakarrik.
Filebeat. Nola egin zitzaigun erosoa? Go-n dagoelako, eta esperientzia handia dugulako Go-n. Horren arabera, zerbait gertatuko balitz, nolabait gehi genezake geure buruari. Horregatik ez genuen hartu. Zure kabuz berridazten hasteko tentaziorik ere ez egon dadin.
Sistema-administratzailearentzako irtenbide agerikoa kantitate honetako syslog mota guztiak dira (syslog-ng/rsyslog/nxlog).
Edo idatzi zeure zerbait, baina hau baztertu dugu, baita filebeat ere. Zerbait idazten baduzu, hobe da negozioetarako erabilgarria den zerbait idaztea. Erregistroak emateko, hobe da prest egindako zerbait hartzea.
Hori dela eta, aukera benetan syslog-ng eta rsyslog-en artean aukeratzera iritsi zen. Puppet-en rsyslog-erako klaseak geneukalako besterik gabe rsyslog-era zuzendu nintzen, eta ez nuen haien artean desberdintasun nabaririk aurkitu. Zer da syslog, zer da syslog. Bai, batzuek dokumentazio txarragoa dute, beste batzuek hobea. Honek horrela egin dezake, eta besteak beste modu batera.
Eta rsyslog-i buruz pixka bat. Lehenik eta behin, polita da, modulu asko dituelako. Gizakiek irakur daitekeen RainerScript (konfigurazio-lengoaia modernoa) dauka. Hobari ikaragarria da td-agent-en portaera emulatu genezakeela tresna estandarrak erabiliz, eta ez da ezer aldatu aplikazioetarako. Hau da, td-agent rsyslog-era aldatzen dugu, eta gainerako guztia bakarrik uzten dugu oraingoz. Eta berehala laneko entrega jasotzen dugu. Ondoren, mmnormalize gauza ikaragarria da rsyslog-en. Erregistroak analizatzeko aukera ematen du, baina ez Grok eta adierazpen erregularra erabiliz. Sintaxi-zuhaitz abstraktua egiten du. Erregistroak aztertzen ditu konpiladore batek iturriak aztertzen dituen modu berean. Horri esker, oso azkar lan egin dezakezu, CPU gutxi kontsumitu eta, oro har, gauza polita da. Beste hobari mordoa daude. Ez naiz haietan luzatuko.
rsyslog-ek beste desabantaila asko ditu. Hobariak bezalakoak dira. Arazo nagusiak sukaldatzen jakin behar duzula eta bertsioa hautatu behar duzula dira.
Erregistroak Unix socket batean idatziko genituela erabaki genuen. Eta ez /dev/log-en, sistemaren erregistro nahaspilatsua dugulako, journald kanalizazio honetan dago. Beraz, idatz dezagun socket pertsonalizatu batera. Aparteko arau-multzo bati erantsiko diogu. Ez dezagun ezer oztopatu. Dena gardena eta ulergarria izango da. Horixe da, hain zuzen, egin genuena. Socket hauek dituen direktorioa estandarizatu eta edukiontzi guztietara bidaltzen da. Edukiontziek behar duten entxufea ikusi, ireki eta bertan idatzi dezakete.
Zergatik ez fitxategi bat? Denek irakurtzen dutelako , fitxategi bat dockerra bidaltzen saiatu zen, eta rsyslog berrabiarazi ondoren fitxategiaren deskribatzailea aldatu egin zela ikusi zen eta docker-ek fitxategi hau galdu zuela. Beste zerbait zabalik mantentzen du, baina ez idazten ari diren entxufea. Erabaki genuen arazo honen inguruan lan egingo genuela, eta, aldi berean, blokeo arazoaren inguruan arituko ginela.
Rsyslog-ek diapositiban adierazitako ekintzak egiten ditu eta erregistroak bidaltzen ditu erreleboari edo Kafka-ri. Kafkak bide zaharrari jarraitzen dio. Relay - rsyslog hutsa erabiltzen saiatu naiz erregistroak emateko. Mezu-ilararik gabe, rsyslog tresna estandarrak erabiliz. Funtsean, funtzionatzen du.
Baina ñabardurak daude zati honetara bultzatzeko (Logstash/Graylog/ES). Zati hau (rsyslog-rsyslog) datu-zentroen artean erabiltzen da. Hona hemen konprimitutako tcp esteka bat, eta horrek banda zabalera aurrezteko aukera ematen digu eta, horren arabera, kanala buxatuta dagoenean beste datu-zentro batetik erregistro batzuk jasotzeko probabilitatea handitzen du. Indonesia dugulako, non dena txarto dagoen. Hor dago etengabeko arazoa.
Pentsatu genuen nola kontrolatu dezakegun aplikaziotik grabatu ditugun erregistroak amaierara iristeko probabilitatea? neurketak sortzea erabaki genuen. rsyslog-ek bere estatistikak biltzeko modulua du, kontagailu mota batzuk dituena. Esaterako, ilararen tamaina erakutsi diezazuke, edo zenbat mezu iritsi diren halako eta halako ekintza batean. Dagoeneko har dezakezu zerbait haiengandik. Gainera, konfigura daitezkeen kontagailu pertsonalizatuak ditu, eta, adibidez, API batzuek grabatutako mezu kopurua erakutsiko dizu. Ondoren, rsyslog_exporter idatzi nuen Python-en, eta Prometheus-era bidali genuen guztia eta grafikoak eraiki genituen. Benetan nahi genituen Graylog neurketak, baina oraindik ez dugu konfiguratzeko astirik izan.
Zeintzuk ziren arazoak? Arazoak sortu ziren (BAT-BATEAN!) gure Live APIak segundoko 50k mezu idazten ari zirela deskubritu genuenean. Hau Live API bat baino ez da eszenaratzerik gabe. Eta Graylog-ek 12 mila mezu bakarrik erakusten dizkigu segundoko. Eta arrazoizko galdera bat sortu zen: non daude aztarnak? Hortik ondorioztatu genuen Graylog-ek ezin duela aurre egin. Begiratu genuen, eta, hain zuzen ere, Graylog eta Elasticsearch-ek ezin izan zuten fluxu hori kudeatu.
Jarraian, bidean egin ditugun beste aurkikuntza batzuk.
Socketerako idazketak blokeatuta daude. Nola gertatu zen? Bidaltzeko rsyslog erabiltzen ari nintzenean, noizbait datu-zentroen arteko kanala hautsi zen. Bidalketa leku batean gelditu zen, entrega beste leku batean gelditu zen. Hori guztia rsyslog socketean idazten duten APIekin iritsi da makinara. Han ilara bat zegoen. Ondoren, Unix socketean idazteko ilara, hau da, lehenespenez 128 pakete, bete da. Eta aplikazioan hurrengo write() blokeatuta dago. Go aplikazioetan erabiltzen dugun liburutegia aztertu genuenean, han idatzi zen socketean idaztea blokeatu gabeko moduan gertatzen dela. Ziur geunden ezer ez zela blokeatu. Irakurtzen dugulako horri buruz idatzi zuena. Baina bada momentu bat. Dei honen inguruan ere begizta infinitua zegoen, mezu bat entxufean sartzeko etengabeko saiakera izan zen. Ez genion erreparatu. Liburutegia berridatzi behar izan nuen. Geroztik hainbat aldiz aldatu da, baina orain azpisistema guztietan blokeoak kendu ditugu. Hori dela eta, rsyslog gelditu dezakezu eta ezer ez da huts egingo.
Beharrezkoa da ilaren tamaina kontrolatzea, eta horrek arrastel hau zapaltzea saihesten laguntzen du. Lehenik eta behin, mezuak galtzen hasten garen kontrolatu dezakegu. Bigarrenik, entregatzeko arazoak ditugula kontrolatu dezakegu.
Eta beste une desatsegin bat - mikrozerbitzuen arkitektura batean 10 aldiz handitzea oso erraza da. Ez dugu sarrerako eskaera askorik, baina mezu hauek urrunago bidaiatzen duten grafikoagatik, sarbide-erregistroengatik, egia esan, hamar aldiz handitzen dugu erregistro-karga. Zoritxarrez, ez nuen astirik izan kopuru zehatzak kalkulatzeko, baina mikrozerbitzuak dira. Hau kontuan izan behar da. Ematen du momentuz egur bilketa azpisistema dela kargatuena Lazadan.
Nola konpondu elasticsearch arazoa? Erregistroak leku bakarrean azkar lortu behar badituzu, makina guztietara korritu eta bertan biltzeko, erabili fitxategien biltegiratzea. Horrek funtzionatuko duela bermatuta dago. Edozein zerbitzaritik egin daiteke. Bertan diskoak itsatsi eta syslog instalatu besterik ez duzu behar. Horren ostean, erregistro guztiak leku bakarrean edukitzea ziurtatuta dago. Ondoren, poliki-poliki elastiko bilaketa, graylog eta beste zerbait konfigura ditzakezu. Baina dagoeneko izango dituzu erregistro guztiak, eta, gainera, gorde ditzakezu disko-matrize nahikoa dagoen heinean.
Nire txostena egiteko garaian, eskema honela hasi zen. Ia fitxategian idazteari utzi diogu. Orain, ziurrenik, gainerakoak itzaliko ditugu. APIa exekutatzen duten tokiko makinetan, fitxategietan idazteari utziko diogu. Lehenik eta behin, fitxategien biltegiratzea dago, oso ondo funtzionatzen duena. Bigarrenik, makina hauek espaziorik gabe gelditzen ari dira etengabe; etengabe kontrolatu behar da.
Logstash eta Graylog-ekin zati hau benetan hartzen du. Hori dela eta, kendu egin behar dugu. Gauza bat aukeratu behar duzu.
Logstash eta Kibana botatzea erabaki genuen. Segurtasun saila dugulako. Zein lotura? Konexioa da Kibana X-Pack gabe eta Shield gabe ez duela uzten erregistroetarako sarbide-eskubideak bereizten. Horregatik hartu dugu Graylog. Denetarik dauka. Ez zait gustatzen, baina funtzionatzen du. Hardware berria erosi dugu, Graylog berria instalatu dugu eta formatu zorrotzekin erregistro guztiak Graylog bereizi batera transferitu ditugu. Eremu berdin-mota desberdinekin arazoa konpondu genuen antolakuntzan.
Zer sartzen den zehazki Graylog berrian. Docker-en dena idatzi dugu. Zerbitzari mordo bat hartu genuen, hiru Kafka instantzia zabaldu genituen, 7 Graylog zerbitzarien 2.3 bertsioa (Elasticsearch 5. bertsioa nahi genuelako). Hori guztia HDDtik egindako erasoetan jaso zen. Segundoko 100 mila mezu arteko indexazio-tasa ikusi dugu. Astean 140 terabyte datuak ikusi genituen.
Eta berriz ere arrastoa! Bi salmenta datozkigu. 6 milioi mezutik haratago joan ginen. Graylog-ek ez du mastekatzeko astirik. Nolabait berriro biziraun behar dugu.
Horrela bizirik atera ginen. Zerbitzari eta SSD gehiago gehitu ditugu. Momentu honetan horrela bizi gara. Orain jada 160 mezu mastekatzen ari gara segundoko. Oraindik ez dugu mugara iritsi, beraz, ez dago argi zenbat atera gaitezkeen honetatik.
Hauek dira gure etorkizunerako planak. Horietatik garrantzitsuena erabilgarritasun handia izango da. Oraindik ez dugu. Hainbat kotxe modu berean konfiguratuta daude, baina orain arte dena auto bakarretik doa. Denbora behar da haien artean hutsegitea konfiguratzeko.
Bildu neurketak Graylog-en.
Egin tarifa-muga bat gure banda-zabalera eta beste guztia hiltzen ez duen API zoro bat izan dezagun.
Eta, azkenik, sinatu SLA moduko bat garatzaileekin, hainbeste zerbitzatu ahal izateko. Gehiago idazten baduzu, barkatu.
Eta dokumentazioa idatzi.
Laburbilduz, bizitako guztiaren emaitzak. Lehenik eta behin, estandarrak. Bigarrenik, syslog tarta da. Hirugarrenik, rsyslog-ek diapositiban idatzita dagoen bezala funtzionatzen du. Eta pasa gaitezen galderetara.
Zure galderak.
Galdera: Zergatik erabaki zenuen ez hartzea... (filebeat?)
Erantzun: fitxategi batean idatzi behar dugu. Benetan ez nuen nahi. Zure APIak segundoko milaka mezu idazten dituenean, orduan behin biratzen baduzu ere, hau ez da aukera bat. Tubean idatz dezakezu. Garatzaileek galdetu zidaten: "Zer gertatuko da idazten ari garen prozesua huts egiten bada?" Ez nuen aurkitu zer erantzun, eta esan nuen: "Beno, ados, ez dezagun hori egin".
Galdera: Zergatik ez dituzu erregistroak idazten HDFSra?
Erantzun: Hau hurrengo etapa da. Hasieran pentsatu genuen, baina momentuz horretarako baliabiderik ez dagoenez, gure epe luzerako irtenbidean zintzilik dago.
Galdera: Zutabe formatua egokiagoa litzateke.
Erantzun: Ulertzen dut. Gu bi eskuekin gaude.
Galdera: rsyslog-era idazten ari zara. Bertan TCP eta UDP erabil ditzakezu. Baina UDP bada, nola bermatzen duzu entrega?
Erantzun: Bi puntu daude. Lehenik eta behin, denei esaten diet ez dugula erregistroen entrega bermatzen. Garatzaileak etortzen direnean eta esaten dutenean: «Has gaitezen hor finantza datuak idazten, eta zerbait gertatuz gero nonbait jarriko dizkiguzu», erantzuten diegu: «Oso! Has gaitezen entxufean idazten blokeatzen, eta egin hau transakzioetan, guretzako entxufean jarriko duzula bermatuta eta beste aldean jasotzen dugula ziurtatzeko». Eta momentu honetan, denek berehala ez dute gehiago behar. Beharrezkoa ez bada, zer galdera egin beharko genituzke? Entxufe batean idaztea bermatu nahi ez baduzu, zergatik ziurtatu behar dugu entrega? Gure ahalegina egiten ari gara. Benetan saiatzen gara ahalik eta gehien eta modurik onenean ematen, baina ez dugu %100eko bermerik ematen. Hortaz, ez dago hor finantza-daturik idatzi beharrik. Horretarako transakzioak dituzten datu-baseak daude.
Galdera: APIak erregistroan mezuren bat sortzen duenean eta kontrola mikrozerbitzuetara transferitzen duenean, aurkitu al duzu arazoa mikrozerbitzu ezberdinetako mezuak ordena okerrean iristeko? Horrek nahasmena eragiten du.
Erantzun: Normala da ordena ezberdinetan etortzea. Horretarako prestatuta egon behar duzu. Sareko edozein entregak ez duelako eskaera bermatzen, edo baliabide bereziak gastatu behar dituzu honetan. Fitxategien biltegiratzeak hartzen baditugu, orduan API bakoitzak erregistroak gordetzen ditu bere fitxategian. Edo hobeto esanda, rsyslog-ek direktorioetan sailkatzen ditu. API bakoitzak bere erregistroak ditu, non joan eta begiratu dezakezu, eta gero konparatu ditzakezu erregistro honetako denbora-zigilua erabiliz. Graylog-en begiratzen badute, orduan denbora-zigiluaren arabera ordenatuko dira. Han dena ondo egongo da.
Galdera: Denbora-zigilua milisegundotan alda daiteke.
Erantzun: Denbora-zigilua APIak berak sortzen du. Hau da, hain zuzen ere, kontu osoa. NTP dugu. APIak denbora-zigilu bat sortzen du mezuan bertan. rsyslog-ek ez du gehitzen.
Galdera: Datu-zentroen arteko elkarrekintza ez dago oso argia. Datu-zentroaren barruan, argi dago erregistroak nola bildu eta prozesatu ziren. Nola gertatzen da datu-zentroen arteko elkarrekintza? Edo datu-zentro bakoitzak bere bizitza bizi du?
Erantzun: Ia. Gure herrialdean, herrialde bakoitza datu-zentro batean dago. Momentuz, ez dugu hedapenik herrialde bat datu-zentro ezberdinetan kokatuta egon dadin. Beraz, ez dago horiek konbinatu beharrik. Zentro bakoitzak Log-errelebo bat dauka barruan. Hau Rsyslog zerbitzari bat da. Egia esan, bi kudeaketa-makina. Jarrera bera dute. Baina oraingoz, trafikoa horietako batetik igarotzen da. Erregistro guztiak biltzen ditu. Badaezpada disko-ilara bat dauka. Erregistroak deskargatzen ditu eta datu-zentro zentralera bidaltzen ditu (Singapur), eta gero Graylog-era bidaltzen ditu. Eta datu-zentro bakoitzak bere fitxategien biltegiratzea du. Gure konexioa galduz gero, erregistro guztiak hor ditugu. Han geratuko dira. Bertan gordeko dira.
Galdera: Egoera anormalak izanez gero, hortik jasotzen al dituzu erregistroak?
Erantzun: Hara joan zaitezke (fitxategien biltegira) eta begiratu.
Galdera: Nola kontrolatzen duzu ez duzula erregistroak galtzen?
Erantzun: Benetan galtzen ari gara, eta jarraipena egiten ari gara. Monitorizazioa duela hilabete jarri zen martxan. Go APIek erabiltzen duten liburutegiak metrika ditu. Socket batera idatzi ezin izan duen zenbat aldiz zenbatu dezake. Gaur egun heuristiko burutsu bat dago hor. Buffer bat dago hor. Bertatik socketera mezu bat idazten saiatzen da. Buffer-ak gainezka egiten badu, erortzen hasten da. Eta zenbat erori dituen zenbatzen du. Hor neurgailuak gainezka hasten badira, horren berri izango dugu. Orain ere prometheusera datoz, eta grafikoak Grafanan ikus ditzakezu. Alertak konfigura ditzakezu. Baina oraindik ez dago argi nori bidali.
Galdera: elasticsearch-en erregistroak erredundantziarekin gordetzen dituzu. Zenbat erreplika dituzu?
Erantzun: lerro bat.
Galdera: Hau lerro bakarra al da?
Erantzun: Hau maisua eta erreplika da. Datuak bi kopietan gordetzen dira.
Galdera: Doitu al duzu rsyslog buffer tamaina nolabait?
Erantzun: Datagramak unix socket pertsonalizatu batean idazten ditugu. Honek berehala 128 kilobyteko muga ezartzen digu. Ezin dugu gehiago idatzi. Hau estandarrean idatzi dugu. Biltegian sartu nahi dutenek 128 kilobyte idazten dituzte. Liburutegiak, gainera, moztu egiten dira, eta mezua moztuta dagoela adierazten duen bandera jartzen da. Mezuaren beraren estandarrak eremu berezi bat du, grabatzean moztu den ala ez adierazten duena. Beraz, momentu honen jarraipena egiteko aukera dugu.
Galdera: JSON hautsita idazten al duzu?
Erantzun: hautsitako JSON baztertu egingo da erreleboan paketea handiegia delako. Edo Graylog baztertu egingo da ezin duelako JSON analizatu. Baina badira konpondu beharreko ñabardurak, eta gehienbat rsyslog-i lotuta daude. Dagoeneko hainbat gai bete ditut bertan, oraindik landu beharrekoak.
Galdera: Zergatik Kafka? RabbitMQ probatu al duzu? Graylog-ek huts egiten al du horrelako kargapean?
Erantzun: Ez zaigu funtzionatzen Graylog-ekin. Eta Graylog forma hartzen ari da guretzat. Benetan problematikoa da. Gauza berezi bat da. Eta, egia esan, ez da beharrezkoa. Nahiago nuke rsyslog-etik zuzenean elasticsearch-era idatzi eta gero Kibana begiratu. Baina arazoa segurtasun zaindariekin konpondu behar dugu. Hau gure garapenerako aukera posible bat da, Graylog bota eta Kibana erabiltzen dugunean. Logstash erabiltzeak ez du balio. rsyslog-ekin gauza bera egin dezakedalako. Eta elastikoan idazteko modulu bat dauka. Graylog-ekin nolabait bizitzen saiatzen ari gara. Apur bat afinatu ere egin dugu. Baina oraindik badago zer hobetu.
Kafkari buruz. Horrela gertatu zen historikoki. Iritsi nintzenean, hor zegoen jada, eta erregistroak idazten ari zitzaizkion. Besterik gabe, gure klusterra igo eta erregistroak bertara eraman ditugu. Gu gara bere zuzendaritza, badakigu nola sentitzen den. RabbitMQ-ri dagokionez... ez zaigu funtzionatzen RabbitMQ-rekin. Eta RabbitMQ forma hartzen ari da guretzat. Ekoizpenean daukagu, eta arazoak izan zituen. Orain, salmenta aurretik, xarma egingo zuten, eta normaltasunez hasiko zen lanean. Baina aurretik ez nengoen prest produkziora ateratzeko. Puntu bat gehiago dago. Graylog-ek AMQP 0.9 bertsioa irakur dezake eta rsyslog-ek AMQP 1.0 bertsioa idatz dezake. Eta erdian ez dago biak egin ditzakeen irtenbide bakarra. Bata ala bestea da. Horregatik, momentuz Kafka bakarrik. Baina bere ñabardurak ere baditu. Erabiltzen dugun rsyslog-en bertsioaren omkafkak rsyslog-etik ateratako mezu-buffer osoa gal dezakeelako. Oraingoz jasaten dugu.
Galdera: Kafka erabiltzen ari al zara dagoeneko bazenuelako? Jada ez da ezertarako erabiltzen?
Erantzun: Kafka, zena, Data Science taldeak erabiltzen du. Guztiz aparteko proiektu bat da hau, eta horri buruz, zoritxarrez, ezin dut ezer esan. Ez dakit. Data Science taldeak zuzendu zuen. Erregistroak sortu zirenean, gurea ez instalatzeko erabiltzea erabaki genuen. Orain Graylog eguneratu dugu, eta bateragarritasuna galdu dugu Kafkaren bertsio zaharra duelako. Gurea hasi behar genuen. Aldi berean, lau gai hauek kendu genituen API bakoitzeko. Zuzeneko guztientzako gai zabal bat egin genuen, eszenaratze guztientzako gai zabal bat eta dena jarri genuen. Graylog-ek hau guztia paraleloki kentzen du.
Galdera: Zergatik behar dugu entxufedun xamanismo hau? Edukiontzietarako syslog log kontrolatzailea erabiltzen saiatu al zara?
Erantzun: Galdera hau egin genuen garaian, atrakatzailearekin genuen harremana tirabiratsua zen. Docker 1.0 edo 0.9 zen. Docker bera arraroa zen. Bigarrenik, erregistroak ere sartzen badituzu... Egiaztatu gabeko susmoa daukat erregistro guztiak beretik pasatzen dituela, docker daemonaren bidez. API bat erotzen bada, gainerako APIak ezin dituzte stdout eta stderr bidali. Ez dakit nora eramango duen honek. Susmoa dut leku honetan Docker syslog kontrolatzailea erabili beharrik ez dagoelako sentsazio mailan. Gure proba funtzionalen sailak bere Graylog kluster propioa du erregistroekin. Docker log kontrolatzaileak erabiltzen dituzte eta dena ondo dagoela dirudi. Baina berehala idazten diote GELF Graylog-i. Hau guztia hasi genuen garaian, funtzionatzeko besterik ez genuen behar. Agian gerora, norbait etortzen denean ehun urte ondo funtzionatzen duela esaten duenean, saiatuko gara.
Galdera: Datu-zentroen arteko entrega egiten duzu rsyslog erabiliz. Zergatik ez Kafka?
Erantzun: Biak egiten ditugu egia esan. Bi arrazoirengatik. Kanala guztiz hilda badago, gure erregistro guztiak, forma konprimituta ere, ez dira bertatik arakatuko. Eta Kafkak prozesuan galtzeko aukera ematen dizu. Horrela kentzen ditugu erregistro horiek trabatuta. Kafka zuzenean erabiltzen ari gara kasu honetan. Kanal on bat badugu eta askatu nahi badugu, haien rsyslog erabiltzen dugu. Baina, hain zuzen ere, konfigura dezakezu berak sartzen ez zena jar dezan. Momentuz, rsyslog bidalketa zuzenean nonbait erabiltzen dugu, eta Kafka nonbait.
Iturria: www.habr.com