Loget janë një pjesë e rëndësishme e sistemit që lejon të kuptohet nëse ai funksionon (ose jo) siç pritej. Në kushte të arkitekturës mikroshërbimesh, puna me loget bëhet një disiplinë e veçantë e një olimpade speciale. Duhet të zgjidhen një sërë pyetjesh:
- si të shkruhen loget nga aplikacioni;
- ku të shkruhen loget;
- si të dërgohen loget për ruajtje dhe përpunim;
- si të përpunohen dhe të ruhet loget.
Përdorimi i teknologjive të njohura të kontejnerizimit shton një qëllim të ri ndaj gërvishjeve në fushën e zgjidhjes së problemit.
Pikërisht për këtë bëhet fjalë në interpretimin e raportit të Yuri Bushmelev "Harta e gërvishjeve në fushën e mbledhjes dhe shpërndarjes së logeve"
Kush është interesuar, lutem shihni më poshtë.
Më quajnë Yuri Bushmelev. Punoj në Lazada. Sot do të flas për mënyrën si i kemi bërë loget tona, si i kemi mbledhur, dhe çfarë shkruajmë atje.
From where are we? Who are we? Lazada is the number 1 online store in six Southeast Asian countries. All these countries are distributed among our data centers. We currently have a total of 4 data centers. Why is this important? Because certain solutions were determined by the fact that there is a very weak link between the centers. We have a microservices architecture. I was surprised to find that we already have 80 microservices. When I started the task with logs, there were only 20. Plus, there is a pretty large piece of PHP legacy that we also have to live with. All this generates more than 6 million messages per minute across the system as a whole. Next, I will show how we are trying to manage this and why it is so.
We have to live with these 6 million messages. What do we need to do with them? 6 million messages that need to:
- send from the application
- receive for delivery
- deliver for analysis and storage.
- të analizosh
- store somehow.
Kur arritur në tre milion mesazhe, kisha një pamje përafërsisht të tillë. Sepse kemi filluar me ndonjë cent. Është e qartë që aty shkruhen logët e aplikacioneve. Për shembull, nuk mund të lidhem me bazën e të dhënave, mund të lidhem me bazën e të dhënave, por nuk mund të lexoj diçka. Por përveç kësaj, çdo mikroshërbim ynë shkruan gjithashtu një log akses. Çdo kërkesë që arrin në mikroshërbim, bie në log. Pse e bëjmë këtë? Zhvilluesit duan të kenë mundësinë për të ndjekur. Në çdo log aksesi ka një fushë traceid, e cila më pas një ndërfaqe e veçantë e zhvillon të gjithë këtë zinxhir dhe tregon bukur gjurmimin. Gjurmimi tregon se si kaloi kërkesa, dhe kjo ndihmon zhvilluesit tanë të përballen më shpejt me çdo gjë të pakuptuar.
Si të jetojmë me këtë? Tani do të përmend në përmbledhje një sërë opsionesh — si është zgjidhur kjo problematikë. Si të zgjidhim problemin e mbledhjes, transferimit dhe ruajtjes së logëve.
Si të shkruajmë nga aplikacioni? Është e qartë që ka mënyra të ndryshme. Në veçanti, ka praktika më të mira, siç na thonë shokët e njohur. Ka shkollën e vjetër në dy variante, siç na kanë treguar pleqtë. Ka edhe mënyra të tjera.
Me sjelljen e logëve është një situatë e ngjashme. Ka pak zgjidhje për këtë pjesë të veçantë. Ka më shumë tani, por akoma jo shumë.
Por me shpërndarjen dhe analizën e mëvonshme — numri i variacioneve fillon të shpërthejë. Nuk do të përshkruaj çdo variant tani. Mendoj se variantet kryesore janë të njohura për të gjithë ata që janë interesuar për temën.
Do të tregoj se si e bëmë këtë në Lazada dhe si e filluam këtë gjithçka.
Një vit më parë erdha në Lazada dhe më dërguan në projektin për logët. Ajo ishte pak si kjo. Logu nga aplikacioni shkruhej në stdout dhe stderr. Të gjithë e bënë sipas modës. Por më pas zhvilluesit e hodhën jashtë rrjedhave standarde, dhe të tjerët si specialistët e infrastrukturës do ta kuptonin ndonjëherë. Mes specialistëve të infrastrukturës dhe zhvilluesve ka gjithashtu publikues, të cilët thanë: «ehe... mirë, le ta vendosim thjesht në një skedar duke përdorur shell, dhe mbarojmë». Dhe duke qenë se çdo gjë ndodhte në një kontejner, e vendosën direkt në kontejner, e mapuan brenda katalogut dhe e vendosën atje. Mendoj se është e qartë se çfarë rezultoi nga kjo.
Të shohim pak më larg. Si i dërguam këto loge. Diku dikush zgjodhi td-agent, i cili në të vërtetë është fluentd, por jo plotësisht fluentd. Unë nuk e kuptova marrëdhënien mes këtyre dy projekteve, por duket se janë për të njëjtën gjë. Dhe ky fluentd, i shkruar në Ruby, lexonte skedarët e logeve dhe i analizonte ato në JSON me disa regulat. Më pas i dërgonte në Kafka. Madje në Kafka, për çdo API kishim 4 tema të veçanta. Pse 4? Sepse kishte live, kishte staging, dhe sepse kishte stdout dhe stderr. Zhvilluesit i krijonin ato, ndërsa infrastruktorët duhej t'i krijonin në Kafka. Madje, Kafka kontrollohej nga një departament tjetër. Prandaj, duhej të krijohej një biletë për të krijuar 4 tema për çdo API atje. Të gjithë e harronin këtë. Pra, në përgjithësi, ishte një kaos i madh.
Çfarë bëmë më pas me këtë? Ne e dërguam atë në Kafka. Më pas, nga Kafka, gjysma e logeve shkonte në Logstash. Gjysma tjetër e logeve ndaheshin. Një pjesë shkonte në një Graylog, një pjesë – në Graylog tjetër. Në fund, të gjitha këto shkonte në një grup Elasticsearch. Domethënë, gjithë ky kaos përfundonte atje. Kështu nuk është e drejtë të bëhet!
Ja, kështu duket kur e shikon nga lart. Mos e bëni kështu! Këtu janë të shënuara menjëherë me numra vendet problematike. Në të vërtetë ka më shumë, por 6 janë ato që janë vërtet problematike dhe me të cilat duhet të merret diçka. Për to do të flas veçmas tani.
Këtu (1,2,3) ne shkruajmë skedarët dhe, për pasojë, këtu ka tri kurthe menjëherë.
E para (1) — është se duhet ti shkruajmë diku. Nuk gjithmonë do të doja të jepja API-në mundësinë të shkruajë drejtpërdrejt në skedar. Preferohej që API të ishte e izoluar në një kontejner, e më e mira – të ishte read-only. Unë jam administrator sistemesh, prandaj kam një perspektivë pak më ndryshe për këto gjëra.
Momenti i dytë (2.3) — na vijnë shumë kërkesa në API. API shkruan shumë të dhëna në skedar. Skedarët rriten. Na duhen t'i rrotullojmë. Sepse përndryshe nuk do të ketë disqe të mjaftueshme. Të rrotullohen është e komplikuar, sepse ato krijohen me një redirect përmes shell në një katalog. Nuk mund ta rrotullojmë atë. Nuk mund të kërkosh nga aplikacioni që të rivërë descriptorët. Sepse zhvilluesit do të të shikojnë si budalla: "Cilat descriptorë? Ne shkruajmë në stdout". Infrastrukturistët bënë copytruncate në logrotate, që thjesht krijon një kopje të skedarit dhe trim originalin. Duke qenë se, ndërmjet këtyre proceseve të kopjimit zakonisht mbaron hapësira në disk.
(4) Ne kemi pasur formate të ndryshme në API të ndryshme. Ato paksa ndaheshin, por duhej të shkruhej regexp i ndryshëm. Pasiqë gjithçka kjo administrohej nga Puppet, kishte një grup të madh klasash me problemet e veta. Për më tepër, td-agent shumicën e kohës mund të konsumonte shumë memorie, të ngadalësohej, ose thjesht të bënte sikur po punonte dhe të mos bënte asgjë. Nga jashtë, për të kuptuar që ai nuk po bënte asgjë ishte e pamundur. Në rastin më të mirë, ai do të binte dhe dikush do ta ngrinte përsëri. Saktësisht, do të vinte një alert dhe dikush do të shkonte ta ngrinte me duar.
(6) Po të gjitha, ky ishte elasticsearch. Sepse, ishte një version i vjetër. Sepse, nuk kishim mjeshtër të dedikuar në atë kohë. Kishim log-e të ndryshme, ku fushat mund të përputheshin. Log-e të ndryshme nga aplikacione të ndryshme mund të shkruheshin me emra të njëjtë fushe, por brenda mund të kishte të dhëna të ndryshme. Kështu që, një log arrin me Integer në fushën, për shembull, nivel. Një log tjetër arrin me String në fushën nivel. Në mungesë të një mapimi statik, ndodh një gjë e mrekullueshme. Nëse pas rotacionit të indeksit në elasticsearch, ndjenja e parë është një mesazh me një varg, atëherë ne jetojmë normalisht. Por nëse e para ka qenë me Integer, atëherë të gjitha mesazhet që vijojnë me String thjesht hidhen poshtë. Sepse tipi i fushës nuk përputhet.
Filluam të bënim këto pyetje. Vendosëm të mos kërkojmë fajtorë.
Por kaqë diçka duhet bërë! Një fakt i qartë është se duhet të krijojmë standarde. Disa standarde kemi pasur tashmë. Disa i kemi krijuar më vonë. Fatmirësisht, formati i njëjtë i skedarëve të logeve për të gjithë API-të ishte miratuar deri në atë kohë. Ai është përshkruar direkt në standardet e ndërveprimit të shërbimeve. Prandaj, ata që duan të marrin loget duhet t'i shkruajnë ato në këtë format. Nëse ndokush nuk i shkruan loget në këtë format, atëherë ne nuk garantojmë asgjë.
Më pas, do të doja të krijonim një standard të vetëm për metodat e regjistrimit, dërgimit dhe mbledhjes së logeve. Në thelb, ku t'i shkruajmë dhe çfarë të përdorim për t'i dërguar ato. Situata ideale është kur në projekte përdoret e njëjta bibliotekë. Kështu, ka një bibliotekë të veçantë për regjistrimin në Go, ka një bibliotekë të veçantë për PHP. Të gjithë ata që kemi — duhet t'i përdorin. Më aktualisht do të thosha se për rreth 80% është arritur. Por disa vazhdojnë të hanë kaktus.
Dhe atje (në slajd) fillon të shfaqet me vështirësi "SLA për dorëzimin e logëve". Aktualisht nuk e kemi, por po punojmë për këtë. Sepse është shumë e dobishme kur infrastruktura thotë se nëse shkruani në një format të tillë në një vend të tillë dhe jo më shumë se N mesazhe në sekondë, atëherë me një ndihmë të tillë do ta dorëzojmë atje. Kjo largon shumë shqetësime. Nëse ka SLA, atëherë është thjesht fantastike!
Si filluam të zgjidhim problemin? Problemi kryesor ishte me td-agent. Nuk ishte e qartë se ku po shkonin logët tanë. A po dërgoheshin? A po grumbulloheshin? Ku ishin ata? Prandaj, hapi i parë ishte të zëvendësonim td-agent. Disa mundësi për atë çfarë të vendosnim në vend të tij, shkurtimisht i kam skicuar këtu.
Fluentd. Së pari, e kam hasur në punën time të mëparshme dhe atje shpesh kishte rënie. Së dyti, është e njëjta gjë, vetëm që në profil.
Filebeat. Çfarë e bëri të përshtatshëm për ne? Sepse është në Go dhe ne kemi një eksperiencë të madhe në Go. Pra, në rast se ndodhte ndonjë gjë, mund të e modifikonim në një mënyrë për ne. Prandaj nuk e morëm. Që të mos kishte asnjë tundim për ta riprogramuar për ne.
Një zgjidhje e qartë për administratën mbetet një sërë sish log-esh në një numër të tillë (syslog-ng/rsyslog/nxlog).
Ose të shkruash diçka tënde, por këtë e hodhëm poshtë, ashtu si dhe filebeat. Nëse do të shkruash diçka, le të jetë diçka e dobishme për biznesin. Për dërgimin e log-eve është më mirë të marrësh diçka të gatshme.
Prandaj, zgjedhja faktikisht u reduktua në zgjedhjen mes syslog-ng dhe rsyslog. U përkulëm drejt rsyslog thjesht sepse në Puppet kishim klasa për rsyslog dhe nuk gjetëm ndonjë ndryshim të qartë midis tyre. Atje është syslog, këtu është syslog. Po, disa kanë dokumentacion më të keq, disa më të mirë. Njëri e bën këtë, tjetri atë.
Dhe pak për rsyslog. Së pari, është i shkëlqyer, sepse ka shumë module. Ka një RainerScript të kuptueshëm nga njerëzit (një gjuhë moderne konfigurimi). Një përfitim të shkëlqyer është se mundëm ta simulonim sjelljen e td-agent me mjete të zakonshme, dhe për aplikacionet nuk ka ndryshuar gjithçka. Pra, ne e zëvendësojmë td-agent me rsyslog, ndërsa gjithçka tjetër mbetet e pandryshuar. Dhe menjëherë marrim një dërgesë funksionale. Më tej, mmnormalize është një gjë e mrekullueshme në rsyslog. Lejon të parse log-et, por jo me Grok ose regexp. Kreon një tree sintaksor abstrakt. Parse log-et pak siç një kompilator parse kodin burimor. Kjo lejon operimin shumë të shpejtë, konsumon pak CPU dhe, gjithsesi, është vërtet një gjë shumë e shkëlqyer. Ka një mori përfitimesh të tjera. Nuk do të ndalem në to.
Rsyslog ka gjithashtu një mori disavantazhesh. Ato janë përafërsisht të ngjashme me përfitimet. Problemet kryesore janë se duhen ditur mënyrat e përgatitjes, dhe duhet seçi versioni.
Ne vendosëm që do të shkruajmë logët në unix socket. Ashtu siç nuk do të përdorim /dev/log, sepse aty kemi një kaos nga logët sistemorë, ku është journald në këtë pipeline. Prandaj, le të shkruajmë në një socket të personalizuar. Do ta lidhim me një set rregullash të veçanta. Nuk do të lejojmë asgjë të ndërhyjë. Do të jetë gjithçka e qartë dhe e kuptueshme. Kështu pra e bëmë. Katalogu me këto socket është standardizuar dhe kalon në të gjitha kontenierët. Kontenierët mund të shohin socket-in që iu nevojitet, ta hapin dhe të shkruajnë në të.
Pse jo një skedar? Sepse të gjithë kanë lexuar , i cili përpiqej të kalonte një skedar në docker, dhe doli se pas rilëshimit të rsyslog ndryshonte file descriptor, dhe docker e humbiste atë skedar. Ai mbante të hapur diçka tjetër, por jo atë socket ku shkruhet. Ne vendosëm që ta kalojmë këtë problem dhe, përveç kësaj, të kalojmë problemin e bllokimit.
Rsyslog kryen veprimet e shënuara në slajd dhe i dërgon logët ose në relay ose në Kafka. Kafka korrespondon me mënyrën e vjetër. Relay — përpjekja ime për të përdorur vetëm rsyslog për dërgimin e logëve. Pa Message Queue, me mjetet standarde të rsyslog. Në parim, kjo funksionon.
Porë e rëndësishme është se si t'i futim ato më vonë në këtë pjesë (Logstash/Graylog/ES). Kjo pjesë (rsyslog-rsyslog) përdoret midis qendravë të të dhënave. Këtu është një lidhje e kompresuar TCP, e cila lejon kursimin e bandwidth-it dhe, për pasojë, rrit mundësinë që të marrim ndonjë regjistrim nga një qendër e të dhënave tjetër në kushte kur kanali është i ngarkuar. Sepse, kemi Indonezinë, ku gjithçka është keq. Aty ka një problem të vazhdueshëm.
Ne u menduam për se si ta monitorojmë në fakt, me sa probabilitet regjistrimet që i kemi shënuar nga aplikacioni arrijnë në atë fund? Vendosëm të krijojmë метрики. Rsyslog ka modulin e vet për mbledhjen e statistikave, në të cilin ka disa numërues. Për shembull, mund të tregojë madhësinë e radhës, ose sa mesazhe kanë ardhur në një veprim të tillë. Nga ato mund të marrim diçka. Përveç kësaj, ka numërues të personalizuar që mund të konfigurohen, dhe ai do t'ju tregojë, për shembull, numrin e mesazheve që ka regjistruar një API të caktuar. Pastaj, kam shkruar rsyslog_exporter në Python, dhe e dërguam gjithçka në Prometheus dhe ndërtuam grafika. Më shumë do donim metricat e Graylog, por për momentin nuk kemi arritur t'i konfigurim.
Çfarë probleme ke hasur? Problemet kanë lindur nga fakti se ne zbulonim (papritmas!) se API-të tona Live dërgojnë 50,000 mesazhe në sekondë. Kjo është vetëm për API-të Live, pa të staging. Ndërsa Graylog na tregon vetëm 12,000 mesazhe në sekondë. Dhe lind një pyetje e arsyeshme, ku janë mbeturinat? Nga kjo arritëm në përfundimin se Graylog thjesht nuk po merr dot. I analizuam dhe, vërtet, Graylog me Elasticsearch nuk po përballonin këtë fluks.
Pastaj, zbulime të tjera që bëmë gjatë procesit.
Shkrimi në soket është bllokuar. Si ndodhi kjo? Kur përdorja rsyslog për dërgim, në një moment kanali ynë midis qendrave të të dhënave dështoi. Dërgesa ndaloi në një vend, dërgesa ndaloi në një vend tjetër. Të gjitha këto arritën tek makina me API, të cilat shkruajnë në soketin rsyslog. Aty u plotësua radhë. Pastaj u plotësua radhë për të shkruar në unix soket, i cili parazgjedhje ka 128 paketa. Dhe shkrimi i ardhshëm në aplikacion bllokohet. Kur shikuam në bibliotekën që përdorim në aplikacionet tonë në Go, atje ishte shkruar që shkrimi në soket bëhet në mënyrë jo-bllokuese. Ne ishim të sigurt që asgjë nuk bllokohej. Sepse ne kishim lexuar , që shkroi për këtë. Por ka një moment. Rreth këtij thirrjeje kishte një cikël të pafund, ku vazhdimisht po përpiqeshim të futnim mesazhin në soket. Këtë nuk e vëmë re. Na duhej të rishkruanim bibliotekën. Që atëherë ajo është ndryshuar disa herë, por tani ne e kemi eliminuar bllokimin në të gjitha nën sistemet. Prandaj, mund të ndalojmë rsyslog-un dhe asgjë nuk do të dështojë.
Duhet të monitorojmë madhësinë e radhëve, që ndihmon për të mos shkelur në këto gracka. Së pari, ne mund të monitorojmë kur fillojmë të humbasim mesazhe. Së dyti, mund të monitorojmë nëse kemi probleme me dërgesat në përgjithësi.
Dhe një moment tjetër i pakëndshëm — amplifikimi i 10-fish në arkitekturën mikro-shërbimore është shumë i lehtë. Ne nuk kemi aq shumë kërkesa hyrëse, por për shkak të grafit, përmes të cilit kalojnë këto mesazhe më tej, për shkak të logjeve të aksesit, ne realisht rrisim ngarkesën e logeve përafërsisht 10 herë. Fatkeqësisht nuk e kam pasur kohë të llogaris numrat e saktë, por mikro-shërbimet — janë të tillë. Duhet ta kemi këtë parasysh. Pra, për momentin, nën sistemi i mbledhjes së logeve është më i ngarkuari në Lazada.
Si duhet të zgjidhni problemin e elasticsearch? Nëse keni nevojë për të marrë shpejt log-et në një vend, që të mos bëni shëtitje nëpër të gjitha makinat dhe të mos i mbledhni atje, përdorni një depo të skedarëve. Kjo funksionon me siguri. Mund ta bëni nga çdo server. Thjesht vendosni disqet atje dhe instaloni syslog. Pas kësaj, do të keni me siguri të gjitha log-et në një vend. Më pas, do të jeni në gjendje të konfiguroheni me qetësi për elasticsearch, graylog, diçka tjetër. Por do të keni tashmë të gjitha log-et, dhe madje, mund t’i ruani sa mjafton kapaciteti i disqeve.
Në momentin që po flisja, skema kishte marrë pamjen e kësaj. Ne praktikisht kemi ndaluar shkrimin në skedarë. Tani, për momentin, do të ndalojmë dhe mbeturinat. Në makinat lokale, ku janë aktivizuar API-të, ne do të ndalojmë shkrimin në skedarë. Së pari, ekziston një depo skedarësh që funksionon shumë mirë. Së dyti, në këto makina vazhdimisht po i mbaron hapësira, dhe duhet ta monitorojmë vazhdimisht.
Kjo pjesë me Logstash dhe Graylog, vërtet është problematike. Pra, duhet ta heqim atë. Duhet të zgjedhim vetëm një.
Ne vendosëm të heqim Logstash dhe Kibana. Kjo ndodhi sepse kemi një departament sigurie. Cila është lidhja? Lidhja është se Kibana pa X-Pack dhe pa Shield nuk lejon ndarjen e të drejtave të aksesit në log-e. Prandaj zgjodhëm Graylog. Ai nuk më pëlqen, por funksionon. Blejmë harduer të ri, vendosim aty një Graylog të ri dhe transferojmë të gjitha log-et me formate strikte në një Graylog të veçantë. Zgjidhëm problemin me lloje të ndryshme të të njëjtave fusha organizativisht.
Çfarë përfshin në të vërtetë Graylog i ri. Thjesht e regjistruam gjithçka në Docker. Morëm shumë servera, vendosëm tre instance të Kafka dhe 7 servera Graylog versioni 2.3 (sepse donim Elasticsearch versionin 5). Gjithçka u ngrit në RAID nga HDD. Vërejtëm një indeksim deri në 100 mijë mesazhe në sekondë. Vërejtëm një shifër se 140 terabajt të dhënash në javë.
Dhe përsëri gabime! Na presin dy shfaqje. U transferuam me 6 milion mesazhe. Graylog-i ynë nuk po arrin të përpunojë. Duhet të gjejmë përsëri një mënyrë për të mbijetuar.
Ne kemi mbijetuar kështu. Shtuam edhe disa serverë dhe SSD. Aktualisht jetojmë në këtë mënyrë. Tani jemi duke procesuar 160,000 mesazhe në sekondë. Ende nuk kemi arritur kufirin, prandaj nuk dihet se sa do të mund të nxjerrim nga kjo.
Këto janë planet tona për të ardhmen. Nga to, ndoshta më e rëndësishmja është disponueshmëria e lartë. Aktualisht nuk e kemi atë. Disa makina janë të konfiguruara njësoj, por gjithçka po kalon përmes një makine. Duhet të kalojmë kohë për të konfiguruar failover ndërmjet tyre.
Të mbledhim metrike nga Graylog.
Të bëjmë rate limit që një API e çmendur të mos na shkatërrojë bandwidth-in dhe gjithçka tjetër.
Dhe përfundimisht, të nënshkruajmë një SLA me zhvilluesit, që ne mund të shërbejmë deri në këtë masë. Nëse shkruani më shumë, atëherë na vjen keq.
Dhe të shkruajmë dokumentacion.
Përmbledhje e shkurtër e gjithçkaje që kemi përjetuar. Së pari, standardet. Së dyti, syslog — tortë. Së treti, rsyslog funksionon pikërisht ashtu siç është shkruar në slajd. Tani le të kalojmë te pyetjet.
Pyetje.
Pyetja: Pse vendosët të mos merrni… (filebeat?)
Përgjigja: Duhet të shkruajmë në skedar. S'më pëlqeu aspak. Kur API juaj shkruan mijëra mesazhe në sekondë, madje edhe nëse e rotuloni një herë në orë, kjo s'është akoma një zgjidhje. Mund të shkruhet në pipe. Në çfarëdo që më pyetën zhvilluesit: «Çfarë do ndodhë nëse procesi në të cilin shkruajmë bie?» Unë thjesht nuk gjeta çfarë t'u përgjigjem dhe thashë: «S'nuk do ta bëjmë ashtu».
Pyetja: Pse nuk shkruani log-ët thjesht në HDFS?
Përgjigja: Ky është hapi tjetër. Ne e menduam këtë në fillim, por, tani për tani, për shkak të mungesës së burimeve për ta trajtuar, ai mbetet si zgjidhje afatgjatë.
Pyetja: Formati kolonor do të ishte më i përshtatshëm.
Përgjigja: Unë e kuptoj gjithçka. Ne jemi pro me të dyja duar.
Pyetja: Ju shkruani në rsyslog. Aty mund të keni edhe TCP, edhe UDP. Por nëse përdorni UDP, si e garantoni dorëzimin?
Përgjigja: Kantöhet dy aspekte. E para, unë gjithmonë iu them të gjithëve se ne nuk garantojmë dërgimin e logeve. Sepse, kur zhvilluesit vijnë dhe thonë: “Pse nuk fillojmë të shkruajmë të dhënat financiare atje, dhe ju do t'i ruani ato diku në rast se ndodhin ndodhi,” ne iu përgjigjemi: “Shkëlqyeshëm! Le të filloni të bllokoni regjistrimin në socket dhe ta bëni këtë në transaksione, për të garantuar që na e dërgoni atë në socket dhe të siguroheni se ne e morëm nga ana tjetër.” Dhe në atë moment, të gjithë e kuptojnë se nuk është e nevojshme. Tani, nëse nuk është e nevojshme, çfarë pyetjesh kemi për ju? Nëse nuk dëshironi të garantoni regjistrimin në socket, pse duhet të garantojmë dërgimin? Ne bëjmë përpjekje maksimale. Ne vërtet përpiqemi të dërgojmë sa më shumë dhe sa më mirë, por ne nuk japim garanci 100%. Kështu, mos shkruani atje të dhënat financiare. Për këtë ekzistojnë bazat e të dhënave me transaksione.
Pyetja: Kur API gjeneron një mesazh në log dhe i kalon menaxhimin mikroshërbimeve, a keni hasur ndonjëherë me problemin që mesazhet nga mikroshërbime të ndryshme vijnë në rend të gabuar? Kjo shkakton konfuzion.
Përgjigja: Është normale që ato të vijnë në rend të ndryshëm. Duhet të jemi të gatshëm për këtë. Sepse çdo dërgesë në rrjet nuk garanton rendin, ose duhet të shpenzoni burime specifike për këtë. Nëse marrim depozitë skedarësh, çdo API ruan logjet në skedarin e saj. Në të vërtetë, atje rsyslog i rendit ato në kataloge. Çdo API aty ka logjet e saj, ku mund të shkoni dhe të shihni, dhe më pas sipas timestamp në këtë log mund t'i përputhni ato. Nëse shkojnë të shikojnë në Graylog, atje ato do të renditen sipas timestamp. Atje gjithçka do të jetë mirë.
Pyetja: Timestamp mund të ndryshojë në milisekonda.
Përgjigja: Timestamp i gjeneron vetë API. Kjo, në thelb, është gjithë shaka. Ne kemi NTP. API gjeneron timestamp tashmë në mesazhin e vet. Ai nuk shtohet nga rsyslog.
Pyetja: Nuk është shumë e qartë ndërveprimi midis qendrave të të dhënave. Brenda qendrës së të dhënave është e qartë si u grumbulluan dhe u përpunuan logjet. Si ndodh ndërveprimi midis qendrave të të dhënave? Ose çdo qendër të dhënash jeton jetën e saj?
Përgjigja: Gati. Çdo vend ndodhet në një data qendër të caktuar. Aktualisht nuk kemi një shpërndarje, që do të thotë se një vend është i vendosur në data qendra të ndryshme. Pra, nuk duhet t'i gruponi. Brenda çdo qendre ka Log Relay. Ky është një server Rsyslog. Në fakt, ka dy makina menaxher. Ato janë të konfigurara njësoj. Por aktualisht, vetëm njëra prej tyre e merr trafikun. Ajo agregon të gjitha log-et. Ka një rresht diskash për çdo rast. Ajo kompreson log-et dhe i dërgon në data qendrën qendrore (në Singapor), ku më pas ato dërgohen në Graylog. Çdo data qendër ka një storage të saj për skedarë. Në rast se humbasim lidhjen, ne i kemi të gjitha log-et atje. Ato do të mbeten aty. Ato do të ruhen.
Pyetja: Në situata të paplanifikuara, a merrni log-et nga atje?
Përgjigja: A mund të shkoni atje (në storage-in për skedarë) dhe të shikoni?
Pyetja: Si e monitoroni që mos humbni log-et?
Përgjigja: Në të vërtetë i humbasim ata, dhe ne e monitorojmë këtë. Monitorimi filloi një muaj më parë. Në bibliotekën që përdor API-në Go, ka metrika. Ajo di të numërojë sa herë nuk ka mundur të shkruajë në socket. Atje aktualisht ka një heuristikë të zgjuar. Ka një bufer. Ai përpiqet të dërgojë mesazhin nga ai në socket. Nëse buferi mbushet, fillon t'i braktisë. Dhe numëron sa i ka braktisur. Nëse fillojnë të mbushen numëruesit aty, ne do ta dimë këtë. Tani ata mbërrijnë gjithashtu në prometheus, dhe në Grafana mund të shihni grafikat. Mund të konfigurohen njoftimet. Por tani nuk është e qartë se kujt t'i dërgohen ato.
Pyetja: Në elasticsearch ruani log-et me rezervim. Sa replikat keni?
Përgjigja: Një replikë.
Pyetja: A është këtë vetëm një replikë?
Përgjigja: Ky është master dhe një replikë. Të dhënat ruhet në dy ekzemplarë.
Pyetja: A e keni rregulluar ndonjëherë madhësinë e buferit rsyslog?
Përgjigja: Ne shkruajmë datagramet në një socket të personalizuar UNIX. Kjo na vendos menjëherë një kufizim prej 128 kilobajtësh. Nuk mund të shkruajmë më shumë se kaq. E kemi përfshirë këtë në standard. Ata që duan të hyjnë në magazinat, shkruajnë 128 kilobajtë. Bibliotekat, për më tepër, e presin, duke vendosur një flamur që mesazhi është prishur. Në standardin e vet të mesazhit, ka një fushë speciale që tregon nëse është prishur gjatë shkruarjes apo jo. Pra, kemi mundësinë të ndjekim këtë moment.
Pyetje: A shkruani JSON të prishur?
Përgjigja: JSON i prishur do të hidhet ose gjatë relay-t, sepse paketa është shumë e madhe. Ose do të hidhet nga Graylog, sepse nuk mund të parse-ojë JSON-in. Por ka nuansa që duhet të rregullohen, dhe ato në shumicën e rasteve lidhen me rsyslog-un. Kam plotësuar disa çështje aty që duhet të punojmë ende mbi to.
Pyetje: Pse Kafka? Keni provuar RabbitMQ? Nuk funksionon Graylog nën këto ngarkesa?
Përgjigja: Ne kemi probleme me Graylog. Por Graylog është një ndihmë. Ka vërtetë probleme. Është një gjë e çuditshme. Në të vërtetë, nuk është e nevojshme. Unë do të preferoja të shkruaja direkt nga rsyslog në elasticsearch dhe më pas të shihja në Kibana. Por duhet të zgjidhim çështjen me sigurinë. Ky është një opsion i mundshëm për zhvillimin tonë, kur të heqim Graylog dhe të përdorim Kibana. Nuk do kishte asnjë kuptim të përdorim Logstash. Sepse, mund të bëj të njëjtën gjë me rsyslog. Ai ka një modul për të shkruar në elasticsearch. Me Graylog po përpiqemi të jetojmë. Madje e kemi bërë edhe disa rregullime. Por ka ende hapësirë për përmirësime.
Në lidhje me Kafka. Kështu ka ndodhur historikisht. Kur kam ardhur, ajo ishte tashmë aty dhe në të tashmë ishim duke shkruar loge. Ne thjesht ngritëm klasterin tonë dhe u transferuam me loget. Ne e menaxhojmë atë, dimë si ndjehet. Në lidhje me RabbitMQ… nuk po na del mirë me RabbitMQ. Po na del mirë me RabbitMQ. E kemi në prodhim, dhe kemi pasur probleme me të. Tani, përpara shitjes, e patëm përmirësuar atë, dhe filloi të funksiononte normalisht. Por deri atëherë nuk isha i gatshëm ta nxirrja në prodhim. Ka edhe një aspekt tjetër. Graylog di të lexojë versionin AMQP 0.9, ndërsa rsyslog di të shkruajë versionin AMQP 1.0. Dhe nuk ka asnjë zgjidhje që mund të bëjë të dua. Ka ose njëra ose tjetra. Prandaj për momentin vetëm Kafka. Por ka edhe nuanca të veta. Sepse omkafka i atij versioni të rsyslog, që ne po përdorim, mund të humbasë të gjithë bufferin e mesazheve që ka marrë nga rsyslog. Deri tani po pajtohemi me këtë.
Pyetje: A po përdorni Kafka sepse ajo ishte e juaja? Nuk përdoret për asnjë qëllim tjetër?
Përgjigja: Kafka, e cila është përdorur nga ekipi i Shkencës së të Dhënave. Ky është një projekt krejtësisht ndryshe, për të cilin, fatkeqësisht, nuk mund të them asgjë. Nuk jam në dijeni. Ajo ishte nën menaxhimin e ekipit të Shkencës së të Dhënave. Kur nisëm log-et, vendosëm ta përdorim atë për të mos instaluar edhe një tonit tonën. Tani e kemi përditësuar Graylog, dhe kemi humbur kompatibilitetin, sepse ka një version të vjetër të Kafka. Na duhej të krijonim tonën. Njëherësh, na u hoqën këto katër tema për çdo API. Krijuam një temë të gjerë për të gjithë live-in, një temë të gjerë për të gjithë staging-un dhe thjesht e dërgojmë gjithçka atje. Graylog e mbledh gjithçka paralelisht.
Pyetje: Pse duhet ky magji me soketët? A keni provuar të përdorni log-drejtorin syslog për kontejnerët.
Përgjigja: Në momentin kur ne po merreshim me këtë çështje, marrëdhëniet tona me Docker ishin tendosura. Ishte Docker 1.0 ose 0.9. Docker vetë ishte i çuditshëm. Për më tepër, nëse duhej të dërgonim log-et… Kam një dyshim të pa verifikuar se ai kalon të gjitha log-et përmes tij, përmes demonit Docker. Nëse një API çmendet, atëherë API-të e tjera ngjiten në faktin se nuk mund të dërgojnë stdout dhe stderr. Nuk e di se çfarë do të sjellë kjo. Kam një ndjenjë që nuk duhet ta përdorim driver-in syslog të Docker këtu. Departamenti ynë për testimin funksional ka grupin e vet të vogël Graylog me log-e. Ata përdorin driver-at e log-eve të Docker dhe duket se gjithçka funksionon mirë atje. Por ata e shkruajnë GELF direkt në Graylog. Kur ne po fillonim gjithçka, na duhej të funksiononte vetëm. Ndoshta më vonë, kur dikush të vijë dhe të thotë se kjo tashmë ka funksionuar normalisht për njëqind vjet, do ta provojmë.
Pyetje: Pse dërgoni mes datacentrove me rsyslog? Pse jo me Kafka?
Përgjigja: Ne e bëjmë këtë dhe atë në të vërtetë. Për dy arsye. Nëse kanali është krejtësisht i dëmtuar, atëherë as log-et tona, madje edhe në formë të kompresuar, nuk kalojnë përmes tij. Por Kafka lejon që ata thjesht të humbasin gjatë procesit. Me këtë metodë ne lirohemi nga ngjizja e këtyre log-eve. Ne thjesht e përdorim Kafka drejtpërdrejt në këtë rast. Nëse kemi një kanal të mirë dhe duam ta lirojmë atë, atëherë përdorim rsyslog-in e tyre. Por në të vërtetë e mund ta konfigurojmë në mënyrë që ai të heqë automatikisht atë që nuk kalon. Në këtë moment, ne thjesht përdorim dërgimin rsyslog drejtpërdrejt ndonjëherë, ndonjëherë Kafka.
Burimi: habr.com
