Kilka słów o logach

Typowemu programiście logi kojarzą się z czymś złym. I nie ma się temu co dziwić. Przecież zaglądamy tam tylko, gdy któraś z funkcjonalności nie działa tak, jak powinna. Jednak, bez nich nasze życie byłoby dużo trudniejsze. Dlatego warto zadbać szybki i zunifikowany dostęp do nich. Tak, aby każdy z członków zespołu mógł w każdej chwili zweryfikować poprawność systemu. W szczególności, gdy mamy do czynienia z mikroserwisami rozproszonymi na wielu serwerach.

 

Problem logów

Podczas pisania kodu rzadko zastanawiamy się nad problemem agregacji logów. Większość z nas korzysta z wyspecjalizowanych narzędzi, które ułatwiają nasze codziennie życie. Dzięki nim możemy szybko i w łatwy sposób debugować swoje aplikacje. Dodatkowo wyświetlają w formie pisemnej to, co aktualnie dzieje się w aplikacji, czyli logi. W przypadku gdy napotkamy na błąd, możemy w prosty i szybki sposób otrzymać szczegółowe informacje na jego temat. Oczywiście pod warunkiem, że zadbamy o zapisywanie tych informacji. Poza naszymi błędami, dochodzą problemy  w komunikacji z zewnętrznymi systemami, a w dzisiejszych czasach nie istnieją aplikacje, które tego nie robią. Nie ważne czy jest to baza danych, API wystawione jako restowy endpoint czy może system operacyjny i operacje IO.

IntelliJ

Niestety, gdy skończymy pracę nad kodem i odpalimy aplikacje na serwerze, tracimy dostęp do danych z poziomu edytora kodu.

 

Podejście klasyczne z epoki monolitu

Większość z nas pracuje nad systemami opartymi o architekturę monolityczną. I nie ma w tym tak naprawdę nic złego (często monolit będzie lepszy niż źle zaprojektowany system mikroserwisowy). Spowodowane jest to wymaganiami biznesowymi. Wtedy mamy jeden centralny serwer, na którym zainstalowany został serwer naszej aplikacji. W przypadku języka Java często będzie to np. Wildfly czy stary poczciwy Tomcat.

Jak w takim wypadku odnaleźć logi ? Prawdopodobnie cały proces został już ustalony i wcielony w życie. Logi zapisywane są do zwykłego pliku tekstowego, który przechowuje dane z ostatniego dnia. Na jego koniec dodajemy do nazwy pliku datę i zostawiamy go w spokoju. Niekiedy osoba odpowiedzialna za konfigurację serwera była osobą troskliwą i dodała dodatkowe skrypty. Odpowiadają one za pakowanie danych, a zapisy sprzed kilku miesięcy są usuwane.

Niestety takie rozwiązanie poza swoją prostotą posiada sporo wad. Pierwszą z nich jest sposób przeglądania. Prawdopodobnie plik tekstowy zostanie otworzony zwykłym edytorem tekstu np. notepad++, a osoba odpowiedzialna za znalezienie danych użyje po prostu CTRL+F (albo commad+f, jeżeli należy do „jasnej strony mocy”). Przed przystąpieniem do tych czynności musimy jednak w jakiś sposób dostać się do maszyny, na którym został postawiony serwer. Wymaga to czasu oraz znajomości haseł. Co jednak w przypadku środowisk produkcyjnych ? Sprawa może komplikować się, gdy pieczę nad maszynami sprawuje klient, który dba o bezpieczeństwo swoich danych.

Notepad++ logi

Byłem kiedyś w takim projekcie. Istniała tylko jedna osoba, która była w stanie zalogować się do serwera produkcyjnego. Nie trudno zgadnąć jak wyglądał proces pozyskania logów. Jeżeli ta osoba była aktualnie zajęta, kończyło się to kilku godzinnym oczekiwaniem.

 

Problemy mikroserwisów

Tym razem załóżmy ekstremum. Firma, dla której pracujemy, jest tzw Unicornem. System, który piszecie, oparty został o architekture mikroserwisową. Programiści naklepali już kilkadziesiąt różnych serwisów, do tego dochodzą replikacje. Koniec końców mamy kilkadziesiąt różnych serwerów. Nie wliczając w to podziału na dev, stable czy produkcje. Dodatkowo zrobiliśmy fallback w postaci replikacji między różnymi dostawcami chmury. W jaki sposób mam wtedy pozyskać logi z danego serwisu i do tego z instancji numer x znajdującej się na Azure ? Będziemy przetrzymywać listę wszystkich serwerów oraz spis odpalonych na nich serwisów ? Dodatkowo stworzymy drugą taką listę zawierająca adres login i hasło do każdego z nich ? To brzmi jak katastrofa ! Na szczęście takie firmy chyba nie istnieją. Dlaczego ? Bo jeszcze przed wdrożeniem aplikacji na produkcję ktoś napotka się na ten problem, po czym wdroży system zarządzający logami.

Jakie jednak mamy opcję pozwalające na szybki centralny dostęp do tych niezbędnych w naszej pracy danych ? Czy istnieje jakaś aplikacja zastępująca edytory tekstu podczas przeglądania ? Na szczęście istnieją gotowe i do tego darmowe rozwiązania.

Agregacja i prezentacja logów

Jednym z najbardziej popularnych systemów pozwalających na agregacje logów będzie tzw. ELK stack. Jest to połączenie Elasticsearch, Logstasha i Kibany.

 

 

ELK

 

Elasticsearch jest bazą danych, w której będziemy przechowywać swoje logi w formacie JSON (większość narzędzi wspiera natywne ten format). Jednak aby było to możliwe, musimy opracować sposób na transportowanie naszych plików do bazy. Logstash jest właśnie tym narzędziem. Poza transportem naszych danych pozwala także na ich przetwarzanie, dzięki czemu logi zostaną zapisane w dogodnej dla nas strukturze.

Większość programistów nie ma problemów z wykonywaniem zapytań do bazy danych. Nie jest to jednak najwygodniejszy sposób przeglądania danych, które wypluje nasza aplikacja. Kibana rozwiązuje ten problem. Pozwala na prosta i przejżystą prezentacje wpisów, które zostały zapisane w Elasticsearch przez Logstasha.

 

Kibana

 

Prostota w obsłudze i elegancji sposób prezentowania danych, nie są jedynymi zaletami Kibany. Dzięki niej możemy także manipulować danymi, wykonywać agregacje bez dużej znajomości Elasticsearch oraz narzędzi do ich przetwarzania.

 

Podsumowanie

ELK stack to tylko jeden z wielu sposobów na zarządzanie logami. Warto zauważyć, że każdy z komponentów może zostać zastąpiony. Osoby nieprzepadające za Logstashem mogą wybrać np. Fluentd (bardzo popularne narzędzie w systemach opartych o platformę Docker). Jeżeli nie zależy nam, na byciu platform agnostic możemy skorzystać z systemów naszego dostawcy chmury (np CloudWatch od Amazona).

Najważniejsze, aby wybrane przez nas narzędzie było dostosowane do naszych potrzeb i pomagało w naszej codziennej pracy !

 

  • Łukasz Kuczyński

    Bardzo mi się podoba Twoje zainteresowanie ELKiem 🙂 miałeś może możliwość implementacji tego gdzieś?

    • Tomasz Łukawski

      Swojego czasu pomagałem w implementacji ELKa oraz podobnego stacku tylko zamiast logstasha używaliśmy FluentD.

      • Łukasz Kuczyński

        Jaka implementacja, tylko Logi? I dlaczego FluentD? Jak w ogóle biznes się zapatruje na takie pomysły?