Logs eru mikilvægur hluti af kerfinu, sem gerir þér kleift að skilja að það virkar (eða virkar ekki) eins og búist var við. Í örþjónustuarkitektúr verður vinna með annálum aðskildri grein fyrir sérstaka ólympíuhátíð. Fullt af spurningum þarf að leysa í einu:
- hvernig á að skrifa logs úr forriti;
- hvar á að skrifa logs;
- hvernig á að afhenda logs til geymslu og vinnslu;
- hvernig á að vinna úr og geyma annála.
Notkun á vinsælum gámatækni sem nú er til staðar bætir sandi ofan á hrífuna við valmöguleikana til að leysa vandamálið.
Þetta er nákvæmlega það sem afrit skýrslu Yuri Bushmelev „Kort af hrífum á sviði söfnunar og afhendingar á trjábolum“ fjallar um.
Fyrir áhugasama, vinsamlegast sjáið kött.
Ég heiti Yuri Bushmelev. Ég vinn hjá Lazada. Í dag mun ég tala um hvernig við gerðum annálana okkar, hvernig við söfnuðum þeim og hvað við skrifum þar.
Hvaðan erum við? Hver erum við? Lazada er númer 1 netsala í sex löndum í Suðaustur-Asíu. Öll þessi lönd eru dreift á milli gagnavera okkar. Alls eru 4 gagnaver núna. Hvers vegna er þetta mikilvægt? Vegna þess að sumar ákvarðanir voru vegna þess að það er mjög veik tengsl á milli miðstöðvanna. Við erum með örþjónustuarkitektúr. Það kom mér á óvart að við höfum nú þegar 80 örþjónustur. Þegar ég byrjaði verkefnið með logs voru þeir aðeins 20. Auk þess er frekar stór hluti af PHP arfleifð, sem ég þarf líka að lifa með og sætta mig við. Allt þetta býr nú til meira en 6 milljónir skilaboða á mínútu fyrir kerfið í heild. Næst mun ég sýna hvernig við erum að reyna að lifa með þessu og hvers vegna þetta er svona.
Þú verður einhvern veginn að lifa með þessum 6 milljón skilaboðum. Hvað eigum við að gera við þá? 6 milljónir skilaboða sem þú þarft:
- senda frá app
- taka til afhendingar
- afhenda til greiningar og geymslu.
- greina
- geyma einhvern veginn.
Þegar þrjár milljónir skilaboða birtust leit ég svipað út. Vegna þess að við byrjuðum á örfáum krónum. Það er greinilegt að þar eru skrifaðir umsóknarskrár. Til dæmis gat ég ekki tengst gagnagrunninum, ég gat tengst gagnagrunninum en gat ekki lesið neitt. En fyrir utan þetta skrifar hver örþjónusta okkar einnig aðgangsskrá. Sérhver beiðni sem berst til örþjónustunnar er skráð í log. Af hverju erum við að þessu? Hönnuðir vilja geta rakið. Hver aðgangsskrá inniheldur traceid reit, þar sem sérstakt viðmót vindur síðan upp alla keðjuna og sýnir ummerkin fallega. Ummerkin sýnir hvernig beiðnin gekk og þetta hjálpar þróunaraðilum okkar að takast á við óþekkt sorp hraðar.
Hvernig á að lifa með þessu? Nú mun ég í stuttu máli lýsa sviði valkosta - hvernig þetta vandamál er almennt leyst. Hvernig á að leysa vandamálið við að safna, senda og geyma annála.
Hvernig á að skrifa úr umsókn? Það er ljóst að það eru mismunandi leiðir. Sérstaklega eru bestu venjur, eins og tískufélagar okkar segja okkur. Það eru tvær tegundir af gömlum skóla, eins og afar okkar sögðu okkur. Það eru aðrar leiðir.
Með söfnun logs er staðan nokkurn veginn sú sama. Það eru ekki margir möguleikar til að leysa þennan tiltekna hluta. Þeir eru nú þegar fleiri, en ekki svo margir ennþá.
En með afhendingu og síðari greiningu byrjar fjöldi afbrigða að springa. Ég mun ekki lýsa hverjum valkosti núna. Ég held að helstu valmöguleikar séu vel kunnir öllum sem höfðu áhuga á efninu.
Ég skal sýna þér hvernig við gerðum það á Lazada og hvernig þetta byrjaði í raun og veru.
Fyrir ári síðan kom ég til Lazada og var sendur í verkefni um timbur. Þetta var eitthvað á þessa leið. Forritaskráin var skrifuð á stdout og stderr. Allt var gert á smart hátt. En svo köstuðu verktaki því út úr venjulegu straumunum og þá munu innviðasérfræðingar komast að því einhvern veginn. Milli innviðasérfræðinga og þróunaraðila eru líka útgáfuaðilar sem sögðu: "uh ... jæja, við skulum bara vefja þeim inn í skrá með skel, og það er það." Og þar sem þetta var allt í gámi, vöfðu þeir því beint inn í gáminn sjálfan, kortlögðu vörulistann inni og settu hann þar. Ég held að það sé öllum nokkuð augljóst hvað kom út úr því.
Við skulum líta aðeins lengra. Hvernig afhentum við þessar annálar? Einhver valdi td-agent, sem er reyndar reiprennandi, en ekki alveg reiprennandi. Ég skil samt ekki tengsl þessara tveggja verkefna, en þau virðast vera um það sama. Og þessi reiprennandi, skrifuð í Ruby, las annálaskrár, flokkaði þær í JSON með því að nota nokkrar reglubundnar tjáningar. Síðan sendi ég þá til Kafka. Þar að auki, í Kafka vorum við með 4 aðskilin efni fyrir hvert API. Hvers vegna 4? Vegna þess að það er lifandi, það er sviðsetning, og vegna þess að það er stdout og stderr. Hönnuðir búa þá til og innviðaframleiðendur verða að búa þá til í Kafka. Þar að auki var Kafka stjórnað af annarri deild. Þess vegna var nauðsynlegt að búa til miða þannig að þeir myndu búa til 4 efni fyrir hvert API. Allir gleymdu því. Almennt séð var rusl og læti.
Hvað gerðum við næst með þessu? Við sendum það til Kafka. Þá flaug helmingur stokkanna frá Kafka til Logstash. Hinum helmingi stokkanna var skipt. Sumir flugu á einn Graylog, sumir á annan Graylog. Fyrir vikið fór allt þetta í einn Elasticsearch þyrping. Það er, allt þetta rugl endaði þar. Ekki gera það!
Svona lítur þetta út ef þú horfir á það að ofan. Ekki gera það! Hér eru vandamálasvæðin strax merkt með tölustöfum. Þeir eru reyndar fleiri, en 6 eru virkilega erfiðir sem þarf að gera eitthvað í. Ég skal segja þér frá þeim sérstaklega núna.
Hér (1,2,3) skrifum við skrár og því eru þrjár hrífur hér í einu.
Fyrsta (1) er að við þurfum að skrifa þau einhvers staðar. Það væri ekki alltaf æskilegt að gefa API getu til að skrifa beint í skrá. Æskilegt er að API sé einangrað í íláti, eða jafnvel betra, að það sé skrifvarið. Ég er kerfisstjóri, svo ég hef aðeins aðra sýn á þessa hluti.
Annað atriði (2,3) er að við höfum mikið af beiðnum sem berast til API. API skrifar mikið af gögnum í skrá. Skrárnar eru að stækka. Við þurfum að snúa þeim. Vegna þess að annars muntu ekki geta safnað upp neinum diskum þar. Að snúa þeim er slæmt vegna þess að þeir eru gerðir með því að beina í gegnum skelina í möppuna. Það er engin leið að við getum endurskoðað það. Þú getur ekki sagt forritinu að opna handföngin aftur. Vegna þess að verktaki mun líta á þig eins og þú sért fífl: „Hvaða lýsingar? Við skrifum yfirleitt til stdout. Innviðaframleiðendur gerðu copytruncate til logrotate, sem gerir einfaldlega afrit af skránni og umritar frumritið. Samkvæmt því, milli þessara afritunarferla, klárast diskplássið venjulega.
(4) Við vorum með mismunandi snið í mismunandi API. Þeir voru örlítið mismunandi, en regexp þurfti að skrifa öðruvísi. Þar sem þessu öllu var stjórnað af Puppet, var mikill hópur af bekkjum með sína eigin kakkalakka. Auk þess gat td-agent oftast borðað minni, verið heimskur, hann gat bara látið eins og það væri að virka og ekkert gert. Að utan var ómögulegt að skilja að hann væri ekki að gera neitt. Í besta falli mun hann detta og einhver tekur hann upp síðar. Nánar tiltekið, viðvörun mun berast og einhver mun fara og lyfta henni með höndunum.
(6) Og mest rusl og úrgangur var elasticsearch. Vegna þess að þetta var gömul útgáfa. Vegna þess að við áttum enga hollustu meistara á þeim tíma. Við vorum með ólíka trjástokka þar sem túnin gætu skarast. Mismunandi annálar frá mismunandi forritum gætu verið skrifaðar með sömu reitnöfnum, en það gætu verið mismunandi gögn inni. Það er, einn log kemur með heiltölu í reitnum, til dæmis, level. Annar log kemur með String í vettvangsreitnum. Í fjarveru kyrrstæðrar kortlagningar er þetta svo dásamlegur hlutur. Ef, eftir að hafa snúið vísitölunni í elasticsearch, berast skilaboð með streng fyrst, þá lifum við eðlilega. En ef það fyrsta kom frá Integer, þá er öllum síðari skilaboðum sem bárust frá String einfaldlega hent. Vegna þess að reitgerðin passar ekki.
Við byrjuðum að spyrja þessara spurninga. Við ákváðum að leita ekki að þeim sem ættu sök.
En eitthvað þarf að gera! Það augljósa er að við þurfum að setja staðla. Við höfðum þegar nokkra staðla. Við byrjuðum svolítið seinna. Sem betur fer hafði eitt annálasnið fyrir öll API þegar verið samþykkt á þeim tíma. Það er skrifað beint inn í staðlana fyrir samskipti milli þjónustu. Samkvæmt því verða þeir sem vilja fá annála að skrifa þær á þessu sniði. Ef einhver skrifar ekki logs á þessu sniði, þá ábyrgjumst við ekki neitt.
Næst langar mig að búa til sameinaðan staðal fyrir aðferðir við skráningu, afhendingu og söfnun annála. Reyndar, hvar á að skrifa þær og hvernig á að skila þeim. Kjörstaðan er þegar verkefni nota sama bókasafn. Það er sérstakt skráningarsafn fyrir Go og sérstakt bókasafn fyrir PHP. Allir sem við höfum ættu að nota þau. Í augnablikinu myndi ég segja að við náum 80 prósentum árangri í þessu. En sumir halda áfram að borða kaktusa.
Og þarna (á glærunni) er „SLA fyrir afhendingarskrá“ varla farið að birtast. Það er ekki enn komið, en við erum að vinna í því. Vegna þess að það er mjög þægilegt þegar infra segir að ef þú skrifar á svona og þvílíku sniði á svona og svo stað og ekki meira en N skilaboð á sekúndu þá munum við líklegast afhenda það þangað. Það tekur í burtu mikinn höfuðverk. Ef það er SLA, þá er það bara frábært!
Hvernig byrjuðum við að leysa vandamálið? Helsta vandamálið var með td-agent. Það var ekki ljóst hvert logs okkar fóru. Eru þeir afhentir? Eru þeir að fara? Hvar eru þeir samt? Því var fyrsta atriðið ákveðið að skipta út td-agent. Ég hef lýst í stuttu máli hvaða valkostir eigi að skipta út fyrir hér.
Fljótandi. Í fyrsta lagi hitti ég hann í fyrra starfi og hann féll þar líka reglulega. Í öðru lagi er þetta sami hluturinn, aðeins í prófílnum.
skráarslag. Hvernig var það þægilegt fyrir okkur? Vegna þess að það er í Go og við höfum mikla sérfræðiþekkingu í Go. Í samræmi við það, ef eitthvað gerðist, gætum við einhvern veginn bætt við það fyrir okkur sjálf. Þess vegna tókum við það ekki. Svo að það er ekki einu sinni nein freisting að byrja að endurskrifa það fyrir sjálfan þig.
Augljós lausn fyrir kerfisstjórann er alls kyns syslogs í þessu magni (syslog-ng/rsyslog/nxlog).
Eða skrifaðu eitthvað þitt eigið, en við hentum þessu, sem og filebeat. Ef þú skrifar eitthvað er betra að skrifa eitthvað gagnlegt fyrir fyrirtæki. Til að afhenda logs er betra að taka eitthvað tilbúið.
Þess vegna kom valið í raun niður á valinu á milli syslog-ng og rsyslog. Ég hallaðist að rsyslog einfaldlega vegna þess að við vorum þegar með námskeið fyrir rsyslog í Puppet og ég fann ekki augljósan mun á þeim. Hvað er syslog, hvað er syslog. Já, sumir hafa verri skjöl, aðrir betri. Þessi getur gert þetta á þennan hátt og hinn getur gert þetta öðruvísi.
Og smá um rsyslog. Í fyrsta lagi er það flott vegna þess að það hefur mikið af einingum. Það er með mannalæsilegu RainerScript (nútíma stillingarmáli). Það er æðislegur bónus að við gætum líkt eftir hegðun td-agent með því að nota venjuleg verkfæri og ekkert breyttist fyrir forrit. Það er, við breytum td-agent í rsyslog og látum allt annað í friði í bili. Og við fáum strax virka sendingu. Næst er mmnormalize æðislegur hlutur í rsyslog. Það gerir þér kleift að flokka logs, en ekki með Grok og regexp. Það gerir abstrakt setningafræðitré. Það flokkar annála á svipaðan hátt og þýðandi flokkar heimildir. Þetta gerir þér kleift að vinna mjög hratt, neyta lítinn örgjörva og almennt er þetta mjög flottur hlutur. Það eru fullt af öðrum bónusum. Ég mun ekki dvelja við þá.
rsyslog hefur marga aðra ókosti. Þeir eru um það bil það sama og bónusar. Helstu vandamálin eru að þú þarft að vita hvernig á að elda það og þú þarft að velja útgáfuna.
Við ákváðum að skrifa logs í unix fals. Og ekki í /dev/log, því þarna erum við með rugl af kerfisskrám, journald er í þessari pípu. Svo skulum við skrifa í sérsniðna fals. Við munum hengja það við sérstakt reglusett. Við skulum ekki skipta okkur af neinu. Allt verður gagnsætt og skiljanlegt. Svo við gerðum það reyndar. Skráin með þessum innstungum er stöðluð og send í alla gáma. Gámar geta séð innstunguna sem þeir þurfa, opnað og skrifað í hana.
Af hverju ekki skrá? Vegna þess að allir hafa lesið , sem reyndi að framsenda skrá til docker, og það kom í ljós að eftir að rsyslog var endurræst breyttist skráarlýsingin og docker missti þessa skrá. Það heldur einhverju öðru opnu, en ekki falsinu þar sem þeir eru að skrifa. Við ákváðum að vinna í kringum þetta vandamál og á sama tíma myndum við vinna í kringum hindrunarvandann.
Rsyslog framkvæmir þær aðgerðir sem tilgreindar eru á glærunni og sendir logs til annað hvort gengi eða Kafka. Kafka fylgir gömlu leiðinni. Relay - ég reyndi að nota hreint rsyslog til að skila logs. Án Message Queue, með því að nota staðlað rsyslog verkfæri. Í grundvallaratriðum, það virkar.
En það eru blæbrigði hvernig á að ýta þeim inn í þennan hluta (Logstash/Graylog/ES). Þessi hluti (rsyslog-rsyslog) er notaður á milli gagnavera. Hér er þjappaður tcp hlekkur, sem gerir okkur kleift að spara bandbreidd og eykur því einhvern veginn líkurnar á því að við fáum einhvern log frá öðru gagnaveri þegar rásin er stífluð. Vegna þess að við höfum Indónesíu, þar sem allt er slæmt. Þetta er þar sem stöðug vandamál liggur.
Við hugsuðum um hvernig við getum í raun og veru fylgst með hversu líklegt er að annálarnir sem við skráðum úr forritinu nái endalokum? Við ákváðum að búa til mælikvarða. rsyslog hefur sína eigin tölfræðisöfnunareiningu, sem inniheldur einhvers konar teljara. Það getur til dæmis sýnt þér stærð biðröðarinnar, eða hversu mörg skilaboð hafa borist í svona og slíkri aðgerð. Þú getur nú þegar tekið eitthvað frá þeim. Auk þess hefur það sérsniðna teljara sem hægt er að stilla, og það mun sýna þér, til dæmis, fjölda skilaboða sem sumir API skráðu. Næst skrifaði ég rsyslog_exporter í Python og við sendum það allt til Prometheus og smíðuðum línurit. Okkur langaði mjög í Graylog mæligildi, en við höfum ekki haft tíma til að setja þær upp ennþá.
Hver voru vandamálin? Vandamál komu upp þegar við uppgötvuðum (ALLYNDIÐ!) að Live APIs okkar voru að skrifa 50 þúsund skilaboð á sekúndu. Þetta er aðeins Live API án sviðsetningar. Og Graylog sýnir okkur aðeins 12 þúsund skilaboð á sekúndu. Og eðlileg spurning vaknaði, hvar eru leifarnar? Þar sem við komumst að þeirri niðurstöðu að Graylog geti einfaldlega ekki ráðið við. Við skoðuðum og reyndar náði Graylog með Elasticsearch ekki tökum á þessu flæði.
Næst, aðrar uppgötvanir sem við gerðum á leiðinni.
Skrifað í innstunguna er læst. Hvernig gerðist það? Þegar ég var að nota rsyslog til afhendingar, á einhverjum tímapunkti bilaði rásin milli gagnaveranna. Afhending hækkaði á einum stað, afhending á öðrum stað. Allt þetta hefur komið niður á vél með API sem skrifar í rsyslog falsið. Þar var biðröð. Þá fylltist biðröðin til að skrifa í unix falsið, sem sjálfgefið er 128 pakkar. Og næsta skrifa() í forritablokkunum. Þegar við skoðuðum bókasafnið sem við notum í Go forritum var skrifað þar að ritun í falsið á sér stað í óblokkandi ham. Við vorum viss um að ekkert væri lokað. Vegna þess að við lesum sem skrifaði um það. En það er augnablik. Það var líka óendanleg lykkja í kringum þetta símtal, þar sem stöðugt var reynt að troða skilaboðum í innstunguna. Við tókum ekki eftir honum. Ég þurfti að endurskrifa bókasafnið. Síðan þá hefur það breyst nokkrum sinnum, en nú höfum við losnað við blokkun í öllum undirkerfum. Þess vegna geturðu stöðvað rsyslog og ekkert mun hrynja.
Nauðsynlegt er að fylgjast með stærð biðraðanna, sem hjálpar til við að forðast að stíga á þessa hrífu. Í fyrsta lagi getum við fylgst með því hvenær við byrjum að tapa skilaboðum. Í öðru lagi getum við fylgst með því að við eigum í vandræðum með afhendingu.
Og annað óþægilegt augnablik - mögnun um 10 sinnum í örþjónustuarkitektúr er mjög auðveld. Við höfum ekki margar beiðnir sem berast, en vegna línuritsins sem þessi skilaboð fara lengra eftir, vegna aðgangsskránna, aukum við í raun álagið um það bil tífalt. Því miður hafði ég ekki tíma til að reikna út nákvæmar tölur, en örþjónustur eru það sem þær eru. Þetta verður að hafa í huga. Það kemur í ljós að í augnablikinu er undirkerfi söfnunartrésins mest hlaðið í Lazada.
Hvernig á að leysa elasticsearch vandamál? Ef þú þarft að koma þér fljótt fyrir á einum stað til að hlaupa ekki að öllum vélunum og safna þeim þar skaltu nota skráageymslu. Þetta er tryggt að virka. Það er hægt að gera það frá hvaða netþjóni sem er. Þú þarft bara að festa diska þarna og setja upp syslog. Eftir þetta er tryggt að þú sért með alla annála á einum stað. Svo geturðu stillt hægt og rólega elasticsearch, greylog og eitthvað fleira. En þú munt nú þegar hafa alla annálana, og þar að auki geturðu geymt þá eins langt og það eru nógu margir diskar.
Þegar ég skýrði frá fór kerfið að líta svona út. Við hættum nánast að skrifa í skrána. Nú, líklega, munum við slökkva á restinni. Á staðbundnum vélum sem keyra API, munum við hætta að skrifa í skrár. Í fyrsta lagi er skráageymsla, sem virkar mjög vel. Í öðru lagi eru þessar vélar stöðugt að verða plásslausar, það þarf stöðugt að fylgjast með því.
Þessi hluti með Logstash og Graylog, það tekur virkilega á. Þess vegna þurfum við að losa okkur við það. Þú verður að velja eitt.
Við ákváðum að henda Logstash og Kibana. Vegna þess að við erum með öryggisdeild. Hver er tengingin? Tengingin er sú að Kibana án X-Pack og án Shield leyfir þér ekki að aðgreina aðgangsrétt að annálum. Þess vegna tókum við Graylog. Það hefur allt. Mér líkar það ekki, en það virkar. Við keyptum nýjan vélbúnað, settum upp ferskt Graylog þar og færðum alla loga með ströngu sniði yfir á sérstakan Graylog. Við leystum vandamálið með mismunandi gerðum af eins sviðum skipulagslega.
Hvað nákvæmlega er innifalið í nýja Graylog. Við skrifuðum bara allt í docker. Við tókum fullt af netþjónum, settum út þrjú Kafka tilvik, 7 Graylog netþjóna útgáfu 2.3 (vegna þess að við vildum Elasticsearch útgáfu 5). Allt þetta var tekið upp við árásir frá HDD. Við sáum verðtryggingu allt að 100 þúsund skilaboð á sekúndu. Við sáum töluna sem 140 terabæta af gögnum á viku.
Og aftur hrífan! Við erum með tvær útsölur framundan. Við fórum yfir 6 milljónir skilaboða. Graylog hefur ekki tíma til að tyggja. Einhvern veginn verðum við að lifa af aftur.
Svona lifðum við af. Við bættum við nokkrum netþjónum og SSD diskum í viðbót. Í augnablikinu lifum við svona. Núna erum við nú þegar að tyggja 160 þúsund skilaboð á sekúndu. Við höfum ekki náð takmörkunum ennþá, svo það er óljóst hversu mikið við getum raunverulega fengið út úr þessu.
Þetta eru áætlanir okkar fyrir framtíðina. Þar af er mikilvægast líklega mikið framboð. Við höfum það ekki ennþá. Nokkrir bílar eru settir upp á sama hátt en enn sem komið er er allt að fara í gegnum einn bíl. Það er nauðsynlegt að eyða tíma í að setja upp bilun á milli þeirra.
Safnaðu mælingum frá Graylog.
Búðu til hámarkshraða þannig að við höfum eitt brjálað API sem drepur ekki bandbreidd okkar og allt hitt.
Og að lokum, skrifaðu undir einhvers konar SLA við þróunaraðilana svo að við getum þjónað þessu mikið. Ef þú skrifar meira, þá þykir mér það leitt.
Og skrifa skjöl.
Í stuttu máli, niðurstöður alls sem við upplifðum. Í fyrsta lagi staðlar. Í öðru lagi er syslog kaka. Í þriðja lagi virkar rsyslog nákvæmlega eins og það er skrifað á glærunni. Og snúum okkur að spurningunum.
spurningar.
Spurning: Af hverju ákvaðstu að taka ekki... (filebeat?)
Svara: Við þurfum að skrifa í skrá. Ég vildi það eiginlega ekki. Þegar API þitt skrifar þúsundir skilaboða á sekúndu, jafnvel þó þú snúir því einu sinni á klukkustund, er þetta samt ekki valkostur. Þú getur skrifað í pípu. Við sem verktaki spurðu mig: "Hvað mun gerast ef ferlið sem við erum að skrifa til hrynur?" Ég fann bara ekki hverju ég ætti að svara þeim og sagði: „Jæja, allt í lagi, við skulum ekki gera það.
Spurning: Af hverju skrifarðu ekki bara logs í HDFS?
Svara: Þetta er næsti áfangi. Við hugsuðum um það strax í upphafi, en þar sem í augnablikinu eru engin úrræði til að gera þetta, hangir það í langtímalausninni okkar.
Spurning: Dálkasnið myndi henta betur.
Svara: Ég skil. Við erum fyrir það með báðum höndum.
Spurning: Þú ert að skrifa á rsyslog. Þar geturðu notað bæði TCP og UDP. En ef UDP, hvernig tryggirðu þá afhendingu?
Svara: Það eru tveir punktar. Í fyrsta lagi segi ég öllum strax að við ábyrgjumst ekki afhendingu á logum. Vegna þess að þegar verktaki koma og segja: „Við skulum byrja að skrifa fjárhagsgögn þar, og þú munt setja þau einhvers staðar fyrir okkur ef eitthvað gerist,“ svörum við þeim, „Frábært! Byrjum að loka á að skrifa í falsinn og gerum það í viðskiptum, svo að þú sért tryggð að setja það í falsið fyrir okkur og ganga úr skugga um að við höfum fengið það hinum megin. Og á þessari stundu þurfa allir þess strax ekki lengur. Og ef ekki, hvaða spurningar höfum við þá? Ef þú vilt ekki ábyrgjast skrif í innstunguna, hvers vegna ættum við þá að tryggja afhendingu? Við erum að gera okkar besta. Við reynum í raun að afhenda eins mikið og hægt er og eins vel og hægt er, en við veitum ekki 100% ábyrgð. Þess vegna þarftu ekki að skrifa fjárhagsgögn þar. Það eru til viðskiptagagnagrunnar fyrir þetta.
Spurning: Þegar API býr til einhver skilaboð í skránni og flytur stjórn á örþjónustur, hefur þú lent í því vandamáli að skilaboð frá mismunandi örþjónustu berast í rangri röð? Þetta veldur ruglingi.
Svara: Það er eðlilegt að þeir komi í mismunandi röð. Þú þarft að vera tilbúinn fyrir þetta. Vegna þess að öll netsending tryggir þér ekki pöntun eða þú þarft að eyða sérstöku fjármagni í þetta. Ef við tökum skráageymslur, þá vistar hvert API annála í sína eigin skrá. Frekar, rsyslog sundrar þeim í möppur þar. Hvert API hefur sína eigin loga þar, þar sem þú getur farið og skoðað, og svo geturðu borið þá saman með því að nota tímastimpilinn í þessum log. Ef þeir fara að leita í Graylog, þá verða þeir flokkaðir eftir tímastimpli. Þar verður allt í lagi.
Spurning: Tímastimpill getur verið breytilegur eftir millisekúndum.
Svara: Tímastimpill er búinn til af API sjálfu. Þetta er í rauninni allt málið. Við erum með NTP. API býr til tímastimpil í skilaboðunum sjálfum. rsyslog bætir því ekki við.
Spurning: Samspil gagnavera er ekki mjög skýrt. Innan gagnaversins er ljóst hvernig annálum var safnað og unnið. Hvernig fer samspil gagnavera fram? Eða lifir hver gagnaver sínu eigin lífi?
Svara: Næstum. Í okkar landi er hvert land staðsett í einu gagnaveri. Í augnablikinu höfum við ekki dreifingu þannig að eitt land er staðsett í mismunandi gagnaverum. Þess vegna er engin þörf á að sameina þau. Hver miðstöð er með Log Relay inni. Þetta er Rsyslog þjónn. Reyndar tvær stjórnunarvélar. Þeir hafa sama viðhorf. En í bili fer umferð bara í gegnum einn þeirra. Það safnar saman öllum annálum. Hún er með diskabiðröð til öryggis. Það hleður niður annálunum og sendir þá í miðlæga gagnaverið (Singapúr), þar sem þeir eru síðan sendir til Graylog. Og hver gagnaver hefur sína eigin skráageymslu. Ef tengingin okkar rofnar, höfum við alla annálana þar. Þeir verða þar áfram. Þar verða þeir geymdir.
Spurning: Ef um óeðlilegar aðstæður er að ræða, færðu logs þaðan?
Svara: Þú getur farið þangað (í skráageymsluna) og skoðað.
Spurning: Hvernig fylgist þú með því að þú sért ekki að missa logs?
Svara: Við erum í raun að missa þá, og við erum að fylgjast með því. Vöktun hófst fyrir mánuði síðan. Bókasafnið sem Go APIs nota hefur mælikvarða. Hún getur talið hversu oft hún gat ekki skrifað í innstunguna. Það er nú snjall heuristic þarna. Það er biðminni þar. Það reynir að skrifa skilaboð frá því í innstunguna. Ef biðminni flæðir yfir byrjar hann að sleppa þeim. Og hann telur hversu mörgum þeirra hann sleppti. Ef mælarnir fara að flæða þarna þá fáum við að vita af því. Þeir eru nú líka að koma til prómeþeifs og má sjá línuritin í Grafana. Þú getur sett upp viðvaranir. En það er ekki enn ljóst hverjum á að senda þær.
Spurning: Í elasticsearch geymir þú annála með offramboði. Hvað áttu margar eftirlíkingar?
Svara: Ein lína.
Spurning: Er þetta bara ein lína?
Svara: Þetta er meistarinn og eftirmyndin. Gögnin eru geymd í tveimur eintökum.
Spurning: Lagaðirðu á einhvern hátt stærð rsyslog biðminni?
Svara: Við skrifum gagnagröf í sérsniðna unix fals. Þetta setur okkur strax 128 kílóbæti takmörk. Við getum ekki skrifað meira um það. Við höfum skrifað þetta inn í staðalinn. Hver vill komast í geymslu, þeir skrifa 128 kílóbæti. Bókasöfn, þar að auki, skera burt, og setja fána um að skilaboðin séu klippt af. Staðall okkar fyrir skilaboðin sjálf hefur sérstakan reit sem sýnir hvort það var klippt af við upptöku eða ekki. Þannig að við höfum tækifæri til að fylgjast með þessari stundu.
Spurning: Skrifar þú bilað JSON?
Svara: Brotið JSON verður hent annað hvort á meðan á gengi stendur vegna þess að pakkinn er of stór. Eða Graylog verður sleppt, vegna þess að það mun ekki geta þáttað JSON. En það eru blæbrigði sem þarf að laga og þau eru aðallega bundin við rsyslog. Þar hef ég þegar fyllt út nokkur atriði sem enn á eftir að vinna í.
Spurning: Af hverju Kafka? Hefur þú prófað RabbitMQ? Mistekst Graylog undir slíku álagi?
Svara: Það gengur ekki upp hjá okkur með Graylog. Og Graylog er að taka á sig mynd fyrir okkur. Hann er virkilega vandræðalegur. Hann er sérkennilegur hlutur. Og í rauninni er þess ekki þörf. Ég myndi frekar vilja skrifa frá rsyslog beint í elasticsearch og horfa svo á Kibana. En við þurfum að útkljá málið við öryggisverðina. Þetta er mögulegur valkostur fyrir þróun okkar, þegar við hendum Graylog út og notum Kibana. Það þýðir ekkert að nota Logstash. Vegna þess að ég get gert það sama með rsyslog. Og það hefur einingu til að skrifa í elasticsearch. Við erum að reyna að lifa einhvern veginn með Graylog. Við bættum það meira að segja aðeins upp. En það er enn hægt að gera betur.
Um Kafka. Svona gerðist þetta sögulega. Þegar ég kom var það þegar til staðar og þegar verið var að skrifa logs á það. Við einfaldlega lyftum klasanum okkar og færðum inn í hann stokka. Við erum stjórn hans, við vitum hvernig honum líður. Hvað RabbitMQ varðar... það gengur ekki upp hjá okkur með RabbitMQ. Og RabbitMQ er að taka á sig mynd fyrir okkur. Við erum með það í framleiðslu og það voru vandamál með það. Nú, fyrir söluna, myndu þeir heilla hann og hann myndi byrja að vinna venjulega. En áður var ég ekki tilbúinn að gefa hana út í framleiðslu. Það er einn punktur í viðbót. Graylog getur lesið útgáfu AMQP 0.9 og rsyslog getur skrifað útgáfu AMQP 1.0. Og það er ekki ein lausn í miðjunni sem getur gert hvort tveggja. Það er annað hvort eitt eða annað. Því í augnablikinu aðeins Kafka. En það hefur líka sín eigin blæbrigði. Vegna þess að omkafka útgáfunnar af rsyslog sem við notum getur tapað öllu skilaboðabuffinu sem það rakaði út úr rsyslog. Í bili sættum við okkur við það.
Spurning: Ertu að nota Kafka vegna þess að þú áttir það þegar? Ekki lengur notað í neinum tilgangi?
Svara: Kafka, sem var, er notað af Data Science teyminu. Þetta er algjörlega sérstakt verkefni, sem ég get því miður ekki sagt neitt um. Ég veit ekki. Það var rekið af Data Science teyminu. Þegar annálarnir voru búnir til ákváðum við að nota það til að setja ekki upp okkar eigin. Nú höfum við uppfært Graylog og við höfum misst eindrægni vegna þess að það er með gamla útgáfu af Kafka. Við urðum að stofna okkar eigin. Á sama tíma losuðum við við þessi fjögur efni fyrir hvert API. Við bjuggum til einn breiðan topp fyrir alla í beinni, einn breiðan topp fyrir alla sviðsetningu og við tökum bara allt þar. Graylog skafar þetta allt út samhliða.
Spurning: Af hverju þurfum við þennan shamanisma með innstungum? Hefur þú prófað að nota syslog log driverinn fyrir gáma?
Svara: Þegar við spurðum þessarar spurningar var samband okkar við hafnarmanninn spennuþrungið. Það var docker 1.0 eða 0.9. Docker sjálfur var undarlegur. Í öðru lagi, ef þú ýtir líka inn logs inn í það... Ég hef óstaðfestan grun um að það komi öllum logs í gegnum sig, í gegnum docker púkann. Ef eitt API klikkar, þá eru restin af API fast í þeirri staðreynd að þeir geta ekki sent stdout og stderr. Ég veit ekki hvert þetta leiðir. Ég hef grun um að það sé engin þörf á að nota Docker syslog driverinn á þessum stað. Hagnýtur prófunardeild okkar hefur sinn eigin Graylog þyrping með annálum. Þeir nota Docker log rekla og allt virðist vera í lagi þar. En þeir skrifa GELF strax til Graylog. Á þeim tíma þegar við byrjuðum á þessu öllu þurftum við bara að þetta virkaði. Kannski seinna, þegar einhver kemur og segir að þetta hafi virkað fínt í hundrað ár, munum við reyna.
Spurning: Þú framkvæmir afhendingu milli gagnavera með því að nota rsyslog. Af hverju ekki Kafka?
Svara: Við gerum bæði í rauninni. Af tveimur ástæðum. Ef rásin er algjörlega dauð, þá munu allir logarnir okkar, jafnvel í þjöppuðu formi, ekki skríða í gegnum hana. Og Kafka gerir þér kleift að tapa þeim einfaldlega í því ferli. Þannig losnum við við að þessir stokkar festist. Við erum bara að nota Kafka beint í þessu tilfelli. Ef við erum með góða rás og viljum losa hana, þá notum við rsyslog þeirra. En í raun er hægt að stilla það þannig að það sjálft sleppir því sem passaði ekki í gegn. Í augnablikinu notum við bara rsyslog sendingu beint einhvers staðar og Kafka einhvers staðar.
Heimild: www.habr.com