Przygody DevOps-owe…Parser do Logów – Geneza

Details

Category: O komputerach

Published on Wednesday, 13 March 2024 12:49

Written by Administrator

Hits: 4298

Ostatnimi czasy, zacząłem się zastanawiać nad narzędziami, które służą do agregacji I przeglądania logów...z tych bardziej popularnych mamy do dyspozycji Zabbix, Greylog, czy w końcu cały zestaw ELK (ElasticSearch, Logstash, Kibana).

Z jednej strony Zabbix, który jest udostępniany na zasadzie Open Source, ma spore możliwości, jednak wymaga pewnej wiedzy I w wypadku nietypowych potrzeb może wydawać się mniej przyjazny. Np agregacja logów nie nastręcza trudności, jednak zrobienie odpowiednich reguł dotyczących konkretnych wydarzeń na podstawie tychże logów już może być zadaniem nieco bardziej skomplikowanym I często rozwiązania są tworzone ad-hoc, na podstawie naszej wiedzy I tego co uda nam się znaleźć na przyjaznych forach.

Z drugiej strony mamy Greylog, który jest narzędziem stworzonym stricte do agregacji logów, więc nie ma aż takich możliwości jak Zabbix. Sam nie korzystam aktualnie, więc użytkownicy obydwu narzędzi lepiej wiedzą, w jakich sytuacjach najlepiej z niego korzystać.

W końcu mamy zbiór narzędzi ELK – wydaje się być najpopularniejszym rozwiązaniem do zbierania, monitorowania I alertowania, na podstawie wydarzeń systemowych. Trzeba w tym miejscu zaznaczyć, że nie tylko logów, ale wydarzeń systemowych. W swojej ofercie mają wiele wtyczek, które ułatwiają użytkowanie I dostosowanie do konkretnych potrzeb. Wspierają również takie rozwiązania jak Kubernetes, które w ostatnich latach zyskały wiele na popularności z racji swojej elastyczności. Aby jednak korzystać z ELKa wraz z k8s, musimy wgrać na klaster filebeat’a, które w/w logi będzie zbierał I wysyłał do logstasha. Wydawać by się mogło, że pomysł jest dobry I faktycznie jest – Filebeat zbiera logi, wysyła do Logstash, ten z kolei przesyła je do ElasticSearch I z poziomu ElasticSearch możemy przeglądać to co chcemy, np w Kibanie, lub wysyłać alerty, lub tworzyć wykresy – słowem – możemy robić to, czego tylko nam potrzeba aby nasz monitoring był jak najlepszy. Oczywiście, to wszystko nie jest dostępne w wersji open source, więc alerty na podstawie logów nam odpadają, niestety. Sam zestaw został pomyślany dobrze, tzn filebeat jest napisany w Go, więc jest szybki, natomiast Logstash I ElasticSearch w Javie, co już nie jest tak wydajne. Niestety, wymagania systemowe dla samego ElasticSearch są spore – przynajmniej 8GB Ram + 4CPU to absolutne minimum, żeby serwis działał stabilnie. Mamy możliwość również zklastrowania kilku node’ów co wspomaga wydajność, zarazem zwiększając koszty utrzymania. Coż za coś. Z własnych doświadczeń nie polecam uruchamiać Logstash na tym samym node na którym ElasticSearch, gdyż zwyczajnie w pewnym momencie zabraknie RAM – chyba, że dysponujemy sporymi serwerami, co w zasadzie mija się z celem, ale o tym później.

Cały zestaw ma jednak kilka wad, które w świecie DevOpsowym (I nie tylko) są trudne do zaakceptowania, np – jeśli chcemy filtrować różne rodzaje logów, możemy natknąć się na problemy z właściwą konfiguracją Logstash – “nie wszystko złoto, co się świeci”, tzn nie wszystko co wyczytamy na forach ma rację bytu. I kiedy chcemy zebrać np logi z aplikacji, które są w jakiś sposób nieregularne (quasi Json, lub PlainText ze specjalnymi znakami) możemy natrafić na spory problem, jak napisać poprawny filtr dla Logstash. Możemy się tutaj poratować tagami dla Filebeat I na ich podstawie napisać filtr Logstash (input). Jednym z plusów jest to, że dokumentacja jest dobrze przygotowana, przynajmniej dla typowych rozwiązań, co z kolei bardzo pomaga I de facto skraca czas potrzebny na docelową konfigurację. Z dodatkowych plusów mamy również pełne szyfrowanie Filebeat – Logstash – ElasticSearch – Kibana. Wszystko to sprawia, że cały rodukt jest bardzo atrakcyjny, ale nie dla wszystkich. Z pewnością małe firmy, które nie potrzebują aż tak rozbudowanego systemu logowania mogłyby znaleźć konkurencyjny produkt...ale problem polega na tym, że nie ma nic równie funkcjonalnego.

Dlatego zacząłem myśleć, o alternatywnym rozwiązaniu, które z pozoru może wydawać się co najmniej niepotrzebne. A może by tak napisać własny parser do logów z osobnym frontem, gdzie moglibyśmy przeglądać zebrane log ? Czemu nie !