Logot janë një pjesë e rëndësishme e sistemit, duke lejuar që të kuptohet nëse ai funksionon (ose jo) siç pritet. Në kushtet e arkitekturës mikroshërbimesh, puna me logot bëhet një disiplinë e veçantë. Duhet të zgjidhen menjëherë shumë pyetje:
- si të shkruhen logot nga aplikacioni;
- ku të shkruhen logot;
- si të dërgohen logot për ruajtje dhe përpunim;
- si të përpunohen dhe ruhen logot.
Përdorimi i teknologjive të njohura të konteinerizimit shton më shumë vështirësi për zgjidhjen e problemit.
Pikërisht për këtë flitet në raportin e Yuri Bushmelev, "Hartë e pengesave në fushën e mbledhjes dhe dërgimit të logove"
Kush është i interesuar, ju lutem, shihni më poshtë.
Më quaj Yuri Bushmelev. Punoj në Lazada. Sot do flas për mënyrën se si e kemi ndërtuar logun tonë, si i mbledhim dhe çfarë shkruajmë brenda tij.
Nga jemi? Kush jemi ne? Lazada është marketi numër 1 në gjashtë vende të Azisë Juglindore. Të gjitha këto vende janë të shpërndara në qendrat tona të të dhënave. Aktualisht kemi 4 qendra të dhënash. Pse është e rëndësishme? Sepse disa zgjidhje ishin të përcaktuara nga fakti se midis qendrave ka një lidhje shumë të dobët. Ne kemi një arkitekturë mikroshërbimesh. U befasova kur zbulova se tashmë kemi 80 mikroshërbime. Kur kam filluar projektin me logot, ka pasur vetëm 20. Po ashtu, ka një sasi të konsiderueshme të PHP legacy, me të cilin duhet të jetojmë dhe të pajtohemi. Të gjitha këto gjenerojnë për momentin më shumë se 6 milion mesazhe në minutë në sistemin në tërësi. Më tutje do të tregoj se si përpiqemi të jetojmë me këtë dhe pse është kështu.
Me kĂ«to 6 milion mesazhe, duhet tĂ« jetojmĂ« nĂ« njĂ« farĂ« mĂ«nyre. ĂfarĂ« duhet tĂ« bĂ«jmĂ« me to? 6 milion mesazhe qĂ« duhet:
- dërguar nga aplikacioni
- pranuar për dërgim
- dërguar për analizë dhe ruajtje.
- të analizoni
- dhe ndonjëherë duhet të ruhen.
Kur u shfaqĂ«n tre milion mesazhe, unĂ« kisha njĂ« pamje tĂ« ngjashme. Sepse ne filluam me ndonjĂ« qindarkĂ«. ĂshtĂ« e qartĂ« se aty shkruhen log-Ă«t e aplikacioneve. PĂ«r shembull, nuk arrita tĂ« lidhem me bazĂ«n e tĂ« dhĂ«nave, arrita tĂ« lidhem me bazĂ«n e tĂ« dhĂ«nave, por nuk arrita tĂ« lexoj diçka. Por pĂ«rveç kĂ«saj, çdo mikroshĂ«rbim ynĂ« shkruan gjithashtu njĂ« log tĂ« aksesit. Ădo kĂ«rkesĂ« qĂ« vjen nĂ« mikroshĂ«rbim bie nĂ« log. Pse e bĂ«jmĂ« kĂ«tĂ«? Zhvilluesit duan tĂ« kenĂ« mundĂ«si gjurmi. NĂ« çdo log tĂ« aksesit, ndodhet fusha traceid, me tĂ« cilin mĂ« pas njĂ« ndĂ«rfaqe speciale shtrijon tĂ« gjithĂ« zinxhirin dhe e tregon bukur gjurmimin. Gjurmi tregon se si kaloi kĂ«rkesa dhe kjo i ndihmon zhvilluesit tanĂ« tĂ« pĂ«rballen mĂ« shpejt me çdo gjĂ« tĂ« panjohur.
Si tĂ« jetojmĂ« me kĂ«tĂ«? Tani do tĂ« flas shkurt pĂ«r disa mundĂ«si â si zgjidhet gjithsesi ky problem. Si tĂ« zgjidhet problemi i grumbullimit, transferimit dhe ruajtjes sĂ« log-Ă«ve.
Si të shkruajmë nga aplikacioni? E qartë është se ka mënyra të ndryshme. Në veçanti, ka praktika më të mira, si na tregojnë shokët modernë. Ka stilin e vjetër në dy forma, si na treguan të parët. Ka edhe mënyra të tjera.
Situata me grumbullimin e log-ëve është për afërsisht të njëjtën gjë. Mundësitë për zgjidhjen e kësaj pjesë të veçantë nuk janë shumë. Tani janë më shumë, por akoma jo shumë.
MegjithatĂ«, lidhur 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 si ne bëmë këtë në Lazada, dhe si fillimisht nisi e gjithë kjo.
Një vit më parë, unë erdha në Lazada dhe më dërguan në projektin për log-et. Aty ishte diçka e tillë. Log-u nga aplikacioni shkruhej në stdout dhe stderr. Të gjithë e bënë sipas modës. Por më pas zhvilluesit e hodhën atë nga rrjedhat standarde, dhe më pas spesialistët e infrastrukturës do të merreshin me të. Ndërmjet specialistëve të infrastrukturës dhe zhvilluesve ka edhe lëshues, të cilët thanë: «eh⊠mirë, le të paketojmë thjesht në një skedar me shell-in, dhe mbaroi». Dhe që të gjitha ishin në një kontejner, kështu që i paketuan direkt brenda kontejnerit, e mapuan brenda një directoriesh dhe e vendosën aty. Mendoj se është e qartë për të gjithë se çfarë doli nga kjo.
Të shikojmë disi më thellë. Si i shpërndanim këto log-e. Disa kanë zgjedhur td-agent, i cili në të vërtetë është fluentd, por jo krejtësisht fluentd. Nuk e kuptova kurrë marrëdhënien midis këtyre dy projekteve, por duket se për të njëjtën gjë është fjala. Dhe ky fluentd, i shkruar në Ruby, lexonte skedarët e log-eve, i parse me JSON përmes ndonjë regexi. Pastaj i dërgonte në Kafka. Për më tepër, në Kafka për çdo API kishim 4 tema të veçanta. Pse 4? Sepse kemi live, kemi staging dhe sepse kemi stdout dhe stderr. Zhvilluesit i krijojnë ato, ndërsa inxhinierët e infrastrukturës duhet t'i krijojnë në Kafka. Për më tepër, Kafka kontrollohej nga një departament tjetër. Prandaj, duhej të krijonim një biletë që ata të krijonin 4 tema për çdo API. Të gjithë këtë e harronin. Pra, ishte një kaos total.
ĂfarĂ« bĂ«mĂ« mĂ« pas me kĂ«tĂ«? Ne e dĂ«rguam atĂ« nĂ« Kafka. MĂ« pas, nga Kafka, gjysma e log-eve fluturonte nĂ« Logstash. Gjysma tjetĂ«r e log-eve ndahej. NjĂ« pjesĂ« fluturonte nĂ« njĂ« Graylog, njĂ« pjesĂ« â nĂ« njĂ« Graylog tjetĂ«r. NĂ« pĂ«rfundim, gjithçka pĂ«rfundonte nĂ« njĂ« klaster Elasticsearch. Pra, e gjithĂ« kjo kaos nĂ« fund pĂ«rfundonte aty. Nuk duhet bĂ«rĂ« kĂ«shtu!
Ja si duket, nëse e shikojmë nga lart. Nuk duhet bërë kështu! Këtu janë të shënuara menjëherë me numra pikat e problemit. Në të vërtetë, ka më shumë se kaq, por 6 janë vërtet problemet kryesore me të cilat duhet të bëjmë diçka. Për to do të flas veçmas tani.
Këtu (1, 2, 3) shkruhen skedarët dhe, për pasojë, menjëherë këtu kemi tre pengesa.
E para (1) â Ă«shtĂ« se duhet t'i shkruajmĂ« diku. Nuk do tĂ« dĂ«shironim gjithmonĂ« t'i jepnim API mundĂ«sinĂ« tĂ« shkruajĂ« direkt nĂ« skedar. Preferohet qĂ« API tĂ« jetĂ« e izoluar nĂ« njĂ« kontejner, dhe akoma mĂ« mirĂ« â qĂ« ajo tĂ« jetĂ« read-only. UnĂ« jam sistemadministrator, kĂ«shtu qĂ« kam njĂ« kĂ«ndvĂ«shtrim paksa alternativ pĂ«r kĂ«to çështje.
Momenti i dytĂ« (2,3) â kemi shumĂ« kĂ«rkesa qĂ« vijnĂ« nĂ« API. API-ja shkruan shumĂ« tĂ« dhĂ«na nĂ« skedar. SkedarĂ«t rriten. Na nevojitet t'i rotatojmĂ«. Sepse, pĂ«rndryshe, nuk mund tĂ« sigurojmĂ« hapĂ«sirĂ« nĂ« disqet e papara. Rotimi Ă«shtĂ« i vĂ«shtirĂ«, sepse ata janĂ« tĂ« krijuar me njĂ« kthim pĂ«rmes shell nĂ« katalog. Nuk mund t'i rotatojmĂ« dot. Nuk mund tĂ« kĂ«rkojmĂ« nga aplikacioni qĂ« tĂ« rihapĂ« deskriptorĂ«t e tij. Sepse zhvilluesit do tĂ« na shikojnĂ« si tĂ« çmendur: "Cilat deskriptorĂ«? Ne nĂ« tĂ« vĂ«rtetĂ« shkruajmĂ« nĂ« stdout". Infrastrukturuesit e bĂ«nĂ« copytruncate nĂ« logrotate, i cili thjesht bĂ«n njĂ« kopje tĂ« skedarit dhe truncaton origjinalin. Si rezultat, midis kĂ«tyre proceseve tĂ« kopjimit zakonisht pĂ«rfundon hapĂ«sira nĂ« disk.
(4) Ne kishim formate tĂ« ndryshme nĂ« API tĂ« ndryshme. Ato disi i ndaheshin njĂ«ra-tjetrĂ«s, por duhej tĂ« shkruanim regexp tĂ« ndryshĂ«m. Duke qenĂ« se gjithçka kjo drejtohej nga Puppet, kishte njĂ« grup tĂ« madh klasash me âmerimangaâ tĂ« veta. Plus, ndonjĂ«herĂ« td-agent konsumonte shumĂ« memorie, e ngadalĂ«sonte, mund tĂ« bĂ«nte sikur punonte dhe tĂ« mos bĂ«nte asgjĂ«. Nga jashtĂ« ishte e pamundur tĂ« kuptohej se ai nuk bĂ«ntĂ« asgjĂ«. NĂ« rastin mĂ« tĂ« mirĂ«, ai do tĂ« rrĂ«zohej dhe dikush do ta ngrinte mĂ« pas. SakĂ«sisht, do tĂ« vinte njĂ« alarm dhe dikush do tĂ« shkonte e do ta ngrinte me duar.
(6) Dhe mĂ« e keqja â ishte elasticsearch. Sepse ishte njĂ« version i vjetĂ«r. Sepse, atĂ«herĂ«, nuk kishim master tĂ« dedikuar. Kishim loge tĂ« larmishme, ku fushat mund tĂ« pĂ«rputheshin. Loge tĂ« ndryshme tĂ« aplikacioneve tĂ« ndryshme mund tĂ« shkruheshin me emra tĂ« njĂ«jtĂ« fushe, por brenda mund tĂ« kishin tĂ« dhĂ«na tĂ« ndryshme. DomethĂ«nĂ«, njĂ« log vjen me Integer nĂ« fushĂ«n, pĂ«r shembull, level. NjĂ« log tjetĂ«r vjen me String nĂ« fushĂ«n level. NĂ« mungesĂ« tĂ« njĂ« hartimi statik, rezulton njĂ« gjĂ« e mrekullueshme. NĂ«se pas rotacionit tĂ« indeksit nĂ« elasticsearch, mesazhi i parĂ« qĂ« vjen Ă«shtĂ« me varg, atĂ«herĂ« ne e kalojmĂ« normalisht. Por nĂ«se i pari qĂ« vjen Ă«shtĂ« me Integer, tĂ« gjitha mesazhet e ardhshme qĂ« vijnĂ« me String thjesht pĂ«rjashtohen. Sepse tipi i fushĂ«s nuk pĂ«rputhet.
Filluam të bëjmë këto pyetje. Vendosëm të mos kërkojmë fajtorët.
Por një kohë e gjatë, ishte e qartë se duhej të vendosnim standarde. Disa standarde kishim already. Të tjerë i vendosëm pak më vonë. Për fat, formati i njëjtë i regjistrimeve për të gjitha API-të ishte miratuar në atë kohë. Ai është përshkruar drejtpërdrejt në standartet e bashkëpunimit të shërbimeve. Pra, ata që duan të marrin regjistrimet duhet t'i shkruajnë ato në këtë format. Nëse dikush nuk i shkruan regjistrimet në këtë format, do të thotë se ne nuk garantojmë asgjë.
Më pas, do të dëshiroja të vendosnim një standard të vetëm për mënyrat e regjistrimit, dërgimin dhe mbledhjen e regjistrimeve. Në thelb, ku t'i shkruajmë ato dhe me çfarë t'i dërgojmë. Situata ideale do të ishte të përdorej e njëjta bibliotekë në projekte. Kemi një bibliotekë të veçantë për regjistrimin në Go, dhe një tjetër për PHP. Të gjithë ata që i kemi - të gjithë duhet t'i përdorin ato. Aktualisht do të thosha se rreth 80% e kësaj po funksionon. Por disa vazhdojnë të hanë kaktusë.
Dhe aty (në slajd) fillon ngadalë të shfaqet "SLA për dërgimin e regjistrimeve". Aktualisht nuk e kemi, por jemi duke punuar për të. Sepse është shumë praktike 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ë ne do t'ia dërgojmë atje me një probabilitet të caktuar. Kjo heq shumë nga dhimbjet e kokës. Nëse SLA ekziston, atëherë është thjesht e shkëlqyer!
Si filluam të zgjidhim problemin? Problemi kryesor ishte me td-agent. Nuk ishte e qartë se ku shkonte regjistri. A dërgoheshin ata? A mblidheshin ata? Ku ishin ata në të vërtetë? Prandaj, pika e parë ishte të zëvendësonim td-agent. Kam shkruar shkurtimisht disa opsione për atë që mund ta zëvendësojmë.
Fluentd. Së pari, kam pasur përvojë me të në punën time të mëparshme, dhe ai gjithashtu herë pas here ishte duke rënë. Së dyti, është pikërisht e njëjta gjë, por për profesionistët.
Filebeat. ĂfarĂ« e bĂ«nte atĂ« tĂ« pĂ«rshtatshĂ«m pĂ«r ne? Sepse Ă«shtĂ« nĂ« Go, dhe ne kemi njĂ« ekspertizĂ« tĂ« madhe nĂ« Go. Prandaj, nĂ«se ndodhte diçka, mund tĂ« bĂ«nim disa ndryshime vetĂ«. Prandaj nuk e morĂ«m. QĂ« tĂ« mos kishte asnjĂ« tundim pĂ«r tĂ« filluar ta rishkruanim pĂ«r vete.
Një zgjidhje e qartë për sistem-adminin mbetet çdo lloj sistemi regjistrimi, si syslog-ng / rsyslog / nxlog.
Ose të shkruajmë diçka tonën, por ne këtë e gruntuam, ashtu si dhe filebeat. Nëse do të shkruanim diçka, do të ishte më mirë të shkruanim diçka të dobishme për biznesin. Për dërgimin e regjistrimeve, do të ishte më mirë të merrnim diçka të gatshme.
Prandaj, zgjedhja pĂ«rfundoi duke u pĂ«rqendruar nĂ« syslog-ng dhe rsyslog. U prirĂ«m drejt rsyslog, thjesht sepse kishim klasa pĂ«r rsyslog nĂ« Puppet, dhe nuk gjetĂ«m ndonjĂ« diferencĂ« tĂ« dukshme mes tyre. ĂfarĂ« ka aty syslog, ka dhe kĂ«tu syslog. Po, ndokush ka dokumentacion mĂ« tĂ« keq, ndokush mĂ« tĂ« mirĂ«. Ai di kĂ«shtu, ai ndryshe.
Dhe pak për rsyslog. Së pari, ai është i shkëlqyer, sepse ka shumë module. Ka RainerScript, një gjuhë moderne konfigurimi e kuptueshme për njerëzit. Një bonus fantastik është se mundëm ta simulonim sjelljen e td-agent me mjete standarde, dhe për aplikacionet nuk ndryshoi asgjë. Pra, ne e ndryshojmë td-agent me rsyslog, dhe gjithçka tjetër mbetet e pandryshuar. Dhe menjëherë e marrim dërgesën duke funksionuar. Më pas, mmnormalize është një gjë fantastike në rsyslog. Ai lejon të analizosh log-et, por jo me Grok dhe regexp. Ai bën një pemë të sintaksës abstrakte. Ai analizon log-et përafërsisht si një kompilator analizon burimin. Kjo lejon të punosh shumë shpejt dhe të konsumosh pak CPU, dhe, më të vërtetë, është një gjë shumë e shkëlqyer. Ka shumë bonuse të tjera. Nuk do të ndalem tek ato.
Rsyslog ka shumë disavantazhe të tjera. Ato janë përafërsisht të njëjta me bonuset. Problemet kryesore janë se duhet të dish si ta përgatisësh dhe duhet të zgjidhësh versionin.
Ne vendosëm që do të shkruajmë log-et në unix socket. Dhe jo në /dev/log, sepse atje kemi një kaos nga log-et sistemore, atje journald është në këtë pipeline. Prandaj, le të shkruajmë në një socket të personalizuar. Do ta lidhim me një ruleset të veçantë. Nuk do të përzihen asgjë. Do të jetë gjithçka e qartë dhe në transparencë. Kështu e bëmë. Katalogu me këto socket janë standardizuar dhe kalojnë në të gjitha kontejnerët. Kontejnerët mund të shohin socket-in e nevojshëm, ta hapin dhe të shkruajnë në të.
Pse jo një skedar? Sepse të gjithë kishin lexuar , e cila përpiqej të kalonte një skedar në docker, dhe duke zbuluar se pas rinisjes rsyslog ndryshon descriptor-in e skedarit, dhe docker e humb atë skedar. Ai mban të hapur diçka tjetër, por jo më atë socket ku shkruajnë. Ne vendosëm se do ta shmangim këtë problem dhe, për njëkohësisht, do ta shmangim edhe problemin e bllokimit.
Rsyslog bĂ«n veprimet e caktuara nĂ« diapozitiv dhe dĂ«rgon log-et ose nĂ« relays, ose nĂ« Kafka. Kafka i pĂ«rshtatet mĂ«nyrĂ«s sĂ« vjetĂ«r. Relay â Ă«shtĂ« se pĂ«rpiqesha tĂ« pĂ«rdor vetĂ«m rsyslog pĂ«r dĂ«rgimin e log-eve. Pa Message Queue, me mjete standarde rsyslog. NĂ« thelb, kjo funksionon.
Por shkak të disa veçorive për mënyrën si mund të i futim ato në këtë pjesë (Logstash/Graylog/ES). Kjo pjesë (rsyslog-rsyslog) përdoret midis qendrave të të dhënave. Këtu është një lidhje të dhënash të kompresuar, që lejon ruajtjen e bandës dhe, si rezultat, rrit gjasat që të marrim disa log-e nga një qendër tjetër të të dhënave kur kanali është i ngarkuar. Sepse kemi Indonezinë, ku situata është e vështirë. Atje, kjo është një problem konstant.
Ne po mendojmë se si të monitorojmë, me çfarë probabiliteti log-et që regjistrojmë nga aplikacioni arrijnë në atë skaj? Ne vendosëm të krijojmë metrika. Rsyslog ka modul të vet mbi grumbullimin e statistikave, ku ka disa numërues. Për shembull, ai mund të ju tregojë madhësinë e radhës, ose sa mesazhe kanë ardhur në një veprim të caktuar. Nga këto mund të nxjerrim diçka. Për më tepër, ka numërues personalizues që mund të konfigurojmë, dhe ai do t'ju tregojë, për shembull, numrin e mesazheve që regjistroi një API i caktuar. Më pas, unë shkrova rsyslog_exporter në Python dhe të gjithë këtë e dërguam në Prometheus dhe ndërtuam grafika. Do të donim shumë metrika nga Graylog, por ende nuk kemi arritur t'i konfigurojmë ato.
Cilat probleme kemi hasur? Problemet kanë lindur kur kemi zbuluar (papritur!) se Live API-t tanë dërgojnë 50,000 mesazhe në sekondë. Këto janë vetëm Live API pa staging. Dhe Graylog na tregon vetëm 12,000 mesazhe në sekondë. Ndërsa lind pyetja e arsyeshme, ku janë të tjerët? Nga kjo, ne arritëm në përfundimin se Graylog nuk po përballonte. Kërkuam dhe, në fakt, Graylog me Elasticsearch nuk po përballonte këtë ngarkesë.
Më tej, zbulime të tjera që kemi bërë gjatë procesit.
Shkrimi në socket është bllokuar. Si ndodhi kjo? Kur përdorja rsyslog për dorëzim, një moment u prish lidhja midis qendrave të të dhënave. Dorëzimi u ndal në një vend, ndërsa dorëzimi në një tjetër. Të gjitha këto arritën në makinën me API-t, të cilat shkruajnë në socket rsyslog. Aty u mbush radhë. Më pas, u mbush radhë për shkrim në unix socket, që sipas parazgjedhjes është 128 paketa. Dhe shkrimi i ardhshëm në aplikacion bllokohet. Kur shikuan në bibliotekën që përdorim në aplikacionet në Go, aty shkruhej se shkrimi në socket ndodhte në modin jo-bllokues. Ne ishim të sigurt që asgjë nuk po bllokohej. Sepse kishim lexuar. , e cila ka e shkruajti për këtë. Por ka një moment. Rreth këtij thirrje kishte edhe një cikël të pafund, në të cilin bëhej vazhdimisht një përpjekje për ta futur mesazhin në soket. Këtë nuk e vëmë re. Kemi qenë të detyruar ta rreshim librarinë. Që atëherë ajo është ndërruar 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ë bie.
Duhet të monitorojmë madhësinë e radhëve, që ndihmon që të mos bien në këto gracka. Në radhë të parë, mund të monitorojmë kur fillojmë të humbasim mesazhe. Në radhë të dytë, mund të monitorojmë problemet që kemi në tërësi me dorëzimin.
Dhe njĂ« moment tjetĂ«r i pakĂ«ndshĂ«m â amplifikimi 10-fish nĂ« arkitekturĂ«n e mikrosĂ«rvitorĂ«ve â Ă«shtĂ« shumĂ« e lehtĂ«. Nuk kemi shumĂ« kĂ«rkesa hyrĂ«se, por pĂ«r shkak tĂ« grafit nĂ« tĂ« cilin qarkullojnĂ« kĂ«to mesazhe mĂ« tej, pĂ«r shkak tĂ« log-eve tĂ« aksesit, ne realisht rrisim ngarkesĂ«n pĂ«r log-et rreth dhjetĂ« herĂ«. FatkeqĂ«sisht, nuk kam arritur tĂ« llogaris numrat e saktĂ«, por mikroservisat â ato janĂ« tĂ« tilla. Duhet ta kemi parasysh kĂ«tĂ«. Pra, nĂ« kĂ«tĂ« moment nĂ«n sistemi qĂ« mbledh log-et Ă«shtĂ« mĂ« i ngarkuari nĂ« Lazada.
Si ta zgjidhim problemin me elasticsearch? NĂ«se duhet tĂ« marrim shpejt log-et nĂ« njĂ« vend, pĂ«r tĂ« mos ecur nĂ«pĂ«r tĂ« gjitha makinat, dhe pĂ«r t'i mbledhur atje, pĂ«rdorni njĂ« ruajtje skedari. Kjo funksionon garantuar. Kjo krijohet nga çdo server. Duhet vetĂ«m tâi shtoni disa disqe atje dhe tĂ« vendosni syslog. Pas kĂ«saj do tĂ« keni garantuar tĂ« gjitha log-et nĂ« njĂ« vend. MĂ« pas mund tĂ« filloni tĂ« konfiguroni elasticsearch, graylog, diçka tjetĂ«r nga ngadalĂ«. Por do t'i keni tĂ« gjitha log-et, dhe pĂ«r mĂ« tepĂ«r, mund t'i ruani, sa mjaftojnĂ« masat e disqeve.
Në momentin e prezantimit tim, skema dukej kështu. Praktikisht kemi ndaluar të shkruajmë në skedarë. Tani, me të gjitha gjasat, do të çaktivizojmë mbetjet. Në makinat lokale, në të cilat janë aktivizuar API-të, do të ndalojmë të shkruajmë në skedarë. Së pari, ekziston një ruajtje skedari që funksionon shumë mirë. Së dyti, në këto makina vendoset hapësira vazhdimisht, është e nevojshme ta monitorojmë atë vazhdimisht.
Kjo pjesë me Logstash dhe Graylog, vërtet e ngarkon. Prandaj duhet të heqim dorë prej saj. Duhet të zgjedhim një nga ato.
Ne vendosëm të heqim Logstash dhe Kibana. Sepse kemi një departament të sigurisë. Cila është lidhja? Lidhja është se Kibana pa X-Pack dhe pa Shield nuk lejon ndarjen e të drejtave të aksesit në loge. Prandaj morëm Graylog. Pavarësisht se nuk më pëlqen, ai funksionon. Kemi blerë pajisje të reja, vendosëm aty një Graylog të ri dhe transferuam të gjitha loget me formate të rrepta në një Graylog të veçantë. Ne zgjidhëm problemin me lloje të ndryshme të fushave të njëjta në mënyrë organizative.
ĂfarĂ« pĂ«rfshihet nĂ« Graylog tĂ« ri? Ne thjesht e regjistruam gjithçka nĂ« Docker. MorĂ«m njĂ« sĂ«rĂ« serverĂ«sh, shpĂ«rndamĂ« tre instanca Kafka, 7 serverĂ« Graylog versioni 2.3 (sepse dĂ«shironim Elasticsearch version 5). TĂ« gjitha kĂ«to i ngritĂ«m mbi RAID nga HDD. VĂ«mĂ« re njĂ« normĂ« indeksimi deri nĂ« 100 mijĂ« mesazhe nĂ« sekondĂ«. VĂ«mĂ« re numrin se 140 terabajt tĂ« dhĂ«nash nĂ« javĂ«.
Dhe sërish, pengesa! Po na presin dy shitje të mëdha. Ne kaluam për 6 milion mesazhe. Graylog nuk po arrin të përpunojë. Duhet të mbijetojmë sërish.
Kështu mbijetuam. Shtova pak serverë dhe SSD. Aktualisht po jetojmë me këtë mënyrë. Tani po përpunojmë tashmë 160k mesazhe në sekondë. Ende nuk kemi arritur në limit, prandaj për momentin është e paqartë se sa realisht mund të nxjerrim nga kjo.
Ja si janë planet tona për të ardhmen. Nga këto, ndoshta, më e rëndësishmja është high availability. Për momentin nuk e kemi. Disa makineri janë të konfiguruara njësoj, por të gjitha kalojnë përmes një makinerie. Duhet të shpenzojmë kohë për të konfiguruar një failover mes tyre.
TĂ« mbledhim metrika nga Graylog.
Të bëjmë një limit të normës që një API e rënë nga dora të mos na shkatërrojë bandwidth dhe gjithçka tjetër.
Dhe përfundimisht, të nënshkruajmë një SLA me zhvilluesit, se ne mund të ofrojmë kaq shumë. Nëse shkruani më shumë, nga na vjen keq.
Dhe të shkruajmë dokumentacion.
Shkurtimisht, pĂ«rmbledhja e tĂ« gjitha atyre qĂ« kaluam. SĂ« pari, standartet. SĂ« dyti, syslog â tortĂ«. SĂ« treti, rsyslog funksionon pikĂ«risht siç Ă«shtĂ« shkruar nĂ« slajd. Dhe le tĂ« kalojmĂ« te pyetjet.
Pyetje.
Pyetje: Pse vendosët të mos marrë...
PĂ«rgjigje: Duhet tĂ« shkruhet nĂ« skedarin. Ishte shumĂ« e pakĂ«ndshme. Kur API-ja juaj shkruan mijĂ«ra mesazhe nĂ« sekondĂ«, edhe nĂ«se rrotulloheni njĂ« herĂ« nĂ« orĂ«, kjo nuk Ă«shtĂ« njĂ« mundĂ«si. Mund tĂ« shkruhet nĂ« pipe. Ndaj zhvilluesit mĂ« pyetĂ«n: "ĂfarĂ« do ndodhte nĂ«se procesi nĂ« tĂ« cilin shkruajmĂ« bie"? UnĂ« thjesht nuk e gjeta dot njĂ« pĂ«rgjigje, dhe thashĂ«: "E drejtĂ«, le tĂ« mos e bĂ«jmĂ« ashtu."
Pyetje: Pse nuk i shkruani thjesht loget në HDFS?
Përgjigje: Ky është hapi tjetër. Kemi menduar për të në fillim, por, për shkak se aktualisht nuk kemi burime për të punuar mbi këtë, ai mbetet si një zgjidhje afatgjatë.
Pyetje: Formati kolumnar do të ishte më i përshtatshëm.
Përgjigje: E kuptoj. Ne jemi 'për' me të dyja duar.
Pyetje: Ju shkruani në rsyslog. Aty mund të përdorni si TCP, ashtu edhe UDP. Por nëse përdorni UDP, si garantoni dorëzimin?
Përgjigje: Ka dy çështje. Së pari, unë i tregoj të gjithëve se nuk garantojmë dorëzimin e logeve. Sepse, kur zhvilluesit vijnë dhe thonë: 'Le të fillojmë të shkruajmë të dhëna financiare aty, dhe ju do t'i ruani diku për rast se ndodh ndonjë gjë', ne u përgjigjemi 'E shkëlqyer! Le të fillojmë të bllokojmë shënimin në socket dhe ta bëjmë këtë në transaksione, për të garantuar që ne e kemi vendosur në socket dhe të sigurohemi se ne e kemi marrë atë nga ana tjetër.' Në këtë moment, të gjithëve fillon të mos u nevojitet. Dhe pasi nuk kanë nevojë, çfarë pyetje na kanë ne? Nëse nuk doni të garantoni shënimin në socket, përse duhet të garantojmë dorëzimin? Ne bëjmë përpjekjet më të mira. Ne vërtet përpiqemi të dorëzojmë sa më shumë dhe sa më mirë, por nuk japim 100% garanci. Prandaj, nuk duhet të shkruani atje të dhëna financiare. Për këtë ka databaza me transaksione.
Pyetje: Kur API gjeneron një mesazh në log dhe transferon kontrollin te mikroshërbimet, a keni hasur ndonjëherë në problemin se mesazhet nga mikroshërbime të ndryshme vijnë në rend të gabuar? Kjo shkakton konfuzion.
PĂ«rgjigje: ĂshtĂ« normale qĂ« ato tĂ« vijnĂ« nĂ« rend tĂ« ndryshĂ«m. Duhet tĂ« jeni gati pĂ«r kĂ«tĂ«. Sepse çdo dĂ«rgesĂ« rrjetĂ«rore nuk ju garanton rendin, ose duhet tĂ« shpenzoni burime posaçërisht pĂ«r kĂ«tĂ«. NĂ«se marim depozitat e skedarĂ«ve, çdo API ruan loget nĂ« skedarin e vet. NĂ« tĂ« vĂ«rtetĂ«, rsyslog i vendos ato nĂ« kataloge. Ădo API ka loget e veta, ku mund tĂ« shkoni dhe tĂ« shikoni, dhe mĂ« pas sipas timestamp nĂ« kĂ«tĂ« log mund t'i korrespondoni. NĂ«se ata shkojnĂ« tĂ« shikojnĂ« nĂ« Graylog, atje do tĂ« sortohen sipas timestamp. Aty do tĂ« jetĂ« gjithçka nĂ« rregull.
Pyetje: Timestamp mund të ndryshojë me milisekonda.
Përgjigje: Timestamp gjenerohet nga vetë API. Kjo është, në thelb, e gjithë ideja. Ne kemi NTP. API gjeneron timestamp edhe në mesazhin vetë. Nuk është rsyslog që e shton atë.
Pyetje: Nuk është shumë e qartë si ndodhi ndërveprimi midis qendravë të të dhënave. Brenda qendrës së të dhënave është e qartë se si u mbledhën dhe u përpunuan logjet. Si ndodh ndërveprimi midis qendrave të të dhënave? Apo secila qendër të dhënash jeton jetën e saj?
PĂ«rgjigje: PjesĂ«risht. Ădo vend ndodhet nĂ« njĂ« qendĂ«r tĂ« dhĂ«nash tĂ« caktuar. Aktualisht nuk kemi shtrirje, qĂ« njĂ« vend tĂ« jetĂ« i vendosur nĂ« qendra tĂ« dhĂ«nash tĂ« ndryshme. Prandaj, nuk Ă«shtĂ« e nevojshme t'i bashkojmĂ« ato. Brenda çdo qendre ka Log Relay. Kjo Ă«shtĂ« njĂ« server Rsyslog. NĂ« tĂ« vĂ«rtetĂ«, ka dy makina menaxhimi. Ato janĂ« tĂ« konfiguruara njĂ«soj. Por pĂ«r momentin, thjesht trafiku kalon pĂ«rmes njĂ« prej tyre. Ajo agregon tĂ« gjithĂ« logjet. Ka njĂ« radhĂ« disku pĂ«r çdo rast. Ajo kompreson logjet dhe i dĂ«rgon nĂ« qendrĂ«n e dhĂ«nave qendrore (nĂ« Singapor), nga ku mĂ« pas ato dĂ«rgohen nĂ« Graylog. NĂ« çdo qendĂ«r tĂ« tĂ« dhĂ«nave ka edhe njĂ« storage tĂ« tij. NĂ« rast se na mungon lidhja, ne kemi tĂ« gjitha logjet atje. Ato do tĂ« mbesin atje. Ato do tĂ« ruhen atje.
Pyetje: Në situata jashtëzakonshme, a e merrni logun nga atje?
Përgjigje: Mund të shkoni aty (në storage) dhe të shikoni.
Pyetje: Si i monitoroni që të mos i humbni logjet?
PĂ«rgjigje: NĂ« tĂ« vĂ«rtetĂ«, i humbim logjet dhe ne e monitorojmĂ« kĂ«tĂ«. Monitorimi filloi para njĂ« muaji. NĂ« bibliotekĂ«n qĂ« pĂ«rdor Go API, ka metrika. Ajo di tĂ« numĂ«rojĂ« se sa herĂ« nuk ka mundur tĂ« shkruajĂ« nĂ« socket. Atje aktualisht ka njĂ« heuristik tĂ« zgjuar. Ka njĂ« buffer. Ai pĂ«rpiqet tĂ« shkruajĂ« mesazhin nga ai nĂ« socket. NĂ«se bufferi mbushet, ai fillon tâi heqĂ«. Dhe llogarit se sa i ka hequr. NĂ«se fillojnĂ« tĂ« mbushen numrat, ne merremi vesh pĂ«r kĂ«tĂ«. Tani ato dĂ«rgohen gjithashtu nĂ« Prometheus, dhe nĂ« Grafana mund tĂ« shihni grafikĂ«t. Mund tĂ« konfiguroni njoftimet. Por pĂ«r momentin nuk Ă«shtĂ« e qartĂ« se kujt t'ia dĂ«rgojmĂ«.
Pyetje: NĂ« elasticsearch, ju ruani logjet me rezervim. Sa replika keni?
Përgjigje: Një replikë.
Pyetje: A është vetëm një replikë?
Përgjigje: Kjo është një master dhe një replikë. Të dhënat ruhen në dy kopje.
Pyetje: A e keni modifikuar ndonjëherë madhësinë e buffer-it të rsyslog?
Përgjigje: Ne shkruajmë datagramet në një socket unix të personalizuar. Kjo na vë menjëherë një kufizim prej 128 kilobajt. Nuk mund të shkruajmë më shumë në të. Këtë e kemi specifikuar në standard. Ata që duan të kalojnë në storagë, shkruajnë 128 kilobajt. Bibliotekat, për më tepër, e presin atë dhe vendosin një flag që mesazhi është prishur. Në standardin e vet të mesazhit kemi një fushë të veçantë që tregon nëse është prishur gjatë shkrimit apo jo. Prandaj kemi mundësinë të ndjekim edhe këtë moment.
Pyetje: A shkruani JSON të prishur?
Përgjigje: JSON i prishur do të hidhet ose gjatë relay, për shkak të paketës supe të madhe. Ose do të hidhet nga Graylog, sepse nuk do të jetë në gjendje ta analizojë JSON-in. Por ka disa nuanca që duhen rregulluar, dhe ato kryesisht lidhen me rsyslog. Kam përfunduar aty disa çështje, mbi të cilat duhet ende të punojmë.
Pyetje: Pse Kafka? A keni provuar RabbitMQ? A po has problemi me Graylog nën këto ngarkesa?
PĂ«rgjigje: Nuk po funksionojmĂ« me Graylog. Por me Graylog jemi duke funksionuar. ĂshtĂ« tejet problematik. Ai Ă«shtĂ« njĂ« gjĂ« origjinale. Dhe, nĂ« tĂ« vĂ«rtetĂ«, nuk Ă«shtĂ« i nevojshĂ«m. Do tĂ« preferoja tĂ« shkruaja nga rsyslog direkt nĂ« elasticsearch dhe pastaj tĂ« shihja Kibana. Por duhet tĂ« zgjidhim çështjen me sigurimin. Ky Ă«shtĂ« njĂ« variant i mundshĂ«m i zhvillimit tonĂ«, kur do tĂ« heqim Graylog dhe do tĂ« pĂ«rdorim Kibana. Nuk do tĂ« ketĂ« kuptim tĂ« pĂ«rdorim Logstash. Sepse, mund tĂ« bĂ«j tĂ« njĂ«jtĂ«n gjĂ« me rsyslog. Dhe ai ka njĂ« modul pĂ«r tĂ« shkruar nĂ« elasticsearch. Me Graylog po pĂ«rpiqemi tĂ« jetojmĂ« ndonjĂ«herĂ«. Madje e kemi bĂ«rĂ« pak tuning. Por ka ende hapĂ«sirĂ« pĂ«r pĂ«rmirĂ«sime.
Rreth Kafka-s. Kështu ka ndodhur historikisht. Kur erdha, ajo tashmë ekzistonte, dhe ishim duke shkruar skedarët e log-ut në të. Ne thjesht ngritëm klasterin tonë dhe kaluam log-et në të. Ne e menaxhojmë, dhe e dimë si ndihen. Rreth RabbitMQ... nuk shkon mirë me RabbitMQ. Por me RabbitMQ shkojmë. E kemi në prodhim, dhe kishim disa probleme me të. Tani, para shitjeve, e kemi rregulluar dhe tani punon normalisht. Por deri atëherë nuk isha i gatshëm ta nxirrja në prodhim. Ka një moment tjetër. Graylog mund të lexojë versionin AMQP 0.9, ndërsa rsyslog mund të shkruajë versionin AMQP 1.0. Nuk ka asnjë zgjidhje që mund të bëjë të dyja. Ka vetëm njëri ose tjetri. Prandaj, për momentin vetëm Kafka. Por gjithashtu ka nuanca të veta. Sepse omkafka në atë versionin e rsyslog-it që po përdorim, mund të humbasë tërë tamponin e mesazheve që ka marrë nga rsyslog. Deri tani po pajtohemi me këtë.
Pyetje: A e përdorni Kafka-n sepse ajo tashmë ishte atje? Nuk përdoret për ndonjë qëllim tjetër?
PĂ«rgjigje: Kafka, e cila ishte atje, pĂ«rdoret nga ekipi i Data SŃience. Ky Ă«shtĂ« njĂ« projekt krejt ndryshe, pĂ«r tĂ« cilin, fatkeqĂ«sisht, nuk mund tĂ« them asgjĂ«. Nuk jam nĂ« dijeni. Ajo ka qenĂ« nĂ«n menaxhimin e ekipit tĂ« Data SŃience. Kur hodhĂ«n log-et, vendosĂ«n ta pĂ«rdorin atĂ«, pĂ«r tĂ« mos u detyruar tĂ« instalonin edhe tĂ« vetĂ«n. Tani e kemi pĂ«rditĂ«suar Graylog-un dhe humbĂ«m kompatibilitetin, sepse atje Ă«shtĂ« njĂ« version i vjetĂ«r i Kafka-s. Na duhej tĂ« krijonim tĂ« tonĂ«n. NjĂ«kohĂ«sisht u shpĂ«tuam nga ato katĂ«r tema pĂ«r çdo API. BĂ«mĂ« njĂ« temĂ« tĂ« gjerĂ« pĂ«r tĂ« gjitha live-t, njĂ« temĂ« tĂ« gjerĂ« pĂ«r tĂ« gjitha staging-t dhe thjesht i dĂ«rgojmĂ« tĂ« gjitha aty. Graylog-i i ekzekuton kĂ«to paralelisht.
Pyetje: Pse është e nevojshme kjo magji me soketët? A keni provuar të përdorni log-drajverin syslog për kontejnerët?
Përgjigje: Në atë moment kur u angazhuam me këtë çështje, marrëdhëniet tona me Docker-in ishin tensionuese. Ishte Docker 1.0 ose 0.9. Docker vetë ishte i çuditshëm. Së dyti, nëse duhet të fusësh log-et në të... Kam një dyshim të pasigurt se ai i kalon të gjitha log-et përmes vetes, përmes demonit të Docker-it. Nëse një API ynë është duke u çmendur, atëherë API-të e tjera hasin vështirësi në dërgimin e stdout dhe stderr. Nuk e di çfarë do të ndodhë nga kjo. Kam një ndjenjë intuitive se nuk duhet të përdorim drejtuesin syslog të Docker-it në këtë vend. Departamenti ynë për testimin funksional ka një kluster të vetin Graylog me log-et. Ata përdorin drejtues log-esh të Docker-it dhe duket se gjithçka shkon mirë. Por ata e shkruajnë GELF direkt në Graylog. Kur filluam këtë, duhej të funksiononte thjesht. Ndoshta më vonë, kur dikush të thotë se gjithçka funksionon mirë për një kohë të gjatë, do ta provojmë.
Pyetje: Po e bëni dërgesën mes qendrave të të dhënave me rsyslog. Pse jo me Kafka?
Përgjigje: Ne e bëjmë edhe kështu, edhe ashtu në të vërtetë. Për dy arsye. Nëse kanali është plotësisht i prishur, të gjithë log-et tanë, përfshirë ato të kompresuar, nuk kalojnë përmes tij. Ndërsa Kafka lejon që ato thjesht të humbasin gjatë procesit. Me këtë metodë ne shmangim ngjeshjen e këtyre log-eve. Thjesht përdorim Kafka në këtë rast direkt. Nëse kanali ynë është i mirë dhe duam ta lëmë atë të lirë, atëherë përdorim rsyslog-in. Por në të vërtetë, mund ta konfiguroni në mënyrë që ai vetë të hedh atë që nuk kalon. Në këtë moment ne thjesht përdorim dërgimin rsyslog direkt në disa vende, dhe Kafka në të tjerët.
Burimi: habr.com
