Protokoly sú dôležitou súčasťou systému a umožňujú vám pochopiť, že funguje (alebo nefunguje) podľa očakávania. V architektúre mikroservisov sa práca s protokolmi stáva samostatnou disciplínou špeciálnej olympiády. Je potrebné vyriešiť niekoľko otázok naraz:
- ako písať denníky z aplikácie;
- kam písať denníky;
- ako dodať protokoly na uskladnenie a spracovanie;
- ako spracovávať a uchovávať protokoly.
Použitie v súčasnosti populárnych technológií kontajnerovania pridáva piesok na vrchu hrablí do poľa možností riešenia problému.
Presne o tom je prepis správy Jurija Bushmeleva „Mapa hrablí v oblasti zberu a doručovania guľatiny“.
Koho to zaujíma, prosím pod mačku.
Volám sa Jurij Bushmelev. Pracujem v Lazade. Dnes budem hovoriť o tom, ako sme vyrábali naše polená, ako sme ich zbierali a čo tam píšeme.
odkiaľ sme? Kto sme? Lazada je online predajca číslo 1 v šiestich krajinách juhovýchodnej Ázie. Všetky tieto krajiny sú rozdelené medzi naše dátové centrá. V súčasnosti existujú celkom 4 dátové centrá. Prečo je to dôležité? Pretože niektoré rozhodnutia boli spôsobené tým, že medzi centrami je veľmi slabé prepojenie. Máme architektúru mikroslužieb. S prekvapením som zistil, že už máme 80 mikroslužieb. Keď som začal úlohu s protokolmi, bolo ich len 20. Plus je tam dosť veľký kus dedičstva PHP, s ktorým tiež musím žiť a strpieť ho. To všetko v súčasnosti generuje viac ako 6 miliónov správ za minútu pre systém ako celok. Ďalej ukážem, ako sa s tým snažíme žiť a prečo je to tak.
S týmito 6 miliónmi správ musíte nejako žiť. Čo by sme s nimi mali robiť? 6 miliónov správ, ktoré potrebujete:
- odoslať z aplikácie
- prijať na doručenie
- dodať na analýzu a uskladnenie.
- analyzovať
- nejako to uložiť.
Keď sa objavili tri milióny správ, vyzeral som približne rovnako. Pretože sme začínali len s pár haliermi. Je jasné, že sa tam píšu protokoly aplikácií. Napríklad som sa nemohol pripojiť k databáze, mohol som sa pripojiť k databáze, ale nemohol som nič prečítať. Okrem toho však každá z našich mikroslužieb zapisuje aj denník prístupu. Každá požiadavka, ktorá príde do mikroslužby, sa zaznamená do denníka. Prečo to robíme? Vývojári chcú mať možnosť sledovať. Každý prístupový protokol obsahuje pole traceid, pomocou ktorého potom špeciálne rozhranie rozvinie celý reťazec a krásne zobrazí sledovanie. Sledovanie ukazuje, ako žiadosť prebehla, a to pomáha našim vývojárom rýchlo sa vysporiadať s akýmkoľvek neidentifikovaným odpadom.
Ako s tým žiť? Teraz stručne popíšem pole možností - ako sa tento problém všeobecne rieši. Ako vyriešiť problém zberu, prenosu a ukladania protokolov.
Ako písať z aplikácie? Je jasné, že existujú rôzne spôsoby. Ide najmä o osvedčené postupy, ako nám hovoria naši módni súdruhovia. Existujú dva typy starej školy, ako nám hovorili naši starí otcovia. Sú aj iné spôsoby.
Pri zbieraní guľatiny je situácia približne rovnaká. Nie je veľa možností na riešenie tejto konkrétnej časti. Je ich už viac, ale ešte nie toľko.
S doručením a následnou analýzou však počet variácií začne explodovať. Nebudem teraz popisovať jednotlivé možnosti. Myslím, že hlavné možnosti sú dobre známe každému, kto sa o danú tému zaujíma.
Ukážem vám, ako sme to robili na Lazade, a ako to vlastne celé začalo.
Pred rokom som prišiel do Lazady a poslali ma do projektu o polenách. Bolo to niečo podobné. Protokol aplikácie bol zapísaný do stdout a stderr. Všetko sa robilo módnym spôsobom. Ale potom to vývojári vyhodili zo štandardných tokov a potom na to nejako prídu špecialisti na infraštruktúru. Medzi špecialistami na infraštruktúru a vývojármi sú aj vydavatelia, ktorí povedali: „Uh... no, zabalíme ich do súboru s shellom, a je to.“ A keďže toto všetko bolo v kontajneri, zabalili to rovno do samotného kontajnera, zmapovali katalóg vnútri a dali to tam. Myslím, že je každému jasné, čo z toho vzniklo.
Pozrime sa zatiaľ trochu ďalej. Ako sme doručili tieto protokoly? Niekto si vybral td-agent, ktorý v skutočnosti hovorí plynule, ale nie úplne plynule. Stále nerozumiem vzťahu medzi týmito dvoma projektmi, ale zdá sa, že sú o tom istom. A tento plynulý, napísaný v Ruby, čítal protokolové súbory, analyzoval ich do JSON pomocou určitej pravidelnosti. Potom som ich poslal Kafkovi. Navyše v Kafke sme mali 4 samostatné témy pre každé API. Prečo 4? Pretože existuje živé vysielanie, existuje inscenácia a pretože existuje stdout a stderr. Vytvárajú ich vývojári a vývojári infraštruktúry ich musia vytvárať v Kafke. Navyše Kafku kontrolovalo iné oddelenie. Preto bolo potrebné vytvoriť lístok tak, aby vytvorili 4 témy pre každé api. Všetci na to zabudli. Vo všeobecnosti tam bol odpad a rozruch.
Čo sme s tým urobili ďalej? Poslali sme to Kafkovi. Potom polovica polená od Kafku odletela do Logstashe. Druhá polovica guľatiny bola rozdelená. Niektorí leteli k jednému Graylogovi, niektorí k druhému Graylogovi. Výsledkom bolo, že to všetko išlo do jedného klastra Elasticsearch. To znamená, že všetok tento neporiadok skončil tam. Nerob to!
Takto to vyzerá, keď sa na to pozriete zhora. Nerob to! Tu sú problémové oblasti okamžite označené číslami. V skutočnosti je ich viac, ale 6 je naozaj problémových, s ktorými treba niečo robiť. Teraz vám o nich poviem samostatne.
Sem (1,2,3) zapisujeme súbory a podľa toho sú tu tri hrable naraz.
Prvý (1) je, že ich musíme niekam zapísať. Nie vždy by bolo žiaduce dať API možnosť zapisovať priamo do súboru. Je žiaduce, aby API bolo izolované v kontajneri, alebo ešte lepšie, aby bolo len na čítanie. Som správca systému, takže mám na tieto veci trochu alternatívny pohľad.
Druhý bod (2,3) je, že na API prichádza veľa požiadaviek. API zapisuje veľa údajov do súboru. Súbory pribúdajú. Musíme ich striedať. Pretože inak tam nebudete môcť zásobiť žiadne disky. Ich otáčanie je zlé, pretože sa robia presmerovaním cez shell do adresára. Neexistuje spôsob, ako by sme ho mohli revidovať. Nemôžete prikázať aplikácii, aby znova otvorila kľučky. Pretože vývojári sa na vás budú pozerať ako na blázna: „Aké deskriptory? Vo všeobecnosti píšeme stdout.“ Vývojári infraštruktúry vytvorili copytruncate na logrotate, čo jednoducho vytvorí kópiu súboru a prepíše originál. V súlade s tým sa medzi týmito procesmi kopírovania zvyčajne minie miesto na disku.
(4) Mali sme rôzne formáty v rôznych rozhraniach API. Boli mierne odlišné, ale regulárny výraz musel byť napísaný inak. Keďže toto všetko ovládal Puppet, bola tu veľká skupina tried s vlastnými švábmi. Navyše, väčšinu času td-agent mohol požierať pamäť, byť hlúpy, mohol len predstierať, že to funguje a nič nerobiť. Zvonku nebolo možné pochopiť, že nič nerobí. V lepšom prípade spadne a niekto ho neskôr zoberie. Presnejšie povedané, príde upozornenie a niekto to pôjde zdvihnúť rukami.
(6) A najviac odpadu a odpadu bolo elasticsearch. Pretože to bola stará verzia. Pretože sme v tom čase nemali oddaných majstrov. Mali sme heterogénne guľatiny, ktorých polia sa mohli prekrývať. Rôzne protokoly z rôznych aplikácií môžu byť zapísané s rovnakými názvami polí, ale vo vnútri môžu byť rôzne údaje. To znamená, že jeden protokol prichádza s Integer v poli, napríklad úroveň. Ďalší protokol prichádza s reťazcom v poli úrovne. Pri absencii statického mapovania je to taká úžasná vec. Ak po otočení indexu v elasticsearch príde ako prvá správa s reťazcom, tak žijeme normálne. Ak však prvá prišla z čísla Integer, všetky nasledujúce správy, ktoré prišli z reťazca String, sa jednoducho zahodia. Pretože typ poľa sa nezhoduje.
Začali sme si klásť tieto otázky. Rozhodli sme sa nehľadať vinníkov.
Ale treba niečo urobiť! Samozrejmosťou je, že musíme zaviesť normy. Mali sme už nejaké štandardy. S niektorými sme začali o niečo neskôr. Našťastie už v tom čase bol schválený jednotný formát protokolu pre všetky rozhrania API. Je to zapísané priamo v štandardoch pre interakciu medzi službami. Preto tí, ktorí chcú dostávať protokoly, ich musia napísať v tomto formáte. Ak niekto nepíše logy v tomto formáte, tak neručíme za nič.
Ďalej by som chcel vytvoriť jednotný štandard pre spôsoby evidencie, doručovania a zberu protokolov. Vlastne, kde ich napísať a ako ich doručiť. Ideálny stav je, keď projekty využívajú rovnakú knižnicu. Existuje samostatná knižnica protokolov pre Go a samostatná knižnica pre PHP. Každý, koho máme, by ich mal používať. Momentálne by som povedal, že v tomto sme úspešní na 80 percent. Niektorí ľudia však naďalej jedia kaktusy.
A tam (na snímke) sa sotva začína objavovať „SLA na doručenie protokolov“. Zatiaľ neexistuje, ale pracujeme na tom. Pretože je veľmi pohodlné, keď infraštruktúra hovorí, že ak napíšete v takom a takom formáte na také a také miesto a nie viac ako N správ za sekundu, tak to s najväčšou pravdepodobnosťou doručíme na také a také miesto. To uľaví od mnohých bolestí hlavy. Ak existuje SLA, potom je to úplne úžasné!
Ako sme začali problém riešiť? Hlavný problém bol s td-agentom. Nebolo jasné, kam šli naše polená. Sú doručené? idú? Kde vlastne sú? Preto bolo v prvom bode rozhodnuté nahradiť td-agent. Možnosti, čím ho nahradiť, som v krátkosti načrtol tu.
Plynulé. Po prvé, stretol som ho v predchádzajúcej práci a tiež tam pravidelne padal. Po druhé, ide o to isté, len z profilu.
Filebeat. Ako nám to vyhovovalo? Pretože je to v Go a my máme v Go veľa odborných znalostí. Podľa toho, keby sa niečo stalo, mohli by sme to nejako doplniť pre seba. Preto sme to nezobrali. Aby ani nebolo pokušenie začať si to prepisovať na seba.
Samozrejmým riešením pre správcu systému sú najrôznejšie syslogy v tomto množstve (syslog-ng/rsyslog/nxlog).
Alebo napíšte niečo vlastné, ale toto sme zahodili, rovnako ako filebeat. Ak niečo napíšete, je lepšie napísať niečo užitočné pre podnikanie. Na doručenie guľatiny je lepšie vziať niečo hotové.
Preto výber v skutočnosti padol na výber medzi syslog-ng a rsyslog. Priklonil som sa k rsyslogu jednoducho preto, lebo sme už mali triedy pre rsyslog v Puppet a nenašiel som medzi nimi zjavný rozdiel. Čo je syslog, čo je syslog. Áno, niektorí majú horšiu dokumentáciu, niektorí majú lepšiu. Tento to dokáže takto a ten druhý inak.
A trochu o rsyslog. V prvom rade je to super, pretože má veľa modulov. Má ľudsky čitateľný RainerScript (moderný konfiguračný jazyk). Je to úžasný bonus, že sme mohli napodobniť správanie td-agenta pomocou štandardných nástrojov a pre aplikácie sa nič nezmenilo. To znamená, že zmeníme td-agent na rsyslog a všetko ostatné zatiaľ necháme na pokoji. A okamžite dostaneme pracovnú dodávku. Ďalej, mmnormalize je úžasná vec v rsyslog. Umožňuje vám analyzovať protokoly, ale nepoužívate Grok a regexp. Vytvára abstraktný strom syntaxe. Analyzuje protokoly takmer rovnakým spôsobom ako kompilátor analyzuje zdroje. To vám umožní pracovať veľmi rýchlo, spotrebovať málo CPU a vo všeobecnosti je to naozaj skvelá vec. Existuje kopa ďalších bonusov. Nebudem sa nimi zaoberať.
rsyslog má veľa ďalších nevýhod. Sú približne rovnaké ako bonusy. Hlavným problémom je, že musíte vedieť, ako ho variť, a musíte si vybrať verziu.
Rozhodli sme sa, že budeme zapisovať protokoly do unixového socketu. A nie v /dev/log, pretože tam máme neporiadok systémových protokolov, journald je v tomto potrubí. Poďme teda napísať do vlastnej zásuvky. Pripojíme ho k samostatnému súboru pravidiel. Do ničoho nezasahujme. Všetko bude transparentné a zrozumiteľné. Presne to sme urobili. Adresár s týmito zásuvkami je štandardizovaný a posielaný do všetkých kontajnerov. Kontajnery môžu vidieť zásuvku, ktorú potrebujú, otvoriť ju a zapisovať do nej.
Prečo nie súbor? Pretože to čítajú všetci , ktorý sa pokúsil preposlať súbor do dockera a zistilo sa, že po reštarte rsyslog sa zmenil deskriptor súboru a docker tento súbor stratil. Necháva otvorené niečo iné, ale nie zásuvku, do ktorej píšu. Rozhodli sme sa, že tento problém vyriešime a zároveň vyriešime problém s blokovaním.
Rsyslog vykonáva akcie uvedené na snímke a odosiela protokoly buď relé alebo Kafkovi. Kafka ide po starom. Relé - Skúsil som použiť čistý rsyslog na doručenie protokolov. Bez frontu správ, pomocou štandardných nástrojov rsyslog. V podstate to funguje.
Existujú však nuansy, ako ich vložiť do tejto časti (Logstash/Graylog/ES). Táto časť (rsyslog-rsyslog) sa používa medzi dátovými centrami. Tu je komprimovaný odkaz tcp, ktorý nám umožňuje ušetriť šírku pásma a podľa toho nejakým spôsobom zvýšiť pravdepodobnosť, že dostaneme nejaké protokoly z iného dátového centra, keď je kanál upchatý. Lebo máme Indonéziu, kde je všetko zlé. V tom spočíva neustály problém.
Rozmýšľali sme nad tým, ako vlastne môžeme sledovať, aká je pravdepodobnosť, že logy, ktoré sme zaznamenali z aplikácie, sa dostanú do konca? Rozhodli sme sa vytvoriť metriky. rsyslog má svoj vlastný modul zberu štatistík, ktorý obsahuje nejaké počítadlá. Môže vám napríklad ukázať veľkosť frontu, alebo koľko správ prišlo v takej a takej akcii. Už si z nich môžete niečo vziať. Navyše má vlastné počítadlá, ktoré sa dajú konfigurovať a ukáže vám napríklad počet správ, ktoré niektoré API zaznamenalo. Ďalej som napísal rsyslog_exporter v Pythone a všetko sme to poslali do Prometheus a vytvorili grafy. Naozaj sme chceli metriky Graylog, ale ešte sme nemali čas ich nastaviť.
Aké boli problémy? Problémy nastali, keď sme (NÁRAZU!) zistili, že naše Live API píšu 50 12 správ za sekundu. Toto je len Live API bez stagingu. A Graylog nám zobrazuje iba XNUMX tisíc správ za sekundu. A vyvstala rozumná otázka: kde sú pozostatky? Z čoho sme usúdili, že Graylog sa jednoducho nedokáže vyrovnať. Pozreli sme sa a skutočne, Graylog a Elasticsearch tento tok nezvládli.
Ďalej ďalšie objavy, ktoré sme cestou urobili.
Zápisy do zásuvky sú zablokované. Ako sa to stalo? Keď som na doručovanie používal rsyslog, v určitom bode sa kanál medzi dátovými centrami pokazil. Dodávka sa zastavila na jednom mieste, dodávka sa zastavila na inom mieste. Toto všetko sa dostalo do stroja s API, ktoré zapisuje do soketu rsyslog. Bol tam rad. Potom sa zaplnil front na zápis do unixového socketu, ktorý je štandardne 128 paketov. A ďalší zápis() v aplikácii je zablokovaný. Keď sme sa pozerali na knižnicu, ktorú používame v Go aplikáciách, bolo tam napísané, že zápis do socketu prebieha v neblokovacom režime. Boli sme si istí, že nič nie je blokované. Pretože čítame kto o tom písal. Ale je tu moment. Okolo tohto hovoru bola tiež nekonečná slučka, v ktorej prebiehal neustály pokus o zatlačenie správy do zásuvky. Nevšímali sme si ho. Musel som prepísať knižnicu. Odvtedy sa to niekoľkokrát zmenilo, no teraz sme sa zbavili blokovania vo všetkých podsystémoch. Preto môžete zastaviť rsyslog a nič sa nezrúti.
Je potrebné sledovať veľkosť frontov, čo pomáha vyhnúť sa šliapaniu na tento hrable. Po prvé, môžeme sledovať, kedy začneme strácať správy. Po druhé, môžeme sledovať, že máme problémy s doručením.
A ďalší nepríjemný moment - 10-násobné zosilnenie v mikroservisnej architektúre je veľmi jednoduché. Nemáme veľa prichádzajúcich požiadaviek, ale kvôli grafu, po ktorom tieto správy putujú ďalej, kvôli protokolom prístupu v skutočnosti zvyšujeme zaťaženie denníka asi desaťkrát. Bohužiaľ som nemal čas vypočítať presné čísla, ale mikroslužby sú také, aké sú. Toto treba mať na pamäti. Ukazuje sa, že momentálne je v Lazade najviac zaťažený subsystém zberu logov.
Ako vyriešiť problém elasticsearch? Ak potrebujete rýchlo získať protokoly na jednom mieste, aby ste nebehali ku všetkým strojom a zbierali ich tam, použite úložisko súborov. Toto zaručene funguje. Dá sa to urobiť z akéhokoľvek servera. Stačí tam prilepiť disky a nainštalovať syslog. Potom budete mať zaručene všetky záznamy na jednom mieste. Potom môžete pomaly nakonfigurovať elasticsearch, graylog a niečo iné. Ale už budete mať všetky protokoly a navyše ich môžete ukladať, pokiaľ je dostatok diskových polí.
V čase mojej správy začala schéma vyzerať takto. Prakticky sme prestali zapisovať do súboru. Teraz s najväčšou pravdepodobnosťou vypneme zvyšok. Na lokálnych počítačoch s rozhraním API prestaneme zapisovať do súborov. Po prvé, je tu ukladanie súborov, ktoré funguje veľmi dobre. Po druhé, týmto strojom neustále dochádza miesto, je potrebné ho neustále monitorovať.
Táto časť s Logstashom a Graylogom sa naozaj rozbehne. Preto sa ho musíme zbaviť. Musíte si vybrať jednu vec.
Rozhodli sme sa vyhodiť Logstasha a Kibanu. Pretože máme bezpečnostné oddelenie. Aké spojenie? Súvislosť je v tom, že Kibana bez X-Packu a bez Shieldu neumožňuje rozlišovať prístupové práva k protokolom. Preto sme vzali Grayloga. Má to všetko. Nepáči sa mi to, ale funguje to. Kúpili sme nový hardvér, nainštalovali sme tam čerstvý Graylog a preniesli všetky protokoly so striktnými formátmi do samostatného Graylogu. Problém s rôznymi typmi identických polí sme riešili organizačne.
Čo presne obsahuje nový Graylog. Všetko sme práve zapísali do dockeru. Vzali sme veľa serverov, spustili sme tri inštancie Kafka, 7 serverov Graylog verzie 2.3 (pretože sme chceli Elasticsearch verziu 5). Toto všetko bolo pozbierané pri nájazdoch z HDD. Videli sme rýchlosť indexovania až 100 tisíc správ za sekundu. Videli sme údaj, že 140 terabajtov dát za týždeň.
A opäť hrable! Čakajú nás dva výpredaje. Posunuli sme sa za hranicu 6 miliónov správ. Graylog nemá čas žuť. Nejako to musíme znova prežiť.
Takto sme prežili. Pridali sme niekoľko ďalších serverov a SSD. Momentálne takto žijeme. Teraz už prežúvame 160 XNUMX správ za sekundu. Zatiaľ sme nedosiahli limit, takže nie je jasné, koľko z toho môžeme v skutočnosti vyťažiť.
Toto sú naše plány do budúcnosti. Z nich je najdôležitejšia asi vysoká dostupnosť. Zatiaľ ho nemáme. Viacero áut je nakonfigurovaných rovnako, no zatiaľ všetko ide cez jedno auto. Nastavenie núdzového prepnutia medzi nimi chvíľu trvá.
Zbierajte metriky z Graylogu.
Stanovte si limit rýchlosti, aby sme mali jedno bláznivé API, ktoré nezabíja našu šírku pásma a všetko ostatné.
A nakoniec, podpíšte nejakú SLA s vývojármi, aby sme mohli toľko slúžiť. Ak napíšeš viac, tak sa ospravedlňujem.
A napísať dokumentáciu.
Stručne povedané, výsledky všetkého, čo sme zažili. Po prvé, normy. Po druhé, syslog je koláč. Po tretie, rsyslog funguje presne tak, ako je napísané na snímke. A prejdime k otázkam.
otázky.
otázka: Prečo ste sa rozhodli neprijať... (doba súboru?)
odpoveď: Potrebujeme zapisovať do súboru. Naozaj som nechcel. Keď vaše API zapisuje tisíce správ za sekundu, aj keď ho otočíte raz za hodinu, stále to nie je možné. Môžete písať do potrubia. Na čo sa ma vývojári pýtali: „Čo sa stane, ak proces, do ktorého píšeme, zlyhá? Len som nenašiel, čo im mám odpovedať, a povedal som: "No dobre, nerobme to."
otázka: Prečo jednoducho nezapíšete protokoly do HDFS?
odpoveď: Toto je ďalšia fáza. Uvažovali sme o tom hneď na začiatku, no keďže momentálne na to nie sú prostriedky, visí to v našom dlhodobom riešení.
otázka: Vhodnejší by bol stĺpcový formát.
odpoveď: Rozumiem. Sme za to oboma rukami.
otázka: Píšete na rsyslog. Tam môžete použiť TCP aj UDP. Ale ak UDP, ako potom garantujete doručenie?
odpoveď: Existujú dva body. Najprv všetkým hneď hovorím, že negarantujeme doručenie guľatiny. Pretože keď vývojári prídu a povedia: „Začnime tam písať finančné údaje a vy nám ich niekde umiestnite, keby sa niečo stalo,“ odpovieme im: „Skvelé! Začnime blokovať zápis do soketu a urobte to v transakciách, aby ste ho zaručene umiestnili na soket a ubezpečili sa, že ho dostaneme z druhej strany.“ A v tejto chvíli to už každý nepotrebuje. Ak to nie je potrebné, aké otázky by sme si mali položiť? Ak nechcete zaručiť zápis do zásuvky, prečo potom musíme garantovať doručenie? Robíme maximum. Naozaj sa snažíme dodať čo najviac a najlepším možným spôsobom, ale neposkytujeme 100% záruku. Preto tam netreba zapisovať finančné údaje. Na to existujú databázy s transakciami.
otázka: Keď API vygeneruje nejakú správu v denníku a prenesie kontrolu na mikroslužby, stretli ste sa s problémom, že správy z rôznych mikroslužieb prichádzajú v nesprávnom poradí? To spôsobuje zmätok.
odpoveď: Je normálne, že prichádzajú v rôznom poradí. Na to sa treba pripraviť. Pretože akákoľvek sieťová dodávka nezaručuje objednávku, alebo na to musíte minúť špeciálne zdroje. Ak vezmeme úložiská súborov, potom každé API ukladá protokoly do vlastného súboru. Alebo skôr, tam ich rsyslog triedi do adresárov. Každé API má svoje vlastné protokoly, kam sa môžete pozrieť a potom ich môžete porovnať pomocou časovej pečiatky v tomto protokole. Ak sa pôjdu pozrieť do Graylogu, potom sú tam zoradené podľa časovej pečiatky. Tam bude všetko v poriadku.
otázka: Časová pečiatka sa môže líšiť o milisekundy.
odpoveď: Časovú pečiatku generuje samotné API. To je vlastne celá podstata. Máme NTP. API generuje časovú pečiatku v samotnej správe. rsyslog to nepridáva.
otázka: Interakcia medzi dátovými centrami nie je veľmi jasná. V rámci dátového centra je jasné, akým spôsobom boli protokoly zbierané a spracovávané. Ako prebieha interakcia medzi dátovými centrami? Alebo si každé dátové centrum žije vlastným životom?
odpoveď: Takmer. U nás sa každá krajina nachádza v jednom dátovom centre. Momentálne nemáme rozložené tak, aby sa jedna krajina nachádzala v rôznych dátových centrách. Preto ich nie je potrebné kombinovať. Každé centrum má vnútri Log Relay. Toto je server Rsyslog. Vlastne dva riadiace stroje. Majú rovnaký postoj. Zatiaľ však premávka prechádza len cez jednu z nich. Zhromažďuje všetky protokoly. Pre každý prípad má diskový rad. Stiahne protokoly a odošle ich do centrálneho dátového centra (Singapur), kde sa potom odošlú do Graylogu. A každé dátové centrum má svoje vlastné úložisko súborov. V prípade straty spojenia tam máme všetky záznamy. Zostanú tam. Tam budú uložené.
otázka: V prípade abnormálnych situácií dostávate protokoly odtiaľ?
odpoveď: Môžete ísť tam (do úložiska súborov) a pozrieť sa.
otázka: Ako sledujete, či nestrácate logy?
odpoveď: V skutočnosti ich strácame a sledujeme to. Monitoring bol spustený pred mesiacom. Knižnica, ktorú používajú rozhrania Go API, má metriky. Vie spočítať, koľkokrát sa jej nepodarilo zapísať do zásuvky. V súčasnosti tam funguje šikovná heuristika. Je tam nárazník. Snaží sa z neho napísať správu do zásuvky. Ak buffer pretečie, začne ich zahadzovať. A počíta, koľko ich zhodil. Ak tam začnú pretekať merače, budeme o tom vedieť. Teraz prichádzajú aj na prometheus a grafy si môžete pozrieť v Grafane. Môžete si nastaviť upozornenia. Zatiaľ ale nie je jasné, komu ich poslať.
otázka: V elasticsearch ukladáte protokoly s redundanciou. Koľko replík máte?
odpoveď: Jedna čiara.
otázka: Je to len jeden riadok?
odpoveď: Toto je predloha a replika. Údaje sú uložené v dvoch kópiách.
otázka: Upravili ste nejako veľkosť vyrovnávacej pamäte rsyslog?
odpoveď: Datagramy zapisujeme do vlastného unixového socketu. To nám okamžite ukladá limit 128 kilobajtov. Viac k tomu napísať nemôžeme. Zapísali sme to do normy. Tí, ktorí sa chcú dostať do úložiska, píšu 128 kilobajtov. Knižnice sú navyše odrezané a je umiestnený príznak, že správa je odrezaná. Náš štandard pre samotnú správu má špeciálne pole, ktoré ukazuje, či bola počas nahrávania prerušená alebo nie. Máme teda možnosť sledovať aj tento moment.
Otázka: Píšete zlomený JSON?
odpoveď: Poškodený JSON bude vyradený buď počas prenosu, pretože paket je príliš veľký. Alebo sa Graylog zahodí, pretože nedokáže analyzovať JSON. Existujú však nuansy, ktoré je potrebné opraviť, a väčšinou sú viazané na rsyslog. Vyplnil som tam už niekoľko záležitostí, na ktorých treba ešte popracovať.
Otázka: Prečo Kafka? Skúšali ste RabbitMQ? Zlyhá Graylog pri takomto zaťažení?
odpoveď: S Graylogom nám to nefunguje. A Graylog sa nám formuje. Je naozaj problematický. On je zvláštna vec. A v skutočnosti to nie je potrebné. Najradšej by som napísal z rsyslog priamo do elasticsearch a potom sa pozrel na Kibana. Ale musíme vyriešiť problém s ochrankou. Toto je možná možnosť pre náš vývoj, keď vyhodíme Graylog a použijeme Kibana. Nemá zmysel používať Logstash. Pretože to isté môžem urobiť s rsyslog. A má modul na zápis do elasticsearch. Snažíme sa nejako žiť s Graylogom. Dokonca sme to trochu vyladili. Stále je však čo zlepšovať.
O Kafkovi. Takto sa to historicky stalo. Keď som prišiel, už tam bol a už sa doň zapisovali protokoly. Jednoducho sme zdvihli náš klaster a presunuli doň polená. Sme jeho manažment, vieme, ako sa cíti. Čo sa týka RabbitMQ... s RabbitMQ nám to nevychádza. A RabbitMQ sa nám formuje. Máme ho vo výrobe a boli s ním problémy. Teraz pred predajom by ho očarili a on by začal normálne pracovať. Predtým som však nebol pripravený vydať ho do výroby. Je tu ešte jeden bod. Graylog dokáže čítať verziu AMQP 0.9 a rsyslog môže zapisovať verziu AMQP 1.0. A v strede neexistuje jediné riešenie, ktoré dokáže oboje. Buď je to jedno alebo druhé. Preto momentálne iba Kafka. Ale má aj svoje vlastné nuansy. Pretože omkafka verzie rsyslog, ktorú používame, môže stratiť celú vyrovnávaciu pamäť správ, ktorú vybrala z rsyslogu. Zatiaľ sme sa s tým zmierili.
Otázka: Používate Kafku, pretože ste ho už mali? Už sa nepoužíva na žiadny účel?
odpoveď: Kafka, ktorý bol, používa tím Data Science. Ide o úplne samostatný projekt, o ktorom, žiaľ, nemôžem nič povedať. Neviem. Prevádzkoval ho tím Data Science. Keď boli protokoly vytvorené, rozhodli sme sa ho použiť, aby sme si neinštalovali vlastné. Teraz sme aktualizovali Graylog a stratili sme kompatibilitu, pretože má starú verziu Kafka. Museli sme začať svoj vlastný. Zároveň sme sa zbavili týchto štyroch tém pre každé API. Urobili sme jednu širokú tému pre všetkých naživo, jednu širokú tému pre všetky inscenácie a dali sme tam všetko. Graylog to všetko paralelne zoškrabuje.
Otázka: Prečo potrebujeme tento šamanizmus so zásuvkami? Skúsili ste použiť ovládač denníka syslog pre kontajnery?
odpoveď: V čase, keď sme túto otázku položili, bol náš vzťah s dockerom napätý. Bol to docker 1.0 alebo 0.9. Samotný Docker bol zvláštny. Po druhé, ak do nej strčíš aj logy... Mám neoverené podozrenie, že všetky logy prechádza cez seba, cez démona dockera. Ak sa jedno API zblázni, potom ostatné API uviazli v tom, že nemôžu posielať stdout a stderr. Neviem, kam to povedie. Mám podozrenie na úrovni pocitu, že na tomto mieste nie je potrebné použiť ovládač syslog Docker. Naše oddelenie funkčného testovania má vlastný klaster Graylog s protokolmi. Používajú ovládače protokolu Docker a zdá sa, že je tam všetko v poriadku. Ale hneď píšu GELF Graylogovi. V čase, keď sme s tým všetkým začínali, sme len potrebovali, aby to fungovalo. Možno neskôr, keď niekto príde a povie, že to funguje dobre už sto rokov, skúsime to.
Otázka: Doručovanie medzi dátovými centrami vykonávate pomocou rsyslog. Prečo nie Kafka?
odpoveď: V skutočnosti robíme oboje. Z dvoch dôvodov. Ak je kanál úplne mŕtvy, všetky naše záznamy, dokonca ani v komprimovanej forme, cez neho neprelezú. A Kafka vám umožňuje jednoducho ich stratiť. Takto sa zbavíme zaseknutia týchto polená. V tomto prípade používame priamo Kafku. Ak máme dobrý kanál a chceme ho uvoľniť, použijeme ich rsyslog. V skutočnosti ho však môžete nakonfigurovať tak, aby sám vypustil to, čo sa cez neho nezmestilo. Momentálne niekde používame akurát doručovanie rsyslog priamo a niekde Kafku.
Zdroj: hab.com