ELK stack stos to zestaw trzech narzędzi open source – Elasticsearch, Logstash i Kibana – które razem tworzą kompletny system zbierania, przetwarzania i wizualizacji logów. Po elk stack stos sięgają dziś nie tylko duże korporacje, lecz także kilkuosobowe zespoły utrzymujące sklepy internetowe, aplikacje SaaS czy portale contentowe. Powód jest prozaiczny: pojedynczy serwer aplikacyjny potrafi wygenerować kilkaset megabajtów logów dziennie, a ręczne przeglądanie plików tekstowych przestaje mieć sens już przy trzech maszynach. Zamiast logować się przez SSH i przeszukiwać katalogi, administrator otwiera przeglądarkę i w kilka sekund filtruje miliony wpisów po adresie IP, kodzie odpowiedzi HTTP albo identyfikatorze sesji. W tym poradniku znajdziesz konkretne informacje: z czego składa się architektura, ile realnie kosztuje utrzymanie klastra w złotówkach, jakie parametry sprzętowe faktycznie mają znaczenie oraz jakie błędy konfiguracyjne najczęściej kończą się przepełnionym dyskiem i bezpowrotną utratą danych.
Z czego składa się architektura i jak płyną w niej dane
Nazwa ELK to skrót od trzech komponentów. Elasticsearch pełni funkcję rozproszonej bazy dokumentowej z silnikiem wyszukiwania pełnotekstowego, Logstash odpowiada za odbieranie, parsowanie i wzbogacanie zdarzeń, a Kibana dostarcza warstwę wizualną: dashboardy, wykresy, mapy oraz konsolę zapytań. Każdy element działa niezależnie i można go skalować osobno, na oddzielnych maszynach.
Przepływ danych jest liniowy. Aplikacja zapisuje log do pliku lub gniazda, agent zbierający wysyła go do Logstasha, tam filtr grok rozbija surowy tekst na pola, dokładany jest znacznik czasu i dane geolokalizacyjne, a gotowy dokument trafia do indeksu. Kibana odpytuje ten indeks i renderuje wynik, zwykle w ciągu dwóch do dziesięciu sekund od zdarzenia.
Kluczowa różnica względem klasycznego monitoringu polega na granularności. Narzędzie metryczne poinformuje, że średni czas odpowiedzi wzrósł do 900 ms, natomiast elk stack stos pokaże dokładnie te 240 żądań, które ten wzrost wywołały, razem z parametrami zapytania, nagłówkami i identyfikatorem użytkownika. To skraca diagnozę awarii z kilku godzin do kilkunastu minut.
Rola agentów Beats w nowoczesnym wdrożeniu
Logstash jest napisany w Javie i przy pełnym zestawie filtrów potrafi zająć 1-2 GB pamięci. Dlatego na serwerach produkcyjnych instaluje się zamiast niego lekkie agenty Beats: Filebeat do plików tekstowych, Metricbeat do metryk systemowych, Packetbeat do ruchu sieciowego. Zużywają one zwykle 30-80 MB RAM i obciążają procesor w stopniu niezauważalnym.
Typowy schemat wygląda następująco: Filebeat na dziesięciu serwerach aplikacyjnych wysyła zdarzenia do jednego lub dwóch węzłów Logstasha, które pełnią funkcję centralnego procesora i bufora. Dopiero stamtąd dane trafiają do klastra Elasticsearch. Taki podział pozwala przetrwać chwilową niedostępność bazy bez gubienia pojedynczego wiersza logu.
Wymagania sprzętowe i dobór serwera pod klaster
Elasticsearch jest głodny pamięci. Podstawowa zasada mówi, że sterta JVM powinna zajmować połowę dostępnego RAM, a jej rozmiar nigdy nie powinien przekraczać 31 GB – powyżej tej wartości maszyna wirtualna traci kompresję wskaźników i realna wydajność spada. Praktyczne minimum produkcyjne to 8 GB pamięci na węzeł, komfortowy start to 16 GB.
Drugim wąskim gardłem jest dysk. Indeksowanie to operacja losowego zapisu, więc talerzowe HDD odpadają natychmiast. Nośnik NVMe o wydajności powyżej 50 tysięcy IOPS potrafi przyjąć kilkanaście tysięcy dokumentów na sekundę, podczas gdy zwykły SATA SSD zatrzyma się na kilku tysiącach. Sieć o przepustowości 1 Gb/s wystarcza dla większości wdrożeń.
Na starcie sensownym wyborem jest OVH VPS lub zbliżona usługa u innego dostawcy – maszyna z czterema rdzeniami, 16 GB RAM i dyskiem 160 GB NVMe zamyka się w kwocie 120-180 zł miesięcznie i obsłuży logi z kilkunastu stron oraz aplikacji. Przy większym wolumenie przechodzi się na serwer dedykowany albo klaster trzech mniejszych węzłów.
| Skala wdrożenia | Dzienny wolumen logów | Zalecana konfiguracja | Orientacyjny koszt miesięczny |
|---|---|---|---|
| Pojedyncza aplikacja | do 2 GB | 1 węzeł, 8 GB RAM, 80 GB NVMe | 80-120 zł |
| Kilkanaście serwisów | 2-15 GB | 1 węzeł, 16 GB RAM, 250 GB NVMe | 150-300 zł |
| Sklep e-commerce | 15-60 GB | 3 węzły, 32 GB RAM, 1 TB NVMe | 600-1200 zł |
| Platforma SaaS | powyżej 100 GB | 5+ węzłów, warstwy hot-warm-cold | 2500 zł i więcej |
Stanowisko pracy administratora klastra
Analiza logów to godziny spędzone na czytaniu i pisaniu zapytań, więc ergonomia stanowiska przekłada się bezpośrednio na tempo pracy. Dobrze dobrany monitor do komputera o przekątnej 27 cali i rozdzielczości 2560×1440 mieści obok siebie panel Kibany oraz terminal, co eliminuje ciągłe przełączanie okien i gubienie kontekstu przy porównywaniu dwóch zakresów czasowych.
Podobnie działa klawiatura mechaniczna – przy setkach zapytań DSL wyraźny punkt aktywacji przełącznika zmniejsza liczbę literówek w składni JSON. Sprawdzi się zarówno pełnowymiarowy układ z blokiem numerycznym, jak i klawiatura mechaniczna 60 procent, jeśli liczy się miejsce na biurku; klawiatura gamingowa mechaniczna z programowalnymi makrami pozwala dodatkowo podpiąć często używane filtry pod pojedyncze skróty. Zespoły dokumentujące architekturę doceniają też tablet graficzny Wacom, na którym szybciej rysuje się schematy przepływu danych niż w edytorze diagramów.
Realne koszty wdrożenia i utrzymania
Samo oprogramowanie w wariancie podstawowym nie generuje opłat licencyjnych, co bywa mylące. Rzeczywisty koszt to infrastruktura plus czas ludzi. Uruchomienie działającego klastra z jednym węzłem, agentami na pięciu serwerach i trzema dashboardami zajmuje doświadczonemu administratorowi 12-20 godzin, co przy stawce 150-250 zł za godzinę daje 2000-5000 zł jednorazowo.
Do tego dochodzi utrzymanie: aktualizacje wersji, rotacja indeksów, reagowanie na alerty. Rozsądnie planuje się od dwóch do sześciu godzin miesięcznie. Firmy, które nie chcą utrzymywać kompetencji wewnętrznie, wybierają usługę zarządzaną – rozwiązania chmurowe startują od około 70-90 zł miesięcznie za najmniejszą instancję i rosną liniowo wraz z ilością przechowywanych danych.
W budżecie zespołu warto ująć narzędzia towarzyszące. Google Workspace cena za jednego użytkownika w podstawowym planie to kilkadziesiąt złotych miesięcznie, a wspólna skrzynka i kalendarz dyżurów są potrzebne od pierwszego dnia, gdy zaczynają przychodzić alerty. Sklepy dokładają jeszcze integracje z zewnętrznymi kanałami sprzedaży.
Właśnie te integracje bywają najbardziej wdzięcznym zastosowaniem. Feed produktowy wysyłany do Google Merchant Center potrafi odrzucać ofertę z powodu błędu 400 zwracanego przez API sklepu raz na kilkaset żądań. Bez centralnego zbierania logów taki problem pozostaje niewidoczny miesiącami, a z indeksem pełnym zdarzeń wykrywa się go jednym zapytaniem.
Konfiguracja indeksów, cykl życia danych i typowe zastosowania
Pierwszą decyzją po instalacji jest strategia indeksowania. Standardem jest tworzenie osobnego indeksu na dobę i typ danych, na przykład logi-nginx-2024.03.11. Dzięki temu usunięcie starych danych sprowadza się do skasowania całego indeksu, co trwa ułamek sekundy, zamiast kosztownego usuwania pojedynczych dokumentów z ogromnej struktury.
Drugą decyzją jest polityka cyklu życia. Mechanizm ILM przenosi indeksy między warstwami: przez pierwsze siedem dni dane leżą na szybkich dyskach i są zapisywane, przez kolejne trzydzieści są tylko odczytywane z wolniejszych nośników, a po dziewięćdziesięciu dniach znikają albo trafiają do archiwum na tanim magazynie obiektowym. Bez tej polityki dysk zapełni się w kilka tygodni.
Zastosowań jest więcej, niż sugeruje sama nazwa. Agencje zajmujące się projektowaniem stron internetowych zbierają w jednym miejscu logi kilkudziesięciu serwisów klienckich i natychmiast widzą, który z nich zaczął zwracać błędy 500 po aktualizacji wtyczek. Ten sam zestaw wychwytuje wzmożone próby wejścia na adres wordpress logowanie, czyli klasyczny atak słownikowy na panel administracyjny.
Dane z logów serwera przydają się także w marketingu. Analiza nagłówków User-Agent pokazuje, jak często roboty wyszukiwarek odwiedzają poszczególne sekcje serwisu i ile czasu zajmuje im pobranie strony – a to twarde wejście w budżet indeksowania, o który opiera się skuteczne pozycjonowanie strony. Wykres liczby żądań Googlebota w czasie mówi więcej niż deklaracje z panelu.
Bezpieczeństwo, najczęstsze błędy i dobre praktyki
Najkosztowniejszy błąd to wystawienie Elasticsearcha na publiczny adres IP bez uwierzytelniania. Domyślnie usługa nasłuchuje na porcie 9200 i każdy, kto go znajdzie, może odczytać oraz skasować całą zawartość. Skanery internetowe znajdują takie instancje w ciągu kilkudziesięciu minut od uruchomienia, a odzyskanie danych bywa niemożliwe.
Drugi błąd to brak limitu na rozmiar sterty i pozostawienie domyślnego 1 GB. Klaster działa poprawnie do momentu, w którym ktoś zbuduje agregację po polu o wysokiej kardynalności – wtedy węzeł wpada w pętlę odśmiecania pamięci i przestaje odpowiadać. Trzeci błąd to zbyt duża liczba shardów: kilkanaście tysięcy małych fragmentów obciąża pamięć węzła bardziej niż same dane.
Higiena operacyjna sprowadza się do kilku nawyków: włączony moduł bezpieczeństwa z rolami i hasłami, komunikacja po TLS, dostęp do Kibany wyłącznie przez VPN lub reverse proxy z drugim składnikiem uwierzytelniania, cotygodniowe migawki indeksów na osobny zasób oraz alert na zajętość dysku ustawiony na 75 procent. Każdy z tych elementów konfiguruje się raz i działa latami.
Warto też pilnować, żeby dane z logów faktycznie trafiały do decyzji biznesowych. Raport pokazujący, że roboty marnują połowę budżetu indeksowania na parametryzowane adresy filtrów, przekłada się wprost na pozycjonowanie strony w google, bo pozwala odciąć śmieciowe ścieżki w pliku robots.txt. To samo źródło danych obsługuje jednocześnie dział techniczny i marketingowy.
Jak zacząć wdrożenie ELK od zera, jeśli nie mam doświadczenia z klastrami?
Zacznij od jednej maszyny testowej z 8 GB RAM i uruchom wszystkie trzy komponenty przez Docker Compose – gotowy plik konfiguracyjny pozwala postawić środowisko w kilkanaście minut. Podłącz najpierw jedno źródło danych, na przykład logi dostępowe serwera WWW, i zbuduj z nich prosty dashboard z liczbą żądań, rozkładem kodów odpowiedzi oraz listą najwolniejszych adresów. Dopiero gdy ten obieg działa stabilnie przez tydzień, dodawaj kolejne źródła. Kluczowe jest opanowanie filtrów grok, bo to one decydują o tym, czy log stanie się przeszukiwalnym zbiorem pól, czy pozostanie jednym wielkim tekstem. Środowisko produkcyjne buduj osobno, nigdy przez rozbudowę instalacji testowej.
Czy ELK stack stos opłaca się przy jednym serwerze i małym ruchu?
Przy jednej maszynie i kilkuset odsłonach dziennie pełny klaster jest przerostem formy nad treścią – narzut pamięciowy przewyższy zasoby zużywane przez samą aplikację. Próg opłacalności zaczyna się mniej więcej tam, gdzie masz co najmniej trzy źródła logów albo gdzie przestój usługi kosztuje realne pieniądze. Sklep internetowy z obrotem kilkudziesięciu tysięcy złotych miesięcznie zwraca koszt wdrożenia po jednej wykrytej awarii koszyka. Dla mniejszych projektów rozsądniejsze są lżejsze alternatywy: Loki z Grafaną zużywa kilkukrotnie mniej pamięci, a hostowane usługi zbierania logów startują od kilkudziesięciu złotych miesięcznie bez potrzeby utrzymywania własnej infrastruktury.
Co zrobić, gdy Elasticsearch zaczyna zwracać status czerwony?
Czerwony status oznacza, że przynajmniej jeden shard podstawowy jest niedostępny i część danych nie da się odczytać ani zapisać. Sprawdź kolejno trzy rzeczy: zajętość dysku, bo po przekroczeniu progu 95 procent klaster automatycznie blokuje zapisy i przełącza indeksy w tryb tylko do odczytu; dostępność wszystkich węzłów, bo utrata jednego przy braku repliki od razu daje czerwony stan; oraz logi samego Elasticsearcha pod kątem błędów odśmiecania pamięci. W większości przypadków wystarczy zwolnić miejsce przez usunięcie najstarszych indeksów i ręcznie zdjąć blokadę zapisu. Jeśli shard jest trwale uszkodzony, odtwórz go z ostatniej migawki – dlatego kopie zapasowe konfiguruje się przed pierwszym wdrożeniem produkcyjnym, a nie po awarii.
