Dnevniki so pomemben del sistema, saj vam omogočajo, da razumete, ali deluje (ali ne deluje) po pričakovanjih. V pogojih mikrostoritvene arhitekture postane delo z dnevniki ločena disciplina specialne olimpijade. Obstaja veliko vprašanj, ki jih je treba obravnavati:
- kako pisati dnevnike iz aplikacije;
- kam pisati dnevnike;
- kako dostaviti hlodovino v hrambo in obdelavo;
- kako obdelovati in shranjevati dnevnike.
Uporaba trenutno priljubljenih tehnologij kontejnerizacije dodaja pesek na vrh na področju možnosti reševanja problemov.
Približno to je prepis poročila Jurija Bušmeleva "Zemljevid grablje na področju zbiranja in dostave hlodov"
Koga briga, prosim pod kat.
Moje ime je Yuri Bushmelev. Delam za Lazado. Danes bom govoril o tem, kako smo naredili naše dnevnike, kako smo jih zbirali in kaj pišemo tam.
od kod prihajamo Kdo smo mi? Lazada je spletni trgovec št. 1 v šestih državah jugovzhodne Azije. Vse te države so razporejene po podatkovnih centrih. Podatkovni centri so zdaj skupaj 4. Zakaj je to pomembno? Kajti nekatere odločitve so bile posledica dejstva, da je med centri zelo šibka povezava. Imamo mikrostoritveno arhitekturo. Presenečeno sem ugotovil, da imamo že 80 mikrostoritev. Ko sem nalogo začel z dnevniki, jih je bilo samo 20. Poleg tega obstaja precej velik del zapuščine PHP, s katero moram živeti in se sprijazniti. Vse to nam trenutno ustvari več kot 6 milijonov sporočil na minuto za sistem kot celoto. V nadaljevanju bom pokazal, kako poskušamo s tem živeti in zakaj je temu tako.
S temi 6 milijoni sporočil moraš nekako živeti. Kaj naj storimo z njimi? 6 milijonov potrebnih sporočil:
- pošlji iz aplikacije
- sprejeti za dostavo
- dostaviti v analizo in shranjevanje.
- analizirati
- nekako shraniti.
Ko je bilo tri milijone sporočil, sem imel približno enak videz. Ker smo začeli z nekaj peniji. Jasno je, da so tam zapisani dnevniki aplikacij. Na primer, ni se mogel povezati z bazo podatkov, mogel se je povezati z bazo podatkov, vendar nečesa ni mogel prebrati. Toda poleg tega vsaka naša mikrostoritev piše tudi dnevnik dostopov. Vsaka zahteva, ki prispe v mikroservis, se zabeleži v dnevnik. Zakaj to počnemo? Razvijalci želijo imeti možnost sledenja. Vsak dostopni dnevnik vsebuje polje traceid, po katerem nato poseben vmesnik odvije celotno verigo in lepo prikaže sled. Sled prikazuje, kako je zahteva potekala, kar našim razvijalcem pomaga hitreje obravnavati vse neznane smeti.
Kako živeti s tem? Zdaj bom na kratko opisal področje možnosti - kako se ta problem na splošno rešuje. Kako rešiti problem zbiranja, prenosa in skladiščenja hlodovine.
Kako pisati iz aplikacije? Jasno je, da obstajajo različni načini. Zlasti obstaja najboljša praksa, kot nam pravijo modni tovariši. Obstajata dve vrsti stare šole, kot so rekli dedki. Obstajajo tudi drugi načini.
Pri zbiranju hlodovine je situacija približno enaka. Za rešitev tega dela ni veliko možnosti. Več jih je, a še ne toliko.
Toda z dostavo in kasnejšo analizo začne število različic eksplodirati. Zdaj ne bom opisoval vsake možnosti. Mislim, da so glavne možnosti dobro znane vsem, ki jih je tema zanimala.
Pokazal vam bom, kako smo to naredili pri Lazadi in kako se je vse začelo.
Pred enim letom sem prišel v Lazado in poslali so me na projekt log. Tam je bilo takole. Dnevnik iz aplikacije je bil zapisan v stdout in stderr. Vse je bilo narejeno na moden način. Toda potem so ga razvijalci vrgli iz standardnih tokov, potem pa bodo strokovnjaki za infrastrukturo to nekako ugotovili. Med strokovnjaki za infrastrukturo in razvijalci so tudi izdajatelji, ki so rekli: "uh ... no, zavijmo jih v datoteko z lupino in to je to." In ker je vse to v kontejnerju, so ga zavili kar v sam kontejner, preslikali imenik noter in ga dali tja. Mislim, da je vsem jasno, kaj se je zgodilo.
Poglejmo še malo naprej. Kako smo dostavili te hlode. Nekdo je izbral td-agent, ki je dejansko tekoč, vendar ne povsem tekoč. Še vedno ne razumem razmerja med tema dvema projektoma, vendar se zdi, da gre za isto stvar. In ta fluentd, napisan v Rubyju, je bral dnevniške datoteke, jih razčlenil v JSON z uporabo nekaterih regularnih izrazov. Potem so jih poslali h Kafki. Poleg tega smo v Kafki imeli 4 ločene teme za vsak API. Zakaj 4? Ker obstaja živo, obstaja uprizarjanje in ker obstajata stdout in stderr. Proizvajajo jih razvijalci, infrastrukturni delavci pa jih morajo ustvariti v Kafki. Še več, Kafko je nadzoroval drug oddelek. Zato je bilo treba ustvariti vstopnico, da so tam ustvarili 4 teme za vsak api. Vsi so pozabili na to. Na splošno so bile smeti in odpadki.
Kaj smo potem storili z njim? Poslali smo ga kafki. Dalje od Kafke je polovica polen letela v Logstash. Druga polovica polen je bila razdeljena. Nekateri so leteli v en Graylog, nekateri v drugega Graylog. Posledično je vse to letelo v eno gručo Elasticsearch. Se pravi, vsa ta zmešnjava je na koncu padla tja. Tega vam ni treba narediti!
Tako je videti, če ga gledamo od zgoraj. Tega vam ni treba narediti! Tukaj so problematična področja takoj označena s številkami. Dejansko jih je več, a 6 je res problematičnih, s katerimi je treba nekaj narediti. Zdaj bom o njih povedal ločeno.
Tukaj (1,2,3) pišemo datoteke in zato so tukaj tri grablje hkrati.
Prvi (1) je, da jih moramo nekam zapisati. Ni vedno zaželeno dati API-ju možnost neposrednega pisanja v datoteko. Zaželeno je, da je API izoliran v vsebniku, še bolje pa je, da je samo za branje. Sem sistemski administrator, tako da imam na te stvari nekoliko drugačen pogled.
Druga točka (2,3) je, da imamo veliko zahtev, ki prihajajo v API. API zapiše veliko podatkov v datoteko. Datoteke rastejo. Moramo jih vrteti. Ker sicer tam ne boš mogel shraniti nobenega diska. Njihovo vrtenje je slabo, ker so prek lupine preusmerjeni v imenik. Nikakor ga ne moremo vrteti. Aplikaciji ne morete ukazati, naj znova odpre ročice. Ker vas bodo razvijalci gledali kot norca: »Kakšni deskriptorji? Na splošno pišemo v stdout. Ogrodja, narejena za copytruncate, se pretvorijo v logrotate, kar samo naredi kopijo datoteke in razdeli izvirnik. V skladu s tem med temi postopki kopiranja običajno zmanjka prostora na disku.
(4) Imeli smo različne formate v različnih API-jih. Bili so nekoliko drugačni, vendar je bilo treba regexp zapisati drugače. Ker je vse upravljal Puppet, je bil velik kup razredov s svojimi ščurki. Poleg tega bi lahko td-agent večino časa žrl spomin, bil neumen, lahko se je samo pretvarjal, da dela, in naredil ničesar. Navzven je bilo nemogoče razumeti, da ne dela ničesar. V najboljšem primeru bo padel, kasneje pa ga bo nekdo pobral. Natančneje, opozorilo bo priletelo in nekdo ga bo šel dvigniti z rokami.
(6) In največ smeti in odpadkov - to je bilo elastično iskanje. Ker je bila stara različica. Ker takrat še nismo imeli predanih mojstrov. Imeli smo heterogene dnevnike, katerih polja so se lahko prekrivala. Različni dnevniki različnih aplikacij so lahko zapisani z enakimi imeni polj, hkrati pa so lahko notri različni podatki. To pomeni, da ima en dnevnik celo število v polju, na primer raven. Drugi dnevnik je opremljen z nizom v polju ravni. V odsotnosti statičnega preslikave se izkaže tako čudovita stvar. Če je po rotaciji indeksa najprej v elasticsearch prispelo sporočilo z nizom, potem živimo normalno. In če je prvo prispelo s Celim številom, se vsa naslednja sporočila, ki so prispela z Nizom, preprosto zavržejo. Ker se vrsta polja ne ujema.
Začeli smo postavljati ta vprašanja. Odločili smo se, da ne bomo iskali krivcev.
Ampak nekaj je treba narediti! Očitno je, da moramo vzpostaviti standarde. Nekaj standardov smo že imeli. Nekatere smo pripeljali malo kasneje. Na srečo je bil takrat že odobren enoten format dnevnika za vse API-je. Zapisano je neposredno v standardih za interakcijo storitev. Zato naj tisti, ki želijo prejemati dnevnike, pišejo v tem formatu. Če nekdo ne piše dnevnikov v tem formatu, potem ne jamčimo ničesar.
Poleg tega bi želel imeti enoten standard za načine evidentiranja, dostave in zbiranja hlodovine. Pravzaprav, kam jih napisati in kako jih dostaviti. Idealna situacija je, ko projekti uporabljajo isto knjižnico. Obstaja ločena knjižnica beleženja za Go, obstaja ločena knjižnica za PHP. Vsi, ki jih imamo, bi jih morali vsi uporabljati. Trenutno bi rekel, da nam to uspeva v 80 odstotkih. Toda nekateri še naprej jedo kaktuse.
In tam (na diapozitivu) se "SLA za dostavo dnevnikov" komaj začne pojavljati. Ni še tam, vendar delamo na tem. Ker je zelo priročno, ko infra piše, da če pišeš v takem in takem formatu na to in to mesto in ne več kot N sporočil na sekundo, potem ga najverjetneje dostavimo tja. Odpravlja veliko glavobolov. Če obstaja SLA, potem je to preprosto super!
Kako smo se lotili reševanja problema? Glavni rake je bil pri td-agentu. Ni bilo jasno, kam gredo naši dnevniki. Ali so dostavljeni? Ali gredo? Kje sploh so? Zato je bilo odločeno, da se td-agent nadomesti s prvim elementom. Možnosti, s čim ga zamenjati, sem na kratko orisal tukaj.
Fluentd. Prvič, srečal sem ga v prejšnji službi in tam je tudi občasno padel. Drugič, to je isto, samo v profilu.
filebeat. Kako nam je bilo dobro? Dejstvo, da je on v Go in imamo veliko strokovnega znanja v Go. Temu primerno, če že kaj, bi ga lahko nekako dodali sebi. Zato ga nismo vzeli. Da sploh ne bi prišlo do skušnjave, da bi jo začeli prepisovati zase.
Očitna rešitev za sistemskega skrbnika so vse vrste sistemskih dnevnikov v tej količini (syslog-ng/rsyslog/nxlog).
Ali pa napišite nekaj svojega, pa smo ga zavrgli, kot tudi filebeat. Če nekaj pišete, potem je bolje, da napišete nekaj koristnega za posel. Za dostavo hlodov je bolje vzeti nekaj že pripravljenega.
Zato se je izbira dejansko zmanjšala na izbiro med syslog-ng in rsyslog. Nagnil sem se k rsyslogu preprosto zato, ker smo že imeli razrede za rsyslog v Puppet in nisem našel očitne razlike med njimi. Kaj je syslog, kaj je syslog. Ja, nekatera dokumentacija je slabša, druga boljša. On zna tako in dela drugače.
In še nekaj o rsyslogu. Prvič, kul je, ker ima veliko modulov. Ima človeku berljiv RainerScript (sodoben konfiguracijski jezik). Izjemen bonus je, da smo lahko posnemali vedenje td-agenta z njegovimi standardnimi orodji, pri aplikacijah pa se ni nič spremenilo. To pomeni, da td-agent spremenimo v rsyslog in se vsega drugega še ne dotikamo. In takoj dobimo delujočo dostavo. Naprej, mmnormalize je kul stvar pri rsyslog. Omogoča vam razčlenjevanje dnevnikov, vendar ne z Grok in regexp. Ustvari abstraktno skladenjsko drevo. Dnevnike razčlenjuje na približno enak način, kot prevajalnik razčlenjuje izvorno kodo. To vam omogoča, da delate zelo hitro, porabite malo procesorja in na splošno je to zelo kul stvar. Obstaja kup drugih bonusov. Ne bom o njih razglabljal.
rsyslog ima veliko več pomanjkljivosti. So približno enaki bonusom. Glavni problemi so, da ga morate znati kuhati in morate izbrati različico.
Odločili smo se, da bomo zapisovali dnevnike v vtičnico unix. In ne v /dev/log, ker imamo tam nered sistemskih dnevnikov, v tem cevovodu je journald. Pišimo torej v vtičnico po meri. Priložili ga bomo ločenemu naboru pravil. Ne vmešavajmo se v nič. Vse bo pregledno in razumljivo. Tako smo dejansko storili. Imenik s temi vtičnicami je standardiziran in posredovan vsem vsebnikom. Vsebniki lahko vidijo vtičnico, ki jo potrebujejo, jo odprejo in vanjo pišejo.
Zakaj ne datoteke? Ker so vsi prebrali , ki je poskušal datoteko posredovati dockerju in ugotovil, da se po ponovnem zagonu rsyslog deskriptor datoteke spremeni in docker to datoteko izgubi. Drži odprto nekaj drugega, vendar ne iste vtičnice, kjer pišejo. Odločili smo se, da bomo to težavo zaobšli in hkrati zaobšli težavo z blokiranjem.
Rsyslog izvede dejanja, navedena na diapozitivu, in pošlje dnevnike releju ali Kafki. Kafka gre po starem. Rayleigh - Poskušal sem uporabiti čisti rsyslog za dostavo dnevnikov. Brez čakalne vrste sporočil, z uporabo standardnih orodij rsyslog. V bistvu deluje.
Toda obstajajo nianse, kako jih pozneje vstaviti v ta del (Logstash/Graylog/ES). Ta del (rsyslog-rsyslog) se uporablja med podatkovnimi centri. Tukaj je stisnjena tcp povezava, ki vam omogoča, da prihranite pasovno širino in s tem nekako povečate verjetnost, da bomo prejeli nekaj dnevnikov iz drugega podatkovnega centra, ko je kanal poln. Ker imamo Indonezijo, kjer je vse slabo. Tu je stalni problem.
Razmišljali smo, kako pravzaprav spremljamo, s kakšno verjetnostjo dnevniki, ki smo jih posneli iz aplikacije, pridejo do tega konca? Odločili smo se, da bomo začeli meriti. Rsyslog ima svoj modul za zbiranje statističnih podatkov, ki ima neke vrste števce. Lahko vam na primer pokaže velikost čakalne vrste ali koliko sporočil je prispelo za to in to dejanje. Od njih že lahko kaj vzameš. Poleg tega ima števce po meri, ki jih lahko konfigurirate, in vam bodo na primer pokazali število sporočil, ki jih je zabeležil nek API. Nato sem v Pythonu napisal rsyslog_exporter, vse smo poslali Prometheusu in izrisali. Zelo smo si želeli metrike Graylog, vendar jih doslej nismo imeli časa nastaviti.
Kakšne so težave? Problem je nastal ob dejstvu, da smo ugotovili (NENADOMA!), da naši Live API-ji pišejo 50k sporočil na sekundo. To je samo Live API brez uprizarjanja. In Graylog nam pokaže samo 12 tisoč sporočil na sekundo. In pojavilo se je razumno vprašanje, kje so ostanki? Iz česar smo sklepali, da Graylog preprosto ne zmore. Pogledali smo in ugotovili, da Graylog z Elasticsearch res ni obvladal tega toka.
Nato sledijo druga odkritja, do katerih smo prišli na poti.
Zapisi v vtičnico so blokirani. Kako se je to zgodilo? Ko sem za dostavo uporabil rsyslog, smo na neki točki prekinili kanal med podatkovnimi centri. Dostava je vstala na enem mestu, dostava je vstala na drugem mestu. Vse to je prišlo do stroja z API-ji, ki pišejo v vtičnico rsyslog. Bila je čakalna vrsta. Nato se je napolnila čakalna vrsta za pisanje v vtičnico unix, ki je privzeto 128 paketov. In naslednji write() v aplikacijskih blokih. Ko smo pogledali knjižnico, ki jo uporabljamo v aplikacijah Go, je tam pisalo, da pisanje v vtičnico poteka v načinu brez blokiranja. Prepričani smo bili, da ni nič blokirano. Ker smo prebrali ki je pisal o tem. Toda obstaja trenutek. Okoli tega klica je bila tudi neskončna zanka, v kateri je prišlo do nenehnih poskusov potisniti sporočilo v vtičnico. Nismo ga opazili. Moral sem prepisati knjižnico. Od takrat se je večkrat spremenil, zdaj pa smo se znebili ključavnic v vseh podsistemih. Zato lahko zaustavite rsyslog in nič ne bo padlo.
Treba je spremljati velikost čakalnih vrst, kar pomaga, da ne stopimo na te grablje. Prvič, lahko spremljamo, kdaj začnemo izgubljati sporočila. Drugič, lahko spremljamo, da imamo v bistvu težave z dostavo.
In še en neprijeten trenutek - ojačanje za 10-krat v mikrostoritveni arhitekturi je zelo enostavno. Nimamo toliko vhodnih zahtev, ampak zaradi grafa, po katerem ta sporočila tečejo naprej, zaradi dostopovnih dnevnikov dejansko povečamo obremenitev dnevnikov za približno desetkrat. Na žalost nisem imel časa izračunati točnih številk, a mikrostoritve so, kar so. To je treba upoštevati. Izkazalo se je, da je trenutno v Lazadi najbolj obremenjen podsistem za zbiranje dnevnikov.
Kako rešiti problem z elastičnim iskanjem? Če morate hitro dobiti dnevnike na enem mestu, da ne bi tekli po vseh strojih in jih zbirali tam, uporabite shranjevanje datotek. To bo zagotovljeno delovalo. Izvaja se s katerega koli strežnika. Samo diske morate prilepiti tja in postaviti syslog. Po tem boste zagotovo imeli vse dnevnike na enem mestu. Potem bo mogoče počasi konfigurirati elasticsearch, graylog ali kaj drugega. Vse dnevnike pa boste že imeli in poleg tega jih lahko shranite, če je dovolj diskovnih polj.
V času mojega poročila je shema začela izgledati takole. Praktično smo nehali pisati v datoteko. Zdaj bomo najverjetneje izklopili ostanke. Na lokalnih računalnikih, ki izvajajo API, bomo prenehali pisati v datoteke. Najprej je tu shramba datotek, ki deluje zelo dobro. Drugič, tem strojem nenehno zmanjkuje prostora, nenehno ga morate spremljati.
Ta del z Logstashom in Graylogom je zares visok. Zato se ga morate znebiti. Izbrati morate enega.
Odločili smo se, da opustimo Logstash in Kibano. Ker imamo varnostni oddelek. Kakšna je povezava? Povezava je v tem, da Kibana brez X-Packa in brez Shielda ne omogoča razlikovanja pravic dostopa do dnevnikov. Zato so vzeli Graylog. Ima vse. Ni mi všeč, vendar deluje. Kupili smo novo strojno opremo, tam namestili svež Graylog in vse dnevnike s strogimi formati prenesli v ločen Graylog. Problem z različnimi vrstami istih področij smo organizacijsko rešili.
Kaj točno je vključeno v novi Graylog. Pravkar smo vse zapisali v doker. Vzeli smo kup strežnikov, predstavili tri instance Kafka, 7 strežnikov Graylog različice 2.3 (ker sem hotel Elasticsearch različico 5). Vse to je bilo dvignjeno na racijah s trdega diska. Videli smo stopnjo indeksiranja do 100 tisoč sporočil na sekundo. Videli smo podatek, da 140 terabajtov podatkov na teden.
In spet grablje! Čakata nas dve prodaji. Presegli smo 6 milijonov objav. Mi Graylog nimamo časa žvečiti. Nekako moraš spet preživeti.
Tako smo preživeli. Dodanih je še nekaj strežnikov in SSD-jev. Trenutno živimo tako. Sedaj že žvečimo 160k sporočil na sekundo. Nismo še dosegli meje, zato ni jasno, koliko lahko realno iz tega izvlečemo.
To so naši načrti za prihodnost. Med temi je verjetno najbolj pomembna visoka razpoložljivost. Mi ga še nimamo. Več avtomobilov je postavljenih na enak način, vendar zaenkrat vse poteka skozi en avto. Potrebno je porabiti čas za vzpostavitev samodejnega preklopa med njimi.
Zbirajte meritve iz Grayloga.
Naredite omejitev hitrosti, tako da bomo imeli en nor API, ki nam ne ubija pasovne širine in vsega drugega.
In končno, podpišite nekakšen SLA z razvijalci, da bomo lahko toliko služili. Če pišeš več, potem oprosti.
In napišite dokumentacijo.
Na kratko, rezultati vsega, kar smo doživeli. Prvič, standardi. Drugič, syslog je kolač. Tretjič, rsyslog deluje točno tako, kot je zapisano na prosojnici. In pojdimo k vprašanjem.
vprašanja.
Vprašanje: Zakaj so se odločili, da ne bodo vzeli ... (filebeat?)
Odgovorite: Pisati je treba v datoteko. Res nisem hotela. Ko vaš API zapiše na tisoče sporočil na sekundo, tudi če rotirate enkrat na uro, to še vedno ni možnost. Pišete lahko v cev. Na kar so me razvijalci vprašali: "Kaj se bo zgodilo, če proces, v katerem pišemo, pade"? Enostavno nisem našel, kaj naj jim odgovorim, in sem rekel: "No, ok, ne delajmo tega."
Vprašanje: Zakaj preprosto ne pišete dnevnikov v HDFS?
OdgovoriteO: To je naslednja stopnja. O tem smo razmišljali že na samem začetku, a ker trenutno ni sredstev za reševanje, to visi v naši dolgoročni rešitvi.
Vprašanje: Primernejša bi bila oblika stolpca.
Odgovorite: Razumem. Z obema rokama smo "za".
Vprašanje: pišete v rsyslog. Tam sta na voljo tako TCP kot UDP. Ampak, če je UDP, kako potem zagotoviti dostavo?
OdgovoriteO: Obstajata dve točki. Najprej vsem takoj povem, da za dobavo hlodovine ne jamčimo. Ker ko pridejo razvijalci in rečejo: »Začnimo tam pisati finančne podatke, pa nam jih boste nekam dali, če se kaj zgodi,« jim odgovorimo »Super! Začnimo blokirati pri pisanju v vtičnico in to storimo v transakcijah, tako da boste zagotovili, da jo boste namesto nas vstavili v vtičnico in se prepričali, da smo jo prejeli od druge strani. In v tem trenutku vsi takoj postanejo nepotrebni. In če ne, kakšna vprašanja imamo? Če ne želite zagotoviti pisanja v vtičnico, zakaj bi potem zagotavljali dostavo? Trudimo se po najboljših močeh. Res se trudimo dostaviti čim več in čim bolje, vendar ne dajemo 100% garancije. Zato vam tam ni treba pisati finančnih podatkov. Za to obstajajo transakcijske baze podatkov.
Vprašanje: Ko API ustvari neko sporočilo v dnevnik in prenese nadzor na mikrostoritve, ali ste naleteli na težavo, da sporočila iz različnih mikrostoritev prispejo v napačnem vrstnem redu? Zaradi tega nastane zmeda.
OdgovoriteO: Normalno je, da pridejo v drugačnem vrstnem redu. Na to moraš biti pripravljen. Ker vam nobena mrežna dostava ne zagotavlja reda ali pa morate za to porabiti posebna sredstva. Če vzamemo shrambo datotek, potem vsak API shrani dnevnike v svojo datoteko. Namesto tega jih rsyslog tam razgradi v imenike. Vsak API ima tam svoje dnevnike, kamor lahko greste in pogledate, nato pa jih lahko primerjate s časovnim žigom v tem dnevniku. Če gredo pogledat v Graylog, bodo tam razvrščeni po časovnem žigu. Tam bo vse v redu.
Vprašanje: Časovni žig se lahko razlikuje za milisekunde.
Odgovorite: časovni žig ustvari sam API. To je pravzaprav bistvo. Imamo NTP. API ustvari časovni žig že v samem sporočilu. Ne dodaja ga rsyslog.
Vprašanje: Interakcija med podatkovnimi centri ni zelo jasna. V okviru podatkovnega centra je razvidno, kako so se dnevniki zbirali in obdelovali. Kakšna je interakcija med podatkovnimi centri? Ali pa vsak podatkovni center živi svoje življenje?
Odgovorite: Skoraj. Vsako državo imamo v enem podatkovnem centru. Trenutno nimamo širjenja, tako da je ena država postavljena v različne podatkovne centre. Zato jih ni treba kombinirati. Znotraj vsakega centra je Log Relay. To je strežnik Rsyslog. Pravzaprav dva stroja za upravljanje. Postavljeni so na enak način. Toda zaenkrat promet poteka le skozi enega od njih. Zapisuje vse agregate. Za vsak slučaj ima čakalno vrsto na disku. Ona stisne dnevnike in jih pošlje v centralni podatkovni center (Singapur), kjer se naprej že zastrupijo v Graylogu. In vsak podatkovni center ima svojo shrambo datotek. Če izgubimo povezavo, imamo vse dnevnike tam. Tam bodo ostali. Tam bodo shranjeni.
Vprašanje: Ali od tam dobite dnevnike v neobičajnih situacijah?
Odgovorite: Lahko greš tja (v shrambo datotek) in pogledaš.
Vprašanje: Kako spremljate, da ne izgubite dnevnikov?
Odgovorite: Dejansko jih izgubljamo in to spremljamo. Monitoring se je začel pred mesecem dni. Knjižnica, ki jo uporabljajo API-ji Go, ima meritve. Lahko prešteje, kolikokrat ji ni uspelo pisati v vtičnico. Trenutno obstaja zapletena hevristika. Tam je medpomnilnik. Iz njega poskuša napisati sporočilo v vtičnico. Če se medpomnilnik prepolni, jih začne spuščati. In prešteje, koliko jih je spustil. Če se bodo tam začeli prelivati števci, bomo vedeli za to. Zdaj prihajajo tudi v prometheus, grafe pa si lahko ogledate v Grafanu. Nastavite lahko opozorila. Ni pa še jasno, komu jih poslati.
Vprašanje: V elasticsearch shranjujete dnevnike z redundanco. Koliko replik imate?
Odgovorite: Ena replika.
Vprašanje: Je samo ena vrstica?
Odgovorite: To je mojster in replika. Podatki so shranjeni v dvojniku.
Vprašanje: Ali ste nekako prilagodili velikost medpomnilnika rsyslog?
Odgovorite: Datagrame pišemo v unix vtičnico po meri. To nam takoj naloži omejitev 128 kilobajtov. Več o tem ne moremo napisati. To smo zapisali v standard. Kdor želi priti v shrambo, piše 128 kilobajtov. Knjižnice poleg tega odrežejo in postavijo zastavico, da je sporočilo odrezano. V standardu samega sporočila imamo posebno polje, ki prikazuje, ali je bilo med snemanjem odrezano ali ne. Tako imamo možnost slediti temu trenutku.
vprašanje: Ali pišete pokvarjen JSON?
Odgovorite: Pokvarjen JSON bo zavržen med posredovanjem, ker je paket prevelik. Ali pa bo Graylog opuščen, ker ne bo mogel razčleniti JSON. Toda tukaj obstajajo nianse, ki jih je treba popraviti in so večinoma vezane na rsyslog. Tam sem že izpolnil nekaj vprašanj, na katerih je treba še delati.
vprašanje: Zakaj Kafka? Ste poskusili RabbitMQ? Graylog se pod takimi obremenitvami ne sešteva?
Odgovorite: Z Graylogom ne gre. In Graylog dobiva obliko. Zanj je res problematično. On je nekakšna stvar. In pravzaprav ni potreben. Raje bi pisal iz rsyslog neposredno v elasticsearch in potem gledal Kibano. Moramo pa rešiti zadevo z varnostniki. To je možna varianta našega razvoja, ko izločimo Graylog in uporabimo Kibano. Logstash ne bo imel smisla. Ker lahko naredim isto z rsyslog. In ima modul za pisanje v elasticsearch. Z Graylogom poskušamo nekako živeti. Malo smo ga celo prilagodili. Vendar je še vedno prostor za izboljšave.
O Kafki. Tako se je zgodovinsko zgodilo. Ko sem prišel, je bil že tam in že so se mu pisali dnevniki. Pravkar smo dvignili našo gručo in vanjo prestavili polena. Upravljamo ga, vemo, kako se počuti. Kar zadeva RabbitMQ... imamo težave z RabbitMQ. In RabbitMQ razvija za nas. Imamo ga v proizvodnji in z njim so bile težave. Zdaj, pred prodajo, bi ga šamanizirali in bi začel normalno delati. Toda pred tem ga nisem bil pripravljen izdati v proizvodnjo. Obstaja še ena točka. Graylog lahko bere različico AMQP 0.9, rsyslog pa lahko piše različico AMQP 1.0. In ni ene same rešitve, ki bi zmogla oboje na sredini. Obstaja eno ali drugo. Zato trenutno samo Kafka. Vendar obstajajo tudi nianse. Ker lahko omkafka različice rsyslog, ki jo uporabljamo, izgubi celoten medpomnilnik sporočil, ki ga je pobrala iz rsyslog. Dokler to prenašamo.
vprašanje: Uporabljaš Kafko, ker si jo imel? Se ne uporablja za noben drug namen?
Odgovorite: Kafka, ki ga je uporabila ekipa Data Science. To je popolnoma ločen projekt, o katerem žal ne morem reči ničesar. Ne vem. Vodila jo je ekipa Data Science. Ko so se začela hlodi, so se odločili, da ga uporabijo, da ne bi postavili svojih. Zdaj smo posodobili Graylog in izgubili smo združljivost, ker obstaja stara različica Kafke. Morali smo narediti svoje. Hkrati smo se znebili teh štirih tem za vsak API. Naredili smo en širok top za vse v živo, en širok širok top za vse uprizoritve in vse posnamemo tam. Graylog vse to grabi vzporedno.
vprašanje: Zakaj rabimo ta šamanizem z vtičnicami? Ali ste poskusili uporabiti gonilnik dnevnika syslog za vsebnike.
Odgovorite: V času, ko smo postavili to vprašanje, smo imeli s pristaniščem napete odnose. Bil je docker 1.0 ali 0.9. Sam Docker je bil čuden. Drugič, če vanj rineš še loge ... Nepreverjeno sumim, da vse loge spušča skozi sebe, skozi docker daemon. Če imamo en API, ki ponori, bodo ostali API-ji naleteli na dejstvo, da ne morejo poslati stdout in stderr. Ne vem, kam bo to pripeljalo. Na ravni občutka sumim, da na tem mestu ni treba uporabljati gonilnika docker syslog. Naš oddelek za funkcionalno testiranje ima lastno gručo Graylog z dnevniki. Uporabljajo gonilnike dnevnika docker in zdi se, da je tam vse v redu. Graylogu pa takoj napišejo GELF. V trenutku, ko smo vse to začeli, smo potrebovali, da samo deluje. Morda kasneje, ko pride kdo in reče, da že sto let normalno dela, bomo poskusili.
vprašanje: Dostavljate med podatkovnimi centri z uporabo rsyslog. Zakaj ne na Kafko?
Odgovorite: To počnemo in tako je v resnici. Iz dveh razlogov. Če je kanal popolnoma mrtev, potem vsi naši hlodi, tudi v stisnjeni obliki, ne bodo splezali skozenj. In kafka jim omogoča, da pri tem preprosto izgubijo. Na ta način se rešimo lepljenja teh polen. V tem primeru neposredno uporabljamo Kafko. Če imamo dober kanal in ga želimo sprostiti, potem uporabimo njihov rsyslog. Toda v resnici ga lahko nastavite tako, da izpusti tisto, skozi kar ni prišel. Trenutno samo uporabljamo dostavo rsyslog neposredno nekje, nekje Kafka.
Vir: www.habr.com