Jurnalele sunt o parte importantă a sistemului, permițându-vă să înțelegeți că funcționează (sau nu funcționează) conform așteptărilor. Într-o arhitectură de microservicii, lucrul cu jurnalele devine o disciplină separată pentru o Olimpiada specială. O grămadă de întrebări trebuie rezolvate deodată:
- cum să scrieți jurnalele dintr-o aplicație;
- unde să scrieți jurnalele;
- cum se livrează jurnalele pentru stocare și procesare;
- cum să procesați și să stocați jurnalele.
Utilizarea tehnologiilor de containerizare populare în prezent adaugă nisip pe partea de sus a greblei în domeniul opțiunilor de rezolvare a problemei.
Este exact despre ce este vorba în transcrierea raportului lui Yuri Bushmelev „Harta greblelor în domeniul colectării și livrării buștenilor”.
Pentru cei interesați, vă rugăm să vedeți cat.
Numele meu este Yuri Bushmelev. Lucrez la Lazada. Astăzi voi vorbi despre cum ne-am făcut buștenii, cum le-am colectat și ce scriem acolo.
De unde suntem? Cine suntem noi? Lazada este retailerul online nr. 1 în șase țări din Asia de Sud-Est. Toate aceste țări sunt distribuite între centrele noastre de date. În prezent, există 4 centre de date în total. De ce este important acest lucru? Pentru că unele decizii s-au datorat faptului că există o legătură foarte slabă între centre. Avem o arhitectură de microservicii. Am fost surprins să constat că avem deja 80 de microservicii. Când am început sarcina cu jurnalele, erau doar 20. În plus, există o bucată destul de mare de moștenire PHP, cu care trebuie să trăiesc și să o suport. Toate acestea generează în prezent peste 6 milioane de mesaje pe minut pentru întregul sistem. În continuare, voi arăta cum încercăm să trăim cu asta și de ce este așa.
Trebuie să trăiești cumva cu aceste 6 milioane de mesaje. Ce ar trebui să facem cu ei? 6 milioane de mesaje de care aveți nevoie:
- trimite din aplicație
- accepta pentru livrare
- livrați pentru analiză și depozitare.
- a analiza
- depozitează-l cumva.
Când au apărut trei milioane de mesaje, eu arătam cam la fel. Pentru că am început cu doar câțiva bănuți. Este clar că acolo sunt scrise jurnalele de aplicații. De exemplu, nu m-am putut conecta la baza de date, am putut să mă conectez la baza de date, dar nu am putut citi nimic. Dar, pe lângă aceasta, fiecare dintre microservicii noastre scrie și un jurnal de acces. Fiecare cerere care ajunge la microserviciu este înregistrată în jurnal. De ce facem asta? Dezvoltatorii doresc să poată urmări. Fiecare jurnal de acces conține un câmp traceid, folosindu-se de o interfață specială care apoi desfășoară întregul lanț și afișează frumos urma. Urmărirea arată cum a decurs cererea, iar acest lucru îi ajută pe dezvoltatorii noștri să se ocupe rapid de orice gunoi neidentificat.
Cum să trăiești cu asta? Acum voi descrie pe scurt domeniul opțiunilor - cum se rezolvă în general această problemă. Cum se rezolvă problema culegerii, transmiterii și stocării jurnalelor.
Cum se scrie dintr-o aplicație? Este clar că există moduri diferite. În special, există cele mai bune practici, după cum ne spun camarazii noștri la modă. Există două tipuri de școală veche, așa cum ne spuneau bunicii noștri. Există și alte moduri.
Situația cu colectarea buștenilor este aproximativ aceeași. Nu există multe opțiuni pentru a rezolva această parte anume. Sunt deja mai mulți, dar încă nu atât de mulți.
Dar odată cu livrarea și analiza ulterioară, numărul de variații începe să explodeze. Nu voi descrie fiecare opțiune acum. Cred că opțiunile principale sunt bine cunoscute de toți cei interesați de subiect.
Vă voi arăta cum am făcut-o la Lazada și cum a început totul de fapt.
Acum un an am venit la Lazada și am fost trimis la un proiect despre bușteni. A fost ceva de genul asta. Jurnalul aplicației a fost scris în stdout și stderr. Totul a fost făcut într-un mod la modă. Dar apoi dezvoltatorii l-au aruncat din fluxurile standard și apoi, cumva, specialiștii în infrastructură o vor da seama. Între specialiști în infrastructură și dezvoltatori, există și eliberatori care au spus: „uh... bine, hai să-i înfășurăm într-un fișier cu un shell și gata.” Și din moment ce toate acestea erau într-un container, l-au împachetat chiar în containerul în sine, au cartografiat catalogul în interior și l-au pus acolo. Cred că este destul de evident pentru toată lumea ce a rezultat din asta.
Să privim puțin mai departe deocamdată. Cum am livrat aceste bușteni? Cineva a ales td-agent, care este de fapt fluent, dar nu destul de fluent. Încă nu înțeleg relația dintre aceste două proiecte, dar par să fie cam același lucru. Și acest fluentd, scris în Ruby, a citit fișierele jurnal, le-a analizat în JSON folosind un fel de regularitate. Apoi i-am trimis la Kafka. Mai mult, în Kafka am avut 4 subiecte separate pentru fiecare API. De ce 4? Pentru că există live, există punere în scenă și pentru că există stdout și stderr. Dezvoltatorii le creează, iar dezvoltatorii de infrastructură trebuie să le creeze în Kafka. Mai mult, Kafka era controlat de un alt departament. Prin urmare, a fost necesar să se creeze un bilet, astfel încât să creeze 4 subiecte pentru fiecare api. Toată lumea a uitat de asta. În general, a fost gunoaie și agitație.
Ce am făcut mai departe cu asta? I-am trimis-o lui Kafka. Apoi jumătate din buștenii de la Kafka au zburat către Logstash. Cealaltă jumătate de bușteni au fost împărțite. Unii au zburat către un Graylog, alții către altul Graylog. Ca rezultat, toate acestea au intrat într-un singur cluster Elasticsearch. Adică toată mizeria asta a ajuns acolo. Nu face asta!
Așa arată dacă te uiți la el de sus. Nu face asta! Aici zonele cu probleme sunt imediat marcate cu numere. De fapt, sunt mai multe, dar 6 sunt cu adevărat problematice pentru care trebuie făcut ceva. Vă voi spune despre ele separat acum.
Aici (1,2,3) scriem fișiere și, în consecință, există trei rake aici deodată.
Primul (1) este că trebuie să le scriem undeva. Nu ar fi întotdeauna de dorit să se ofere API-ului capacitatea de a scrie direct într-un fișier. Este de dorit ca API-ul să fie izolat într-un container, sau chiar mai bine, ca acesta să fie doar pentru citire. Sunt administrator de sistem, așa că am o viziune puțin alternativă asupra acestor lucruri.
Al doilea punct (2,3) este că avem o mulțime de solicitări care vin la API. API-ul scrie multe date într-un fișier. Fișierele cresc. Trebuie să le rotim. Pentru că altfel nu veți putea să vă stocați pe niciun disc acolo. Rotirea lor este proastă deoarece sunt făcute prin redirecționarea prin shell către director. Nu avem cum să-l revizuim. Nu poți spune aplicației să redeschidă mânerele. Pentru că dezvoltatorii te vor privi de parcă ai fi un prost: „Ce descriptori? În general, scriem la stdout.” Dezvoltatorii de infrastructură au făcut copytruncate în logrotate, care pur și simplu face o copie a fișierului și transcrie originalul. În consecință, între aceste procese de copiere spațiul pe disc se epuizează de obicei.
(4) Aveam formate diferite în API-uri diferite. Erau ușor diferite, dar expresia regulată trebuia scrisă diferit. Deoarece toate acestea erau controlate de Puppet, existau o grămadă mare de clase cu proprii lor gândaci. În plus, de cele mai multe ori td-agent putea să mănânce memoria, să fie prost, putea doar să pretindă că funcționează și să nu facă nimic. Din afară era imposibil de înțeles că nu făcea nimic. În cel mai bun caz, va cădea și cineva îl va ridica mai târziu. Mai exact, va sosi o alertă, iar cineva va merge și o va ridica cu mâinile.
(6) Și cele mai multe gunoi și deșeuri a fost elasticsearch. Pentru că era o versiune veche. Pentru că nu aveam maeștri dedicați la acea vreme. Aveam loguri eterogene ale căror câmpuri se puteau suprapune. Ar putea fi scrise jurnalele diferite din aplicații diferite cu aceleași nume de câmp, dar ar putea exista date diferite în interior. Adică, un jurnal vine cu Integer în câmp, de exemplu, nivel. Un alt jurnal vine cu String în câmpul de nivel. În absența cartografierii statice, acesta este un lucru minunat. Dacă, după rotirea indexului în elasticsearch, sosește primul un mesaj cu șir, atunci trăim normal. Dar dacă primul a sosit de la Integer, atunci toate mesajele ulterioare care au sosit de la String sunt pur și simplu aruncate. Deoarece tipul câmpului nu se potrivește.
Am început să punem aceste întrebări. Am decis să nu căutăm pe cei de vină.
Dar ceva trebuie făcut! Lucrul evident este că trebuie să stabilim standarde. Aveam deja niște standarde. Am început câteva ceva mai târziu. Din fericire, un singur format de jurnal pentru toate API-urile fusese deja aprobat la acel moment. Este scris direct în standardele de interacțiune între servicii. În consecință, cei care doresc să primească jurnalele trebuie să le scrie în acest format. Dacă cineva nu scrie jurnalele în acest format, atunci nu garantăm nimic.
În continuare, aș dori să creez un standard unificat pentru metodele de înregistrare, livrare și colectare a jurnalelor. De fapt, unde să le scrii și cum să le livrezi. Situația ideală este atunci când proiectele folosesc aceeași bibliotecă. Există o bibliotecă de înregistrare separată pentru Go și o bibliotecă separată pentru PHP. Toți cei pe care îi avem ar trebui să le folosească. În acest moment, aș spune că avem succes în proporție de 80 la sută în acest sens. Dar unii oameni continuă să mănânce cactusi.
Și acolo (pe diapozitiv) „SLA pentru livrarea jurnalelor” abia începe să apară. Nu există încă, dar lucrăm la el. Pentru că este foarte convenabil când infrastructura spune că dacă scrieți într-un astfel de format într-un loc și nu mai mult de N mesaje pe secundă, atunci cel mai probabil îl vom livra într-un loc. Acest lucru ameliorează multe dureri de cap. Dacă există un SLA, atunci acesta este absolut minunat!
Cum am început să rezolvăm problema? Problema principală a fost cu td-agent. Nu era clar unde se duceau buștenii noștri. Sunt livrate? Se duc? Unde sunt, oricum? Prin urmare, primul punct a fost decis să înlocuiască td-agent. Am subliniat pe scurt opțiunile cu ce să-l înlocuiesc aici.
Fluentd. În primul rând, l-am întâlnit la o slujbă anterioară și, de asemenea, a căzut periodic acolo. În al doilea rând, acesta este același lucru, doar de profil.
Filebeat. Cum ne-a fost convenabil? Pentru că este în Go și avem multă experiență în Go. În consecință, dacă s-ar întâmpla ceva, am putea cumva să adăugăm la asta pentru noi înșine. De aceea nu am luat-o. Ca să nu existe nici măcar tentația de a începe să o rescrieți pentru dvs.
Soluția evidentă pentru administratorul de sistem este tot felul de syslog-uri în această cantitate (syslog-ng/rsyslog/nxlog).
Sau scrie ceva al tău, dar am renunțat la asta, precum și filebeat. Dacă scrieți ceva, este mai bine să scrieți ceva util pentru afaceri. Pentru a livra bușteni, este mai bine să luați ceva gata făcut.
Prin urmare, alegerea s-a rezumat la alegerea între syslog-ng și rsyslog. M-am înclinat spre rsyslog pur și simplu pentru că aveam deja cursuri pentru rsyslog în Puppet și nu am găsit o diferență evidentă între ele. Ce este syslog, ce este syslog. Da, unii au o documentație mai proastă, altele au mai bune. Acesta o poate face astfel, iar celălalt o poate face altfel.
Și puțin despre rsyslog. În primul rând, e mișto pentru că are o mulțime de module. Are RainerScript (un limbaj de configurare modern) care poate fi citit de om. Este un bonus extraordinar că am putea emula comportamentul td-agent folosind instrumente standard și nu s-a schimbat nimic pentru aplicații. Adică schimbăm td-agent în rsyslog și lăsăm totul în pace pentru moment. Și primim imediat livrare de lucru. În continuare, mmnormalize este un lucru minunat în rsyslog. Vă permite să analizați jurnalele, dar nu folosind Grok și regexp. Face un arbore de sintaxă abstractă. Analizează jurnalele în același mod în care un compilator analizează sursele. Acest lucru vă permite să lucrați foarte repede, să consumați puțin procesor și, în general, este un lucru foarte grozav. Există o grămadă de alte bonusuri. Nu mă voi opri asupra lor.
rsyslog are multe alte dezavantaje. Sunt aproximativ la fel ca bonusurile. Principalele probleme sunt că trebuie să știți cum să-l gătiți și trebuie să selectați versiunea.
Am decis că vom scrie jurnalele pe un socket Unix. Și nu în /dev/log, pentru că acolo avem o mizerie de jurnale de sistem, journald este în această conductă. Deci, să scriem într-un socket personalizat. Îl vom atașa la un set de reguli separat. Să nu interferăm cu nimic. Totul va fi transparent și de înțeles. Exact asta am făcut. Directorul cu aceste socket-uri este standardizat și transmis către toate containerele. Containerele pot vedea priza de care au nevoie, pot deschide și pot scrie în el.
De ce nu un dosar? Pentru că toată lumea a citit-o , care a încercat să redirecționeze un fișier către docker și s-a descoperit că după repornirea rsyslog, descriptorul fișierului s-a schimbat și docker a pierdut acest fișier. Mai ține ceva deschis, dar nu soclul unde scriu. Am decis că vom rezolva această problemă și, în același timp, vom rezolva problema blocării.
Rsyslog efectuează acțiunile indicate pe slide și trimite jurnalele fie către releu, fie către Kafka. Kafka urmează calea veche. Relay - Am încercat să folosesc rsyslog pur pentru a livra jurnalele. Fără Message Queue, folosind instrumente standard rsyslog. Practic, funcționează.
Dar există nuanțe cu privire la modul de a le împinge în această parte (Logstash/Graylog/ES). Această parte (rsyslog-rsyslog) este utilizată între centrele de date. Iată o legătură tcp comprimată, care ne permite să economisim lățime de bandă și, în consecință, să creștem cumva probabilitatea de a primi niște loguri de la un alt centru de date atunci când canalul este înfundat. Pentru că avem Indonezia, unde totul este rău. Aici se află problema constantă.
Ne-am gândit cum putem monitoriza de fapt cât de probabil este ca jurnalele pe care le-am înregistrat din aplicație să ajungă la sfârșit? Am decis să creăm valori. rsyslog are propriul modul de colectare a statisticilor, care conține un fel de contoare. De exemplu, vă poate arăta dimensiunea cozii sau câte mesaje au sosit într-o astfel de acțiune. Deja poți lua ceva de la ei. În plus, are contoare personalizate care pot fi configurate și vă va arăta, de exemplu, numărul de mesaje pe care le-au înregistrat unele API. Apoi, am scris rsyslog_exporter în Python și am trimis totul lui Prometheus și am construit grafice. Ne-am dorit foarte mult valori Graylog, dar încă nu am avut timp să le setăm.
Care au fost problemele? Probleme au apărut atunci când am descoperit (DEBUT!) că API-urile noastre Live scriau 50 de mesaje pe secundă. Acesta este doar un API Live fără punere în scenă. Și Graylog ne arată doar 12 mii de mesaje pe secundă. Și a apărut o întrebare rezonabilă: unde sunt rămășițele? Din care am concluzionat că Graylog pur și simplu nu poate face față. Ne-am uitat și, într-adevăr, Graylog și Elasticsearch nu au putut face față acestui flux.
În continuare, alte descoperiri pe care le-am făcut pe parcurs.
Scrierile pe socket sunt blocate. Cum s-a întâmplat? Când foloseam rsyslog pentru livrare, la un moment dat canalul dintre centrele de date s-a stricat. Livrarea s-a oprit într-un loc, livrarea s-a oprit în alt loc. Toate acestea au ajuns la mașină cu API-uri care scriu în socket-ul rsyslog. Era o coadă acolo. Apoi, coada de scriere pe socket-ul Unix, care implicit este de 128 de pachete, s-a umplut. Și următorul write() din aplicație este blocat. Când ne-am uitat la biblioteca pe care o folosim în aplicațiile Go, s-a scris acolo că scrierea pe socket are loc în modul neblocant. Eram siguri că nimic nu era blocat. Pentru că citim care a scris despre asta. Dar există un moment. A existat și o buclă infinită în jurul acestui apel, în care a existat o încercare constantă de a împinge un mesaj în priză. Nu l-am observat. A trebuit să rescriu biblioteca. De atunci s-a schimbat de mai multe ori, dar acum am scăpat de blocaje în toate subsistemele. Prin urmare, puteți opri rsyslog și nimic nu se va bloca.
Este necesar să se monitorizeze dimensiunea cozilor, ceea ce ajută la evitarea călcării pe această greblă. În primul rând, putem monitoriza când începem să pierdem mesaje. În al doilea rând, putem monitoriza că avem probleme cu livrarea.
Și încă un moment neplăcut - amplificarea de 10 ori într-o arhitectură de microservicii este foarte ușoară. Nu avem multe solicitări primite, dar datorită graficului de-a lungul căruia aceste mesaje parcurg mai departe, din cauza jurnalelor de acces, de fapt creștem încărcarea jurnalului de aproximativ zece ori. Din păcate, nu am avut timp să calculez cifrele exacte, dar microservicii sunt ceea ce sunt. Acest lucru trebuie reținut. Se dovedește că în acest moment subsistemul de colectare a buștenilor este cel mai încărcat din Lazada.
Cum se rezolvă problema elasticsearch? Dacă trebuie să obțineți rapid jurnalele într-un singur loc, pentru a nu alerga la toate mașinile și a le colecta acolo, utilizați stocarea fișierelor. Acest lucru este garantat să funcționeze. Se poate face de pe orice server. Trebuie doar să lipiți discuri acolo și să instalați syslog. După aceasta, aveți garantat că aveți toate jurnalele într-un singur loc. Apoi puteți configura încet elasticsearch, graylog și altceva. Dar veți avea deja toate jurnalele și, în plus, le puteți stoca atâta timp cât sunt suficiente matrice de discuri.
La momentul raportului meu, schema a început să arate așa. Practic am încetat să scriem în fișier. Acum, cel mai probabil, vom opri restul. Pe mașinile locale care rulează API-ul, vom opri scrierea în fișiere. În primul rând, există stocarea fișierelor, care funcționează foarte bine. În al doilea rând, aceste mașini rămân în mod constant fără spațiu; acesta trebuie monitorizat în mod constant.
Partea asta cu Logstash și Graylog, decolează cu adevărat. Prin urmare, trebuie să scăpăm de el. Trebuie să alegi un lucru.
Am decis să aruncăm Logstash și Kibana. Pentru că avem un departament de securitate. Ce legătură? Conexiunea este că Kibana fără X-Pack și fără Shield nu vă permite să diferențiați drepturile de acces la jurnalele. De aceea am luat Graylog. Are de toate. Nu-mi place, dar funcționează. Am cumpărat hardware nou, am instalat acolo Graylog proaspăt și am transferat toate jurnalele cu formate stricte într-un Graylog separat. Am rezolvat problema cu diferite tipuri de domenii identice din punct de vedere organizațional.
Ce este inclus exact în noul Graylog. Tocmai am scris totul în docker. Am luat o grămadă de servere, am lansat trei instanțe Kafka, 7 servere Graylog versiunea 2.3 (pentru că am vrut Elasticsearch versiunea 5). Toate acestea au fost preluate în timpul raidurilor de pe HDD. Am văzut o rată de indexare de până la 100 de mii de mesaje pe secundă. Am văzut cifra că 140 terabytes de date pe săptămână.
Și din nou grebla! Urmează două vânzări. Am depășit 6 milioane de mesaje. Graylog nu are timp să mestece. Cumva trebuie să supraviețuim din nou.
Așa am supraviețuit. Am adăugat încă câteva servere și SSD-uri. Momentan traim asa. Acum mestecăm deja 160 de mesaje pe secundă. Încă nu am atins limita, așa că nu este clar cât de mult putem obține de fapt din asta.
Acestea sunt planurile noastre pentru viitor. Dintre acestea, cea mai importantă este probabil disponibilitatea ridicată. Încă nu-l avem. Mai multe mașini sunt configurate în același mod, dar până acum totul trece printr-o singură mașină. Este nevoie de timp pentru a configura failover-ul între ele.
Colectați valori de la Graylog.
Faceți o limită de rată, astfel încât să avem un API nebun care să nu ne distrugă lățimea de bandă și orice altceva.
Și, în sfârșit, semnați un fel de SLA cu dezvoltatorii, astfel încât să putem servi atât de mult. Dacă mai scrii, atunci îmi pare rău.
Și scrieți documentația.
Pe scurt, rezultatele a tot ceea ce am experimentat. În primul rând, standardele. În al doilea rând, syslog este tort. În al treilea rând, rsyslog funcționează exact așa cum este scris pe diapozitiv. Și să trecem la întrebări.
întrebări.
Întrebare: De ce ai decis să nu iei... (filebeat?)
Răspunde: Trebuie să scriem într-un fișier. Chiar nu am vrut. Când API-ul dvs. scrie mii de mesaje pe secundă, chiar dacă îl rotiți o dată pe oră, aceasta încă nu este o opțiune. Puteți scrie în pipe. La care dezvoltatorii m-au întrebat: „Ce se va întâmpla dacă procesul căruia îi scriem se blochează?” Pur și simplu nu am găsit ce să le răspund și am spus: „Ei bine, bine, să nu facem asta.”
Întrebare: De ce nu scrieți doar jurnalele pe HDFS?
Răspunde: Aceasta este etapa următoare. Ne-am gândit la asta chiar de la început, dar din moment ce nu există resurse pentru a face acest lucru, se blochează în soluția noastră pe termen lung.
Întrebare: Formatul coloanei ar fi mai potrivit.
Răspunde: Am înțeles. Suntem pentru asta cu ambele mâini.
Întrebare: Scrieți la rsyslog. Acolo puteți folosi atât TCP, cât și UDP. Dar dacă UDP, atunci cum garantați livrarea?
Răspunde: Sunt două puncte. În primul rând, le spun imediat tuturor că nu garantăm livrarea buștenilor. Pentru că atunci când vin dezvoltatorii și spun: „Hai să începem să scriem date financiare acolo și le vei pune undeva pentru noi în cazul în care se întâmplă ceva”, le răspundem: „Foarte! Să începem să blocăm scrierea pe socket și să facem acest lucru în tranzacții, astfel încât să fiți garantat să îl puneți pe socket pentru noi și să vă asigurați că îl primim de cealaltă parte.” Și în acest moment, toată lumea imediat nu mai are nevoie de el. Dacă nu este necesar, atunci ce întrebări ar trebui să punem? Dacă nu doriți să garantați scrierea pe o priză, atunci de ce trebuie să garantăm livrarea? Facem tot posibilul. Chiar încercăm să livrăm cât mai mult și în cel mai bun mod posibil, dar nu oferim o garanție 100%. Prin urmare, nu este nevoie să scrieți acolo date financiare. Există baze de date cu tranzacții pentru asta.
Întrebare: Când API-ul generează un mesaj în jurnal și transferă controlul către microservicii, ați întâmpinat problema că mesajele de la diferite microservicii ajung în ordine greșită? Acest lucru provoacă confuzie.
Răspunde: Este normal să vină în ordine diferite. Trebuie să fii pregătit pentru asta. Pentru că orice livrare în rețea nu garantează comanda, sau trebuie să cheltuiți resurse speciale pentru asta. Dacă luăm stocări de fișiere, atunci fiecare API salvează jurnalele în propriul fișier. Sau, mai degrabă, acolo rsyslog le sortează în directoare. Fiecare API are propriile sale jurnale, unde puteți merge și căuta, apoi le puteți compara folosind marcajul de timp din acest jurnal. Dacă se uită în Graylog, atunci sunt sortate acolo după marcaj de timp. Totul va fi bine acolo.
Întrebare: Timpul poate varia cu milisecunde.
Răspunde: Timpul este generat de API-ul în sine. Acesta este, de fapt, toată ideea. Avem NTP. API-ul generează un marcaj de timp în mesajul însuși. rsyslog nu îl adaugă.
Întrebare: Interacțiunea dintre centrele de date nu este foarte clară. În cadrul centrului de date, este clar cum au fost colectate și procesate jurnalele. Cum are loc interacțiunea dintre centrele de date? Sau fiecare centru de date își trăiește propria viață?
Răspunde: Aproape. În țara noastră, fiecare țară este situată într-un singur centru de date. În prezent, nu avem o distribuție, astfel încât o țară să fie situată în centre de date diferite. Prin urmare, nu este nevoie să le combinați. Fiecare centru are înăuntru un releu de jurnal. Acesta este un server Rsyslog. De fapt, două mașini de management. Au aceeasi atitudine. Dar deocamdată, traficul trece doar prin unul dintre ele. Agregează toate jurnalele. Are o coadă de disc pentru orice eventualitate. Acesta descarcă jurnalele și le trimite la centrul de date central (Singapore), unde sunt apoi trimise la Graylog. Și fiecare centru de date are propriul său spațiu de stocare a fișierelor. În cazul în care conexiunea noastră se pierde, avem toate jurnalele acolo. Vor rămâne acolo. Ele vor fi depozitate acolo.
Întrebare: În cazul unor situații anormale, primiți loguri de acolo?
Răspunde: Puteți merge acolo (la stocarea fișierelor) și căutați.
Întrebare: Cum monitorizezi că nu pierzi jurnalele?
Răspunde: De fapt îi pierdem și îl monitorizăm. Monitorizarea a fost lansată în urmă cu o lună. Biblioteca pe care o folosesc API-urile Go are valori. Ea poate număra de câte ori nu a putut să scrie la o priză. În prezent există o euristică inteligentă acolo. Există un tampon acolo. Încearcă să scrie un mesaj de la el pe soclu. Dacă tamponul se depășește, începe să le piardă. Și numără câte dintre ele a scăpat. Dacă contoarele încep să se reverse acolo, vom ști despre asta. Acum vin și la prometheus și puteți vedea graficele în Grafana. Puteți configura alerte. Dar nu este încă clar cui să le trimită.
Întrebare: În elasticsearch stocați jurnalele cu redundanță. Câte replici ai?
Răspunde: O linie.
Întrebare: Aceasta este doar o linie?
Răspunde: Acesta este maestrul și replica. Datele sunt stocate în două copii.
Întrebare: Ați ajustat cumva dimensiunea bufferului rsyslog?
Răspunde: Scriem datagrame pe un socket Unix personalizat. Acest lucru ne impune imediat o limită de 128 de kiloocteți. Nu putem scrie mai multe despre el. Am scris acest lucru în standard. Cei care vor să intre în stocare scriu 128 kilobytes. În plus, bibliotecile sunt tăiate și este plasat un steag că mesajul este tăiat. Standardul nostru pentru mesajul în sine are un câmp special care arată dacă a fost întrerupt în timpul înregistrării sau nu. Așa că avem ocazia să urmărim și acest moment.
Întrebare: Scrieți JSON rupt?
Răspunde: JSON rupt va fi eliminat fie în timpul reluării, deoarece pachetul este prea mare. Sau Graylog va fi eliminat deoarece nu poate analiza JSON. Dar există nuanțe care trebuie remediate și sunt în mare parte legate de rsyslog. Am completat deja mai multe probleme acolo, la care încă mai trebuie să fie lucrate.
Întrebare: De ce Kafka? Ați încercat RabbitMQ? Greylog eșuează la astfel de sarcini?
Răspunde: Nu ne merge cu Graylog. Și Graylog prinde contur pentru noi. El chiar este problematic. El este un lucru ciudat. Și, de fapt, nu este nevoie. Aș prefera să scriu din rsyslog direct în elasticsearch și apoi să mă uit la Kibana. Dar trebuie să rezolvăm problema cu securiștii. Aceasta este o opțiune posibilă pentru dezvoltarea noastră, atunci când aruncăm Graylog și folosim Kibana. Nu are rost să folosești Logstash. Pentru că pot face același lucru cu rsyslog. Și are un modul pentru scriere în elasticsearch. Încercăm să trăim cumva cu Graylog. Chiar l-am reglat puțin. Dar mai este loc de îmbunătățire.
Despre Kafka. Așa s-a întâmplat istoric. Când am ajuns, era deja acolo, iar jurnalele erau deja scrise în el. Pur și simplu ne-am ridicat grupul și am mutat busteni în el. Noi suntem conducerea lui, știm cum se simte. Cât despre RabbitMQ... la noi nu merge cu RabbitMQ. Și RabbitMQ prinde contur pentru noi. Îl avem în producție și au fost probleme cu el. Acum, înainte de vânzare, îl fermecau, iar el începea să lucreze normal. Dar înainte de asta nu eram pregătit să-l lansez în producție. Mai este un punct. Graylog poate citi versiunea AMQP 0.9, iar rsyslog poate scrie versiunea AMQP 1.0. Și nu există o singură soluție la mijloc care să le poată face pe amândouă. Este fie una, fie alta. Prin urmare, momentan doar Kafka. Dar are și propriile sale nuanțe. Deoarece omkafka a versiunii de rsyslog pe care o folosim poate pierde întregul buffer de mesaje pe care l-a extras din rsyslog. Deocamdată o suportăm.
Întrebare: Folosești Kafka pentru că îl aveai deja? Nu mai este folosit în niciun scop?
Răspunde: Kafka, care a fost, este folosit de echipa Data Science. Acesta este un proiect complet separat, despre care, din păcate, nu pot spune nimic. Nu stiu. A fost condus de echipa Data Science. Când au fost create jurnalele, am decis să-l folosim pentru a nu instala propriile noastre. Acum am actualizat Graylog și am pierdut compatibilitatea deoarece are o versiune veche de Kafka. Trebuia să începem pe a noastră. În același timp, am scăpat de aceste patru subiecte pentru fiecare API. Am creat un subiect larg pentru toți în direct, un subiect larg pentru toate punerea în scenă și am pus totul acolo. Graylog zgârie toate acestea în paralel.
Întrebare: De ce avem nevoie de acest șamanism cu prize? Ați încercat să utilizați driverul de jurnal syslog pentru containere?
Răspunde: La momentul în care am pus această întrebare, relația noastră cu docker-ul era tensionată. Era docker 1.0 sau 0.9. Docker însuși era ciudat. În al doilea rând, dacă împingi și loguri în el... Am o suspiciune neverificată că trece toate jurnalele prin el însuși, prin demonul docker. Dacă un API o ia razna, atunci restul API-urilor sunt blocate în faptul că nu pot trimite stdout și stderr. Nu știu unde va duce asta. Am o suspiciune la nivelul sentimentului că nu este nevoie să utilizați driverul Syslog Docker în acest loc. Departamentul nostru de testare funcțională are propriul său cluster Graylog cu jurnalele. Ei folosesc drivere de jurnal Docker și totul pare să fie bine acolo. Dar ii scriu imediat GELF lui Graylog. La momentul în care am început toate acestea, aveam nevoie doar să funcționeze. Poate mai târziu, când vine cineva și va spune că funcționează bine de o sută de ani, vom încerca.
Întrebare: Efectuați livrarea între centrele de date folosind rsyslog. De ce nu Kafka?
Răspunde: De fapt, le facem pe amândouă. Din două motive. Dacă canalul este complet mort, atunci toate jurnalele noastre, chiar și în formă comprimată, nu se vor târâ prin el. Iar Kafka vă permite să le pierdeți pur și simplu în acest proces. Așa scăpăm de aceste bușteni care se blochează. Îl folosim direct pe Kafka în acest caz. Dacă avem un canal bun și vrem să-l eliberăm, atunci folosim rsyslog-ul lor. Dar, de fapt, îl puteți configura astfel încât el însuși să piardă ceea ce nu s-a potrivit. Momentan, folosim doar livrarea rsyslog direct undeva și Kafka undeva.
Sursa: www.habr.com