Žurnalai yra svarbi sistemos dalis, leidžianti suprasti, kad ji veikia (arba neveikia), kaip tikėtasi. Mikroserviso architektūroje darbas su rąstais tampa atskira specialios olimpiados disciplina. Vienu metu reikia išspręsti daugybę klausimų:
- kaip rašyti žurnalus iš programos;
- kur rašyti žurnalus;
- kaip pristatyti rąstus saugojimui ir perdirbimui;
- kaip apdoroti ir saugoti žurnalus.
Šiuo metu populiarių konteinerizavimo technologijų naudojimas prideda smėlio ant grėblio į problemos sprendimo galimybių sritį.
Būtent apie tai ir yra Jurijaus Bušmelevo pranešimo „Gėblių žemėlapis rąstų rinkimo ir pristatymo srityje“ stenograma.
Kam rūpi, prašau po katinu.
Mano vardas Jurijus Bušmelevas. Dirbu Lazada. Šiandien kalbėsiu apie tai, kaip gaminome rąstus, kaip juos rinkome ir ką ten rašome.
Iš kur mes? Kas mes esame? „Lazada“ yra pirmasis internetinis mažmenininkas šešiose Pietryčių Azijos šalyse. Visos šios šalys yra paskirstytos mūsų duomenų centruose. Šiuo metu iš viso yra 1 duomenų centrai. Kodėl tai svarbu? Nes kai kurie sprendimai buvo nulemti dėl to, kad tarp centrų yra labai silpnas ryšys. Turime mikro paslaugų architektūrą. Nustebau, kad jau turime 4 mikro paslaugų. Kai pradėjau užduotį su žurnalais, jų buvo tik 80. Be to, yra gana didelis PHP palikimo gabalas, su kuriuo taip pat tenka gyventi ir taikstytis. Visa tai šiuo metu generuoja daugiau nei 20 milijonus pranešimų per minutę visai sistemai. Toliau parodysiu, kaip mes stengiamės su tuo gyventi ir kodėl taip yra.
Jūs turite kažkaip gyventi su šiais 6 milijonais pranešimų. Ką turėtume su jais daryti? 6 milijonai pranešimų, kurių jums reikia:
- siųsti iš programos
- priimti pristatymui
- pristatyti analizei ir saugojimui.
- analizuoti
- kaip nors saugoti.
Kai pasirodė trys milijonai pranešimų, atrodžiau maždaug taip pat. Nes pradėjome vos nuo kelių centų. Aišku, kad ten rašomi programų žurnalai. Pavyzdžiui, aš negalėjau prisijungti prie duomenų bazės, galėjau prisijungti prie duomenų bazės, bet negalėjau nieko perskaityti. Bet be to, kiekviena iš mūsų mikropaslaugų taip pat rašo prieigos žurnalą. Kiekviena į mikrotarnybą gaunama užklausa įrašoma į žurnalą. Kodėl mes tai darome? Kūrėjai nori turėti galimybę atsekti. Kiekviename prieigos žurnale yra sekimo laukas, kurį naudojant speciali sąsaja išvynioja visą grandinę ir gražiai atvaizduoja pėdsaką. Pėdsakas rodo, kaip buvo įvykdyta užklausa, ir tai padeda mūsų kūrėjams greitai susidoroti su bet kokiomis neidentifikuotomis šiukšlėmis.
Kaip su tuo gyventi? Dabar trumpai aprašysiu pasirinkimų lauką – kaip ši problema apskritai sprendžiama. Kaip išspręsti rąstų rinkimo, perdavimo ir saugojimo problemą.
Kaip rašyti iš programos? Akivaizdu, kad yra įvairių būdų. Visų pirma, yra geriausia praktika, kaip mums sako madingi bendražygiai. Kaip pasakojo mūsų seneliai, yra dviejų tipų senoji mokykla. Yra ir kitų būdų.
Su rąstų rinkimu situacija yra maždaug tokia pati. Nėra daug galimybių išspręsti šią konkrečią dalį. Jų jau yra daugiau, bet dar ne tiek daug.
Tačiau su pristatymu ir vėlesne analize variantų skaičius pradeda sprogti. Dabar neaprašysiu kiekvieno varianto. Manau, kad pagrindiniai variantai yra gerai žinomi visiems, kurie domisi šia tema.
Parodysiu, kaip mes tai padarėme Lazadoje ir kaip viskas iš tikrųjų prasidėjo.
Prieš metus atvykau į Lazadą ir buvau išsiųstas į projektą apie rąstus. Tai buvo kažkas tokio. Programos žurnalas buvo įrašytas į stdout ir stderr. Viskas buvo padaryta madingai. Bet tada kūrėjai jį išmetė iš standartinių srautų, o tada infrastruktūros specialistai kaip nors išsiaiškins. Tarp infrastruktūros specialistų ir kūrėjų taip pat yra leidėjų, kurie pasakė: „na... na, tiesiog suvyniokime juos į failą su apvalkalu, ir viskas“. O kadangi visa tai buvo konteineryje, tai suvyniojo tiesiai į patį konteinerį, surašė katalogą viduje ir įdėjo ten. Manau, kad visiems gana akivaizdu, kas iš to išėjo.
Kol kas pažiūrėkime šiek tiek toliau. Kaip mes pristatėme šiuos rąstus? Kažkas pasirinko td-agent, kuris iš tikrųjų yra laisvas, bet ne visai laisvas. Vis dar nesuprantu šių dviejų projektų santykio, bet atrodo, kad jie yra apie tą patį. Ir šis sklandus, parašytas Ruby, skaitė žurnalo failus, išanalizuoja juos į JSON, naudodamas tam tikrą reguliarumą. Tada nusiunčiau juos į Kafką. Be to, Kafkoje kiekvienai API turėjome 4 atskiras temas. Kodėl 4? Kadangi yra gyvai, yra inscenizacija ir todėl, kad yra stdout ir stderr. Kūrėjai jas kuria, o infrastruktūros kūrėjai turi sukurti Kafkoje. Be to, Kafką kontroliavo kitas skyrius. Todėl reikėjo sukurti bilietą, kad kiekvienai api jie sukurtų po 4 temas. Visi apie tai pamiršo. Apskritai buvo šiukšlių ir šurmulio.
Ką mes darėme toliau su tuo? Išsiuntėme Kafkai. Tada pusė Kafkos rąstų nuskrido į Logstash. Kita pusė rąstų buvo padalinta. Vieni skrido į vieną Graylogą, kiti į kitą Graylogą. Dėl to visa tai pateko į vieną Elasticsearch klasterį. Tai yra, visa šita netvarka ir baigėsi. Nedaryk to!
Taip atrodo, pažvelgus iš viršaus. Nedaryk to! Čia probleminės sritys iš karto pažymimos skaičiais. Iš tikrųjų jų yra daugiau, tačiau 6 yra tikrai problemiški, su kuriais reikia ką nors padaryti. Dabar apie juos papasakosiu atskirai.
Čia (1,2,3) rašome failus ir atitinkamai čia yra trys grėbliai vienu metu.
Pirmasis (1) yra tas, kad turime juos kur nors parašyti. Ne visada būtų pageidautina suteikti API galimybę rašyti tiesiai į failą. Pageidautina, kad API būtų izoliuota talpykloje arba dar geriau, kad ji būtų tik skaitymo. Esu sistemos administratorius, todėl turiu šiek tiek kitokį požiūrį į šiuos dalykus.
Antras punktas (2,3) yra tai, kad į API gauname daug užklausų. API į failą įrašo daug duomenų. Failai auga. Turime juos pasukti. Nes kitaip jūs negalėsite ten kaupti jokių diskų. Juos pasukti yra blogai, nes jie daromi nukreipiant per apvalkalą į katalogą. Jokiu būdu negalime jo peržiūrėti. Negalite nurodyti programai iš naujo atidaryti rankenėlių. Nes kūrėjai į tave žiūrės kaip į kvailį: „Kokie aprašai? Paprastai rašome stdout. Infrastruktūros kūrėjai padarė kopijavimo sutrumpinimą į logrotate, o tai tiesiog padaro failo kopiją ir perrašo originalą. Atitinkamai tarp šių kopijavimo procesų vietos diske paprastai baigiasi.
(4) Mes turėjome skirtingus formatus skirtingose API. Jie šiek tiek skyrėsi, tačiau regexp turėjo būti parašytas kitaip. Kadangi visa tai kontroliavo Puppet, buvo didelis būrys klasių su savo tarakonais. Be to, dažniausiai „td-agent“ galėjo valgyti atmintį, būti kvailas, galėjo tiesiog apsimesti, kad veikia, ir nieko nedaryti. Iš šalies buvo neįmanoma suprasti, kad jis nieko nedaro. Geriausiu atveju jis nukris, o vėliau kažkas jį pasiims. Tiksliau, ateis perspėjimas, kažkas nueis ir pakels rankomis.
(6) Daugiausia šiukšlių ir atliekų buvo elasticsearch. Nes tai buvo sena versija. Nes tuo metu dar neturėjome atsidavusių meistrų. Turėjome nevienalyčių rąstų, kurių laukai galėjo persidengti. Skirtingi žurnalai iš skirtingų programų gali būti parašyti tais pačiais laukų pavadinimais, tačiau viduje gali būti skirtingi duomenys. Tai yra, vienas žurnalas ateina su sveikuoju skaičiumi lauke, pavyzdžiui, lygiu. Kitas žurnalas pateikiamas su String lygio lauke. Jei nėra statinio žemėlapio, tai toks nuostabus dalykas. Jei pasukus indeksą elasticsearch, pirmiausia atkeliauja pranešimas su eilute, tada gyvename normaliai. Bet jei pirmasis gautas iš sveikojo skaičiaus, tada visi tolesni pranešimai, gauti iš eilutės, yra tiesiog atmetami. Nes nesutampa lauko tipas.
Mes pradėjome užduoti šiuos klausimus. Nusprendėme neieškoti kaltų.
Bet reikia kažką daryti! Akivaizdu, kad turime nustatyti standartus. Jau turėjome tam tikrus standartus. Pradėjome šiek tiek vėliau. Laimei, tuo metu jau buvo patvirtintas vieno žurnalo formatas visoms API. Tai įrašyta tiesiai į paslaugų sąveikos standartus. Atitinkamai, norintys gauti žurnalus, turi juos rašyti tokiu formatu. Jei kas nors nerašo žurnalų tokiu formatu, mes nieko negarantuojame.
Toliau norėčiau sukurti vieningą žurnalų registravimo, pristatymo ir surinkimo metodų standartą. Tiesą sakant, kur juos parašyti ir kaip juos pristatyti. Ideali situacija yra tada, kai projektai naudoja tą pačią biblioteką. Yra atskira „Go“ registravimo biblioteka ir atskira PHP biblioteka. Kiekvienas, kurį turime, turėtų jais naudotis. Šiuo metu, sakyčiau, mums tai sekasi 80 proc. Tačiau kai kurie žmonės ir toliau valgo kaktusus.
Ir ten (skaidrėje) vos pradeda pasirodyti „SLA rąstų pristatymui“. Jo dar nėra, bet mes su juo dirbame. Nes labai patogu, kai infrastruktūra sako, kad jeigu tu parašysi tokiu ir tokiu formatu į tokią ir tokią vietą ir ne daugiau nei N žinučių per sekundę, tai mes greičiausiai pristatysime į tokią ir tokią vietą. Tai palengvina daugybę galvos skausmų. Jei yra SLA, tai tikrai nuostabu!
Kaip mes pradėjome spręsti problemą? Pagrindinė problema buvo su td-agent. Kur dingo mūsų rąstai, nebuvo aišku. Ar jie pristatomi? Ar jie eina? Kur jie vis dėlto yra? Todėl pirmasis punktas buvo nuspręstas pakeisti td-agent. Čia trumpai aprašiau variantus, kuo jį pakeisti.
Fluentd. Pirma, aš susidūriau su juo ankstesniame darbe, ir jis taip pat periodiškai ten krisdavo. Antra, tai tas pats, tik profilyje.
Filebeat. Kaip mums buvo patogu? Nes tai yra „Go“ ir mes turime daug „Go“ patirties. Atitinkamai, jei kas atsitiktų, galėtume kažkaip pridėti prie savęs. Štai kodėl mes jo neėmėme. Kad net nekiltų pagunda pradėti perrašinėti sau.
Akivaizdus sprendimas sistemos administratoriui yra visokie tokio kiekio syslogai (syslog-ng/rsyslog/nxlog).
Arba parašykite ką nors savo, bet mes atmetėme tai, kaip ir failą. Jei ką nors rašai, geriau parašyk ką nors naudingo verslui. Norėdami pristatyti rąstus, geriau pasiimti ką nors paruošto.
Todėl pasirinkimas iš tikrųjų buvo pasirinktas tarp syslog-ng ir rsyslog. Aš palinkau į rsyslog tiesiog todėl, kad jau turėjome rsyslog pamokas programoje Puppet ir neradau akivaizdaus skirtumo tarp jų. Kas yra syslog, kas yra syslog. Taip, kai kurių dokumentai yra prastesni, kiti – geresni. Šis gali padaryti taip, o kitas – kitaip.
Ir šiek tiek apie rsyslog. Visų pirma, tai šaunu, nes turi daug modulių. Jame yra žmogaus skaitoma RainerScript (šiuolaikinė konfigūravimo kalba). Tai nuostabi premija, kad galime imituoti td-agent elgesį naudodami standartinius įrankius, o programose niekas nepasikeitė. Tai yra, td-agent pakeičiame į rsyslog, o visa kita kol kas paliekame ramybėje. Ir iš karto gauname darbinį pristatymą. Be to, mmnormalize yra nuostabus dalykas rsyslog. Tai leidžia analizuoti žurnalus, bet nenaudojant Grok ir regexp. Tai sudaro abstrakčią sintaksės medį. Jis analizuoja žurnalus taip pat, kaip kompiliatorius analizuoja šaltinius. Tai leidžia dirbti labai greitai, sunaudoti mažai procesoriaus ir apskritai tai tikrai šaunus dalykas. Yra daugybė kitų premijų. Aš apie juos nesigilinsiu.
rsyslog turi daug kitų trūkumų. Jie yra maždaug tokie patys kaip premijos. Pagrindinės problemos yra ta, kad reikia mokėti jį virti ir pasirinkti versiją.
Nusprendėme, kad žurnalus rašysime į unix lizdą. Ir ne /dev/log, nes ten mes turime netvarką sistemos žurnalų, žurnalas yra šiame konvejeryje. Taigi rašykime į pasirinktinį lizdą. Pridėsime prie atskiro taisyklių rinkinio. Į nieką netrukdykime. Viskas bus skaidru ir suprantama. Būtent tai ir padarėme. Katalogas su šiais lizdais yra standartizuotas ir persiunčiamas į visus konteinerius. Konteineriai gali matyti jiems reikalingą lizdą, atidaryti ir į jį įrašyti.
Kodėl ne failas? Nes visi skaitė , kuri bandė persiųsti failą į docker, ir buvo aptikta, kad iš naujo paleidus rsyslog pasikeitė failo aprašas ir docker šį failą prarado. Tai palieka atvirą ką nors kita, bet ne lizdą, kuriame jie rašo. Nusprendėme, kad išspręsime šią problemą ir tuo pat metu pašalinsime blokavimo problemą.
„Rsyslog“ atlieka skaidrėje nurodytus veiksmus ir siunčia žurnalus į relę arba „Kafka“. Kafka seka senuoju būdu. Relė – bandžiau naudoti gryną rsyslog žurnalų pristatymui. Be pranešimų eilės, naudojant standartinius rsyslog įrankius. Iš esmės tai veikia.
Tačiau yra niuansų, kaip juos įtraukti į šią dalį (Logstash/Graylog/ES). Ši dalis (rsyslog-rsyslog) naudojama tarp duomenų centrų. Čia yra suspausta tcp nuoroda, kuri leidžia sutaupyti pralaidumą ir atitinkamai kažkaip padidinti tikimybę, kad užsikimšus kanalui gausime kai kuriuos žurnalus iš kito duomenų centro. Nes mes turime Indoneziją, kur viskas blogai. Čia ir slypi nuolatinė problema.
Pagalvojome, kaip iš tikrųjų galime stebėti, kokia tikimybė, kad žurnalai, kuriuos įrašėme iš programos, pasieks pabaigą? Nusprendėme sukurti metrikas. rsyslog turi savo statistikos rinkimo modulį, kuriame yra tam tikri skaitikliai. Pavyzdžiui, jis gali parodyti eilės dydį arba kiek pranešimų gauta atliekant tokį ir tokį veiksmą. Jau galima ką nors iš jų paimti. Be to, jame yra pasirinktiniai skaitikliai, kuriuos galima konfigūruoti, ir jis parodys, pavyzdžiui, pranešimų, kuriuos užregistravo kai kurios API, skaičių. Tada Python programoje parašiau rsyslog_exporter, išsiuntėme viską į Prometheus ir sukūrėme grafikus. Labai norėjome „Graylog“ metrikos, bet dar neturėjome laiko jų nustatyti.
Kokios buvo problemos? Problemos iškilo, kai (staiga!) sužinojome, kad mūsų tiesioginės API rašo 50 12 pranešimų per sekundę. Tai tik tiesioginė API be sustojimo. O „Graylog“ mums rodo tik XNUMX tūkstančių pranešimų per sekundę. Ir kilo pagrįstas klausimas: kur yra palaikai? Iš to padarėme išvadą, kad „Graylog“ tiesiog negali susidoroti. Mes pažiūrėjome, ir iš tikrųjų „Graylog“ ir „Elasticsearch“ negalėjo susidoroti su šiuo srautu.
Toliau – kiti atradimai, kuriuos padarėme kelyje.
Įrašai į lizdą blokuojami. Kaip tai nutiko? Kai pristatymui naudojau rsyslog, tam tikru momentu kanalas tarp duomenų centrų sugedo. Pristatymas sustojo vienoje vietoje, pristatymas sustojo kitur. Visa tai pasiekė mašiną su API, kurios rašo į rsyslog lizdą. Ten buvo eilė. Tada užsipildė rašymo į unix lizdą eilė, kuri pagal nutylėjimą yra 128 paketai. Ir kitas rašymas() programoje užblokuotas. Kai pažiūrėjome į biblioteką, kurią naudojame Go programose, ten buvo parašyta, kad rašymas į lizdą vyksta neblokuojančiu režimu. Buvome tikri, kad niekas nebuvo užblokuotas. Nes mes skaitome kas apie tai rašė. Bet yra momentas. Aplink šį skambutį taip pat buvo begalinis ciklas, kurio metu buvo nuolat bandoma įstumti pranešimą į lizdą. Mes jo nepastebėjome. Teko perrašyti biblioteką. Nuo to laiko jis keletą kartų keitėsi, bet dabar jau atsikratėme blokavimo visuose posistemiuose. Todėl galite sustabdyti rsyslog ir niekas nesuges.
Būtina stebėti eilių dydį, kuris padeda nelipti ant šio grėblio. Pirma, galime stebėti, kada pradedame prarasti pranešimus. Antra, galime stebėti, ar turime problemų su pristatymu.
Ir dar vienas nemalonus momentas – sustiprinti 10 kartų mikroserviso architektūroje labai paprasta. Mes neturime daug gaunamų užklausų, bet dėl grafiko, kuriuo šie pranešimai keliauja toliau, dėl prieigos žurnalų mes iš tikrųjų padidiname žurnalo apkrovą maždaug dešimt kartų. Deja, nespėjau skaičiuoti tikslių skaičių, bet mikropaslaugos yra tokios, kokios yra. Tai reikia turėti omenyje. Pasirodo, šiuo metu Lazadoje labiausiai apkraunamas rąstų surinkimo posistemis.
Kaip išspręsti elastinės paieškos problemą? Jei jums reikia greitai gauti žurnalus vienoje vietoje, kad nebėgtumėte prie visų mašinų ir nerinktumėte jų ten, naudokite failų saugyklą. Tai garantuotai veiks. Tai galima padaryti iš bet kurio serverio. Jums tereikia ten įdėti diskus ir įdiegti syslog. Po to visi rąstai bus garantuoti vienoje vietoje. Tada galite lėtai konfigūruoti elasticsearch, graylog ir dar ką nors. Bet jūs jau turėsite visus žurnalus, be to, galėsite juos saugoti tiek, kiek yra pakankamai diskų masyvų.
Mano pranešimo metu schema pradėjo atrodyti taip. Mes praktiškai nustojome rašyti į failą. Dabar greičiausiai išjungsime likusią dalį. Vietiniuose kompiuteriuose, kuriuose veikia API, nustosime rašyti į failus. Pirma, yra failų saugykla, kuri veikia labai gerai. Antra, šiose mašinose nuolat trūksta vietos, ją reikia nuolat stebėti.
Ši dalis su Logstash ir Graylog tikrai pakyla. Todėl turime jo atsikratyti. Turite pasirinkti vieną dalyką.
Nusprendėme išmesti Logstash ir Kibana. Nes mes turime apsaugos skyrių. Koks ryšys? Ryšys yra tas, kad Kibana be X-Pack ir be skydo neleidžia atskirti prieigos prie žurnalų teisių. Štai kodėl mes paėmėme „Graylog“. Jis turi viską. Man tai nepatinka, bet veikia. Įsigijome naują techninę įrangą, ten įdiegėme naują „Graylog“ ir perkėlėme visus griežtų formatų žurnalus į atskirą „Graylog“. Mes organizaciškai išsprendėme problemą su skirtingų tipų identiškais laukais.
Kas tiksliai įtraukta į naująjį „Graylog“. Mes tiesiog viską įrašėme į dokerį. Paėmėme krūvą serverių, išleidome tris Kafka egzempliorius, 7 Graylog serverių 2.3 versiją (nes norėjome 5 versijos Elasticsearch). Visa tai buvo paimta per reidus iš HDD. Matėme indeksavimo greitį iki 100 tūkstančių pranešimų per sekundę. Matėme skaičių, kad 140 terabaitų duomenų per savaitę.
Ir vėl grėblys! Turime du išpardavimus. Perkėlėme daugiau nei 6 milijonus pranešimų. Graylog neturi laiko kramtyti. Kažkaip vėl turime išgyventi.
Taip išgyvenome. Pridėjome dar kelis serverius ir SSD. Šiuo metu mes taip gyvename. Dabar jau kramtome 160 XNUMX pranešimų per sekundę. Dar nepasiekėme ribos, todėl neaišku, kiek iš tikrųjų galime iš to gauti.
Tai mūsų ateities planai. Iš jų svarbiausias turbūt yra didelis prieinamumas. Mes jo dar neturime. Keli automobiliai sukonfigūruoti vienodai, bet kol kas viskas vyksta per vieną automobilį. Reikia laiko, kol tarp jų bus nustatytas perjungimas.
Surinkite metrikas iš „Graylog“.
Nustatykite greičio ribą, kad turėtume vieną beprotišką API, kuri neužmuštų mūsų pralaidumo ir viso kito.
Ir galiausiai su kūrėjais pasirašykite kažkokį SLA, kad galėtume tiek aptarnauti. Jei parašysi daugiau, tai atsiprašau.
Ir rašyti dokumentus.
Trumpai – viso to, ką patyrėme, rezultatai. Pirma, standartai. Antra, syslog yra pyragas. Trečia, rsyslog veikia tiksliai taip, kaip parašyta skaidrėje. Ir pereikime prie klausimų.
Klausimai.
Klausimas: Kodėl nusprendei neimti... (filebeat?)
Atsakyti: Turime įrašyti į failą. Tikrai nenorėjau. Kai jūsų API rašo tūkstančius pranešimų per sekundę, net jei jį pasukate kartą per valandą, tai vis tiek nėra parinktis. Galite rašyti vamzdžiu. Į ką kūrėjai manęs paklausė: „Kas bus, jei procesas, į kurį rašome, sugenda? Tiesiog neradau, ką jiems atsakyti, ir pasakiau: „Na, gerai, nedarykim to“.
Klausimas: Kodėl tiesiog nerašant žurnalų į HDFS?
Atsakyti: Tai kitas etapas. Apie tai galvojome pačioje pradžioje, bet kadangi šiuo metu tam nėra resursų, tai priklauso nuo mūsų ilgalaikio sprendimo.
Klausimas: Labiau tiktų stulpelio formatas.
Atsakyti: Aš suprantu. Mes už tai abiem rankomis.
Klausimas: Jūs rašote į rsyslog. Čia galite naudoti ir TCP, ir UDP. Bet jei UDP, tai kaip garantuoti pristatymą?
Atsakyti: Yra du punktai. Pirma, iš karto visiems sakau, kad mes negarantuojame rąstų pristatymo. Nes kai ateina kūrėjai ir sako: „Pradėkime ten rašyti finansinius duomenis, o jūs juos kur nors mums patalpinsite, jei kas nutiktų“, mes jiems atsakome: „Puiku! Pradėkime blokuoti rašydami į lizdą, o tai darykime per sandorius, kad garantuotai jį įdėtumėte į lizdą mums ir įsitikintumėte, kad gausime iš kitos pusės. Ir šią akimirką visiems jo iškart nebereikia. Jei tai nėra būtina, kokius klausimus turėtume užduoti? Jei nenorite garantuoti rašymo į lizdą, kodėl mums reikia garantuoti pristatymą? Dedame visas pastangas. Tikrai stengiamės pristatyti kuo daugiau ir geriausiu įmanomu būdu, tačiau 100% garantijos nesuteikiame. Todėl finansinių duomenų ten rašyti nereikia. Tam yra duomenų bazės su sandoriais.
Klausimas: Kai API generuoja tam tikrą pranešimą žurnale ir perduoda valdymą mikropaslaugoms, ar susidūrėte su problema, kad pranešimai iš skirtingų mikropaslaugų gaunami netinkama tvarka? Tai sukelia painiavą.
Atsakyti: Normalu, kad jie būna skirtinga tvarka. Tam reikia pasiruošti. Kadangi bet koks pristatymas tinkle negarantuoja užsakymo arba tam turite išleisti specialius išteklius. Jei imsime failų saugyklas, kiekviena API išsaugo žurnalus savo faile. Arba, rsyslog surūšiuoja juos į katalogus. Kiekviena API turi savo žurnalus, kuriuose galite eiti ir peržiūrėti, o tada galite juos palyginti naudodami šio žurnalo laiko žymą. Jei jie ieško pilkų žurnalų, jie ten surūšiuojami pagal laiko žymą. Ten viskas bus gerai.
Klausimas: Laiko žyma gali skirtis milisekundėmis.
Atsakyti: laiko žymą generuoja pati API. Tiesą sakant, tai yra visa esmė. Mes turime NTP. API sugeneruoja laiko žymą pačiame pranešime. rsyslog jo neprideda.
Klausimas: Duomenų centrų sąveika nėra labai aiški. Duomenų centre aišku, kaip buvo renkami ir apdorojami žurnalai. Kaip vyksta sąveika tarp duomenų centrų? O gal kiekvienas duomenų centras gyvena savo gyvenimą?
Atsakyti: Beveik. Mūsų šalyje kiekviena šalis yra viename duomenų centre. Šiuo metu mes nesame pasiskirstę taip, kad viena šalis būtų skirtinguose duomenų centruose. Todėl nereikia jų derinti. Kiekviename centre yra rąstų relė. Tai yra Rsyslog serveris. Tiesą sakant, dvi valdymo mašinos. Jie turi tą patį požiūrį. Tačiau kol kas eismas vyksta tik per vieną iš jų. Jis sujungia visus žurnalus. Ji turi disko eilę tik tuo atveju. Ji atsisiunčia žurnalus ir siunčia juos į centrinį duomenų centrą (Singapūras), kur jie siunčiami į Graylog. Ir kiekvienas duomenų centras turi savo failų saugyklą. Jei mūsų ryšys nutrūktų, mes turime visus žurnalus. Jie ten liks. Ten jie bus saugomi.
Klausimas: Neįprastų situacijų atveju iš ten gaunate žurnalus?
Atsakyti: galite eiti ten (į failų saugyklą) ir pažiūrėti.
Klausimas: Kaip stebite, kad neprarastumėte žurnalų?
Atsakyti: Mes iš tikrųjų juos prarandame ir tai stebime. Stebėjimas pradėtas prieš mėnesį. Bibliotekoje, kurią naudoja Go API, yra metrikos. Ji gali suskaičiuoti, kiek kartų negalėjo rašyti į lizdą. Šiuo metu ten yra protinga euristika. Ten yra buferis. Jis bando parašyti pranešimą iš jo į lizdą. Jei buferis persipildo, jis pradeda juos nuleisti. Ir skaičiuoja, kiek jų numetė. Jei ten skaitikliai pradės pilti, apie tai sužinosime. Dabar jie taip pat ateina į „Prometheus“, o grafikus galite pamatyti „Grafana“. Galite nustatyti įspėjimus. Tačiau dar neaišku, kam juos siųsti.
Klausimas: Elasticsearch saugote rąstus su pertekliumi. Kiek kopijų turite?
Atsakyti: Viena linija.
Klausimas: Ar tai tik viena eilutė?
Atsakyti: Tai yra pagrindinis ir kopija. Duomenys saugomi dviem egzemplioriais.
Klausimas: Ar kažkaip pakoregavote rsyslog buferio dydį?
Atsakyti: Rašome datagramas į pasirinktinį unix lizdą. Tai iš karto nustato mums 128 kilobaitų limitą. Daugiau į jį rašyti negalime. Mes tai įrašėme į standartą. Norintys patekti į saugyklą rašo 128 kilobaitus. Be to, bibliotekos nutraukiamos, uždedama vėliavėlė, kad pranešimas nutraukiamas. Mūsų paties pranešimo standartas turi specialų lauką, rodantį, ar jis buvo nutrauktas įrašant, ar ne. Taigi turime galimybę sekti ir šį momentą.
Klausimas: Ar rašote sugadintą JSON?
Atsakyti: Sugadintas JSON bus atmestas per perdavimo metu, nes paketas yra per didelis. Arba „Graylog“ bus atmestas, nes negali išanalizuoti JSON. Tačiau yra niuansų, kuriuos reikia taisyti, ir jie dažniausiai yra susieti su rsyslog. Ten jau užpildžiau keletą klausimų, su kuriais dar reikia padirbėti.
Klausimas: Kodėl Kafka? Ar bandėte RabbitMQ? Ar „Graylog“ sugenda esant tokioms apkrovoms?
Atsakyti: Mums su „Graylog“ netinka. Ir Graylog mums formuojasi. Jis tikrai problemiškas. Jis yra savotiškas dalykas. Ir, tiesą sakant, to nereikia. Norėčiau rašyti iš rsyslog tiesiai į elasticsearch ir tada pažvelgti į Kibana. Bet mes turime išspręsti problemą su apsaugos darbuotojais. Tai galimas mūsų plėtros variantas, kai išmetame „Graylog“ ir naudojame „Kibana“. Logstash naudoti nėra prasmės. Nes tą patį galiu padaryti su rsyslog. Ir jame yra modulis, skirtas rašyti į elasticsearch. Bandome kažkaip gyventi su Greylogu. Net šiek tiek pakoregavome. Tačiau dar yra kur tobulėti.
Apie Kafką. Taip atsitiko istoriškai. Kai atvažiavau, jis jau buvo, prie jo jau buvo rašomi žurnalai. Mes tiesiog pakėlėme savo grupę ir perkėlėme į ją rąstus. Mes esame jo vadovybė, žinome, kaip jis jaučiasi. Kalbant apie RabbitMQ... mums tai netinka su RabbitMQ. Ir RabbitMQ mums formuojasi. Turime jį gamyboje, ir buvo su juo problemų. Dabar, prieš pardavimą, sužavėtų, ir jis pradėtų normaliai dirbti. Tačiau prieš tai nebuvau pasiruošęs išleisti jo į gamybą. Yra dar vienas punktas. „Graylog“ gali skaityti AMQP 0.9 versiją, o „rsyslog“ gali rašyti AMQP 1.0 versiją. Ir nėra vieno sprendimo, kuris galėtų padaryti abu. Tai arba vienas, arba kitas. Todėl šiuo metu tik Kafka. Tačiau tai taip pat turi savų niuansų. Kadangi mūsų naudojamos rsyslog versijos omkafka gali prarasti visą pranešimų buferį, kurį jis išėmė iš rsyslog. Kol kas mes tai pakenčiame.
Klausimas: Ar naudojate Kafka, nes ją jau turėjote? Nebenaudojate jokiam tikslui?
Atsakyti: Kafka, kuri buvo, naudojama duomenų mokslo komandos. Tai visiškai atskiras projektas, apie kurį, deja, nieko pasakyti negaliu. Aš nežinau. Jį valdė duomenų mokslų komanda. Kai buvo sukurti žurnalai, nusprendėme jį naudoti, kad neįdiegtume savo. Dabar atnaujinome „Graylog“ ir praradome suderinamumą, nes jis turi seną „Kafka“ versiją. Turėjome pradėti savo. Tuo pačiu metu mes atsikratėme šių keturių temų kiekvienai API. Mes sukūrėme vieną plačią temą visiems gyvai, vieną plačią plačią temą visiems pastatymui ir tiesiog viską sudėjome. Graylog visa tai iškrapšto lygiagrečiai.
Klausimas: Kam mums reikalingas šis šamanizmas su lizdais? Ar bandėte naudoti syslog žurnalo tvarkyklę konteineriams?
Atsakyti: Tuo metu, kai uždavėme šį klausimą, mūsų santykiai su dokeriu buvo įtempti. Tai buvo docker 1.0 arba 0.9. Pats Dockeris buvo keistas. Antra, jei dar ir rąstus įstumsi... Turiu nepatvirtintą įtarimą, kad visus rąstus perleidžia per save, per docker demoną. Jei viena API išprotėja, likusios API įstrigo dėl to, kad negali išsiųsti stdout ir stderr. Nežinau, kur tai nuves. Turiu įtarimą, kad šioje vietoje nereikia naudoti Docker syslog tvarkyklės. Mūsų funkcinių tyrimų skyrius turi savo Graylog klasterį su rąstais. Jie naudoja „Docker“ žurnalo tvarkykles ir atrodo, kad viskas ten gerai. Bet jie tuoj pat parašo GELF į Graylogą. Tuo metu, kai visa tai pradėjome, mums tiesiog reikėjo, kad tai veiktų. Galbūt vėliau, kai kas nors ateis ir pasakys, kad jau šimtą metų veikia gerai, pabandysime.
Klausimas: siuntimą tarp duomenų centrų atliekate naudodami rsyslog. Kodėl ne Kafka?
Atsakyti: Mes darome abu. Dėl dviejų priežasčių. Jei kanalas visiškai negyvas, visi mūsų rąstai, net ir suspausti, per jį neperskaitys. O Kafka leidžia paprasčiausiai juos prarasti. Taip atsikratome šių rąstų įstrigimo. Šiuo atveju mes tiesiog naudojame Kafką. Jei turime gerą kanalą ir norime jį atlaisvinti, naudojame jų rsyslogą. Bet iš tikrųjų galite jį sukonfigūruoti taip, kad jis pats numestų tai, kas netilpo. Šiuo metu mes tiesiog naudojame rsyslog pristatymą tiesiai kažkur, o Kafka - kažkur.
Šaltinis: www.habr.com