Protokoly jsou důležitou součástí systému a umožňují vám pochopit, že funguje (nebo nefunguje) podle očekávání. V podmínkách architektury mikroservisů se práce s logy stává samostatnou disciplínou Speciální olympiády. Je potřeba řešit spoustu problémů:
- jak zapisovat protokoly z aplikace;
- kam zapisovat protokoly;
- jak dodat protokoly ke skladování a zpracování;
- jak zpracovávat a ukládat protokoly.
Použití v současné době populárních technologií kontejnerizace přidává písek na hrábě v oblasti možností řešení problémů.
Právě o tom je přepis zprávy Jurije Bushmeleva „Mapa hrábě v oblasti sběru a doručování klád“
Koho to zajímá, prosím pod kočku.
Jmenuji se Yuri Bushmelev. Pracuji pro Lazadu. Dnes budu mluvit o tom, jak jsme naše logy vyráběli, jak jsme je sbírali a co tam píšeme.
odkud jsme? Kdo jsme? Lazada je online prodejce číslo 1 v šesti zemích jihovýchodní Asie. Všechny tyto země jsou distribuovány mezi datová centra. Datacentra jsou nyní celkem 4. Proč je to důležité? Protože některá rozhodnutí byla způsobena tím, že mezi centry je velmi slabé spojení. Máme architekturu mikroslužeb. S překvapením jsem zjistil, že už máme 80 mikroslužeb. Když jsem úlohu s logy začínal, bylo jich jen 20. Navíc je tu poměrně velký kus dědictví PHP, se kterým také musím žít a snášet ho. To vše nám v tuto chvíli generuje více než 6 milionů zpráv za minutu pro systém jako celek. Dále ukážu, jak se s tím snažíme žít a proč tomu tak je.
S těmito 6 miliony zpráv musíte nějak žít. Co s nimi máme dělat? Potřebných 6 milionů zpráv:
- odeslat z aplikace
- přijmout k doručení
- dodat k analýze a uložení.
- analyzovat
- nějak uložit.
Když tam byly tři miliony zpráv, vypadal jsem asi stejně. Protože jsme začali s nějakými haléři. Je jasné, že se tam píšou aplikační logy. Například se nemohl připojit k databázi, mohl se připojit k databázi, ale nemohl něco přečíst. Ale kromě toho každá z našich mikroslužeb také zapisuje přístupový protokol. Každý požadavek, který dorazí do mikroslužby, spadá do protokolu. Proč to děláme? Vývojáři chtějí mít možnost sledovat. Každý přístupový log obsahuje pole traceid, podle kterého pak speciální rozhraní rozvine celý řetězec a krásně zobrazí trasování. Trasa ukazuje, jak požadavek probíhal, a to našim vývojářům pomáhá rychleji se vypořádat s jakýmkoli neznámým odpadem.
Jak s tím žít? Nyní stručně popíšu pole možností - jak se tento problém obecně řeší. Jak vyřešit problém shromažďování, přenášení a ukládání protokolů.
Jak psát z aplikace? Je jasné, že existují různé způsoby. Zejména existují osvědčené postupy, jak nám módní soudruzi říkají. Existují dva typy staré školy, jak říkali dědové. Jsou i jiné způsoby.
Se sběrem kulatiny je situace přibližně stejná. Možností, jak tuto konkrétní část vyřešit, není tolik. Je jich víc, ale ještě ne tolik.
Ale s dodáním a následnou analýzou začne počet variací explodovat. Nebudu nyní popisovat jednotlivé možnosti. Myslím, že hlavní možnosti jsou všem, koho téma zaujalo, dobře známé.
Ukážu vám, jak jsme to dělali na Lazadě a jak to všechno začalo.
Před rokem jsem přišel do Lazady a byl jsem poslán do projektu log. Bylo to tam takhle. Protokol z aplikace byl zapsán do stdout a stderr. Všechno bylo děláno módním způsobem. Pak to ale vývojáři vyhodili ze standardních streamů a pak na to specialisté na infrastrukturu nějak přijdou. Mezi specialisty na infrastrukturu a vývojáři jsou také uvolňovači, kteří řekli: "uh ... no, zabalíme je do souboru s shellem, a je to." A protože je to všechno v kontejneru, zabalili to přímo do kontejneru, zmapovali adresář uvnitř a dali to tam. Myslím, že je všem jasné, co se stalo.
Podívejme se trochu dále. Jak jsme doručili tyto protokoly. Někdo si vybral td-agent, který je ve skutečnosti plynný, ale ne zcela plynný. Stále nechápu vztah těchto dvou projektů, ale zdá se, že jsou o tom samém. A tento plynulý, napsaný v Ruby, četl soubory protokolu, analyzoval je do JSON pomocí některých regulárních výrazů. Pak byli posláni ke Kafkovi. Navíc jsme v Kafce měli 4 samostatná témata pro každé API. Proč 4? Protože tam je živě, je tu inscenace, a protože je stdout a stderr. Vyrábí je vývojáři a pracovníci infrastruktury je musí vytvářet v Kafkovi. Kafku navíc ovládalo jiné oddělení. Proto bylo potřeba vytvořit tiket tak, aby tam pro každé api vytvořili 4 témata. Všichni na to zapomněli. Obecně to byl odpad a odpad.
Co jsme s tím udělali dál? Poslali jsme to kafkovi. Dále od Kafky letěla polovina klád do Logstashe. Druhá polovina protokolů byla sdílena. Někteří letěli k jednomu Graylogovi, někteří k jinému Graylogovi. Výsledkem bylo, že to vše letělo do jednoho shluku Elasticsearch. To znamená, že všechen ten nepořádek tam nakonec spadl. To nemusíte dělat!
Takhle to vypadá při pohledu shora. To nemusíte dělat! Zde jsou problémové oblasti ihned označeny čísly. Je jich vlastně víc, ale 6 je opravdu problematických, se kterými je potřeba něco dělat. Nyní o nich řeknu samostatně.
Zde (1,2,3) zapisujeme soubory a podle toho jsou zde tři hrábě najednou.
První (1) je, že je musíme někam napsat. Není vždy žádoucí dát API možnost zapisovat přímo do souboru. Je žádoucí, aby API bylo izolováno v kontejneru, a ještě lépe, aby bylo pouze pro čtení. Jsem systémový administrátor, takže mám na tyto věci trochu alternativní pohled.
Druhým bodem (2,3) je, že na API přichází mnoho požadavků. API zapisuje velké množství dat do souboru. Soubory rostou. Musíme je otočit. Protože jinak tam žádné disky neuložíte. Jejich otáčení je špatné, protože jsou přesměrovány přes shell do adresáře. Nemůžeme to nijak otočit. Aplikaci nemůžete říct, aby znovu otevřela úchyty. Protože se na vás vývojáři budou dívat jako na blázna: „Jaké deskriptory? Obecně píšeme do stdout. Rámce udělaly copytruncate do logrotate, které pouze zkopíruje soubor a složí originál. V souladu s tím mezi těmito procesy kopírování obvykle končí místo na disku.
(4) Měli jsme různé formáty v různých API. Byly mírně odlišné, ale regexp musel být napsán jinak. Vzhledem k tomu, že to všechno řídil Puppet, byla tam velká skupina tříd s vlastními šváby. Navíc, td-agent většinu času mohl požírat paměť, být hloupý, mohl jen předstírat, že pracuje a nic nedělat. Navenek nebylo možné pochopit, že nic nedělá. V lepším případě spadne a někdo ho později sebere. Přesněji řečeno, přiletí upozornění a někdo to půjde zvedat rukama.
(6) A nejvíce odpadu a odpadu - to byl elasticsearch. Protože to byla stará verze. Protože jsme v té době neměli oddané mistry. Měli jsme heterogenní klády, jejichž pole se mohla překrývat. Různé protokoly různých aplikací by mohly být zapsány se stejnými názvy polí, ale zároveň uvnitř mohou být různá data. To znamená, že jeden protokol přichází s celým číslem v poli, například úroveň. Další protokol přichází s řetězcem v poli úrovně. Při absenci statického mapování se ukazuje taková úžasná věc. Pokud po otočení indexu nejprve do elasticsearch dorazila zpráva s řetězcem, žijeme normálně. A pokud první dorazila s Integer, pak všechny následující zprávy, které dorazily s Stringem, jsou jednoduše zahozeny. Protože typ pole se neshoduje.
Začali jsme si klást tyto otázky. Rozhodli jsme se, že nebudeme hledat viníky.
Ale je potřeba něco udělat! Je zřejmé, že musíme stanovit normy. Nějaké standardy jsme už měli. Některé jsme přinesli o něco později. Naštěstí již v té době byl schválen jednotný formát protokolu pro všechna API. Je zapsán přímo do standardů interakce služeb. Proto by ti, kteří chtějí dostávat protokoly, měli je zapisovat v tomto formátu. Pokud někdo nepíše logy v tomto formátu, tak za nic neručíme.
Dále bych chtěl mít jednotný standard pro způsoby zaznamenávání, doručování a shromažďování protokolů. Vlastně, kam je napsat a jak je doručit. Ideální situace je, když projekty využívají stejnou knihovnu. Pro Go existuje samostatná knihovna protokolování, pro PHP existuje samostatná knihovna. Každý, koho máme, by je měl používat každý. V tuto chvíli bych řekl, že se nám to daří tak z 80 procent. Někteří ale nadále jedí kaktusy.
A tam (na snímku) se „SLA pro doručení protokolu“ sotva začíná objevovat. Ještě to tam není, ale pracujeme na tom. Protože je velmi pohodlné, když infra říká, že když napíšete v takovém a takovém formátu na takové a takové místo a ne více než N zpráv za sekundu, tak to tam s největší pravděpodobností doručíme. Odstraňuje spoustu bolestí hlavy. Pokud existuje SLA, pak je to skvělé!
Jak jsme začali problém řešit? Hlavní rake byl s td-agent. Nebylo jasné, kam jdou naše záznamy. Jsou doručeny? jdou? Kde vůbec jsou? Proto bylo rozhodnuto nahradit td-agent první položkou. Možnosti, čím to nahradit, jsem stručně nastínil zde.
Plynule. Jednak jsem na něj narazil v předchozím zaměstnání a také tam pravidelně padal. Za druhé, je to totéž, pouze z profilu.
filebeat. Jak to pro nás bylo dobré? Skutečnost, že je v Go a my máme v Go velké zkušenosti. V souladu s tím, kdyby něco, mohli bychom to nějak přidat k sobě. Proto jsme to nevzali. Aby ani nebylo pokušení začít to přepisovat na sebe.
Zřejmým řešením pro sysadmina jsou nejrůznější syslogy v tomto množství (syslog-ng/rsyslog/nxlog).
Nebo napište něco vlastního, ale my jsme to zahodili, stejně jako filebeat. Pokud něco napíšete, pak je lepší napsat něco užitečného pro podnikání. Pro dodání protokolů je lepší vzít něco hotového.
Volba tedy ve skutečnosti padla na volbu mezi syslog-ng a rsyslog. Přiklonil jsem se k rsyslog jednoduše proto, že jsme již měli třídy pro rsyslog v Puppet a nenašel jsem mezi nimi zjevný rozdíl. Co je syslog, co je syslog. Ano, některá dokumentace je horší, některá lepší. Zná to tímto způsobem a dělá to jinak.
A něco málo o rsyslogu. Za prvé, je to skvělé, protože má spoustu modulů. Má pro člověka čitelný RainerScript (moderní konfigurační jazyk). Úžasným bonusem je, že jsme mohli emulovat chování td-agent s jeho standardními nástroji a pro aplikace se nic nezměnilo. To znamená, že změníme td-agent na rsyslog a zatím se nedotýkáme všeho ostatního. A okamžitě dostaneme funkční dodávku. Dále, mmnormalize je skvělá věc na rsyslog. Umožňuje vám analyzovat protokoly, ale ne pomocí Grok a regexp. Vytváří abstraktní syntaktický strom. Analyzuje protokoly v podstatě stejným způsobem, jakým kompilátor analyzuje zdrojový kód. To vám umožňuje pracovat velmi rychle, spotřebovávat málo CPU a obecně je to prostě skvělá věc. Existuje hromada dalších bonusů. Nebudu se jimi zabývat.
rsyslog má mnohem více nevýhod. Jsou přibližně stejné jako bonusy. Hlavní problémy jsou v tom, že to musíte umět vařit a musíte vybrat verzi.
Rozhodli jsme se, že budeme zapisovat protokoly v unixovém socketu. A ne v /dev/log, protože tam máme nepořádek systémových protokolů, v tomto potrubí je journald. Pojďme tedy napsat do vlastní zásuvky. Připojíme jej k samostatné sadě pravidel. Do ničeho nezasahujme. Vše bude transparentní a srozumitelné. Takže jsme to vlastně udělali. Adresář s těmito sokety je standardizován a předáván všem kontejnerům. Kontejnery mohou vidět soket, který potřebují, otevřít jej a zapisovat do něj.
Proč ne soubor? Protože všichni četli , který se pokusil přeposlat soubor do dockeru a zjistil, že po restartování rsyslog se deskriptor souboru změní a docker tento soubor ztratí. Nechává otevřené něco jiného, ale ne stejnou zásuvku, kam píšou. Rozhodli jsme se, že tento problém obejdeme a zároveň obejdeme problém s blokováním.
Rsyslog provádí akce uvedené na snímku a odesílá protokoly buď relé nebo Kafkovi. Kafka jde starým způsobem. Rayleigh - Zkoušel jsem použít čistý rsyslog k doručení protokolů. Bez fronty zpráv, pomocí standardních nástrojů rsyslog. V podstatě to funguje.
Existují však nuance, jak je později nacpat do této části (Logstash/Graylog/ES). Tato část (rsyslog-rsyslog) se používá mezi datovými centry. Zde je komprimovaný odkaz tcp, který vám umožňuje ušetřit šířku pásma a podle toho nějak zvýšit pravděpodobnost, že obdržíme nějaké protokoly z jiného datového centra, když je kanál plný. Protože máme Indonésii, kde je všechno špatně. V tom spočívá neustálý problém.
Přemýšleli jsme o tom, jak vlastně sledujeme, s jakou pravděpodobností k tomu dosáhnou logy, které jsme z aplikace zaznamenali? Rozhodli jsme se začít s metrikami. Rsyslog má svůj vlastní modul pro sběr statistik, který má jakési čítače. Může vám například ukázat velikost fronty nebo kolik zpráv přišlo pro takovou a takovou akci. Už si z nich můžete něco vzít. Navíc má vlastní čítače, které si můžete nakonfigurovat, a ukáže vám například počet zpráv, které nějaké API zaznamenalo. Dále jsem v Pythonu napsal rsyslog_exporter a vše jsme poslali do Promethea a vykreslili. Opravdu jsme chtěli metriky Graylog, ale zatím jsme neměli čas je nastavit.
jaké jsou problémy? Problém nastal s tím, že jsme (NÁHLE!) zjistili, že naše Live API zapisují 50k zpráv za sekundu. Toto je pouze Live API bez stagingu. A Graylog nám ukazuje pouze 12 tisíc zpráv za sekundu. A vyvstala rozumná otázka, kde jsou ty zbytky? Z čehož jsme usoudili, že Graylog si prostě neporadí. Dívali jsme se, a skutečně, Graylog s Elasticsearch tento tok nezvládl.
Dále další objevy, které jsme cestou učinili.
Zápisy do soketu jsou blokovány. Jak se to stalo? Když jsem pro doručení použil rsyslog, v určitém okamžiku jsme přerušili kanál mezi datovými centry. Dodávka vstala na jednom místě, dodávka vstala na jiném místě. To vše má na svědomí stroj s API, která zapisují do soketu rsyslog. Byla tam fronta. Poté se zaplnila fronta pro zápis do unixového socketu, která je standardně 128 paketů. A další write() v aplikačních blocích. Když jsme se dívali na knihovnu, kterou používáme v Go aplikacích, bylo tam napsáno, že zápis do socketu probíhá v neblokovacím režimu. Byli jsme si jisti, že nic není blokováno. Protože jsme četli kdo o tom psal. Ale je tu okamžik. Kolem tohoto hovoru byla také nekonečná smyčka, ve které docházelo k neustálým pokusům o zatlačení zprávy do zásuvky. Nevšimli jsme si ho. Musel jsem přepsat knihovnu. Od té doby se to několikrát změnilo, ale nyní jsme se zbavili zámků ve všech subsystémech. Proto můžete zastavit rsyslog a nic nespadne.
Je potřeba hlídat velikost front, což napomáhá tomu, aby se na toto hrábě nešlapalo. Za prvé, můžeme sledovat, kdy začneme ztrácet zprávy. Za druhé můžeme sledovat, že máme v podstatě problémy s doručením.
A další nepříjemný moment - 10násobné zesílení v mikroservisní architektuře je velmi snadné. Nemáme tolik příchozích požadavků, ale kvůli grafu, po kterém tyto zprávy běží dále, kvůli protokolům přístupu ve skutečnosti zvyšujeme zatížení protokolů asi desetkrát. Přesná čísla jsem bohužel nestihl spočítat, ale mikroslužby jsou takové, jaké jsou. To je třeba mít na paměti. Ukazuje se, že v současnosti je v Lazadě nejvíce zatížen subsystém sběru logů.
Jak vyřešit problém elasticsearch? Pokud potřebujete rychle získat protokoly na jednom místě, abyste neběhali přes všechny stroje a nesbírali je tam, použijte úložiště souborů. To zaručeně funguje. Provádí se z libovolného serveru. Stačí tam nalepit disky a dát syslog. Poté budete mít zaručeně všechny logy na jednom místě. Pak bude možné pomalu konfigurovat elasticsearch, graylog, nebo něco jiného. Všechny logy už ale budete mít a navíc je můžete ukládat, pokud je dostatek diskových polí.
V době mé zprávy začalo schéma vypadat takto. Prakticky jsme přestali zapisovat do souboru. Nyní s největší pravděpodobností vypneme zbytky. Na lokálních počítačích s rozhraním API přestaneme zapisovat do souborů. Za prvé je tu úložiště souborů, které funguje velmi dobře. Za druhé, těmto strojům neustále dochází místo, musíte to neustále sledovat.
Tenhle díl s Logstashem a Graylogem, to opravdu stoupá. Proto je potřeba se ho zbavit. Musíte si vybrat jednu.
Rozhodli jsme se vysadit Logstashe a Kibanu. Protože máme bezpečnostní oddělení. jaká je souvislost? Souvisí to s tím, že Kibana bez X-Packu a bez Shieldu neumožňuje rozlišit přístupová práva k logům. Proto vzali Grayloga. Má to všechno. Nelíbí se mi to, ale funguje to. Koupili jsme nový hardware, nainstalovali tam čerstvý Graylog a přesunuli všechny protokoly s přísnými formáty do samostatného Graylogu. Problém s různými typy stejných oborů jsme vyřešili organizačně.
Co přesně je součástí nového Graylogu. Všechno jsme právě napsali do dockeru. Vzali jsme spoustu serverů, spustili tři instance Kafka, 7 serverů Graylog verze 2.3 (protože jsem chtěl Elasticsearch verze 5). To vše bylo vzneseno na nájezdech z HDD. Viděli jsme rychlost indexování až 100 tisíc zpráv za sekundu. Viděli jsme číslo, že 140 terabajtů dat za týden.
A zase hrábě! Čekají nás dva výprodeje. Posunuli jsme se nad 6 milionů příspěvků. My Graylog nemáme čas žvýkat. Nějak to zase musíte přežít.
Takhle jsme přežili. Přidáno několik dalších serverů a SSD. Momentálně žijeme takto. Nyní už žvýkáme 160 tisíc zpráv za sekundu. Zatím jsme nenarazili na limit, takže není jasné, jak moc se z toho můžeme reálně dostat.
To jsou naše plány do budoucna. Z nich je skutečně nejdůležitější pravděpodobně vysoká dostupnost. To ještě nemáme. Několik vozů je nastaveno stejně, ale zatím vše prochází jedním autem. Je nutné věnovat čas nastavení failover mezi nimi.
Sbírejte metriky z Graylogu.
Stanovte si limit rychlosti, abychom měli jedno šílené API, které nám nezabije šířku pásma a všechno ostatní.
A nakonec podepsat s vývojáři nějakou SLA, abychom mohli tolik sloužit. Jestli napíšeš víc, tak se omlouvám.
A napsat dokumentaci.
Stručně řečeno, výsledky všeho, co jsme zažili. Za prvé, normy. Za druhé, syslog je koláč. Za třetí, rsyslog funguje přesně tak, jak je napsáno na snímku. A pojďme k otázkám.
otázky.
otázka: Proč se rozhodli nepřijmout... (soubor?)
odpověď: Potřebujete zapisovat do souboru. Opravdu jsem nechtěl. Když vaše API zapisuje tisíce zpráv za sekundu, i když rotujete jednou za hodinu, stále to není možnost. Můžete psát do potrubí. Na což se mě vývojáři zeptali: „Co se stane, když proces, ve kterém píšeme, selže“? Jen jsem nenašel, co jim odpovědět, a řekl jsem: "No dobře, tak to nedělejme."
otázka: Proč prostě nezapíšete protokoly do HDFS?
odpověďA: Toto je další fáze. Uvažovali jsme o tom na samém začátku, ale protože v tuto chvíli nejsou žádné zdroje, abychom to řešili, visí to v našem dlouhodobém řešení.
otázka: Vhodnější by byl sloupcový formát.
odpověď: Chápu. Jsme „pro“ oběma rukama.
otázka: Píšete na rsyslog. Jsou tam k dispozici TCP i UDP. Ale pokud UDP, jak pak garantujete doručení?
odpověďA: Existují dva body. Nejprve všem okamžitě říkám, že negarantujeme dodání kulatiny. Protože když vývojáři přijdou a řeknou: „Začněme tam psát finanční data a vy nám je někam dáte, kdyby se něco stalo,“ odpovíme jim: „Skvělé! Začněme blokovat zápis do soketu a udělejme to v transakcích, abyste nám to zaručeně dali do soketu a ujistili se, že jsme to dostali z druhé strany. A v tuto chvíli se všichni okamžitě stanou nepotřebnými. A pokud ne, tak jaké máme otázky? Pokud nechcete garantovat zápis do socketu, tak proč bychom garantovali doručení? Vynakládáme maximální úsilí. Opravdu se snažíme dodat co nejvíce a nejlépe, ale nedáváme 100% záruku. Proto tam nemusíte psát finanční údaje. Na to existují transakční databáze.
otázka: Když API vygeneruje nějakou zprávu do protokolu a přenese řízení na mikroslužby, setkali jste se s problémem, že zprávy z různých mikroslužeb přicházejí ve špatném pořadí? Z tohoto důvodu vzniká zmatek.
odpověďA: Je normální, že přicházejí v jiném pořadí. Na to musíte být připraveni. Protože jakákoli síťová dodávka vám nezaručí pořádek, nebo na to musíte vynaložit zvláštní prostředky. Pokud vezmeme úložiště souborů, pak každé API ukládá protokoly do vlastního souboru. Spíše je tam rsyslog rozloží do adresářů. Každé API tam má své vlastní logy, kam se můžete jít podívat, a pak je můžete porovnat pomocí časového razítka v tomto logu. Pokud se půjdou podívat do Graylogu, tak tam budou seřazeny podle časového razítka. Všechno tam bude v pořádku.
otázka: Časové razítko se může lišit o milisekundy.
odpověď: Časové razítko generuje samotné API. To je ve skutečnosti celá podstata. Máme NTP. API generuje časové razítko již v samotné zprávě. Není přidán rsyslog.
otázka: Interakce mezi datovými centry není příliš jasná. V rámci datového centra je jasné, jak byly protokoly shromažďovány a zpracovávány. Jak probíhá interakce mezi datovými centry? Nebo si každé datové centrum žije svým vlastním životem?
odpověď: Téměř. Každou zemi máme umístěnou v jednom datovém centru. V současné době nemáme šíření, takže jedna země je umístěna v různých datových centrech. Není tedy potřeba je kombinovat. Uvnitř každého centra je Log Relay. Toto je server Rsyslog. Ve skutečnosti dva řídicí stroje. Jsou nastaveny stejně. Doprava ale zatím jen prochází jedním z nich. Zaznamenává vše dohromady. Pro každý případ má diskovou frontu. Stlačí protokoly a pošle je do centrálního datového centra (Singapur), kde jsou dále otráveni v Graylogu. A každé datové centrum má vlastní úložiště souborů. Pro případ, že bychom ztratili spojení, máme tam všechny logy. Zůstanou tam. Budou tam uloženy.
otázka: Dostáváte odtud protokoly během abnormálních situací?
odpověď: Můžete jít tam (do úložiště souborů) a podívat se.
otázka: Jak hlídáte, abyste neztráceli logy?
odpověď: Ve skutečnosti je ztrácíme a sledujeme to. Monitorování začalo před měsícem. Knihovna, kterou rozhraní Go API používají, má metriky. Dokáže spočítat, kolikrát se jí nepodařilo zapsat do zásuvky. V tuto chvíli existuje záludná heuristika. Je tam vyrovnávací paměť. Zkouší z něj napsat zprávu do socketu. Pokud vyrovnávací paměť přeteče, začne je zahazovat. A počítá, kolik jich upustil. Pokud tam začnou přetékat počítadla, budeme o tom vědět. Nyní přicházejí také na prometheus a grafy můžete vidět v Grafaně. Můžete si nastavit upozornění. Zatím ale není jasné, komu je poslat.
otázka: V elasticsearch ukládáte protokoly s redundancí. Kolik máte replik?
odpověď: Jedna replika.
otázka: Je to jen jeden řádek?
odpověď: Toto je předloha a replika. Data jsou uložena duplicitně.
otázka: Upravili jste nějak velikost vyrovnávací paměti rsyslog?
odpověď: Datagramy zapisujeme do vlastního unixového socketu. To nám okamžitě ukládá omezení na 128 kilobajtů. Víc do toho napsat nemůžeme. Zapsali jsme to do normy. Kdo se chce dostat do úložiště, napíše 128 kilobajtů. Knihovny navíc odříznou a dají příznak, že zpráva je odříznuta. Ve standardu samotné zprávy máme speciální pole, které ukazuje, zda byla při nahrávání odříznuta nebo ne. Máme tedy možnost tento okamžik sledovat.
Otázka: Píšete nefunkční JSON?
odpověď: Poškozený JSON bude zahozen buď během přenosu, protože paket je příliš velký. Nebo bude Graylog zrušen, protože nebude schopen analyzovat JSON. Ale jsou zde nuance, které je třeba opravit, a většinou jsou spojeny s rsyslog. Už jsem tam vyplnil pár záležitostí, na kterých je potřeba ještě zapracovat.
Otázka: Proč Kafka? Zkoušeli jste RabbitMQ? Graylog se při takovém zatížení nesčítá?
odpověď: S Graylogem to nejde. A Graylog se formuje. Je to pro něj opravdu problematické. On je tak trochu věc. A ve skutečnosti to není potřeba. Raději píšu z rsyslog přímo do elasticsearch a pak sleduju Kibanu. Ale musíme to vyřešit s ochrankou. Toto je možná varianta našeho vývoje, když vyhodíme Graylog a použijeme Kibana. Logstash nebude dávat smysl. Protože to samé mohu udělat s rsyslog. A má modul pro zápis do elasticsearch. S Graylogem se snažíme nějak žít. Dokonce jsme to trochu upravili. Stále je ale co zlepšovat.
O Kafkovi. Tak se to historicky stalo. Když jsem přijel, už tam byl a už se do něj zapisovaly protokoly. Jen jsme zvedli náš klastr a přesunuli do něj klády. Zvládáme ho, víme, jak se cítí. Co se týče RabbitMQ... máme potíže s RabbitMQ. A RabbitMQ se pro nás vyvíjí. Máme to ve výrobě a byly s tím problémy. Nyní, před prodejem, bude šamanizován a začne normálně pracovat. Předtím jsem ale nebyl připraven to pustit do výroby. Je tu ještě jedna věc. Graylog umí číst verzi AMQP 0.9 a rsyslog umí zapisovat verzi AMQP 1.0. A neexistuje jediné řešení, které by dokázalo obojí uprostřed. Existuje buď jedno, nebo druhé. Takže zatím jen Kafka. Ale existují také nuance. Protože omkafka verze rsyslog, kterou používáme, může ztratit celý buffer zpráv, který nabral z rsyslog. Dokud to vydržíme.
Otázka: Používáš Kafku, protože jsi ho měl? Nepoužívá se k jinému účelu?
odpověď: Kafka, kterou používal tým Data Science. Jedná se o zcela samostatný projekt, o kterém bohužel nemohu nic říci. Nevím. Řídil ji tým Data Science. Když začaly klády, rozhodli se to použít, aby nedávali své vlastní. Nyní jsme aktualizovali Graylog a ztratili jsme kompatibilitu, protože existuje stará verze Kafky. Museli jsme si vyrobit vlastní. Zároveň jsme se zbavili těchto čtyř témat pro každé API. Udělali jsme jeden široký top pro všechny naživo, jeden široký široký top pro všechny inscenace a tam prostě všechno točíme. Graylog to všechno vyhrabává paralelně.
Otázka: Proč potřebujeme tento šamanismus se zásuvkami? Zkusili jste použít ovladač protokolu syslog pro kontejnery.
odpověď: V době, kdy jsme tuto otázku položili, jsme měli s dockerem napjaté vztahy. Byl to docker 1.0 nebo 0.9. Samotný Docker byl zvláštní. Za druhé, když do toho strčíš i logy ... mám neověřené podezření, že to všechny logy prochází skrz sebe, přes démona dockeru. Pokud máme jedno API, které se zblázní, pak ostatní API narazí na skutečnost, že nemohou odesílat stdout a stderr. Nevím, kam to povede. Mám podezření na úrovni pocitu, že na tomto místě není nutné používat ovladač docker syslog. Naše oddělení funkčního testování má svůj vlastní Graylog cluster s logy. Používají ovladače protokolu docker a zdá se, že je tam vše v pořádku. Ale hned píšou GELF Graylogovi. Ve chvíli, kdy jsme s tím vším začínali, jsme potřebovali, aby to prostě fungovalo. Snad později, až někdo přijde a řekne, že to už sto let normálně funguje, zkusíme.
Otázka: Doručujete mezi datovými centry pomocí rsyslog. Proč ne na Kafku?
odpověď: Děláme to a takhle to opravdu je. Ze dvou důvodů. Pokud je kanál zcela mrtvý, pak všechny naše kmeny, dokonce ani ve stlačené podobě, skrz něj neprolezou. A kafka jim umožňuje jednoduše prohrát. Tímto způsobem se zbavíme slepování těchto polen. V tomto případě používáme přímo Kafku. Pokud máme dobrý kanál a chceme ho uvolnit, použijeme jejich rsyslog. Ale ve skutečnosti to můžete nastavit tak, aby to, co neprošlo, zahodilo. Momentálně jen někde používáme doručování rsyslog přímo, někde Kafka.
Zdroj: www.habr.com