Ogarnij logi. Zamień Kibane na Grayloga


Bez względu na to, czy mamy do czynienia ze złożonym, wielo-node’owym środowiskiem opartym o mikroserwisy, czy niewielkim zestawem aplikacyjnym, właściwa agregacja logów oraz możliwość ich szybkiego przeglądu, nie jest kwestią wyboru. To konieczność.

Typ artykułu: Techniczny, DevOps
Poziom: dla średnio-zaawansowanych

Jeżeli już korzystasz z Kibany – w tym artykule zachęcę Cię do zmiany 🙂 przejdź do listy argumentów tutaj: Dlaczego Graylog?
Jeżeli jeszcze nie korzystasz z agregatorów logów, to mam nadzieję, że Cię do tego namówię, niezależnie, czy jesteś programistą czy devopsem.

Wydawałoby się, że pisanie o takich narzędziach jak ElasticSearch i Kibana albo Graylog w kontekście logowania, powinno stanowić relikt przeszłości.
Zadziwiająco jednak, wciąż można spotkać się z projektami, w których logi pisane są jedynie do pliku, a ponadto sam proces ich przeglądania, polega na
chałupniczym scrolowaniu w notatniku.

Taki stan rzeczy często wynika z pośpiechu. Wymagania zebrane w ostatniej chwili trzeba jak najszybciej wdrożyć, a poświęcanie czasu na niefunkcjonalne wymagania, takie jak agregacja logów, wydaje się zbytkiem luksusu.

Warto jednak sobie uzmysłowić, że profesjonalne wytwarzanie oprogramowania, wymaga zadbania każdy etap, od planowania, przez testy i automatyczne wdrażanie, po zbieranie metryk i logów.

1. Przestań pisać logi do plików

Jedną z zasad tworzenia aplikacji zgodnie ze standardem 12th factor app, jest to, aby zapisywać logi jedynie na strumieniu wyjścia. Twoja aplikacja nie powinna zajmować się takimi sprawami jak to, gdzie te logi są przetwarzane, przesyłane oraz jak nazywa się plik z logami.

System nie powinien wysypywać się tylko, dlatego, że miejsce na dysku przeznaczonym na logi się skończyło, plik z logami jest edytowany, albo połączenie do huba przeznaczonego na logi, zostało zamknięte.

Twoja aplikacja ma robić, to, co robi i nic więcej, niech logami zajmie się inny system (zwłaszcza taki, który usunie stare, zbędne logi).

2. Przestań przeglądać logi jak amator

Wchodzenie na serwer i robienie tail na logach, lub co gorsza, otwieranie ich w notatniku na Windows Server, z profesjonalnym developmentem nie mają nic wspólnego.

Jeżeli zapisujesz logi, zadbaj o ich właściwy format, najlepiej, aby był to json, który można dowolnie rozszerzać. Jeżeli możesz szybko znaleźć, wszystkie błędy, z danego dnia, dla swoich dwóch aplikacji, dotyczących konkretnego klienta – to znaczy, że jesteś na dobrej drodze. Jeżeli jednak taka operacja wymaga od Ciebie napisania zaawansowanego regexa połączonego z sed’em, to coś poszło nie tak.

3. Logi to TWOJA sprawa

Tak, Twoja! Nie kolegi, nie zespołu DevOpsów, ale Twoja. Bez względu na to, kto teoretycznie odpowiada za różne elementy systemu, jesteś równie odpowiedzialny za jego działanie.

Powinieneś niezwłocznie wiedzieć, kiedy w aplikacji powstaje krytyczny błąd i czy ten krytyczny błąd, należy naprawić szybkim hot-fixem, restartem, dodaniem kolejnego node’a czy zwiększeniem zasobów.

Jeżeli ktoś zadzwoni lub napisze e-mail prosząc o informację co się stało, powinieneś być w stanie sprawnie znaleźć odpowiedni log i zweryfikować sytuację.
Co więcej, gdy sam łączysz się do zewnętrznej aplikacji, która przestaje działać, nie wysyłaj maila:
Coś nie działa od wczoraj.

Zamiast tego, przeglądając logi, powinieneś wskazać dokładnie jaki był czas i parametry requestu oraz kod odpowiedzi serwera.

Niestety wciąż zdarza się, że na prośbę o logi w takiej sytuacji, czeka się kilka dni i dostaje się wycinki stacktrace’a z Javy, które z logami, mającymi znaczenie dla klienckiej aplikacji, niewiele mają wspólnego

4. Brak wiadomości to też wiadomość

Istotnym elementem przeglądania logów jest nie tylko szukanie problemów w samym źródle wiadomości, ale także faktu braku wiadomości.

Czy nie została zalogowana akcja, która powinna się wydarzyć? Ile minęło godzin od ostatniej aktywności aplikacji?

Istnienie logów jest jak migająca kontrolka w czujniku czadu – jeżeli nowe logi się pojawiają, jest dobrze.

5. Logi to naturalny profiler

Chociaż logi nie zastąpią profesjonalnych narzędzi do profilingu, to jednak już sam czas logowania żądań, daje całkiem dobry ogląd sytuacji.

Zakładając, że nasze logi uzbroiliśmy w dodatkowe informacje, jak ID requestu lub inny identyfikator, jesteśmy w stanie przeanalizować ile trwa przejście informacji od początku, do końca.

Dlaczego Graylog?

1. Graylog wymaga logowania już od pierwszej chwili

W przeciwieństwie do Kibany, Graylog może być wystawiony na zewnątrz bez obawy, że ktoś zacznie przeglądać nasze wpisy.

Oczywiście wciąż jest ryzyko, że uruchomimy go z domyślnym hasłem (sic!) jednak nie potrzebujemy żadnych wtyczek ani proxy, aby autoryzować ruch do przeglądania logów.

Ponadto Graylog wspiera tworzenie użytkowników a także logowanie po LDAP.

Warto zwrócić na to uwagę szczególnie w kontekście GDPR, gdzie część logów należy chronić i zapewniać do nich dostęp, jedynie zdefiniowanym grupom developerów.

2. Graylog potrafi akceptować połączenia

O ile Kibana jest jedynie nakładką na przeglądanie zgromadzonych w ElasticSearch logów, o tyle Graylog to pełnoprawny serwer. Bez problemu możemy wystawić tzw. wejścia i akceptować z nich połączenia. Pisanie logów może odbywać się z wielu miejsc, takich jak daemonset FluentD na Kubernetesie, albo sidecar oparty o filebeat stojąc na Window Server. Wspierane są zarówno połączania TCP jak i UDP. Ilość wspieranych systemów oraz sposobów przesyłu logów, powinna nam zupełnie wystarczyć

3. Alerty i notyfikacje


Największą zaletą z mojego punktu widzenia jest zaawansowany system notyfikacji. Bez problemu możemy powiadamiać o błędach lub specyficznych zachowaniach poprzez złożony mechanizm warunków i alarmów w Graylog. Wiadomość można przesłać chociażby na specjalny kanał na Slacku.

Graylog bardzo sprawnie wykrywa zdefiniowane wcześniej pola oraz wyodrębnione fragmenty wiadomości. Nie ma problemu, aby otrzymać powiadomienie gdy zalogowany czas operacji, albo otrzymana wartość, przekraczają warunki brzegowe. Jest to szczególnie przydatne w niedeterministycznych systemach, takich jak aplikacje oparte o machine learning. Informacja o tym, czy coś błędnie obliczyliśmy poznamy dopiero w przyszłości. Precyzja jaką chcemy osiągnąć, często może zależeć od klienta, a nawet pory roku. W takiej sytuacji możliwość dynamicznej analizy logów, a tym samym otrzymania powiadomienia, jest nie do przecenienia.

4. Wyodrębnianie logów

Bez względu czy nasze logi dostarczamy jako pliki JSON, csv albo we własnym formacie, przy pomocy mechanizmu extractors, możemy parsować dowolne fragmenty, wyodrębniając je jako składowe wyszukiwań.

Podstawowe wtyczki w Graylogu bez problemu parsują większość znanych formatów, pozwalając np. wylistować nazwy namespace z kontenerów na Kubernetesie.

5. Czytanie logów jest przyjemniejsze

Co prawda to kwestia gustu, ale porównując na pierwszy rzut oka wpis z Kibany i Grayloga, odnosi się wrażenie, że wygląd i układ działa na korzyść tego drugiego.
Kibana:

Graylog:

Mimo wszystko, nie ma lekko

W trakcie konfiguracji stosu, bez względu na to czy korzystamy z Kibany lub Grayloga, należy uzbroić się w nieco cierpliwości. W zależności od środowiska, a także kolejnych wersji Elasticsearch, FluentD, Kibany, oraz Grayloga konfiguracja w pełni działającego, poprawnie skonfigurowanego (multinode, clustered), systemu, może przysporzyć sporo nerwów. Bardzo ciekawie opisuje to vados w swoim artykule: Adding logging management with the EFKK stack

Materiały

Zachęcam do przetestowania Grayloga, najprościej oczywiście użyć dockera

Dodaj komentarz

This site uses Akismet to reduce spam. Learn how your comment data is processed.