Log Management bez indeksów

Rezygnacja z pełnego indeksowania na rzecz inteligentnego wykorzystania metadanych może pomóc obniżyć koszty oraz uprościć procesy przetwarzania logów i pozwolić na oszczędzanie mocy obliczeniowej naszych maszyn.

Dwa światy logowania: Indeks kontra metadane

Tradycyjne systemy, używając popularny stos ELK (Elasticsearch, Logstash, Kibana), opierają się na indeksowaniu pełnotekstowym, co oznacza, że każda linijka logu jest analizowana, a jej treść trafia do potężnego indeksu, który umożliwia błyskawiczne wyszukiwanie dowolnej frazy. Problem w tym, że sam indeks często zajmuje tyle samo miejsca co oryginalne dane (a czasem więcej), zwiększając koszty przechowywania. Co więcej, proces indeksowania w czasie rzeczywistym jest operacją wymagającą dużej mocy obliczeniowej CPU i pamięci RAM.

Systemy bezindeksowe, takie jak Loki, odwracają tę filozofię. Zamiast indeksować treść, indeksują wyłącznie metadane – czyli etykiety i nagłówki, które sami przypisujemy do strumieni logów (np. app="trip-planner", cluster="prod-eu-central"). Wyszukiwanie jest dwuetapowe: najpierw system zawęża dane, na których pracujemy, filtrując po indeksowanych etykietach, a następnie tylko na tym niewielkim wycinku danych wykonuje wyszukiwanie pełnotekstowe, podobne do komendy grep w linuxie. To opłacalny kompromis: rezygnujemy z części analitycznych możliwości na rzecz ogromnej redukcji kosztów.

Dlaczego giganci porzucili pełne indeksowanie?

Dla firm takich jak Cloudflare, które przetwarzają petabajty logów dziennie, tradycyjne podejście stało się nie tylko ekstremalnie drogie, ale niemal technicznie niewykonalne. Koszt przechowywania i indeksowania każdego logu rósł wykładniczo, sprawiając, że zarządzanie logami stawało się droższe niż kluczowe elementy infrastruktury.

Inżynierowie tych firm, zamiast znaleźć odpowiedź na pytanie "Jak możemy zindeksować to wszystko wydajniej?", pomyśleli "Czy na pewno musimy wszystko indeksować?". Odpowiedzią było stworzenie systemów, w których to właśnie metadane stały się kluczem. Większość zapytań zadawanych systemom logowania nie wymaga skomplikowanej analityki – deweloper zazwyczaj wie, czego szuka: logów z konkretnej aplikacji, klastra czy na określonym poziomie błędu. Model ten pozwala przeszukiwać gigabajty danych zamiast petabajtów, co jest operacją tanią i wystarczająco szybką do celów diagnostycznych.

Kompromis, na który warto się zgodzić

Podejście bezindeksowe powinno zostać zaimplementowane jako świadomy wybór, ponieważ niesie ze sobą konkretne wady i zalety.

Zalety:

1. Znacząca redukcja kosztów: Koszty przechowywania spadają niemal o połowę (brak indeksów), a wymagania co do CPU i RAM są nieporównywalnie niższe. Logi można przechowywać w tanich magazynach obiektowych, jak Amazon S3.
2. Prostsza architektura i skalowalność: Utrzymanie takiego systemu jest znacznie łatwiejsze.
3. Szybkość zapisu: System nie jest obciążony kosztowną operacją indeksowania, więc jest w stanie przyjmować więcej danych przez brak wąskiego gardła w tym miejscu.

Wady:

1. Wolniejsze i mniej złożone zapytania: Zapytania, obejmujące szeroki zakres czasu lub wymagające korelacji wielu pól w treści logów, będą znacznie wolniejsze niż w systemie z pełnym indeksem.
2. Konieczność planowania etykiet: Skuteczność zależy od dobrze zaprojektowanego zestawu etykiet. Jeśli nie przewidzimy jakiegoś wymiaru jako etykiety, przeszukiwanie pod tym kątem pozbawi nasze rozwiązanie sensu.

Kiedy warto pójść w ślady gigantów?

Podejście bezindeksowe nie jest dla każdego. Jeśli Twoja firma opiera kluczowe procesy na skomplikowanych procesach analitycznych i przetwarzaniu logów w czasie rzeczywistym, tradycyjny system jak stos ELK może być nadal lepszym wyborem.

Jeśli jednak większość Twoich interakcji z logami to debugowanie i zadawanie pytań w stylu: "Pokaż mi wszystkie błędy z aplikacji X w ciągu ostatniej godziny", model oparty na etykietach jest prawdopodobnie strzałem w dziesiątkę. To idealne rozwiązanie dla organizacji, które chcą mieć scentralizowany system logowania, ale przerażają je koszty i złożoność tradycyjnych narzędzi.

Solution Architect - wdraża i utrzymuje narzędzie Dynatrace, dokonuje analiz kodu oraz procesów w systemach z perspektywy technicznej i biznesowej oraz integruje systemy.