Dnevnici su važan dio sustava, omogućujući vam da shvatite da radi (ili ne radi) kako se očekuje. U uvjetima mikroservisne arhitekture, rad sa logom postaje zasebna disciplina Specijalne olimpijade. Postoji mnogo problema kojima se treba pozabaviti:
- kako pisati zapise iz aplikacije;
- gdje pisati dnevnike;
- kako dostaviti trupce na skladištenje i obradu;
- kako obraditi i pohraniti trupce.
Korištenje trenutno popularnih tehnologija kontejnerizacije dodaje pijesak na vrh grablji u polju mogućnosti rješavanja problema.
Otprilike ovo je transkript izvještaja Jurija Bušmeleva "Karta grablje u polju sakupljanja i isporuke trupaca"
Koga briga neka pod mačku.
Moje ime je Yuri Bushmelev. Radim za Lazadu. Danas ću pričati o tome kako smo napravili naše dnevnike, kako smo ih skupljali i što tamo pišemo.
odakle smo Tko smo mi? Lazada je broj 1 online trgovac u šest zemalja jugoistočne Azije. Sve te zemlje raspoređene su po podatkovnim centrima. Sada postoje ukupno 4 podatkovna centra. Zašto je to važno? Jer neke su odluke bile zbog činjenice da postoji vrlo slaba veza između centara. Imamo mikroservisnu arhitekturu. Iznenadio sam se kada sam otkrio da već imamo 80 mikroservisa. Kad sam započeo zadatak sa zapisima, bilo ih je samo 20. Osim toga, tu je i prilično veliki dio PHP naslijeđa, s kojim također moram živjeti i podnositi ga. Sve to za nas trenutno generira više od 6 milijuna poruka u minuti za sustav u cjelini. Dalje ću pokazati kako mi pokušavamo živjeti s tim i zašto je to tako.
Moraš nekako živjeti s ovih 6 milijuna poruka. Što da radimo s njima? Potrebno 6 milijuna poruka:
- poslati iz aplikacije
- prihvatiti za isporuku
- dostaviti na analizu i skladištenje.
- analizirati
- spremiti nekako.
Kad je bilo tri milijuna poruka, imao sam otprilike isti pogled. Jer smo počeli s nekim novčićima. Jasno je da se tamo pišu zapisnici aplikacija. Na primjer, nije se mogao povezati s bazom podataka, mogao se povezati s bazom podataka, ali nije mogao nešto pročitati. Ali osim toga, svaki naš mikroservis također piše pristupni dnevnik. Svaki zahtjev koji stigne mikroservisu upisuje se u dnevnik. Zašto ovo radimo? Programeri žele imati mogućnost praćenja. Svaki log pristupa sadrži traceid polje prema kojem posebno sučelje odmotava cijeli lanac i lijepo prikazuje trag. Praćenje pokazuje kako je zahtjev prošao, a to pomaže našim programerima da se brže pozabave svim nepoznatim otpadom.
Kako živjeti s tim? Sada ću ukratko opisati polje opcija - kako se ovaj problem općenito rješava. Kako riješiti problem prikupljanja, prijenosa i skladištenja trupaca.
Kako pisati iz aplikacije? Jasno je da postoje različiti načini. Konkretno, postoji najbolja praksa, kako nam govore moderni drugovi. Postoje dvije vrste stare škole, kako su djedovi govorili. Ima i drugih načina.
Kod prikupljanja trupaca situacija je otprilike ista. Nema toliko mogućnosti za rješavanje ovog dijela. Ima ih još, ali još ne toliko.
Ali s isporukom i naknadnom analizom, broj varijacija počinje eksplodirati. Neću sada opisivati svaku opciju. Mislim da su glavne opcije dobro poznate svima koji su bili zainteresirani za ovu temu.
Pokazat ću vam kako smo to radili u Lazadi i kako je sve počelo.
Prije godinu dana došao sam u Lazadu i poslali su me na log project. Tamo je bilo ovako. Dnevnik iz aplikacije zapisan je u stdout i stderr. Sve je urađeno na moderan način. Ali onda su ga programeri izbacili iz standardnih tokova, a onda će stručnjaci za infrastrukturu to nekako shvatiti. Između stručnjaka za infrastrukturu i programera, postoje i izdavači koji su rekli: "uh ... dobro, samo ih zamotajmo u datoteku s ljuskom, i to je to." A budući da je sve ovo u kontejneru, zamotali su to u sam kontejner, mapirali imenik unutra i stavili ga tamo. Mislim da je svima prilično jasno što se dogodilo.
Pogledajmo malo dalje. Kako smo isporučili ove trupce. Netko je odabrao td-agent, koji je zapravo tečan, ali ne sasvim tečan. Još uvijek ne razumijem odnos ova dva projekta, ali čini se da se radi o istoj stvari. A ovaj fluentd, napisan u Rubyju, čitao je datoteke dnevnika, raščlanjivao ih u JSON koristeći neke regularne izraze. Zatim su poslani Kafki. Štoviše, u Kafki smo imali 4 zasebne teme za svaki API. Zašto 4? Zato što postoji uživo, postoji staging, i zato što postoje stdout i stderr. Programeri ih proizvode, a infrastrukturni radnici ih moraju stvoriti u Kafki. Štoviše, Kafku je kontrolirao drugi odjel. Stoga je bilo potrebno napraviti tiket tako da su tamo napravili 4 teme za svaki api. Svi su to zaboravili. Općenito, bilo je to smeće i otpad.
Što smo sljedeće učinili s njim? Poslali smo ga kafki. Dalje od Kafke polovica balvana odletjela je u Logstash. Druga polovica cjepanica je podijeljena. Neki su odletjeli u jedan Graylog, neki u drugi Graylog. Kao rezultat toga, sve je to odletjelo u jedan Elasticsearch klaster. Odnosno, sav ovaj nered je na kraju pao tamo. Ne morate to učiniti!
Ovako to izgleda gledano odozgo. Ne morate to učiniti! Ovdje su problematična područja odmah označena brojevima. Zapravo ih ima više, ali 6 je stvarno problematičnih, s kojima treba nešto poduzeti. O njima ću sada reći zasebno.
Ovdje (1,2,3) pišemo datoteke i, shodno tome, ovdje postoje tri rake odjednom.
Prvi (1) je da ih moramo negdje napisati. Nije uvijek poželjno API-ju dati mogućnost izravnog pisanja u datoteku. Poželjno je da API bude izoliran u spremniku, a još bolje da bude samo za čitanje. Ja sam administrator sustava, pa imam malo alternativniji pogled na te stvari.
Druga točka (2,3) je da imamo puno zahtjeva koji dolaze prema API-ju. API zapisuje mnogo podataka u datoteku. Datoteke rastu. Moramo ih rotirati. Jer inače tamo nećete moći spremiti nijedan disk. Njihovo rotiranje je loše jer se preko ljuske preusmjeravaju u direktorij. Nema šanse da ga možemo rotirati. Ne možete reći aplikaciji da ponovno otvori ručke. Jer programeri će vas gledati kao budalu: “Kakvi deskriptori? Općenito pišemo u stdout. Frameworks napravljen copytruncate u logrotate, koji samo radi kopiju datoteke i spaja izvornik. Sukladno tome, između ovih procesa kopiranja, prostor na disku obično završava.
(4) Imali smo različite formate u različitim API-jima. Bili su malo drugačiji, ali regexp je morao biti drugačije napisan. Budući da je svime upravljao Puppet, postojala je velika hrpa razreda sa svojim vlastitim žoharima. Osim toga, td-agent je većinu vremena mogao gristi sjećanje, biti glup, mogao se samo pretvarati da radi i ne raditi ništa. Izvana je bilo nemoguće shvatiti da ne radi ništa. U najboljem će slučaju pasti, a netko će ga kasnije podići. Točnije, doletjet će uzbuna, a netko će otići dignuti rukama.
(6) A najviše smeća i otpada - bilo je to elastično pretraživanje. Jer je to bila stara verzija. Jer u to vrijeme nismo imali posvećene majstore. Imali smo heterogene dnevnike čija su se polja mogla preklapati. Različiti dnevnici različitih aplikacija mogu se pisati s istim nazivima polja, ali u isto vrijeme unutra mogu biti različiti podaci. Odnosno, jedan dnevnik dolazi s cijelim brojem u polju, na primjer, razina. Još jedan zapisnik dolazi s nizom u polju razine. U nedostatku statičkog mapiranja, ispada tako divna stvar. Ako je nakon rotacije indeksa prva stigla poruka sa stringom u elasticsearch, onda živimo normalno. A ako je prva stigla s Integerom, onda se sve sljedeće poruke koje su stigle s Stringom jednostavno odbacuju. Budući da se vrsta polja ne podudara.
Počeli smo postavljati ta pitanja. Odlučili smo da nećemo tražiti krivce.
Ali nešto treba poduzeti! Očigledno je da moramo uspostaviti standarde. Već smo imali neke standarde. Neke smo donijeli malo kasnije. Srećom, jedinstveni format dnevnika za sve API-je već je tada odobren. Zapisano je izravno u standardima interakcije usluge. Sukladno tome, oni koji žele primati zapisnike trebaju ih pisati u ovom formatu. Ako netko ne piše zapisnike u ovom formatu, ne jamčimo ništa.
Nadalje, želio bih imati jedinstven standard za metode evidentiranja, dostave i prikupljanja trupaca. Zapravo, gdje ih napisati i kako ih dostaviti. Idealna situacija je kada projekti koriste istu knjižnicu. Postoji zasebna biblioteka za bilježenje za Go, postoji zasebna biblioteka za PHP. Svi koje imamo, svi bi ih trebali koristiti. Trenutačno bih rekao da nam to uspijeva 80 posto. Ali neki nastavljaju jesti kaktuse.
A tamo (na slajdu) se "SLA za isporuku dnevnika" jedva počinje pojavljivati. Još nije tu, ali radimo na tome. Jer je jako zgodno kad infra kaže da ako pišeš u tom i tom formatu na to i to mjesto i ne više od N poruka u sekundi, onda ćemo najvjerojatnije tamo dostaviti. Otklanja mnoge glavobolje. Ako postoji SLA, onda je to jednostavno super!
Kako smo počeli rješavati problem? Glavni rake je bio s td-agentom. Bilo je nejasno kamo idu naši dnevnici. Jesu li isporučeni? Idu li? Gdje su oni uopće? Stoga je odlučeno da se td-agent zamijeni prvom stavkom. Ovdje sam ukratko opisao mogućnosti čime ga zamijeniti.
Tečno Prvo, naišao sam na njega na prethodnom poslu, a on je također povremeno padao tamo. Drugo, ovo je isto, samo u profilu.
filebeat. Kako nam je bilo dobro? Činjenica da je on u Gou, a mi imamo veliku stručnost u Gou. Sukladno tome, ako išta, mogli bismo to nekako dodati sebi. Zato ga nismo uzeli. Kako ne bi bilo ikakvog iskušenja da ga počnete prepisivati za sebe.
Očito rješenje za sysadmina su sve vrste syslogova u ovoj količini (syslog-ng/rsyslog/nxlog).
Ili napišite nešto svoje, ali smo to odbacili, kao i filebeat. Ako nešto pišete, onda je bolje da napišete nešto korisno za posao. Za isporuku trupaca bolje je uzeti nešto gotovo.
Stoga se izbor zapravo sveo na izbor između syslog-ng i rsyslog. Priklonio sam se rsyslogu jednostavno zato što smo već imali klase za rsyslog u Puppetu i nisam našao očitu razliku među njima. Što je syslog, što je syslog. Da, neka je dokumentacija lošija, neka bolja. On zna ovako, a radi drugačije.
I malo o rsyslogu. Prvo, cool je jer ima puno modula. Ima čovjeku čitljiv RainerScript (moderni konfiguracijski jezik). Sjajan bonus je to što smo mogli emulirati ponašanje td-agenta s njegovim standardnim alatima, a ništa se nije promijenilo za aplikacije. Odnosno, mijenjamo td-agent u rsyslog, a sve ostalo još ne diramo. I odmah dobivamo radnu dostavu. Dalje, mmnormalize je cool stvar kod rsyslog-a. Omogućuje vam analizu zapisa, ali ne s Grokom i regexpom. To čini apstraktno stablo sintakse. Raščlanjuje zapisnike na sličan način na koji kompajler analizira izvorni kod. To vam omogućuje da radite vrlo brzo, trošite malo CPU-a i, općenito, to je vrlo cool stvar. Postoji hrpa drugih bonusa. Neću se zadržavati na njima.
rsyslog ima puno više nedostataka. Otprilike su isti kao bonusi. Glavni problemi su što ga morate znati skuhati i trebate odabrati verziju.
Odlučili smo da ćemo zapisivati zapise u unix utičnici. I ne u /dev/log, jer tamo imamo nered sistemskih zapisa, tu je journald u ovom cjevovodu. Pa hajde pisati u prilagođenu utičnicu. Priložit ćemo ga zasebnom skupu pravila. Nemojmo se ništa miješati. Sve će biti transparentno i razumljivo. Tako smo zapravo i učinili. Imenik s ovim utičnicama je standardiziran i proslijeđen svim spremnicima. Kontejneri mogu vidjeti socket koji im je potreban, otvoriti ga i pisati u njega.
Zašto ne datoteku? Jer svi su čitali , koji je pokušao proslijediti datoteku dockeru i otkrio da se nakon ponovnog pokretanja rsyslog deskriptor datoteke mijenja i docker gubi ovu datoteku. Drži otvoreno još nešto, ali ne istu utičnicu gdje pišu. Odlučili smo da ćemo zaobići ovaj problem, a u isto vrijeme i problem blokiranja.
Rsyslog radi radnje naznačene na slajdu i šalje zapisnike releju ili Kafki. Kafka ide starim putem. Rayleigh - Pokušao sam koristiti čisti rsyslog za isporuku zapisa. Bez reda poruka, koristeći standardne rsyslog alate. Uglavnom, radi.
Ali postoje nijanse u tome kako ih kasnije ubaciti u ovaj dio (Logstash/Graylog/ES). Ovaj dio (rsyslog-rsyslog) koristi se između podatkovnih centara. Ovdje je komprimirana tcp veza koja vam omogućuje uštedu propusnosti i, sukladno tome, na neki način povećava vjerojatnost da ćemo primiti neke zapise iz drugog podatkovnog centra kada je kanal pun. Jer imamo Indoneziju, gdje je sve loše. Tu leži stalni problem.
Razmišljali smo o tome kako zapravo pratimo, s kojom vjerojatnošću logovi koje smo snimili iz aplikacije stižu do tog kraja? Odlučili smo pokrenuti metriku. Rsyslog ima vlastiti modul za prikupljanje statistike, koji ima neku vrstu brojača. Na primjer, može vam pokazati veličinu reda čekanja ili koliko je poruka stiglo za tu i tu akciju. Od njih već možete nešto uzeti. Osim toga, ima prilagođene brojače koje možete konfigurirati, a pokazat će vam, na primjer, broj poruka koje je neki API zabilježio. Zatim sam napisao rsyslog_exporter u Pythonu i sve smo to poslali Prometheusu i iscrtali. Stvarno smo željeli Graylog metriku, ali do sada nismo imali vremena da je postavimo.
Koji su problemi? Problem je nastao činjenicom da smo saznali (IZNENADA!) da naši Live API-ji pišu 50k poruka u sekundi. Ovo je samo Live API bez postavljanja. A Graylog nam pokazuje samo 12 tisuća poruka u sekundi. I postavilo se razumno pitanje, gdje su ostaci? Iz čega smo zaključili da se Graylog jednostavno ne snalazi. Pogledali smo i doista, Graylog s Elasticsearchom nije svladao ovaj tijek.
Zatim, druga otkrića do kojih smo usput došli.
Pisanje u utičnicu je blokirano. Kako se to dogodilo? Kad sam koristio rsyslog za isporuku, u nekom smo trenutku prekinuli kanal između podatkovnih centara. Dostava je ustala na jednom mjestu, dostava je ustala na drugom mjestu. Sve se to svelo na stroj s API-jima koji pišu u rsyslog utičnicu. Bio je red. Tada se popunio red čekanja za upisivanje u unix socket, koji je po defaultu 128 paketa. I sljedeći write() u blokovima aplikacije. Kad smo pogledali biblioteku koju koristimo u Go aplikacijama, tamo je pisalo da se pisanje u utičnicu odvija u neblokirajućem načinu rada. Bili smo sigurni da ništa nije blokirano. Jer smo čitali koji je o tome pisao. Ali postoji trenutak. Postojala je i beskonačna petlja oko ovog poziva, u kojoj je bilo stalnih pokušaja da se poruka ubaci u utičnicu. Nismo ga primijetili. Morao sam ponovno napisati biblioteku. Od tada se mijenjao nekoliko puta, ali sada smo se riješili blokada u svim podsustavima. Stoga, možete zaustaviti rsyslog i ništa neće pasti.
Potrebno je pratiti veličinu redova, što pomaže da se ne stane na ovu grablje. Prvo, možemo pratiti kada počnemo gubiti poruke. Drugo, možemo pratiti da u osnovi imamo problema s isporukom.
I još jedan neugodan trenutak - pojačanje za 10 puta u mikroservisnoj arhitekturi vrlo je jednostavno. Nemamo toliko pristiglih zahtjeva, ali zbog grafa po kojem te poruke idu dalje, zbog pristupnih logova, stvarno povećavamo opterećenje logova za desetak puta. Nažalost, nisam imao vremena izračunati točne brojke, ali mikroservisi su to što jesu. Ovo se mora imati na umu. Ispostavilo se da je trenutno podsustav za prikupljanje dnevnika najopterećeniji u Lazadi.
Kako riješiti problem elastičnog pretraživanja? Ako trebate brzo dobiti zapise na jednom mjestu, kako ne biste trčali po svim strojevima i tamo ih skupljali, koristite pohranu datoteka. Ovo će zajamčeno uspjeti. To se radi s bilo kojeg poslužitelja. Treba samo zalijepiti diskove tamo i staviti syslog. Nakon toga zajamčeno ćete imati sve zapisnike na jednom mjestu. Tada će biti moguće polako konfigurirati elasticsearch, graylog ili nešto treće. Ali već ćete imati sve zapisnike i, štoviše, možete ih pohraniti, ako ima dovoljno diskovnih polja.
U vrijeme mog izvješća shema je počela izgledati ovako. Praktično smo prestali pisati u datoteku. Sada ćemo najvjerojatnije isključiti ostatke. Na lokalnim strojevima koji izvode API, prestat ćemo pisati u datoteke. Prvo, tu je pohrana datoteka, koja radi vrlo dobro. Drugo, tim strojevima stalno ponestaje prostora, morate ga stalno nadzirati.
Ovaj dio s Logstashom i Graylogom je stvarno veliki. Stoga ga se morate riješiti. Morate odabrati jedan.
Odlučili smo odustati od Logstasha i Kibane. Jer imamo odjel sigurnosti. Kakva je veza? Veza je u tome što Kibana bez X-Packa i bez Shielda ne dopušta razlikovanje prava pristupa zapisima. Stoga su uzeli Graylog. Ima sve. Ne sviđa mi se, ali djeluje. Kupili smo novi hardver, tamo instalirali svježi Graylog i premjestili sve zapisnike sa strogim formatima u zasebni Graylog. Organizacijski smo riješili problem različitih vrsta istih terena.
Što je točno uključeno u novi Graylog. Upravo smo sve napisali u docker. Uzeli smo hrpu servera, izbacili tri Kafka instance, 7 Graylog servera verzije 2.3 (jer sam htio Elasticsearch verziju 5). Sve je to podignuto na napadima s HDD-a. Vidjeli smo stopu indeksiranja do 100 tisuća poruka u sekundi. Vidjeli smo brojku od 140 terabajta podataka tjedno.
I opet grablje! Predstoje nam dvije prodaje. Prešli smo više od 6 milijuna postova. Mi Graylog nemamo vremena žvakati. Nekako opet moraš preživjeti.
Ovako smo preživjeli. Dodano je još nekoliko poslužitelja i SSD-ova. U ovom trenutku živimo ovako. Sada već žvačemo 160 tisuća poruka u sekundi. Još nismo dosegnuli limit pa je nejasno koliko realno možemo iz toga izvući.
To su naši planovi za budućnost. Od njih je vjerojatno najvažnija visoka dostupnost. Još ga nemamo. Nekoliko automobila je postavljeno na isti način, ali za sada sve ide kroz jedan automobil. Potrebno je potrošiti vrijeme da se postavi failover između njih.
Prikupite metriku iz Grayloga.
Napravite ograničenje brzine tako da imamo jedan ludi API koji nam ne ubija propusnost i sve ostalo.
I na kraju, potpišite nekakav SLA s programerima kako bismo mogli toliko služiti. Ako napišeš više, izvini.
I napisati dokumentaciju.
Ukratko, rezultati svega što smo doživjeli. Prvo, standardi. Drugo, syslog je kolač. Treće, rsyslog radi točno onako kako je napisano na slajdu. I prijeđimo na pitanja.
pitanja.
Pitanje: Zašto su odlučili ne uzeti ... (filebeat?)
Odgovoriti: Treba pisati u datoteku. Stvarno nisam htjela. Kada vaš API piše tisuće poruka u sekundi, čak i ako rotirate jednom na sat, to još uvijek nije opcija. Možete pisati na cijevi. Na što su me programeri pitali: “Što će se dogoditi ako proces u kojem pišemo padne”? Samo nisam našao što da im odgovorim, i rekao sam: "Pa dobro, nemojmo to raditi."
Pitanje: Zašto jednostavno ne pišete zapisnike u HDFS?
OdgovoritiO: Ovo je sljedeća faza. Razmišljali smo o tome na samom početku, ali budući da trenutno nema resursa za rješavanje toga, to ostaje u našem dugoročnom rješenju.
Pitanje: Format stupca bio bi prikladniji.
Odgovoriti: Razumijem. Mi smo s obje ruke "za".
Pitanje: Vi pišete u rsyslog. Tu su dostupni i TCP i UDP. Ali ako je UDP, kako onda jamčiti isporuku?
OdgovoritiO: Postoje dvije točke. Prvo, odmah svima kažem da ne garantiramo isporuku trupaca. Jer kada programeri dođu i kažu: “Ajmo tamo početi pisati financijske podatke, a vi ćete nam ih negdje staviti u slučaju da se nešto dogodi”, mi im odgovaramo “Super! Počnimo s blokiranjem pisanja u socket, i to u transakcijama, tako da ga zajamčeno ubacite u socket umjesto nas i da budemo sigurni da smo ga primili s druge strane. I u ovom trenutku svi odmah postaju nepotrebni. A ako ne, kakva pitanja imamo? Ako ne želite jamčiti pisanje u utičnicu, zašto bismo mi jamčili isporuku? Dajemo sve od sebe. Zaista se trudimo isporučiti što više i što bolje, ali ne dajemo 100% garanciju. Stoga tamo ne morate upisivati financijske podatke. Za to postoje transakcijske baze podataka.
Pitanje: Kada API generira neku poruku u dnevnik i prenese kontrolu na mikroservise, jeste li se susreli s problemom da poruke od različitih mikroservisa stižu pogrešnim redoslijedom? Zbog toga nastaje zabuna.
OdgovoritiO: Normalno je da dolaze drugačijim redoslijedom. Morate biti spremni na ovo. Jer bilo kakva mrežna dostava ne jamči vam red, ili morate potrošiti posebna sredstva na to. Ako uzmemo pohranu datoteka, tada svaki API sprema zapisnike u vlastitu datoteku. Umjesto toga, rsyslog ih tamo rastavlja u direktorije. Svaki API tamo ima svoje zapise, gdje možete otići i pogledati, a zatim ih možete usporediti pomoću vremenske oznake u ovom zapisniku. Ako odu tražiti u Graylogu, tamo će biti poredani po vremenskoj oznaci. Tamo će sve biti u redu.
Pitanje: Vremenska oznaka može varirati po milisekundama.
Odgovoriti: Vremensku oznaku generira sam API. To je, zapravo, cijela poanta. Imamo NTP. API generira vremensku oznaku već u samoj poruci. Ne dodaje ga rsyslog.
Pitanje: Interakcija između podatkovnih centara nije baš jasna. U okviru podatkovnog centra jasno je kako su se dnevnici prikupljali i obrađivali. Kakva je interakcija između podatkovnih centara? Ili svaki podatkovni centar živi svoj život?
Odgovoriti: Skoro. Svaku državu nalazimo u jednom podatkovnom centru. Trenutno nemamo širenje, tako da se jedna država nalazi u različitim podatkovnim centrima. Stoga ih nema potrebe kombinirati. Unutar svakog centra nalazi se Log Relay. Ovo je Rsyslog poslužitelj. Zapravo, dva upravljačka stroja. Postavljeni su na isti način. Ali za sada promet ide samo kroz jedan od njih. Ona bilježi sve agregate. Za svaki slučaj ima red čekanja na disku. Ona preša zapise i šalje ih u središnji podatkovni centar (Singapur), gdje se dalje već truju u Graylogu. A svaki podatkovni centar ima vlastitu pohranu datoteka. U slučaju da izgubimo vezu, tamo imamo sve zapise. Oni će ostati tamo. Tamo će biti pohranjeni.
Pitanje: Dobivate li zapise odande tijekom nenormalnih situacija?
Odgovoriti: Možete otići tamo (u pohranu datoteka) i pogledati.
Pitanje: Kako nadzireš da ne gubiš dnevnike?
Odgovoriti: Zapravo ih gubimo i to pratimo. Praćenje je počelo prije mjesec dana. Knjižnica koju Go API-ji koriste ima metriku. Može izbrojati koliko puta nije uspjela pisati u utičnicu. U ovom trenutku postoji lukava heuristika. Tamo je međuspremnik. Pokušava napisati poruku s njega na utičnicu. Ako se međuspremnik prepuni, počinje ih ispuštati. I broji koliko ih je ispustio. Ako se šalteri tamo počnu prelijevati, znat ćemo za to. Sada dolaze i u prometheus, a grafikone možete vidjeti u Grafani. Možete postaviti upozorenja. Ali još nije jasno kome ih poslati.
Pitanje: U elasticsearch-u pohranjujete zapise sa redundancijom. Koliko replika imate?
Odgovoriti: Jedna replika.
Pitanje: Je li to samo jedna linija?
Odgovoriti: Ovo je majstor i replika. Podaci se pohranjuju u duplikatu.
Pitanje: Jeste li nekako podesili veličinu međuspremnika rsyslog?
Odgovoriti: Datagrame pišemo u prilagođenu unix utičnicu. To nam odmah nameće ograničenje od 128 kilobajta. Ne možemo napisati više o tome. To smo napisali u standardu. Tko želi ući u skladište, napiše 128 kilobajta. Knjižnice, štoviše, odsječene, i staviti oznaku da je poruka odsječena. U standardu same poruke imamo posebno polje koje pokazuje da li je odrezana tijekom snimanja ili ne. Dakle, imamo priliku pratiti ovaj trenutak.
Pitanje: Pišete li oštećeni JSON?
Odgovoriti: Pokvareni JSON bit će odbačen tijekom prijenosa jer je paket prevelik. Ili će Graylog biti odbačen jer neće moći analizirati JSON. Ali ovdje postoje nijanse koje treba popraviti, a uglavnom su vezane uz rsyslog. Već sam ispunio nekoliko pitanja na kojima još treba raditi.
Pitanje: Zašto Kafka? Jeste li probali RabbitMQ? Graylog se ne zbraja pod takvim opterećenjima?
Odgovoriti: Ne ide s Graylogom. A Graylog poprima oblik. Njemu je to stvarno problematično. On je neka vrsta stvari. I, zapravo, nije potreban. Radije bih pisao iz rsyslog izravno u elasticsearch i onda gledao Kibanu. Ali moramo riješiti problem sa zaštitarima. Ovo je moguća varijanta našeg razvoja kada izbacimo Graylog i koristimo Kibanu. Logstash neće imati smisla. Jer mogu učiniti isto s rsyslogom. I ima modul za pisanje u elasticsearch. S Graylogom pokušavamo nekako živjeti. Čak smo ga i malo dotjerali. Ali još ima prostora za napredak.
O Kafki. Tako se to povijesno dogodilo. Kad sam stigao, već je bio tu i već su se pisali dnevnici. Upravo smo podigli naš klaster i u njega premjestili trupce. Mi njime upravljamo, znamo kako se osjeća. Što se tiče RabbitMQ... imamo problema s RabbitMQ. I RabbitMQ razvija za nas. Imamo ga u proizvodnji, a bilo je problema s njim. Sada bi ga prije prodaje šamanizirali i počeo bi normalno raditi. Ali prije toga nisam bio spreman pustiti ga u proizvodnju. Postoji još jedna stvar. Graylog može čitati verziju AMQP 0.9, a rsyslog može pisati verziju AMQP 1.0. I ne postoji niti jedno rješenje koje može učiniti oboje u sredini. Postoji ili jedno ili drugo. Dakle, za sada samo Kafka. Ali postoje i nijanse. Zato što omkafka verzije rsyslog-a koju koristimo može izgubiti cijeli međuspremnik poruka koji je pokupila iz rsyslog-a. Sve dok to trpimo.
Pitanje: Koristite li Kafku jer ste je imali? Ne koristi se ni u koju drugu svrhu?
Odgovoriti: Kafka, koju je koristio tim Data Science. Ovo je potpuno zaseban projekt o kojem, nažalost, ne mogu ništa reći. Ne znam. Vodio ju je tim Data Science. Kad su krenule cjepanice, odlučili su je iskoristiti, da ne stavljaju svoje. Sada smo ažurirali Graylog i izgubili smo kompatibilnost jer postoji stara verzija Kafke. Morali smo napraviti svoje. U isto vrijeme, riješili smo se ove četiri teme za svaki API. Napravili smo jedan široki gornji dio za sve uživo, jedan široki široki gornji dio za sve pozornice i sve tamo snimamo. Graylog sve to vadi paralelno.
Pitanje: Zašto nam treba taj šamanizam sa utičnicama? Jeste li pokušali koristiti upravljački program zapisnika syslog za spremnike.
Odgovoriti: U trenutku kada smo postavili ovo pitanje, imali smo napete odnose s lučkom osobom. Bio je to docker 1.0 ili 0.9. Docker je sam po sebi bio čudan. Drugo, ako još i logove uguraš u njega ... Neprovjereno sumnjam da sve logove provlači kroz sebe, kroz docker daemon. Ako imamo jedan API koji poludi, tada će ostali API-ji naići na činjenicu da ne mogu slati stdout i stderr. Ne znam kamo će ovo odvesti. Imam sumnju na razini osjećaja da nije potrebno koristiti upravljački program docker syslog na ovom mjestu. Naš odjel za funkcionalno testiranje ima vlastiti Graylog klaster s zapisima. Koriste upravljačke programe za docker log i čini se da je tamo sve u redu. Ali Graylogu odmah pišu GELF. U trenutku kada smo sve ovo pokrenuli, trebalo nam je da samo funkcionira. Možda ćemo kasnije, kad netko dođe i kaže da radi sto godina normalno, pokušati.
Pitanje: Dostavljate između podatkovnih centara koristeći rsyslog. Zašto ne na Kafku?
Odgovoriti: Mi to radimo i to je tako. Iz dva razloga. Ako je kanal potpuno mrtav, tada se svi naši trupci, čak ni u komprimiranom obliku, neće popeti kroz njega. A kafka im omogućuje da jednostavno izgube u procesu. Na taj način se rješavamo lijepljenja ovih trupaca. U ovom slučaju samo izravno koristimo Kafku. Ako imamo dobar kanal i želimo ga osloboditi, onda koristimo njihov rsyslog. Ali zapravo, možete ga postaviti tako da ispusti ono kroz što nije prošao. Trenutno samo koristimo isporuku rsyslog izravno negdje, negdje Kafka.
Izvor: www.habr.com