Dnevnici su važan dio sistema, omogućavajući vam da shvatite da radi (ili ne radi) kako se očekuje. U uslovima mikroservisne arhitekture, rad sa balvanima postaje posebna disciplina Specijalne olimpijade. Postoji mnogo problema koje treba riješiti:
- kako pisati dnevnike iz aplikacije;
- gdje pisati dnevnike;
- kako dostaviti trupce za skladištenje i obradu;
- kako obraditi i pohraniti dnevnike.
Korištenje trenutno popularnih tehnologija kontejnerizacije dodaje pijesak na vrh grabulja u području mogućnosti rješavanja problema.
Otprilike ovo je transkript izvještaja Jurija Bušmeljeva "Mapa grabulja u oblasti sakupljanja i isporuke trupaca"
Koga briga, molim pod mačku.
Moje ime je Yuri Bushmelev. Radim za Lazadu. Danas ću pričati o tome kako smo pravili naše trupce, kako smo ih sakupljali i šta tu pišemo.
odakle smo? Ko smo mi? Lazada je broj 1 online trgovac na malo u šest zemalja jugoistočne Azije. Sve ove zemlje su raspoređene po data centrima. Sada postoje ukupno 4 data centra.Zašto je to važno? Jer neke odluke su bile zbog činjenice da postoji vrlo slaba veza između centara. Imamo mikroservisnu arhitekturu. Bio sam iznenađen kada sam otkrio da već imamo 80 mikroservisa. Kada sam započeo zadatak sa logovima, bilo ih je samo 20. Plus, postoji prilično veliki deo PHP nasleđa, sa kojim takođe moram da živim i trpim. Sve ovo za nas trenutno generiše više od 6 miliona poruka u minuti za sistem u celini. Dalje ću pokazati kako pokušavamo da živimo sa ovim i zašto je to tako.
Morate nekako živjeti sa ovih 6 miliona poruka. Šta da radimo s njima? Potrebno je 6 miliona poruka:
- poslati iz aplikacije
- prihvatiti za isporuku
- dostaviti na analizu i skladištenje.
- analiza
- pohraniti nekako.
Kada je bilo tri miliona poruka, imao sam otprilike isti izgled. Zato što smo počeli sa par penija. Jasno je da su tamo upisani logovi aplikacija. Na primjer, ne mogu se povezati s bazom podataka, mogu se povezati s bazom podataka, ali ne mogu pročitati nešto. Ali pored toga, svaki naš mikroservis takođe piše dnevnik pristupa. Svaki zahtjev koji stigne na mikroservis pada u dnevnik. Zašto ovo radimo? Programeri žele imati mogućnost praćenja. Svaki pristupni dnevnik sadrži polje traceid, prema kojem posebno sučelje zatim odmotava cijeli lanac i lijepo prikazuje trag. Praćenje pokazuje kako je zahtjev prošao, a to pomaže našim programerima da brže riješe bilo kakvo nepoznato smeće.
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 kažu pomodni drugovi. Postoje dvije vrste stare škole, kako su djedovi govorili. Postoje i drugi načini.
Sa prikupljanjem trupaca situacija je otprilike ista. Nema toliko opcija za rješavanje ovog dijela. Ima ih još, ali još ne toliko.
Ali s isporukom i kasnijom analizom, broj varijacija počinje eksplodirati. Neću sada opisivati svaku opciju. Mislim da su glavne opcije dobro poznate svima koje je tema zanimala.
Pokazat ću vam kako smo to radili na Lazadi i kako je sve počelo.
Prije godinu dana došao sam u Lazade i poslao me na log projekat. Tamo je bilo ovako. Dnevnik iz aplikacije je napisan 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... pa, hajde da ih umotamo u datoteku sa školjkom, i to je to." A pošto je sve ovo u kontejneru, umotali su ga pravo u sam kontejner, mapirali direktorijum unutra i stavili ga tamo. Mislim da je svima prilično jasno šta se dogodilo.
Pogledajmo malo dalje. Kako smo isporučili ove trupce. Neko je odabrao td-agent, koji je zapravo tečan, ali ne baš tečan. Još uvijek ne razumijem odnos ova dva projekta, ali izgleda da se radi o istoj stvari. I ovaj fluentd, napisan u Ruby-u, čita datoteke dnevnika, analizira ih u JSON koristeći neke regularne izraze. Zatim su poslani Kafki. Štaviše, u Kafki smo imali 4 odvojene teme za svaki API. Zašto 4? Zato što postoji live, postoji inscenacija, i zato što postoje stdout i stderr. Programeri ih proizvode, a infrastrukturni radnici moraju ih kreirati u Kafki. Štaviše, Kafku je kontrolisalo drugo odeljenje. Stoga je bilo potrebno kreirati tiket tako da su tamo kreirali 4 teme za svaki API. Svi su zaboravili na to. Uglavnom, bilo je to smeće i otpad.
Šta smo dalje uradili s tim? Poslali smo ga kafki. Dalje od Kafke, polovina trupaca je odletjela u Logstash. Druga polovina dnevnika je podijeljena. Neki su odletjeli do jednog Sivog loga, neki do drugog Sivog loga. Kao rezultat, sve je to odletjelo u jedan Elasticsearch klaster. Odnosno, sav ovaj nered je na kraju pao tamo. Ne morate to da radite!
Ovako to izgleda kada se gleda odozgo. Ne morate to da radite! Ovdje su problematična područja odmah označena brojevima. Zapravo ih ima više, ali 6 su zaista problematične, s kojima se nešto mora raditi. O njima ću sada posebno govoriti.
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 dati API-ju mogućnost da piše direktno u datoteku. Poželjno je da API bude izoliran u kontejneru, a još bolje da bude samo za čitanje. Ja sam sistem administrator, tako da imam malo alternativni pogled na ove stvari.
Druga tačka (2,3) je da imamo mnogo zahtjeva koji dolaze do API-ja. API zapisuje mnogo podataka u datoteku. Fajlovi rastu. Moramo ih rotirati. Jer inače nećete moći tamo pohraniti nijedan disk. Njihovo rotiranje je loše jer se preko ljuske preusmjeravaju u direktorij. Nema šanse da ga rotiramo. Ne možete reći aplikaciji da ponovo otvori ručke. Jer će programeri na vas gledati kao na budale: „Kakvi deskriptori? Obično pišemo na stdout. Okviri su napravili copytruncate u logrotate, koji samo pravi kopiju datoteke i spaja original. U skladu s tim, između ovih procesa kopiranja obično ponestane prostora na disku.
(4) Imali smo različite formate u različitim API-jima. Bili su malo drugačiji, ali je regexp morao biti drugačije napisan. Pošto je sve to vodila Puppet, bila je velika gomila časova sa svojim žoharima. Plus, td-agent je većinu vremena mogao pojesti memoriju, biti glup, mogao je samo da se pretvara da radi i ne radi ništa. Spolja je bilo nemoguće shvatiti da on ništa ne radi. U najboljem slučaju će pasti, a neko će ga kasnije podići. Tačnije, doletjet će uzbuna, a neko će otići i podignuti je rukama.
(6) A najviše smeća i otpada - to je bila elastična pretraga. Zato što je to bila stara verzija. Jer tada nismo imali posvećene majstore. Imali smo heterogene trupce čija su se polja mogla preklapati. Različiti dnevniki različitih aplikacija mogu biti napisani sa istim imenima polja, ali u isto vrijeme mogu biti različiti podaci unutra. To jest, jedan dnevnik dolazi sa cijelim brojem u polju, na primjer, nivo. Drugi dnevnik dolazi sa stringom u polju nivoa. U nedostatku statičkog mapiranja, ispada tako divna stvar. Ako je nakon rotacije indeksa poruka sa stringom stigla prva u elasticsearch, onda živimo normalno. A ako je prva stigla sa Integer-om, onda se sve naredne poruke koje su stigle sa String jednostavno odbacuju. Zato što se tip polja ne podudara.
Počeli smo da postavljamo ova pitanja. Odlučili smo da ne tražimo krivce.
Ali nešto treba učiniti! Očigledna stvar je da moramo uspostaviti standarde. Već smo imali neke standarde. Neke smo doneli nešto kasnije. Srećom, jedan format dnevnika za sve API-je već je odobren u to vrijeme. To je direktno upisano u standarde interakcije usluge. Shodno tome, oni koji žele da primaju dnevnike treba da ih napišu u ovom formatu. Ako neko ne piše dnevnike u ovom formatu, onda ne garantujemo ništa.
Nadalje, želio bih imati jedinstven standard za metode evidentiranja, dostave i prikupljanja dnevnika. Zapravo, gdje ih napisati i kako ih dostaviti. Idealna situacija je kada projekti koriste istu biblioteku. Postoji posebna biblioteka za evidentiranje za Go, postoji posebna biblioteka za PHP. Svi koje imamo, svi treba da ih koriste. U ovom trenutku, rekao bih da uspijevamo za 80 posto. Ali neki i dalje jedu kaktuse.
A tamo (na slajdu) “SLA za isporuku dnevnika” jedva počinje da se pojavljuje. Još nije tu, ali radimo na tome. Zato što je vrlo zgodno kada infra kaže da ako pišete u tom i takvom formatu na takvo i to mjesto i ne više od N poruka u sekundi, onda ćemo to najvjerovatnije dostaviti tamo. Uklanja mnogo glavobolje. Ako postoji SLA, onda je to jednostavno sjajno!
Kako smo počeli rješavati problem? Glavni rake je bio sa td-agentom. Bilo je nejasno kuda idu naši trupci. Jesu li isporučeni? Da li idu? Gde su oni uopšte? Stoga je odlučeno da se td-agent zamijeni prvom stavkom. Opcije čime ga zamijeniti, ovdje sam ukratko iznio.
Fluentd. Prvo, naišao sam na njega na prethodnom poslu, a i on je tu povremeno padao. Drugo, ovo je isto, samo u profilu.
filebeat. Kako nam je bilo dobro? Činjenica da je on u Go-u, a mi imamo veliku stručnost u Go-u. Shodno tome, ako išta, mogli bismo to nekako sebi dodati. Zato ga nismo uzeli. Tako da ne bi bilo iskušenja da počnete da ga prepisujete za sebe.
Očigledno rješenje za sysadmin 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 svodio na izbor između syslog-ng i rsyslog. Naginjao sam se rsyslogu jednostavno zato što smo već imali klase za rsyslog u Puppetu, i nisam našao očiglednu razliku između njih. Šta je syslog, šta je syslog. Da, neka dokumentacija je lošija, neka bolja. On zna ovaj način, a radi drugačije.
I malo o rsyslogu. Prvo, to je cool jer ima puno modula. Ima čovjeku čitljiv RainerScript (moderni konfiguracijski jezik). Sjajan bonus je što smo mogli emulirati ponašanje td-agenta sa njegovim standardnim alatima, a ništa se nije promijenilo za aplikacije. To jest, mijenjamo td-agent u rsyslog i ne diramo još sve ostalo. I odmah dobijamo isporuku koja radi. Zatim, mmnormalize je kul stvar u vezi sa rsyslog-om. Omogućava vam da analizirate dnevnike, ali ne sa Grokom i regexpom. Pravi apstraktno sintaktičko stablo. On analizira dnevnike na isti način na koji kompajler analizira izvorni kod. Ovo vam omogućava da radite veoma brzo, jedete malo CPU-a i, generalno, to je samo veoma kul stvar. Postoji gomila drugih bonusa. Neću se zadržavati na njima.
rsyslog ima mnogo više nedostataka. Oni su otprilike isti kao i bonusi. Glavni problemi su što morate biti u mogućnosti da ga skuvate i morate odabrati verziju.
Odlučili smo da ćemo pisati dnevnike u unix socket. A ne u /dev/log, jer tamo imamo zbrku sistemskih dnevnika, postoji dnevnik u ovom cevovodu. Pa hajde da pišemo u prilagođeni socket. Priložit ćemo ga zasebnom skupu pravila. Nemojmo se miješati ni u šta. Sve će biti transparentno i razumljivo. Tako smo i uradili. Direktorij s ovim utičnicama je standardiziran i proslijeđen svim kontejnerima. Kontejneri mogu vidjeti socket koji im je potreban, otvoriti i pisati u njega.
Zašto ne fajl? Jer svi su čitali , koji je pokušao proslediti datoteku docker-u i otkrio da se nakon ponovnog pokretanja rsyslog-a deskriptor datoteke mijenja i docker gubi ovu datoteku. On drži otvoreno nešto drugo, ali ne istu utičnicu u kojoj pišu. Odlučili smo da zaobiđemo ovaj problem, a da istovremeno zaobiđemo i problem blokiranja.
Rsyslog obavlja radnje naznačene na slajdu i šalje zapise bilo releju ili Kafki. Kafka slijedi stari put. Rayleigh - Pokušao sam koristiti čisti rsyslog za isporuku dnevnika. Bez reda za poruke, koristeći standardne rsyslog alate. U osnovi, radi.
Ali postoje nijanse kako ih kasnije staviti u ovaj dio (Logstash/Graylog/ES). Ovaj dio (rsyslog-rsyslog) se koristi između centara podataka. Evo komprimirane tcp veze, koja vam omogućava da uštedite propusni opseg i, shodno tome, na neki način povećate vjerovatnoću da ćemo primiti neke zapise iz drugog data centra kada je kanal pun. Jer imamo Indoneziju u kojoj je sve loše. Tu leži stalni problem.
Razmišljali smo o tome kako zapravo pratimo, s kojom vjerovatnoćom dnevnici koje smo snimili iz aplikacije dođu do tog kraja? Odlučili smo da počnemo sa metrikom. Rsyslog ima svoj vlastiti modul za prikupljanje statistike, koji ima neku vrstu brojača. Na primjer, može vam pokazati veličinu reda, ili koliko je poruka stiglo za tu i takvu radnju. Već možete uzeti nešto od njih. Osim toga, ima prilagođene brojače koje možete konfigurirati i pokazat će vam, na primjer, broj poruka koje je neki API snimio. Zatim sam napisao rsyslog_exporter u Pythonu i sve smo to poslali Prometheusu i nacrtali. Zaista smo željeli Graylog metriku, ali do sada nismo imali vremena da ih postavimo.
koji su problemi? Problem je nastao sa činjenicom da smo otkrili (ODNADNO!) da naši Live API-ji pišu 50 poruka u sekundi. Ovo je samo Live API bez inscenacije. A Graylog nam prikazuje samo 12 hiljada poruka u sekundi. I postavilo se razumno pitanje, gdje su ostaci? Iz čega smo zaključili da se Graylog jednostavno ne može nositi. Pogledali smo i, zaista, Graylog sa Elasticsearch-om nije savladao ovaj tok.
Dalje, druga otkrića do kojih smo došli usput.
Upisi u utičnicu su blokirani. Kako se to dogodilo? Kada sam koristio rsyslog za isporuku, u nekom trenutku smo prekinuli kanal između data centara. Dostava je ustala na jednom mjestu, dostava je ustala na drugom mjestu. Sve se ovo svelo na mašinu sa API-jima koji upisuju u rsyslog socket. Bio je red. Tada se popunio red za pisanje u unix socket, koji je po defaultu 128 paketa. I sljedeći write() u blokovima aplikacije. Kada smo pogledali biblioteku koju koristimo u Go aplikacijama, tamo je bilo napisano da se pisanje u socket odvija u neblokirajućem modu. Bili smo sigurni da ništa nije blokirano. Jer smo čitali ko je pisao o tome. Ali postoji trenutak. Postojala je i beskonačna petlja oko ovog poziva, u kojoj je postojao stalni pokušaj da se poruka ugura u utičnicu. Nismo ga primetili. Morao sam da prepišem biblioteku. Od tada se nekoliko puta mijenjao, ali sada smo se riješili zaključavanja u svim podsistemima. Stoga, možete zaustaviti rsyslog i ništa neće pasti.
Potrebno je pratiti veličinu redova, što pomaže da se ne zgazi na ovu grabulju. Prvo, možemo pratiti kada počnemo gubiti poruke. Drugo, možemo pratiti da u osnovi imamo problema s isporukom.
I još jedan neprijatan trenutak - pojačanje za 10 puta u mikroservisnoj arhitekturi je vrlo lako. Nemamo toliko dolaznih zahtjeva, ali zbog grafa po kojem te poruke idu dalje, zbog pristupnih logova, zapravo povećavamo opterećenje logova za desetak puta. Nažalost, nisam imao vremena da izračunam tačne brojke, ali mikroservis je to što jesu. Ovo se mora imati na umu. Ispostavilo se da je u ovom trenutku podsistem prikupljanja dnevnika najopterećeniji u Lazadi.
Kako riješiti problem elastične pretrage? Ako trebate brzo da dobijete dnevnike na jednom mjestu, kako ne biste trčali preko svih strojeva i skupljali ih tamo, koristite skladište datoteka. Ovo će garantovano raditi. Radi se sa bilo kojeg servera. Samo trebate staviti diskove tamo i staviti syslog. Nakon toga, garantovano ćete imati sve zapise na jednom mjestu. Tada će biti moguće polako konfigurirati elasticsearch, graylog ili nešto drugo. Ali već ćete imati sve zapise, i, osim toga, možete ih pohraniti, sve dok ima dovoljno diskovnih nizova.
U vrijeme mog izvještaja, shema je počela izgledati ovako. Praktično smo prestali pisati u fajl. Sada ćemo, najvjerovatnije, isključiti ostatke. Na lokalnim mašinama koje koriste API, prestat ćemo pisati u datoteke. Prvo, tu je skladište datoteka, koje radi vrlo dobro. Drugo, ovim mašinama stalno ponestaje prostora, morate ga stalno pratiti.
Ovaj dio sa Logstash-om i Graylog-om zaista raste. Stoga ga se morate riješiti. Morate izabrati jednu.
Odlučili smo da napustimo Logstash i Kibanu. Zato što imamo odeljenje obezbeđenja. Kakva je veza? Veza je u tome što vam Kibana bez X-Packa i bez Shield-a ne dozvoljava razlikovanje prava pristupa logovima. Stoga su uzeli Graylog. Ima sve. Ne sviđa mi se, ali radi. Kupili smo novi hardver, instalirali novi Graylog tamo i premjestili sve zapise sa strogim formatima u poseban Graylog. Problem sa različitim tipovima istih polja smo organizacijski riješili.
Šta je tačno uključeno u novi Graylog. Upravo smo sve napisali u docker. Uzeli smo gomilu servera, izbacili tri Kafka instance, 7 Graylog servera verzije 2.3 (jer sam želio Elasticsearch verziju 5). Sve ovo je podignuto na racijama sa HDD-a. Vidjeli smo stopu indeksiranja do 100 hiljada poruka u sekundi. Vidjeli smo cifru da 140 terabajta podataka sedmično.
I opet grablje! Predstoje nam dvije rasprodaje. Prešli smo preko 6 miliona postova. Mi Graylog nemamo vremena za žvakanje. Nekako opet moraš preživjeti.
Ovako smo preživjeli. Dodano još nekoliko servera i SSD-ova. Trenutno živimo ovako. Sada već žvačemo 160 hiljada poruka u sekundi. Još nismo dostigli granicu, pa je nejasno koliko realno možemo izaći iz toga.
Ovo su naši planovi za budućnost. Od njih, zaista, najvažnija je vjerovatno visoka dostupnost. Još ga nemamo. Nekoliko automobila je postavljeno na isti način, ali do sada sve ide kroz jedan automobil. Neophodno je utrošiti vrijeme da se između njih uspostavi prelazak na grešku.
Prikupite metriku iz Graylog-a.
Napravite ograničenje brzine tako da imamo jedan ludi API koji nam ne ubija propusnost i sve ostalo.
I na kraju, potpišite neku vrstu SLA sa programerima kako bismo mogli toliko poslužiti. Ako napišete više, izvinite.
I napisati dokumentaciju.
Ukratko, rezultati svega što smo doživjeli. Prvo, standardi. Drugo, syslog je kolač. Treće, rsyslog radi tačno onako kako je napisano na slajdu. I da pređemo na pitanja.
Vaša pitanja.
Vaše pitanje: Zašto su odlučili da ne uzmu ... (filebeat?)
Odgovori: Treba pisati u datoteku. Zaista nisam htela. Kada vaš API napiše hiljade poruka u sekundi, čak i ako se rotirate jednom na sat, ovo još uvijek nije opcija. Možete pisati na pipe. Na što su me programeri pitali: “Šta će se dogoditi ako padne proces u kojem pišemo”? Samo nisam našao šta da im odgovorim, pa sam rekao: "Pa dobro, da ne radimo to."
Vaše pitanje: Zašto jednostavno ne zapišete dnevnike u HDFS?
OdgovoriO: Ovo je sljedeća faza. Razmišljali smo o tome na samom početku, ali s obzirom da trenutno nema resursa za to, to visi u našem dugoročnom rješenju.
Vaše pitanje: Format kolone bi bio prikladniji.
Odgovori: Razumijem. Mi smo "za" sa obe ruke.
Vaše pitanje: Pišete u rsyslog. Tamo su dostupni i TCP i UDP. Ali ako je UDP, kako onda garantujete isporuku?
OdgovoriO: Postoje dvije tačke. Prvo, odmah kažem svima da ne garantujemo isporuku trupaca. Jer kada programeri dođu i kažu: „Hajde da tamo pišemo finansijske podatke, a vi ćete to staviti negdje za nas u slučaju da se nešto desi“, mi im odgovaramo: „Odlično! Počnimo s blokiranjem pisanja u socket, i to u transakcijama, tako da garantirano stavite u socket umjesto nas i provjerite da li smo ga primili s druge strane. I u ovom trenutku svi odmah postaju nepotrebni. A ako ne, kakva pitanja onda imamo? Ako ne želite da garantujete upis u socket, zašto bismo onda garantovali isporuku? Dajemo sve od sebe. Zaista se trudimo da isporučimo što je više moguće i najbolje moguće, ali ne dajemo 100% garanciju. Stoga, ne morate tamo pisati finansijske podatke. Za to postoje transakcijske baze podataka.
Vaše pitanje: Kada API generiše neku poruku u dnevnik i prenese kontrolu na mikroservise, da li ste naišli na problem da poruke iz različitih mikroservisa stižu pogrešnim redosledom? Zbog toga nastaje zabuna.
OdgovoriO: Normalno je da dolaze drugačijim redoslijedom. Morate biti spremni za ovo. Zato što vam bilo kakva mrežna isporuka ne garantuje red, ili na to morate potrošiti posebne resurse. Ako uzmemo skladišta datoteka, onda svaki API sprema evidencije u svoj vlastiti fajl. Umjesto toga, rsyslog ih tamo razlaže u direktorije. Svaki API ima svoje dnevnike tamo, gdje možete otići i pogledati, a zatim ih možete uporediti koristeći vremensku oznaku u ovom dnevniku. Ako odu da pogledaju u Graylog, onda će tamo biti sortirani po vremenskoj oznaci. Tamo će sve biti u redu.
Vaše pitanje: Vremenska oznaka može varirati u milisekundama.
Odgovori: Vremensku oznaku generira sam API. To je, u stvari, poenta. Imamo NTP. API generiše vremensku oznaku već u samoj poruci. Ne dodaje ga rsyslog.
Vaše pitanje: Interakcija između data centara nije baš jasna. U okviru data centra jasno je kako su dnevnici prikupljeni i obrađeni. Kakva je interakcija između data centara? Ili svaki data centar živi svoj život?
Odgovori: Skoro. Svaku zemlju imamo u jednom data centru. Trenutno nemamo širenje, tako da se jedna država nalazi u različitim data centrima. Stoga, nema potrebe da ih kombinujete. Unutar svakog centra nalazi se Log Relay. Ovo je Rsyslog server. Zapravo, dvije mašine za upravljanje. Oni su postavljeni na isti način. Ali za sada, saobraćaj ide samo kroz jednu od njih. Ona bilježi sve agregate. Za svaki slučaj ima red na disku. Ona presuje trupce i šalje ih u centralni data centar (Singapur), gdje su dalje već zatrovani u Graylogu. I svaki centar podataka ima vlastitu pohranu datoteka. U slučaju da smo izgubili vezu, tamo imamo sve zapise. Oni će ostati tamo. Oni će biti tamo pohranjeni.
Vaše pitanje: Da li dobijate dnevnike odatle tokom nenormalnih situacija?
Odgovori: Možete otići tamo (u skladište datoteka) i pogledati.
Vaše pitanje: Kako pratite da ne gubite dnevnike?
Odgovori: Mi ih zapravo gubimo i to pratimo. Monitoring je počeo prije mjesec dana. Biblioteka koju koriste Go API-ji ima metriku. Može da izbroji koliko puta nije napisala u utičnicu. Tu trenutno postoji lukava heuristika. Tamo je tampon. Pokušava da napiše poruku sa njega u utičnicu. Ako se bafer prepuni, on počinje da ih ispušta. I broji koliko ih je ispustio. Ako se tu šalteri počnu prelijevati, znat ćemo za to. Sada dolaze i u Prometej, a grafikone možete vidjeti u Grafani. Možete podesiti upozorenja. Ali još nije jasno kome ih poslati.
Vaše pitanje: U elasticsearch pohranjujete dnevnike sa redundantnošću. Koliko replika imate?
Odgovori: Jedna replika.
Vaše pitanje: Je li to samo jedan red?
Odgovori: Ovo je master i replika. Podaci se pohranjuju u duplikatu.
Vaše pitanje: Da li ste nekako podesili veličinu rsyslog bafera?
Odgovori: Mi pišemo datagrame u prilagođeni unix socket. Ovo nam odmah nameće ograničenje od 128 kilobajta. Ne možemo pisati više o tome. Ovo smo zapisali u standard. Ko želi da uđe u skladište, upisuje 128 kilobajta. Biblioteke, štaviše, odsječu, i stavljaju zastavicu da je poruka odsječena. U standardu same poruke imamo posebno polje koje pokazuje da li je prekinuta tokom snimanja ili ne. Tako da imamo priliku da pratimo ovaj trenutak.
Pitanje: Da li pišete neispravan JSON?
Odgovori: Pokvareni JSON će biti odbačen ili tokom releja jer je paket prevelik. Ili će Graylog biti odbačen, jer neće moći raščlaniti JSON. Ali ovdje postoje nijanse koje treba popraviti, a one su uglavnom vezane za rsyslog. Tamo sam već popunio nekoliko brojeva na kojima još treba poraditi.
Pitanje: Zašto Kafka? Jeste li probali RabbitMQ? Graylog se ne zbraja pod takvim opterećenjima?
Odgovori: Ne ide sa Graylogom. I Graylog dobija oblik. Za njega je to zaista problematično. On je neka stvar. I, u stvari, nije potrebno. Radije bih pisao sa rsyslog direktno na elasticsearch i onda gledao Kibanu. Ali moramo da riješimo pitanje sa zaštitarima. Ovo je moguća varijanta našeg razvoja kada izbacimo Graylog i koristimo Kibanu. Logstash neće imati smisla. Zato što mogu učiniti isto sa rsyslog-om. I ima modul za pisanje u elasticsearch. Sa Graylogom pokušavamo nekako živjeti. Čak smo ga malo i doradili. Ali još uvijek ima prostora za poboljšanje.
O Kafki. Tako se to istorijski desilo. Kad sam stigao, već je bio tamo i već su se zapisivali u njega. Samo smo podigli naš klaster i premjestili trupce u njega. Mi upravljamo njime, znamo kako se osjeća. Što se tiče RabbitMQ-a... imamo problema sa RabbitMQ-om. I RabbitMQ se razvija za nas. Imamo ga u proizvodnji i bilo je problema s njim. Sada bi ga prije prodaje šamanizirali i počeo bi normalno raditi. Ali prije toga nisam bio spreman da ga pustim 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 nijedno 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 bafer poruka koji je pokupila iz rsyslog-a. Sve dok to trpimo.
Pitanje: Da li koristite Kafku jer ste je imali? Ne koristi se u druge svrhe?
Odgovori: Kafka, koji je koristio Data Science tim. Ovo je potpuno zaseban projekat, o kojem, nažalost, ne mogu ništa reći. Ne znam. Nju je vodio tim nauke o podacima. Kada su balvani krenuli, odlučili su da ga koriste, kako ne bi stavljali svoje. Sada smo ažurirali Graylog i izgubili smo kompatibilnost, jer postoji stara verzija Kafke. Morali smo sami napraviti. Istovremeno smo se riješili ove četiri teme za svaki API. Napravili smo jedan široki vrh za sve uživo, jedan široki gornji dio za sve inscenacije i samo snimamo sve tamo. Graylog sve ovo izvodi paralelno.
Pitanje: Zašto nam treba ovaj šamanizam sa utičnicama? Jeste li probali koristiti drajver syslog dnevnika za kontejnere.
Odgovori: U vrijeme kada smo postavljali ovo pitanje, imali smo napete odnose sa dockerom. Bio je to docker 1.0 ili 0.9. Sam Docker je bio čudan. Drugo, ako u njega ugurate i logove... imam neprovjerenu sumnju da propušta sve logove kroz sebe, kroz docker daemon. Ako jedan API poludi, onda će ostali API-ji naići na činjenicu da ne mogu poslati stdout i stderr. Ne znam kuda će ovo dovesti. Sumnjam na nivou osjećaja da nije potrebno koristiti drajver docker syslog na ovom mjestu. Naš odjel za funkcionalno testiranje ima vlastiti Graylog klaster s logovama. Koriste drajvere dnevnika docker-a i izgleda da je tamo sve u redu. Ali oni odmah pišu GELF Graylogu. U trenutku kada smo sve ovo započeli, trebalo nam je samo da funkcioniše. Možda kasnije, kada neko dođe i kaže da to normalno radi sto godina, pokušaćemo.
Pitanje: Dostavljate između centara podataka koristeći rsyslog. Zašto ne na Kafki?
Odgovori: Mi to radimo, i to je tako. Iz dva razloga. Ako je kanal potpuno mrtav, onda se svi naši trupci, čak ni u komprimiranom obliku, neće popeti kroz njega. A kafka im dozvoljava da jednostavno izgube u tom procesu. Na ovaj način se rješavamo lijepljenja ovih trupaca. Mi samo koristimo Kafku u ovom slučaju direktno. Ako imamo dobar kanal i želimo ga osloboditi, onda koristimo njihov rsyslog. Ali u stvari, možete ga postaviti tako da ispusti ono što nije prošao. Trenutno samo koristimo rsyslog isporuku direktno negde, negde Kafka.
izvor: www.habr.com