Jak se agregace metrik liší od agregace logů? Nemohou logy obsahovat metriky? Nemohou systémy pro agregaci logů dělat stejné věci jako systémy pro agregaci metrik?“

Tyto otázky slýchám často. Také jsem se setkal s tím, že dodavatelé prezentují svůj systém agregace logů jako řešení všech problémů s pozorovatelností. Agregace protokolů je cenný nástroj, ale obvykle není dobrým nástrojem pro data časových řad.

Pár cenných vlastností systému agregace metrik časových řad je pravidelný interval a systém ukládání přizpůsobený speciálně pro data časových řad. Pravidelný interval umožňuje uživateli důsledně odvozovat skutečné matematické výsledky. Pokud systém agregace logů shromažďuje metriky v pravidelném intervalu, může potenciálně fungovat stejným způsobem. Systém ukládání však není optimalizován pro typy dotazů, které jsou typické pro systém agregace metrik. Zpracování těchto dotazů pomocí systémů ukládání, které se nacházejí v nástrojích pro agregaci logů, bude vyžadovat více prostředků a času.

Víme tedy, že systém agregace logů pravděpodobně není vhodný pro data časových řad, ale k čemu je dobrý? Systém agregace protokolů je skvělým místem pro shromažďování dat o událostech. Jedná se o nepravidelné činnosti, které jsou významné. Příkladem mohou být protokoly o přístupu k webové službě. Ty jsou významné, protože chceme vědět, co a kdy přistupuje k našim systémům. Dalším příkladem může být chybový stav aplikace – protože se nejedná o běžný provozní stav, může být cenný při řešení problémů.

Pár pravidel pro protokolování:

• DO obsahovat časovou značku
• DO formátovat v JSON
• NEZAPISOVAT bezvýznamné události
• DO zapisovat všechny chyby aplikace
• MOŽNÁ zapisovat varování
• DO zapnout protokolování
• DO zapisovat zprávy v lidském jazycečitelné formě
• NEZAPISUJTE do produkčního logu informační data
• NEZAPISUJTE do logu nic, co člověk nemůže přečíst nebo na co nemůže reagovat

Cloudové náklady

Při zkoumání nástrojů pro agregaci logů, může cloud vypadat jako atraktivní možnost. Může však být spojena se značnými náklady. Protokoly představují velké množství dat, pokud jsou agregovány napříč stovkami nebo tisíci hostitelů a aplikací. Přijímání, ukládání a vyhledávání těchto dat je v systémech založených na cloudu nákladné.

Jako referenční bod z reálného systému lze uvést, že kolekce přibližně 500 uzlů s několika stovkami aplikací má za následek 200 GB dat protokolů denně. V tomto systému je pravděpodobně prostor pro zlepšení, ale i snížení na polovinu bude v mnoha nabídkách SaaS stát téměř 10 000 dolarů měsíčně. To často zahrnuje uchovávání pouze 30 dní, což není příliš dlouhá doba, pokud se chcete podívat na trendová data v jednotlivých letech.

Tím nechci odrazovat od používání těchto systémů, protože mohou být velmi cenné – zejména pro menší organizace. Účelem je poukázat na to, že mohou vzniknout značné náklady, a to může být odrazující, když se realizují. Ve zbytku tohoto článku se zaměříme na open source a komerční řešení, která jsou samostatně hostitelská.

Možnosti nástrojů

ELK

ELK, zkratka pro Elasticsearch, Logstash a Kibana, je nejpopulárnější open source nástroj pro agregaci logů na trhu. Používají ho společnosti Netflix, Facebook, Microsoft, LinkedIn a Cisco. Všechny tři komponenty vyvíjí a spravuje společnost Elastic. Elasticsearch je v podstatě implementace vyhledávače NoSQL, Lucene. Logstash je systém log pipeline, který dokáže přijímat data, transformovat je a načítat do úložiště, jako je Elasticsearch. Kibana je vizualizační vrstva nad Elasticsearch.

Před několika lety byly představeny Beats. Beats jsou sběrače dat. Zjednodušují proces odesílání dat do Logstash. Místo toho, aby uživatel musel rozumět správné syntaxi jednotlivých typů protokolů, může si nainstalovat Beat, který bude správně exportovat protokoly NGINX nebo protokoly proxy serveru Envoy tak, aby je bylo možné efektivně používat v rámci Elasticsearch.

Při instalaci zásobníku ELK na produkční úrovni může být zahrnuto několik dalších částí, například Kafka, Redis a NGINX. Také je běžné nahradit Logstash systémem Fluentd, o kterém si povíme později. Tento systém může být složitý na obsluhu, což v jeho počátcích vedlo k mnoha problémům a stížnostem. Ty již byly z velké části odstraněny, ale stále se jedná o složitý systém, takže pokud jste menší provoz, možná ho nebudete chtít vyzkoušet.

Podle toho jsou k dispozici služby, takže si s tím nemusíte dělat starosti. Služba Logz.io ji spustí za vás, ale její ceníková cena je trochu vysoká, pokud máte hodně dat. Samozřejmě jste pravděpodobně menší a nemusíte mít mnoho dat. Pokud si Logz.io nemůžete dovolit, můžete se podívat na něco jako AWS Elasticsearch Service (ES). ES je služba, kterou nabízí Amazon Web Services (AWS) a která umožňuje velmi snadno a rychle zprovoznit Elasticsearch. Má také nástroje, které umožňují dostat všechny protokoly AWS do ES pomocí Lambda a S3. Jedná se o mnohem levnější variantu, která však vyžaduje určitou správu a má několik omezení.

Elastic, mateřská společnost stacku, nabízí robustnější produkt, který využívá model otevřeného jádra, který poskytuje další možnosti v oblasti analytických nástrojů a reportování. Lze jej také hostovat na platformě Google Cloud Platform nebo AWS. To by mohla být nejlepší volba, protože tato kombinace nástrojů a hostingových platforem nabízí levnější řešení než většina možností SaaS a stále poskytuje velkou hodnotu. Tento systém by mohl efektivně nahradit nebo poskytnout možnosti systému pro správu bezpečnostních informací a událostí (SIEM).

Soubor ELK také nabízí skvělé vizualizační nástroje prostřednictvím nástroje Kibana, ale chybí mu funkce upozorňování. Elastic poskytuje funkci upozorňování v rámci placeného doplňku X-Pack, ale pro open source systém není nic integrováno. Společnost Yelp vytvořila řešení tohoto problému s názvem ElastAlert a pravděpodobně existují i další. Tento dodatečný software je poměrně robustní, ale zvyšuje složitost již tak složitého systému.

Graylog

Graylog v poslední době získává na popularitě, ale jeho počátek je v roce 2010, kdy jej vytvořil Lennart Koopmann. O dva roky později vznikla společnost se stejným názvem. Navzdory svému rostoucímu využití stále výrazně zaostává za zásobníkem ELK. To také znamená, že má méně funkcí vyvinutých komunitou, ale může používat stejné Beats jako stack ELK. Graylog si získal uznání v komunitě Go zavedením postranního kolektoru Graylog Collector napsaného v jazyce Go.

Graylog používá pod kapotou Elasticsearch, MongoDB a Graylog Server. Díky tomu je jeho provoz stejně složitý jako u zásobníku ELK a možná ještě o něco složitější. Graylog však přichází s upozorňováním integrovaným do open source verze, stejně jako s několika dalšími pozoruhodnými funkcemi, jako je streamování, přepisování zpráv a geolokace.

Funkce streamování umožňuje směrovat data do konkrétních streamů v reálném čase, zatímco jsou zpracovávána. Díky této funkci může uživatel vidět všechny chyby databáze v jednom Streamu a chyby webového serveru v jiném Streamu. Na základě těchto Streamů lze dokonce vytvářet výstrahy při přidávání nových položek nebo při překročení prahové hodnoty. Zpoždění je pravděpodobně jedním z největších problémů systémů agregace protokolů a Streamy tento problém v systému Graylog odstraňují. Jakmile protokol přijde, může být směrován do jiných systémů prostřednictvím Streamu, aniž by byl plně zpracován.

Funkce přepisování zpráv využívá open source engine pravidel Drools. Ten umožňuje vyhodnocovat všechny příchozí zprávy podle souboru pravidel definovaných uživatelem, což umožňuje zprávu vyřadit (tzv. Blacklisting), přidat nebo odebrat pole nebo zprávu upravit.

Nejúžasnější funkcí může být geolokační funkce Graylogu, která podporuje vykreslení IP adres na mapě. Jedná se o poměrně běžnou funkci, která je k dispozici i v systému Kibana, ale přináší velkou přidanou hodnotu – zejména pokud ji chcete používat jako systém SIEM. Funkce geolokace je k dispozici v open source verzi systému.

Společnost Graylog zpoplatňuje podporu open source verze, pokud o ni stojíte. Nabízí také model otevřeného jádra pro svou verzi Enterprise, která nabízí archivaci, protokolování auditů a další podporu. Neexistuje mnoho dalších možností podpory nebo hostingu, takže pokud nepoužijete Graylog (společnost), budete pravděpodobně odkázáni sami na sebe.

Fluentd

Fluentd byl vyvinut ve společnosti Treasure Data a CNCF jej přijala jako inkubační projekt. Byl napsán v jazycích C a Ruby a je doporučován společnostmi AWS a Google Cloud. Fluentd se stal běžnou náhradou za Logstash v mnoha instalacích. Funguje jako místní agregátor, který shromažďuje všechny protokoly uzlů a odesílá je do centrálních úložných systémů. Nejedná se o systém agregace logů.

Používá robustní systém zásuvných modulů, který umožňuje rychlou a snadnou integraci s různými zdroji dat a datovými výstupy. Vzhledem k tomu, že je k dispozici více než 500 zásuvných modulů, měla by být pokryta většina případů použití. Pokud nejsou, zní to jako příležitost přispět zpět komunitě open source.

Fluentd je častou volbou v prostředích Kubernetes díky svým nízkým paměťovým nárokům (jen desítky megabajtů) a vysoké propustnosti. V prostředí, jako je Kubernetes, kde má každý modul Fluentd sidecar, se spotřeba paměti lineárně zvyšuje s každým nově vytvořeným modulem. Použití Fluentd výrazně sníží vytížení systému. To se stává běžným problémem u nástrojů vyvinutých v jazyce Java, které jsou určeny pro běh po jednom na uzel, kde paměťová režie nepředstavovala zásadní problém.