Regjistrat janë një pjesë e rëndësishme e sistemit, duke ju lejuar të kuptoni se funksionon (ose nuk funksionon) siç pritej. Në kushtet e arkitekturës së mikroshërbimeve, puna me shkrime bëhet një disiplinë më vete e Olimpiadës Speciale. Ka shumë çështje që duhen trajtuar:
- si të shkruani regjistrat nga aplikacioni;
- ku të shkruani regjistrat;
- si të dorëzohen regjistrat për ruajtje dhe përpunim;
- si të përpunohen dhe ruhen regjistrat.
Përdorimi i teknologjive aktualisht të njohura të kontejnerizimit shton rërën në majë të grabujës në fushën e opsioneve të zgjidhjes së problemeve.
Pikërisht për këtë është transkripti i raportit të Yuri Bushmelev "Harta e një grabujë në fushën e mbledhjes dhe dorëzimit të trungjeve"
Kush kujdeset, ju lutem nën mace.
Emri im është Yuri Bushmelev. Unë punoj për Lazada. Sot do të flas se si i kemi bërë shkrimet tona, si i kemi mbledhur dhe çfarë shkruajmë atje.
Nga jemi ne? Kush jemi ne? Lazada është shitësi numër 1 në internet në gjashtë vende në Azinë Juglindore. Të gjitha këto vende shpërndahen midis qendrave të të dhënave. Tani ka gjithsej 4 qendra të dhënash Pse është e rëndësishme kjo? Sepse disa vendime ishin për faktin se ka një lidhje shumë të dobët mes qendrave. Ne kemi një arkitekturë mikroservice. U befasova kur zbulova se tashmë kemi 80 mikroshërbime. Kur fillova detyrën me shkrimet, ishin vetëm 20. Plus, ekziston një pjesë mjaft e madhe e trashëgimisë së PHP-së, me të cilën gjithashtu duhet të jetoj dhe ta përballoj. E gjithë kjo gjeneron për ne për momentin më shumë se 6 milionë mesazhe në minutë për sistemin në tërësi. Më tej do të tregoj se si po përpiqemi të jetojmë me këtë, dhe pse është kështu.
Duhet të jetosh me këto 6 milionë mesazhe disi. Çfarë duhet të bëjmë me ta? Nevojiten 6 milionë mesazhe:
- dërgoni nga aplikacioni
- pranoni për dorëzim
- dorëzojë për analizë dhe ruajtje.
- për të analizuar
- ruaj disi.
Kur kishte tre milionë mesazhe, unë kisha pothuajse të njëjtin pamje. Sepse filluam me ca qindarka. Është e qartë se regjistrat e aplikacioneve janë shkruar atje. Për shembull, nuk mund të lidhej me bazën e të dhënave, mund të lidhej me bazën e të dhënave, por nuk mund të lexonte diçka. Por përveç kësaj, secili nga mikroshërbimet tona shkruan gjithashtu një regjistër aksesi. Çdo kërkesë që arrin në mikroshërbim bie në regjistër. Pse po e bëjmë këtë? Zhvilluesit duan të jenë në gjendje të gjurmojnë. Çdo regjistër i aksesit përmban fushën traceid, sipas së cilës një ndërfaqe speciale më pas hap të gjithë zinxhirin dhe shfaq bukur gjurmën. Gjurma tregon se si shkoi kërkesa dhe kjo i ndihmon zhvilluesit tanë të merren më shpejt me çdo mbeturinë të panjohur.
Si të jetoni me të? Tani do të përshkruaj shkurtimisht fushën e opsioneve - si zgjidhet përgjithësisht ky problem. Si të zgjidhni problemin e mbledhjes, transferimit dhe ruajtjes së trungjeve.
Si të shkruani nga aplikacioni? Është e qartë se ka mënyra të ndryshme. Në veçanti, ekziston praktika më e mirë, siç na thonë shokët e modës. Ka dy lloje shkollash të vjetra, siç thoshin gjyshërit. Ka mënyra të tjera.
Me mbledhjen e trungjeve, situata është përafërsisht e njëjtë. Nuk ka aq shumë opsione për zgjidhjen e kësaj pjese të veçantë. Ka më shumë prej tyre, por ende jo aq shumë.
Por me dorëzimin dhe analizën pasuese, numri i variacioneve fillon të shpërthejë. Unë nuk do të përshkruaj çdo opsion tani. Unë mendoj se opsionet kryesore janë të njohura për të gjithë ata që ishin të interesuar për këtë temë.
Unë do t'ju tregoj se si e bëmë atë në Lazada dhe si filloi gjithçka.
Një vit më parë erdha në Lazada dhe më dërguan në projektin e log. Kështu ishte atje. Regjistri nga aplikacioni u shkrua në stdout dhe stderr. Gjithçka ishte bërë në një mënyrë në modë. Por më pas zhvilluesit e hodhën atë nga rrymat standarde, dhe më pas specialistët e infrastrukturës do ta kuptojnë disi. Midis specialistëve të infrastrukturës dhe zhvilluesve, ka edhe lëshues që thanë: "uh ... mirë, le t'i mbështjellim në një skedar me një guaskë dhe kaq." Dhe meqenëse e gjithë kjo është në një enë, ata e mbështjellën atë në vetë kontejnerin, hartuan direktorinë brenda dhe e vendosën atje. Mendoj se është shumë e qartë për të gjithë se çfarë ndodhi.
Le të shohim pak më tej. Si i kemi dorëzuar këto regjistra. Dikush zgjodhi td-agent, i cili në fakt është i rrjedhshëm, por jo mjaft i rrjedhshëm. Ende nuk e kuptoj marrëdhënien e këtyre dy projekteve, por duket se kanë të bëjnë me të njëjtën gjë. Dhe ky i rrjedhshëm, i shkruar në Ruby, lexoi skedarë log, i analizoi ato në JSON duke përdorur disa shprehje të rregullta. Pastaj u dërguan te Kafka. Për më tepër, në Kafka, ne kishim 4 tema të veçanta për çdo API. Pse 4? Sepse ka live, ka skenë, dhe sepse ka stdout dhe stderr. Zhvilluesit i prodhojnë ato dhe punonjësit e infrastrukturës duhet t'i krijojnë ato në Kafka. Për më tepër, Kafka kontrollohej nga një departament tjetër. Prandaj, ishte e nevojshme të krijohej një biletë në mënyrë që ata të krijonin 4 tema atje për çdo api. Të gjithë e harruan. Në përgjithësi, ishte plehra dhe mbeturina.
Çfarë bëmë më pas me të? E dërguam te kafka. Më tej nga Kafka, gjysma e trungjeve fluturuan në Logstash. Gjysma tjetër e shkrimeve u nda. Disa fluturuan në një Graylog, disa në një tjetër Graylog. Si rezultat, e gjithë kjo fluturoi në një grup Elasticsearch. Domethënë, e gjithë kjo rrëmujë ra në fund aty. Nuk duhet ta bëni këtë!
Kështu duket kur shikohet nga lart. Nuk duhet ta bëni këtë! Këtu, zonat problematike shënohen menjëherë me numra. Në fakt ka më shumë prej tyre, por 6 janë vërtet problematike, me të cilat duhet bërë diçka. Tani do të tregoj veçmas për to.
Këtu (1,2,3) ne shkruajmë skedarë dhe, në përputhje me rrethanat, ka tre raketa këtu menjëherë.
E para (1) është se duhet t'i shkruajmë diku. Nuk është gjithmonë e dëshirueshme t'i jepet një API aftësinë për të shkruar drejtpërdrejt në një skedar. Është e dëshirueshme që API të jetë i izoluar në një enë, dhe akoma më mirë, që të jetë vetëm për lexim. Unë jam një administrator sistemi, kështu që kam një pikëpamje paksa alternative për këto gjëra.
Pika e dytë (2,3) është se kemi shumë kërkesa që vijnë në API. API shkruan shumë të dhëna në një skedar. Dosjet po rriten. Ne duhet t'i rrotullojmë ato. Sepse përndryshe nuk do të mund të ruani asnjë disk atje. Rrotullimi i tyre është i keq sepse ato ridrejtohen nëpërmjet shell-it në një drejtori. Nuk ka asnjë mënyrë që ta rrotullojmë. Nuk mund t'i thuash aplikacionit të rihapë dorezat. Sepse zhvilluesit do t'ju shikojnë si një budalla: "Çfarë përshkruesish? Ne përgjithësisht i shkruajmë stdout. Kornizat e bëra copytruncate në logrotate, e cila thjesht bën një kopje të skedarit dhe trunkon origjinalin. Prandaj, midis këtyre proceseve të kopjimit, hapësira në disk zakonisht mbaron.
(4) Ne kishim formate të ndryshme në API të ndryshme. Ato ishin paksa të ndryshme, por regexp duhej të shkruhej ndryshe. Meqenëse gjithçka menaxhohej nga Puppet, kishte një grup të madh klasash me buburrecat e tyre. Plus, td-agent shumicën e kohës mund të hante kujtesën, të ishte budalla, ai thjesht mund të pretendonte se po punonte dhe nuk bënte asgjë. Nga pamja e jashtme, ishte e pamundur të kuptoje se ai nuk po bënte asgjë. Në rastin më të mirë, ai do të bjerë dhe dikush do ta marrë më vonë. Më saktësisht, një alarm do të fluturojë brenda dhe dikush do të shkojë ta ngrejë me duar.
(6) Dhe më së shumti mbeturina dhe mbeturina - ishte kërkimi i elastikës. Sepse ishte një version i vjetër. Sepse ne nuk kishim mjeshtër të përkushtuar në atë kohë. Ne kishim regjistra heterogjenë, fushat e të cilëve mund të mbivendosen. Regjistra të ndryshëm të aplikacioneve të ndryshme mund të shkruhen me emra të njëjtë fushash, por në të njëjtën kohë mund të ketë të dhëna të ndryshme brenda. Kjo do të thotë, një regjistër vjen me një numër të plotë në një fushë, për shembull, nivel. Një regjistër tjetër vjen me një varg në fushën e nivelit. Në mungesë të hartës statike, rezulton një gjë kaq e mrekullueshme. Nëse, pas rrotullimit të indeksit, një mesazh me një varg mbërriti i pari në elasticsearch, atëherë ne jetojmë normalisht. Dhe nëse i pari mbërriti me Integer, atëherë të gjitha mesazhet pasuese që mbërritën me String thjesht hidhen poshtë. Sepse lloji i fushës nuk përputhet.
Ne filluam t'i bënim këto pyetje. Ne vendosëm të mos kërkonim fajtorët.
Por diçka duhet bërë! Gjëja e qartë është se ne duhet të vendosim standarde. Tashmë kishim disa standarde. Disa i sollëm pak më vonë. Për fat të mirë, një format i vetëm regjistri për të gjitha API-të ishte miratuar tashmë në atë kohë. Është shkruar drejtpërdrejt në standardet e ndërveprimit të shërbimit. Prandaj, ata që duan të marrin regjistrat duhet t'i shkruajnë ato në këtë format. Nëse dikush nuk shkruan regjistra në këtë format, atëherë ne nuk garantojmë asgjë.
Më tej, do të doja të kisha një standard të vetëm për metodat e regjistrimit, dërgimit dhe mbledhjes së regjistrave. Në fakt, ku t'i shkruani ato dhe si t'i dorëzoni ato. Situata ideale është kur projektet përdorin të njëjtën bibliotekë. Ekziston një bibliotekë e veçantë regjistrimi për Go, ka një bibliotekë të veçantë për PHP. Të gjithë ne kemi, të gjithë duhet t'i përdorin. Për momentin do të thosha se po ia dalim me 80 për qind. Por disa vazhdojnë të hanë kaktus.
Dhe atje (në rrëshqitje) "SLA për dorëzimin e regjistrave" mezi po fillon të shfaqet. Nuk është ende aty, por ne jemi duke punuar për të. Sepse është shumë i përshtatshëm kur infra thotë se nëse shkruani në atë format në filan vend dhe jo më shumë se N mesazhe në sekondë, atëherë me shumë mundësi do t'i dërgojmë atje. Ai largon shumë dhimbje koke. Nëse ka një SLA, atëherë është thjesht e mrekullueshme!
Si e filluam zgjidhjen e problemit? Grabujë kryesore ishte me td-agent. Ishte e paqartë se ku shkojnë shkrimet tona. A janë dorëzuar? A po shkojnë? Ku janë ata gjithsesi? Prandaj, u vendos që të zëvendësohet td-agent me artikullin e parë. Opsionet se me çfarë të zëvendësohet, i përshkrova shkurtimisht këtu.
I rrjedhshëm. Së pari, e takova në një punë të mëparshme, dhe ai gjithashtu binte periodikisht atje. Së dyti, kjo është e njëjtë, vetëm në profil.
filebeat. Si ishte mirë për ne? Fakti që ai është në Go, dhe ne kemi një ekspertizë të madhe në Go. Prandaj, nëse ka ndonjë gjë, ne mund ta shtojmë disi vetes. Prandaj nuk e morëm. Kështu që të mos kishte as ndonjë tundim për të filluar ta rishkruani për veten tuaj.
Zgjidhja e dukshme për sysadmin është të gjitha llojet e syslog-ve në këtë sasi (syslog-ng/rsyslog/nxlog).
Ose shkruani diçka tuajën, por ne e hodhëm atë, si dhe filebeat. Nëse shkruani diçka, atëherë është më mirë të shkruani diçka të dobishme për biznesin. Për të dorëzuar shkrimet, është më mirë të marrësh diçka të gatshme.
Prandaj, zgjedhja në të vërtetë zbriti në një zgjedhje midis syslog-ng dhe rsyslog. Unë u anova drejt rsyslog thjesht sepse ne kishim tashmë klasa për rsyslog në Puppet, dhe nuk gjeta një ndryshim të dukshëm midis tyre. Çfarë është syslog, çfarë është syslog. Po, disa dokumente janë më të këqija, disa më të mira. Ai e di këtë mënyrë dhe e bën ndryshe.
Dhe pak për rsyslog. Së pari, është mirë sepse ka shumë module. Ka një RainerScript (gjuhë moderne të konfigurimit) të lexueshme nga njeriu. Një bonus i mrekullueshëm është se ne mund të imitojmë sjelljen e td-agent me mjetet e tij standarde dhe asgjë nuk ka ndryshuar për aplikacionet. Kjo do të thotë, ne ndryshojmë td-agent në rsyslog dhe nuk prekim akoma gjithçka tjetër. Dhe menjëherë marrim një dërgesë pune. Tjetra, mmnormalize është gjëja interesante në lidhje me rsyslog. Ju lejon të analizoni regjistrat, por jo me Grok dhe regexp. Krijon një pemë sintakse abstrakte. Ai analizon regjistrat në të njëjtën mënyrë që një përpilues analizon kodin burimor. Kjo ju lejon të punoni shumë shpejt, të hani pak CPU dhe, në përgjithësi, është thjesht një gjë shumë e lezetshme. Ka një mori bonusesh të tjera. Unë nuk do të ndalem në to.
rsyslog ka shumë më tepër disavantazhe. Ato janë pothuajse të njëjta me bonuset. Problemet kryesore janë se ju duhet të jeni në gjendje ta gatuani atë dhe duhet të zgjidhni një version.
Ne vendosëm që të shkruanim regjistrat në një fole unix. Dhe jo në /dev/log, sepse atje kemi një rrëmujë të regjistrave të sistemit, ka ditar në këtë tubacion. Pra, le të shkruajmë në një prizë të personalizuar. Ne do t'ia bashkëngjisim një grup rregullash të veçantë. Të mos ndërhyjmë me asgjë. Gjithçka do të jetë transparente dhe e kuptueshme. Kështu që ne në fakt bëmë. Drejtoria me këto priza standardizohet dhe përcillet në të gjithë kontejnerët. Kontejnerët mund të shohin prizën që u nevojitet, të hapin dhe të shkruajnë në të.
Pse jo një skedar? Sepse të gjithë kanë lexuar , i cili u përpoq ta përcjellë skedarin te docker dhe zbuloi se pas rinisjes së rsyslog, përshkruesi i skedarit ndryshon dhe docker e humb këtë skedar. Ai mban hapur diçka tjetër, por jo të njëjtën fole ku shkruajnë. Ne vendosëm që ta anashkalojmë këtë problem dhe, në të njëjtën kohë, të anashkalojmë problemin e bllokimit.
Rsyslog bën veprimet e treguara në rrëshqitje dhe i dërgon regjistrat ose te stafeta ose te Kafka. Kafka ndjek rrugën e vjetër. Rayleigh - Unë u përpoqa të përdor rsyslog të pastër për të ofruar regjistra. Pa radhë mesazhesh, duke përdorur mjete standarde rsyslog. Në thelb, funksionon.
Por ka nuanca se si t'i futni ato më vonë në këtë pjesë (Logstash/Graylog/ES). Kjo pjesë (rsyslog-rsyslog) përdoret ndërmjet qendrave të të dhënave. Këtu është një lidhje e ngjeshur tcp, e cila ju lejon të kurseni gjerësinë e brezit dhe, në përputhje me rrethanat, të rrisni disi gjasat që të marrim disa regjistra nga një qendër tjetër e të dhënave kur kanali të jetë plot. Sepse ne kemi Indonezinë, ku gjithçka është e keqe. Këtu qëndron problemi i vazhdueshëm.
Menduam se si monitorojmë në të vërtetë, me çfarë probabiliteti logët që kemi regjistruar nga aplikacioni arrijnë deri në atë fund? Ne vendosëm të fillojmë metrikën. Rsyslog ka modulin e vet të mbledhjes së statistikave, i cili ka një lloj numëruesi. Për shembull, mund t'ju tregojë madhësinë e radhës ose sa mesazhe kanë ardhur për një veprim të tillë. Ju tashmë mund të merrni diçka prej tyre. Plus, ai ka numërues të personalizuar që mund t'i konfiguroni dhe do t'ju tregojë, për shembull, numrin e mesazheve që ka regjistruar disa API. Më pas, shkrova rsyslog_exporter në Python, dhe ia dërguam të gjitha Prometheusit dhe komplotuam. Ne i donim vërtet matjet e Graylog, por deri më tani nuk kemi pasur kohë për t'i vendosur ato.
Cilat janë problemet? Problemi lindi me faktin se ne zbuluam (PAPAS!) se API-të tona të drejtpërdrejta shkruajnë 50 mijë mesazhe në sekondë. Kjo është vetëm API e drejtpërdrejtë pa skenë. Dhe Graylog na tregon vetëm 12 mijë mesazhe në sekondë. Dhe lindi një pyetje e arsyeshme, ku janë mbetjet? Nga e cila arritëm në përfundimin se Graylog thjesht nuk mund ta përballojë. Ne shikuam dhe, me të vërtetë, Graylog me Elasticsearch nuk e zotëroi këtë rrjedhë.
Më pas, zbulime të tjera që kemi bërë gjatë rrugës.
Shkrimet në prizë janë të bllokuara. Si ndodhi? Kur përdora rsyslog për dorëzim, në një moment ne thyem kanalin midis qendrave të të dhënave. Dorëzimi u ngrit në një vend, dorëzimi u ngrit në një vend tjetër. E gjithë kjo ka ardhur në një makinë me API që shkruajnë në folenë rsyslog. Kishte një radhë. Pastaj u mbush radha për të shkruar në folenë unix, e cila si parazgjedhje është 128 pako. Dhe shkrimi tjetër () në blloqet e aplikacionit. Kur shikuam bibliotekën që përdorim në aplikacionet Go, aty ishte shkruar se shkrimi në prizë ndodh në modalitetin jo bllokues. Ishim të sigurt që asgjë nuk ishte bllokuar. Sepse ne kemi lexuar i cili shkroi për të. Por ka një moment. Kishte gjithashtu një lak të pafund rreth kësaj thirrjeje, në të cilën kishte një përpjekje të vazhdueshme për të futur një mesazh në prizë. Nuk e vumë re. Më duhej të rishkruaja bibliotekën. Që atëherë, ajo ka ndryshuar disa herë, por tani ne kemi hequr qafe flokët në të gjitha nënsistemet. Prandaj, mund të ndaloni rsyslog dhe asgjë nuk do të bjerë.
Është e nevojshme të monitorohet madhësia e radhëve, gjë që ndihmon për të mos shkelur këtë grabujë. Së pari, ne mund të monitorojmë kur fillojmë të humbasim mesazhet. Së dyti, ne mund të monitorojmë që në thelb kemi probleme me dorëzimin.
Dhe një moment tjetër i pakëndshëm - amplifikimi me 10 herë në një arkitekturë mikroservice është shumë i lehtë. Ne nuk kemi kaq shumë kërkesa hyrëse, por për shkak të grafikut përgjatë të cilit këto mesazhe shkojnë më tej, për shkak të regjistrave të aksesit, ne në fakt e rrisim ngarkesën në regjistra me rreth dhjetë herë. Fatkeqësisht, nuk pata kohë për të llogaritur numrat e saktë, por mikroshërbimet janë ato që janë. Kjo duhet mbajtur parasysh. Rezulton se për momentin nënsistemi i mbledhjes së regjistrave është më i ngarkuari në Lazada.
Si të zgjidhni problemin e kërkimit elastics? Nëse ju duhet të merrni me shpejtësi regjistrat në një vend, në mënyrë që të mos kaloni nëpër të gjitha makinat dhe t'i mblidhni ato atje, përdorni ruajtjen e skedarëve. Kjo është e garantuar për të punuar. Bëhet nga çdo server. Ju vetëm duhet të ngjitni disqe atje dhe të vendosni syslog. Pas kësaj, ju jeni të garantuar që të keni të gjitha shkrimet në një vend. Atëherë do të jetë e mundur të konfiguroni ngadalë elasticsearch, graylog ose diçka tjetër. Por ju tashmë do t'i keni të gjitha regjistrat dhe, për më tepër, mund t'i ruani ato, për aq sa ka mjaft grupe disqesh.
Në momentin e raportimit tim, skema filloi të dukej kështu. Praktikisht ndaluam së shkruari në dosje. Tani, ka shumë të ngjarë, ne do të fikim mbetjet. Në makinat lokale që ekzekutojnë API, ne do të ndalojmë së shkruari në skedarë. Së pari, ekziston ruajtja e skedarëve, e cila funksionon shumë mirë. Së dyti, këtyre makinave u mbaron vazhdimisht hapësira, duhet ta monitoroni vazhdimisht.
Kjo pjesë me Logstash dhe Graylog, ajo me të vërtetë fluturon. Prandaj, duhet ta heqësh qafe atë. Ju duhet të zgjidhni një.
Ne vendosëm të heqim Logstash dhe Kibana. Sepse ne kemi një departament sigurie. Cila është lidhja? Lidhja është se Kibana pa X-Pack dhe pa Shield nuk ju lejon të dalloni të drejtat e aksesit në regjistrat. Prandaj, ata morën Graylog. I ka të gjitha. Nuk më pëlqen, por funksionon. Ne blemë pajisje të reja, instaluam një Graylog të freskët atje dhe i zhvendosëm të gjitha regjistrat me formate strikte në një Graylog të veçantë. Ne e kemi zgjidhur problemin me lloje të ndryshme të të njëjtave fusha në mënyrë organizative.
Çfarë saktësisht përfshihet në Graylog të ri. Ne thjesht shkruam gjithçka në doker. Ne morëm një mori serverësh, shpalosëm tre shembuj të Kafkës, 7 serverë Graylog versionin 2.3 (sepse doja versionin 5 të Elasticsearch). E gjithë kjo u ngrit në bastisjet nga HDD. Ne pamë një normë indeksimi deri në 100 mijë mesazhe në sekondë. Ne pamë shifrën që 140 terabajt të dhëna në javë.
Dhe përsëri një grabujë! Kemi dy shitje që vijnë. Ne kemi lëvizur përtej 6 milionë postimeve. Ne Graylog nuk kemi kohë për të përtypur. Disi ju duhet të mbijetoni përsëri.
Kështu mbijetuam. U shtuan disa serverë të tjerë dhe SSD. Për momentin jetojmë kështu. Tani ne po përtypim 160 mijë mesazhe në sekondë. Ne nuk e kemi arritur ende kufirin, kështu që është e paqartë se sa mund të dalim realisht prej tij.
Këto janë planet tona për të ardhmen. Nga këto, me të vërtetë, më e rëndësishmja është ndoshta disponueshmëria e lartë. Nuk e kemi akoma. Disa makina janë të vendosura në të njëjtën mënyrë, por deri më tani gjithçka kalon përmes një makine. Është e nevojshme të shpenzoni kohë për të vendosur një dështim midis tyre.
Mblidhni metrikë nga Graylog.
Bëni një kufi të tarifës në mënyrë që të kemi një API të çmendur që nuk na vret gjerësinë e brezit dhe gjithçka tjetër.
Dhe së fundi, nënshkruani një lloj SLA me zhvilluesit në mënyrë që ne të mund të shërbejmë aq shumë. Nëse shkruani më shumë, atëherë më falni.
Dhe shkruani dokumentacionin.
Shkurtimisht, rezultatet e gjithçkaje që kemi përjetuar. Së pari, standardet. Së dyti, syslog është tortë. Së treti, rsyslog funksionon saktësisht siç është shkruar në rrëshqitje. Dhe le të kalojmë te pyetjet.
Pyetjet tuaja.
Pyetje: Pse vendosën të mos merrnin ... (filebeat?)
Përgjigjem: Duhet të shkruani në një skedar. Unë me të vërtetë nuk doja. Kur API juaj shkruan mijëra mesazhe në sekondë, edhe nëse rrotulloheni një herë në orë, ky nuk është ende një opsion. Ju mund të shkruani në tub. Për të cilën zhvilluesit më pyetën: "Çfarë do të ndodhë nëse procesi në të cilin ne shkruajmë bie"? Thjesht nuk gjeta se çfarë t'u përgjigjesha dhe thashë: "Epo, mirë, le të mos e bëjmë këtë."
Pyetje: Pse nuk shkruani regjistra në HDFS?
PërgjigjemPërgjigje: Ky është hapi tjetër. Ne e kemi menduar që në fillim, por meqenëse nuk ka burime për t'u marrë me të për momentin, kjo varet nga zgjidhja jonë afatgjatë.
Pyetje: Një format kolone do të ishte më i përshtatshëm.
Përgjigjem: E kuptoj. Jemi “për” me të dyja duart.
Pyetje: Ju shkruani në rsyslog. Të dy TCP dhe UDP janë të disponueshme atje. Por nëse UDP, atëherë si e garantoni dorëzimin?
PërgjigjemPërgjigje: Ka dy pika. Së pari, menjëherë u them të gjithëve se ne nuk garantojmë dorëzimin e shkrimeve. Sepse kur zhvilluesit vijnë dhe thonë: "Le të fillojmë të shkruajmë të dhëna financiare atje, dhe ju do t'i vendosni diku për ne në rast se ndodh diçka", ne u përgjigjemi atyre, "Shkëlqyeshëm! Le të fillojmë të bllokojmë për të shkruar në prizë, dhe ta bëjmë atë në transaksione, në mënyrë që të jeni të garantuar ta vendosni në prizë për ne dhe të siguroheni që e kemi marrë nga ana tjetër. Dhe në këtë moment, të gjithë bëhen menjëherë të panevojshëm. Dhe nëse jo, atëherë çfarë pyetjesh kemi? Nëse nuk dëshironi të garantoni një shkrim në prizë, atëherë pse do të garantonim dorëzimin? Ne po bëjmë përpjekjet më të mira. Ne vërtet përpiqemi të ofrojmë sa më shumë dhe sa më mirë të jetë e mundur, por nuk japim garanci 100%. Prandaj, nuk keni nevojë të shkruani të dhëna financiare atje. Ekzistojnë baza të të dhënave transaksionale për këtë.
Pyetje: Kur API gjeneron një mesazh në regjistër dhe transferon kontrollin te mikroshërbimet, a keni hasur problemin që mesazhet nga mikroshërbime të ndryshme mbërrijnë në rendin e gabuar? Për shkak të kësaj, lind konfuzioni.
PërgjigjemPërgjigje: Është normale që ato vijnë në një mënyrë tjetër. Ju duhet të jeni gati për këtë. Sepse çdo dërgesë në rrjet nuk garanton porosinë për ju, ose ju duhet të shpenzoni burime të veçanta për këtë. Nëse marrim ruajtjen e skedarëve, atëherë çdo API ruan regjistrat në skedarin e vet. Përkundrazi, rsyslog i zbërthen ato në drejtori atje. Çdo API ka regjistrat e vet atje, ku mund të shkoni dhe të shikoni, dhe më pas mund t'i krahasoni ato duke përdorur vulën kohore në këtë regjistër. Nëse shkojnë të shikojnë në Graylog, atëherë atje do të renditen sipas vulës kohore. Gjithçka do të jetë mirë atje.
Pyetje: Vula kohore mund të ndryshojë nga milisekonda.
Përgjigjem: Vula kohore krijohet nga vetë API. Kjo, në fakt, është e gjithë çështja. Ne kemi NTP. API gjeneron një vulë kohore tashmë në vetë mesazhin. Nuk shtohet nga rsyslog.
Pyetje: Ndërveprimi ndërmjet qendrave të të dhënave nuk është shumë i qartë. Brenda kuadrit të qendrës së të dhënave, është e qartë se si janë mbledhur dhe përpunuar regjistrat. Si është ndërveprimi ndërmjet qendrave të të dhënave? Apo çdo qendër të dhënash jeton jetën e vet?
Përgjigjem: Pothuajse. Ne kemi çdo vend të vendosur në një qendër të dhënash. Aktualisht nuk kemi përhapje, në mënyrë që një shtet të vendoset në qendra të ndryshme të dhënash. Prandaj, nuk ka nevojë t'i kombinoni ato. Brenda çdo qendre ka një rele të regjistrit. Ky është një server Rsyslog. Në fakt, dy makina menaxhimi. Ata janë vendosur në të njëjtën mënyrë. Por tani për tani, trafiku kalon përmes njërit prej tyre. Ajo regjistron gjithçka agregat. Ka një radhë disku për çdo rast. Ajo shtyp regjistrat dhe i dërgon në qendrën qendrore të të dhënave (Singapore), ku më tej ata tashmë janë helmuar në Graylog. Dhe çdo qendër e të dhënave ka ruajtjen e vet të skedarëve. Në rast se kemi humbur lidhjen, ne i kemi të gjitha regjistrat atje. Ata do të qëndrojnë atje. Ato do të ruhen atje.
Pyetje: A merrni trungje nga atje gjatë situatave jonormale?
Përgjigjem: Mund të shkoni atje (në ruajtjen e skedarëve) dhe të shikoni.
Pyetje: Si monitoroni që të mos humbisni shkrimet?
Përgjigjem: Në fakt po i humbasim dhe po e monitorojmë. Monitorimi ka nisur një muaj më parë. Biblioteka që përdorin API-të Go ka metrikë. Ajo mund të numërojë sa herë nuk arriti të shkruante në prizë. Për momentin ekziston një heuristikë e ndërlikuar. Aty ka një tampon. Ai përpiqet të shkruajë një mesazh nga ai në prizë. Nëse buferi tejmbush, ai fillon t'i hedhë ato. Dhe numëron sa i ka lëshuar. Nëse sportelet fillojnë të vërshojnë atje, do ta dimë. Ata tani po vijnë edhe te Prometheus, dhe grafikët mund t'i shihni në Grafana. Mund të konfiguroni sinjalizime. Por ende nuk është e qartë se kujt t'i dërgojnë ato.
Pyetje: Në elasticsearch, ju ruani shkrimet me tepricë. Sa kopje keni?
Përgjigjem: Një kopje.
Pyetje: Është vetëm një rresht?
Përgjigjem: Ky është mjeshtri dhe kopja. Të dhënat ruhen në dublikatë.
Pyetje: A e rregulluat disi madhësinë e tamponit rsyslog?
Përgjigjem: Ne shkruajmë datagrame në një prizë unix të personalizuar. Kjo menjëherë na imponon një kufizim prej 128 kilobajt. Nuk mund të shkruajmë më shumë për të. Ne e kemi shkruar këtë në standard. Kush dëshiron të futet në ruajtje, ata shkruajnë 128 kilobajt. Bibliotekat, për më tepër, ndërpresin dhe vendosin një flamur se mesazhi është i prerë. Ne kemi një fushë të veçantë në standardin e vetë mesazhit, e cila tregon nëse është ndërprerë gjatë regjistrimit apo jo. Kështu që ne kemi mundësinë të gjurmojmë këtë moment.
Pyetje: A shkruani JSON të thyer?
Përgjigjem: JSON i prishur do të hidhet poshtë ose gjatë transmetimit sepse paketa është shumë e madhe. Ose Graylog do të hiqet, sepse nuk do të jetë në gjendje të analizojë JSON. Por këtu ka nuanca që duhen rregulluar, dhe ato kryesisht janë të lidhura me rsyslog. Aty kam plotësuar tashmë disa numra, për të cilat ende duhet të punohet.
Pyetje: Pse Kafka? E keni provuar RabbitMQ? Graylog nuk shtohet nën ngarkesa të tilla?
Përgjigjem: Nuk shkon me Graylog. Dhe Graylog po merr formë. Është vërtet problematike për të. Ai është një lloj gjëje. Dhe, në fakt, nuk është e nevojshme. Më mirë do të shkruaj nga rsyslog direkt në elasticsearch dhe më pas të shikoj Kibana. Por ne duhet ta zgjidhim çështjen me rojet e sigurisë. Ky është një variant i mundshëm i zhvillimit tonë kur hedhim Graylog dhe përdorim Kibana. Logstash nuk do të ketë kuptim. Sepse mund të bëj të njëjtën gjë me rsyslog. Dhe ka një modul për të shkruar në elasticsearch. Me Graylog ne po përpiqemi të jetojmë disi. Madje e ndryshuam pak. Por ka ende vend për përmirësim.
Rreth Kafkës. Kështu ndodhi historikisht. Kur mbërrita, ajo ishte tashmë aty dhe tashmë po shkruheshin regjistra. Ne sapo ngritëm grupin tonë dhe zhvendosëm shkrimet në të. Ne e menaxhojmë atë, e dimë se si ndihet. Sa për RabbitMQ... ne kemi probleme me RabbitMQ. Dhe RabbitMQ po zhvillohet për ne. E kemi në prodhim dhe ka pasur probleme me të. Tani, para shitjes, ai do të shamanizohej dhe do të fillonte të punonte normalisht. Por para kësaj, nuk isha gati ta lëshoja në prodhim. Ka edhe një pikë. Graylog mund të lexojë versionin AMQP 0.9 dhe rsyslog mund të shkruajë versionin AMQP 1.0. Dhe nuk ka një zgjidhje të vetme që mund t'i bëjë të dyja në mes. Ekziston ose njëra ose tjetra. Pra, tani për tani vetëm Kafka. Por ka edhe nuanca. Sepse omkafka e versionit të rsyslog që përdorim mund të humbasë të gjithë buferin e mesazheve që ka marrë nga rsyslog. Për sa kohë që ne e durojmë.
Pyetje: Po përdor Kafkën sepse e kishe? Nuk përdoret për ndonjë qëllim tjetër?
Përgjigjem: Kafka, e cila u përdor nga ekipi i Data Science. Ky është një projekt krejtësisht i veçantë, për të cilin, për fat të keq, nuk mund të them asgjë. Nuk e di. Ajo drejtohej nga ekipi i Data Science. Kur filluan shkrimet, ata vendosën ta përdorin atë, në mënyrë që të mos vendosin të tyren. Tani kemi përditësuar Graylog dhe kemi humbur përputhshmërinë, sepse ekziston një version i vjetër i Kafkës. Ne duhej të bënim tonën. Në të njëjtën kohë, ne i hoqëm këto katër tema për secilën API. Ne bëmë një majë të gjerë për të gjithë live, një majë të gjerë të gjerë për të gjitha inskenimet dhe thjesht xhirim gjithçka atje. Graylog i nxjerr të gjitha këto paralelisht.
Pyetje: Pse na duhet ky shamanizëm me priza? A keni provuar të përdorni drejtuesin e regjistrit të syslog për kontejnerët.
Përgjigjem: Në kohën kur e bëmë këtë pyetje, ne kishim marrëdhënie të tensionuara me dokerin. Ishte docker 1.0 ose 0.9. Vetë Docker ishte i çuditshëm. Së dyti, nëse futni edhe logs në të... Kam një dyshim të paverifikuar se ai i kalon të gjitha regjistrat përmes vetes, përmes daemonit docker. Nëse kemi një API që çmendet, atëherë pjesa tjetër e API-ve do të përballet me faktin se ata nuk mund të dërgojnë stdout dhe stderr. Nuk e di se ku do të çojë kjo. Unë kam një dyshim në nivelin e ndjenjës se nuk është e nevojshme të përdoret drejtuesi i sistemit docker në këtë vend. Departamenti ynë i testimit funksional ka grupin e tij Graylog me shkrime. Ata përdorin drejtues të regjistrave docker dhe gjithçka duket se është mirë atje. Por ata menjëherë i shkruajnë GELF Graylog. Në momentin kur filluam të gjitha këto, na duhej që thjesht të funksiononte. Ndoshta më vonë, kur të vijë dikush dhe të thotë se ka njëqind vjet që funksionon normalisht, ne do të përpiqemi.
Pyetje: Ju dorëzoni ndërmjet qendrave të të dhënave duke përdorur rsyslog. Pse jo për Kafkën?
Përgjigjem: Ne e bëjmë këtë, dhe kështu është në të vërtetë. Për dy arsye. Nëse kanali është plotësisht i vdekur, atëherë të gjitha shkrimet tona, madje edhe në një formë të ngjeshur, nuk do të kalojnë nëpër të. Dhe kafka i lejon ata thjesht të humbasin në proces. Në këtë mënyrë heqim qafe ngjitjen e këtyre trungjeve. Ne thjesht po përdorim Kafkën në këtë rast drejtpërdrejt. Nëse kemi një kanal të mirë dhe duam ta çlirojmë, atëherë përdorim rsyslog-in e tyre. Por në fakt, mund ta konfiguroni në mënyrë që të heqë atë që nuk ka kaluar. Për momentin ne po përdorim vetëm dërgimin rsyslog direkt diku, diku Kafka.
Burimi: www.habr.com