Grafana, Loki, Tempo i Prometheus – jak zbudować kompletny system obserwowalności (Observability)?

Wprowadzenie: trzy filary obserwowalności i rola stosu Grafana

Wzrost czasu odpowiedzi aplikacji jest sygnałem problemu, ale nie wyjaśnia jego przyczyny. Źródłem opóźnień może być przeciążona baza danych, wolna usługa zewnętrzna albo błąd wprowadzony podczas ostatniego wdrożenia. Sam wykres pokazujący pogorszenie wydajności nie wystarczy, by rozstrzygnąć, który scenariusz wystąpił. Potrzebne są dane pozwalające przejść od objawu do zrozumienia zachowania systemu.

Obserwowalność (observability) to zdolność wnioskowania o wewnętrznym stanie systemu na podstawie emitowanych przez niego danych. W praktyce pomaga ustalić nie tylko, czy aplikacja działa, lecz także dlaczego działa w określony sposób i jak wpływa to na użytkowników. Jest szczególnie istotna w środowiskach rozproszonych, w których pojedyncze żądanie może angażować wiele usług i zależności.

Metryki, logi i ślady — trzy perspektywy na ten sam system

Metryki, logi i ślady rozproszone są tradycyjnie określane jako trzy filary obserwowalności. Nie wyczerpują wszystkich dostępnych rodzajów telemetrii, ale stanowią podstawę stosu opisywanego w tym artykule. Każdy z nich odpowiada na inny rodzaj pytań:

• Metryki opisują zjawiska liczbowo, w czasie. Pozwalają śledzić między innymi liczbę żądań, udział błędów, opóźnienia i wykorzystanie zasobów. Najlepiej sprawdzają się w ocenie kondycji usług, wykrywaniu trendów oraz sygnalizowaniu odchyleń od oczekiwanego zachowania.
• Logi zapisują konkretne zdarzenia wraz z ich kontekstem. Mogą zawierać komunikat błędu, informację o wykonanej operacji czy przyczynę odrzucenia żądania. Pomagają wyjaśnić, co wydarzyło się w aplikacji, choć ich przydatność zależy od jakości i zakresu zapisywanych informacji.
• Ślady rozproszone (traces) przedstawiają przebieg pojedynczego żądania lub operacji przez kolejne komponenty. Pokazują zależności między wywołaniami i czas ich wykonania, ułatwiając lokalizowanie wąskich gardeł oraz błędów na granicach usług.

Te dane nie są zamiennikami. Metryki dobrze pokazują skalę problemu, logi dostarczają szczegółów zdarzeń, a ślady ujawniają przebieg operacji. Wartość obserwowalności wynika z ich uzupełniania się, a nie z samego zgromadzenia dużej ilości telemetrii.

Za co odpowiadają Prometheus, Loki, Tempo i Grafana?

Prometheus służy do zbierania, przechowywania i odpytywania metryk w postaci szeregów czasowych. To podstawa liczbowego obrazu działania środowiska oraz oceny warunków alarmowych. Loki odpowiada za agregację, przechowywanie i wyszukiwanie logów, natomiast Tempo przechowuje ślady rozproszone i umożliwia ich wyszukiwanie oraz analizę.

Grafana zapewnia wspólny interfejs do pracy z tymi źródłami danych. Umożliwia tworzenie dashboardów, eksplorowanie telemetrii i konfigurowanie alertów. Nie zastępuje przy tym magazynów metryk, logów ani śladów — udostępnia ich dane w jednym środowisku analitycznym.

Razem narzędzia te tworzą otwarty, modułowy fundament systemu obserwowalności. Samo ich uruchomienie nie gwarantuje jednak skutecznej diagnostyki. O użyteczności rozwiązania decyduje przede wszystkim to, czy aplikacje emitują dane pozwalające odpowiedzieć na konkretne pytania o jakość usług, błędy i doświadczenie użytkownika.

2. Komponenty i przepływ danych end-to-end: od instrumentacji do zapytań w Grafanie

Aby zrozumieć architekturę tego stosu, warto prześledzić drogę pojedynczego sygnału: od aplikacji lub infrastruktury, przez warstwę zbierania, aż do systemu przechowywania i zapytania uruchomionego z Grafany. W Cognity często słyszymy pytania, jak praktycznie połączyć te elementy w spójny system obserwowalności – odpowiadamy na nie także na blogu. Prometheus, Loki i Tempo są backendami dla różnych typów telemetrii, a Grafana zapewnia wspólny interfejs dostępu do ich danych. Nie oznacza to jednak, że wszystkie sygnały docierają do nich tą samą drogą.

Instrumentacja: gdzie powstaje telemetria

Instrumentacja to wyposażenie aplikacji w mechanizmy, które opisują jej działanie. Biblioteki klienckie Prometheusa pozwalają udostępniać metryki, na przykład liczbę żądań, czas ich obsługi czy liczbę błędów. OpenTelemetry dostarcza API, SDK i mechanizmy automatycznej instrumentacji, wykorzystywane między innymi do tworzenia śladów wykonania. Logi powstają zwykle za pośrednictwem bibliotek logowania i trafiają na standardowe wyjście procesu, do plików lub bezpośrednio do odbiornika telemetrii.

Nie każde źródło danych wymaga zmian w kodzie. Eksportery udostępniają metryki systemów operacyjnych, baz danych i innych usług w formacie obsługiwanym przez Prometheusa. Automatyczna instrumentacja może natomiast rejestrować część operacji aplikacji bez ręcznego dodawania spanów, czyli jednostek pracy składających się na ślad. Operacje specyficzne dla logiki biznesowej często nadal wymagają instrumentacji ręcznej.

Agenci i collectory: odbiór, przetwarzanie i przekazywanie danych

Między źródłem a backendem może działać agent lub collector, na przykład Grafana Alloy albo OpenTelemetry Collector. Taka warstwa odbiera telemetrię, uzupełnia ją o informacje o środowisku, filtruje niepotrzebne dane i wysyła je do właściwego systemu. W zależności od konfiguracji może również grupować dane w paczki, buforować je i ponawiać wysyłkę po przejściowych problemach z połączeniem. Obsługa konkretnych źródeł i odbiorców zależy od dostępnych komponentów danej dystrybucji.

Agent zwykle działa blisko źródła, na przykład na hoście lub węźle klastra, gdzie zbiera lokalne logi i metryki. Collector może pełnić tę samą funkcję albo działać jako wspólna brama odbierająca dane z wielu aplikacji. To rozróżnienie dotyczy przede wszystkim roli we wdrożeniu, a nie dwóch całkowicie odmiennych kategorii oprogramowania.

Istotna jest różnica między pobieraniem a wysyłaniem danych. Prometheus standardowo cyklicznie odpytuje endpointy metryk — jest to model pull, nazywany scrapingiem. Logi i ślady są zazwyczaj przekazywane do backendów w modelu push. Ślady często docierają do collectora przez OTLP, protokół OpenTelemetry. Obecność collectora nie jest obowiązkowa na każdej ścieżce: Prometheus może pobierać metryki bezpośrednio z aplikacji i eksporterów.

Storage: trzy backendy, różne modele danych

Każdy backend organizuje dane odpowiednio do rodzaju sygnału i sposobu jego późniejszego odczytu:

• Prometheus przechowuje próbki metryk w bazie szeregów czasowych. Szereg identyfikują nazwa metryki oraz zestaw etykiet, a kolejne próbki zawierają wartość i znacznik czasu.
• Loki przechowuje logi pogrupowane w strumienie określone etykietami. Indeksuje przede wszystkim etykiety, a nie pełną treść wpisów, co odróżnia go od klasycznych wyszukiwarek pełnotekstowych.
• Tempo przechowuje ślady złożone ze spanów opisujących operacje i zależności między nimi. Umożliwia odczyt śladu po identyfikatorze oraz wyszukiwanie na podstawie jego atrybutów.

W podstawowym modelu Prometheus korzysta z lokalnej bazy TSDB. Loki i Tempo mogą wykorzystywać magazyn obiektowy do trwałego przechowywania danych. Warstwa storage nie jest więc jednym wspólnym repozytorium dla całego stosu.

Query layer: jak dane trafiają na ekran

Grafana łączy się z backendami przez skonfigurowane źródła danych. Zapytania dotyczące metryk są wykonywane w Prometheusie z użyciem PromQL, logów — w Lokim z użyciem LogQL, a śladów można szukać w Tempo za pomocą TraceQL. Backend przetwarza zapytanie i zwraca wynik, który Grafana prezentuje jako wykres, listę wpisów lub widok śladu.

Grafana nie zastępuje magazynów telemetrii. Przechowuje własną konfigurację, w tym definicje dashboardów i źródeł danych, ale wyświetlane metryki, logi i ślady odczytuje z odpowiednich backendów. Rozdzielenie ścieżki zapisu od ścieżki odczytu pozwala jasno ustalić odpowiedzialność każdego komponentu: instrumentacja wytwarza dane, warstwa zbierania je dostarcza, backend przechowuje i przeszukuje, a Grafana udostępnia wynik użytkownikowi.

Jak elementy współpracują: korelacja metrics → logs → traces

Największą wartość tego stosu widać nie na pojedynczym dashboardzie, lecz podczas przechodzenia między danymi bez utraty kontekstu. Metryka pokazuje skalę i moment wystąpienia problemu, log dostarcza informacji o konkretnym zdarzeniu, a ślad pozwala prześledzić przebieg żądania między usługami. Grafana łączy te perspektywy, ale nie tworzy powiązań automatycznie — potrzebuje wspólnych atrybutów, identyfikatorów oraz skonfigurowanych odsyłaczy między źródłami danych.

Od metryk do logów: wspólne etykiety i zakres czasu

Przejście z Prometheusa do Lokiego opiera się przede wszystkim na kontekście: nazwie usługi, środowisku, klastrze czy przestrzeni nazw Kubernetes. Jeśli metryki i logi pozwalają rozpoznać te same zasoby, zapytanie o logi można zawęzić do komponentu wskazanego przez metrykę oraz do odpowiedniego przedziału czasu. Nazwy atrybutów nie muszą być identyczne w każdym źródle, ale ich znaczenie i sposób mapowania powinny być jednoznaczne.

Takie połączenie można udostępnić przez odpowiednio skonfigurowane linki w panelach Grafany. Nie oznacza ono jednak, że każdy punkt wykresu wskazuje konkretny wpis w logach. Metryki zwykle agregują wiele zdarzeń, dlatego przejście metrics → logs najczęściej prowadzi do zbioru wpisów pasujących do usługi i czasu, a nie do pojedynczego żądania.

Exemplars: bezpośredni skrót z metryki do śladu

Exemplar to przykład pojedynczej obserwacji powiązanej z metryką, zawierający dodatkowy kontekst — najczęściej identyfikator śladu. Dzięki niemu można przejść z wykresu, na przykład przedstawiającego opóźnienia żądań, bezpośrednio do konkretnego trace’a w Tempo. Jest to alternatywna ścieżka metrics → traces, która nie wymaga wcześniejszego przeglądania logów.

Aby z niej korzystać, instrumentacja musi emitować exemplars, ścieżka zbierania metryk musi je obsługiwać, a źródło Prometheus w Grafanie powinno mieć skonfigurowane powiązanie z Tempo. Samo dodanie obu źródeł danych nie wystarczy. Exemplar nie jest również rejestrem wszystkich żądań ani gwarancją znalezienia śladu: wskazany trace musi zostać zachowany i nadal być dostępny w Tempo.

traceID i derived fields: połączenie logów ze śladami

Dokładniejsze powiązanie zapewnia traceID, czyli identyfikator wspólny dla spanów należących do jednego śladu. Jeżeli aplikacja zapisuje w logach identyfikator aktywnego trace’a, wpis z Lokiego można połączyć z przebiegiem tego samego żądania w Tempo. Warunkiem jest poprawna propagacja kontekstu śledzenia między usługami oraz dołączanie go do logów. Opcjonalny spanID pozwala dodatkowo wskazać konkretną operację wewnątrz śladu.

W źródle danych Loki w Grafanie służą do tego między innymi derived fields. Pozwalają rozpoznać wartość identyfikatora w logu i utworzyć na jej podstawie odsyłacz do Tempo. Nazwa pola może być różna, na przykład trace_id lub traceID; konfiguracja musi odpowiadać rzeczywistemu formatowi wpisów. Derived field nie generuje identyfikatora ani nie odtwarza brakującego śladu — wykorzystuje dane, które już istnieją.

Identyfikatora śladu nie należy traktować jak zwykłej etykiety indeksowanej w Lokim. Jego bardzo duża liczba unikalnych wartości powodowałaby wysoką kardynalność. Do korelacji lepiej przechowywać go w treści ustrukturyzowanego logu lub w obsługiwanych przez Loki metadanych strukturalnych.

Explore: wspólna przestrzeń do pracy z kontekstem

Explore w Grafanie umożliwia wykonywanie zapytań do różnych źródeł i korzystanie ze skonfigurowanych powiązań. Prometheus, Loki i Tempo nadal przechowują oraz przeszukują własne dane — Grafana zapewnia nawigację między nimi, a nie wspólną bazę wykonującą automatyczne złączenia.

Korelacja może działać również w odwrotnym kierunku. Funkcja trace to logs pozwala przejść ze śladu lub spanu do logów, wykorzystując mapowanie atrybutów, przedział czasu oraz, przy odpowiedniej konfiguracji, filtrowanie po identyfikatorze śladu. Dobre powiązanie przenosi nie tylko użytkownika do innego widoku, lecz także właściwy kontekst zapytania. To właśnie ogranicza ręczne kopiowanie identyfikatorów i ponowne szukanie tej samej usługi w kolejnych narzędziach.

Budowa wdrożenia krok po kroku: podstawowa konfiguracja Prometheus, Loki, Tempo i Grafany

Pierwsze wdrożenie powinno objąć jedną aplikację i pozwalać sprawdzić cały zestaw na rzeczywistych danych: odczytać jej metryki, znaleźć logi i otworzyć ślad pojedynczego żądania. Dopiero po takim teście warto dodawać kolejne usługi. Na szkoleniach Cognity pokazujemy, jak przejść przez taką konfigurację krok po kroku – poniżej przedstawiamy skrót tego procesu. To punkt wyjścia do lokalnego środowiska testowego, a nie gotowy szablon produkcyjny.

Krok 1. Przygotuj usługi, sieć i pliki konfiguracyjne

Do uruchomienia zestawu możesz wykorzystać Docker Compose. Zdefiniuj usługi prometheus, loki, tempo i grafana we wspólnej sieci. Przypnij konkretne wersje obrazów zamiast używać tagu latest, a składnię konfiguracji sprawdź w dokumentacji wybranych wydań.

Zamontuj pliki konfiguracyjne tylko do odczytu i wskaż je w argumentach uruchomieniowych odpowiednich usług. Dodaj osobne wolumeny na dane Prometheusa, Loki i Tempo oraz katalog /var/lib/grafana. Katalogi danych muszą być zapisywalne dla użytkowników działających wewnątrz kontenerów.

Adresy między kontenerami powinny używać nazw usług, nie localhost. Grafana połączy się więc z Prometheusem pod adresem http://prometheus:9090. Na hosta wystaw tylko potrzebne porty, najlepiej z przypisaniem do 127.0.0.1. Backendów telemetrycznych bez uwierzytelniania nie udostępniaj publicznie.

Krok 2. Skonfiguruj pobieranie metryk w Prometheusie

Najpierw włącz w aplikacji endpoint metryk zgodny z formatem obsługiwanym przez Prometheusa. W poniższym przykładzie aplikacja działa jako usługa app, nasłuchuje na porcie 8080 i udostępnia metryki pod ścieżką /metrics. Zastąp te wartości adresami swojego środowiska.

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: prometheus
    static_configs:
      - targets: ['prometheus:9090']

  - job_name: application
    metrics_path: /metrics
    static_configs:
      - targets: ['app:8080']

Po uruchomieniu Prometheusa otwórz widok Targets. Oba cele powinny mieć stan UP. Zapytanie up{job="application"} powinno zwrócić wartość 1. Jeśli tak nie jest, sprawdź dostępność endpointu z sieci kontenerowej, port aplikacji i ewentualne wymagania dotyczące autoryzacji. Samo działanie kontenera Prometheusa nie potwierdza jeszcze poprawnego zbierania danych.

Krok 3. Uruchom Loki i podłącz źródło logów

Do testów wystarczy Loki działający jako pojedynczy proces z lokalnym systemem plików. Przykładowa konfiguracja wykorzystuje indeks TSDB i schemat v13:

auth_enabled: false

server:
  http_listen_port: 3100

common:
  instance_addr: 127.0.0.1
  path_prefix: /loki
  replication_factor: 1
  ring:
    kvstore:
      store: inmemory
  storage:
    filesystem:
      chunks_directory: /loki/chunks
      rules_directory: /loki/rules

schema_config:
  configs:
    - from: 2024-01-01
      store: tsdb
      object_store: filesystem
      schema: v13
      index:
        prefix: index_
        period: 24h

Data from określa początek obowiązywania schematu i w nowej instalacji musi obejmować czas zapisywanych logów. Nie traktuj tego przykładu jako instrukcji zmiany schematu w istniejącym środowisku.

Loki sam nie odczyta plików aplikacji. Skonfiguruj ich zbieranie, na przykład za pomocą Grafana Alloy: komponent loki.source.file może czytać wskazane pliki i przekazywać wpisy do loki.write. Adresem wysyłki będzie http://loki:3100/loki/api/v1/push. Zapewnij collectorowi dostęp do plików oraz dodaj stabilne etykiety, np. service_name i environment. Identyfikatorów pojedynczych żądań nie dodawaj jako etykiet indeksowanych.

Krok 4. Włącz odbiór śladów w Tempo

W Tempo uruchom odbiorniki OTLP i wskaż lokalne katalogi danych. Port 3200 służy interfejsowi HTTP Tempo, natomiast 4317 i 4318 obsługują przyjmowanie telemetrii przez OTLP.

server:
  http_listen_port: 3200

distributor:
  receivers:
    otlp:
      protocols:
        grpc:
          endpoint: 0.0.0.0:4317
        http:
          endpoint: 0.0.0.0:4318

storage:
  trace:
    backend: local
    wal:
      path: /var/tempo/wal
    local:
      path: /var/tempo/blocks

Adres 0.0.0.0 umożliwia odbiór połączeń z innych kontenerów; nie oznacza konieczności publikowania tych portów w internecie. W aplikacji skonfiguruj instrumentację OpenTelemetry, nazwę usługi oraz eksporter śladów. Dla OTLP/gRPC wewnętrznym adresem odbiornika będzie tempo:4317; dla OTLP/HTTP pełny adres wysyłki śladów to http://tempo:4318/v1/traces. Sposób podania adresu zależy od używanego SDK i eksportera.

Na potrzeby pierwszego testu aplikacja może wysyłać ślady bezpośrednio do Tempo. Jeżeli korzystasz już z collectora, skieruj dane przez niego. Następnie wykonaj kilka żądań do aplikacji i sprawdź, czy eksporter nie zgłasza błędów połączenia.

Krok 5. Dodaj źródła danych w Grafanie

Po zalogowaniu do Grafany zmień domyślne dane dostępowe, a następnie dodaj trzy źródła danych. Użyj adresów osiągalnych z kontenera Grafany:

Dla każdego źródła wykonaj Save & test, a potem sprawdź dane w widoku Explore. Test połączenia potwierdza dostępność backendu, ale nie zastępuje weryfikacji zapisanej telemetrii. Ustaw zakres czasu obejmujący wygenerowany ruch. Przy automatyzowaniu wdrożenia przenieś definicje źródeł do plików provisioningu Grafany i nadaj im stałe identyfikatory uid.

Krok 6. Zbuduj pierwszy dashboard i sprawdź kompletność wdrożenia

Zacznij od niewielkiego dashboardu dla instrumentowanej aplikacji. Dodaj panel dostępności oparty na up{job="application"}, a następnie panele natężenia ruchu, błędów i czasu odpowiedzi — pod warunkiem że aplikacja rzeczywiście eksportuje odpowiednie liczniki i histogramy. Dopasuj zapytania do dostępnych nazw metryk i etykiet; nie zakładaj, że gotowy dashboard będzie zgodny z każdą biblioteką instrumentacyjną.

Dodaj także panel logów z Loki, filtrowany po usłudze. Zapisz dashboard w dedykowanym folderze i wyeksportuj jego definicję JSON do repozytorium konfiguracji. Na koniec wywołaj kontrolowane żądanie testowe: sprawdź zmianę metryk, obecność odpowiadającego mu wpisu w logach oraz dostępność śladu w Tempo. Taki test potwierdza, że wdrożenie nie tylko uruchamia cztery komponenty, lecz także dostarcza dane potrzebne do pracy z aplikacją.

5. Rekomendowana architektura dla małej i średniej organizacji: single-node vs HA, skalowanie i topologie wdrożenia

Architekturę stosu Grafana warto dobierać nie do liczby pracowników, lecz do skali telemetrii i skutków utraty dostępu do niej. Mały zespół utrzymujący usługę działającą całodobowo może potrzebować wysokiej dostępności bardziej niż większa organizacja, dla której kilkugodzinna przerwa w diagnostyce jest akceptowalna. Najważniejsze pytanie brzmi: czy system obserwowalności musi pozostać dostępny podczas awarii środowiska, które monitoruje? Jeśli tak, umieszczenie wszystkich jego komponentów na tym samym hoście lub w tym samym klastrze co aplikacje tworzy istotne wspólne ryzyko.

Single-node: dobry punkt startowy, ale ze świadomie przyjętym ryzykiem

Dla małej organizacji rozsądnym początkiem jest wydzielona maszyna wirtualna, na której działają Grafana, Prometheus oraz Loki i Tempo w trybach monolitycznych. Taka topologia ogranicza liczbę elementów do utrzymania, upraszcza aktualizacje i ułatwia oszacowanie zapotrzebowania na zasoby. Nie wymaga Kubernetes — kontenery zarządzane przez Docker Compose lub usługi systemowe mogą być wystarczające.

Warunkiem jest akceptacja pojedynczego punktu awarii. Awaria hosta oznacza utratę dostępu do całego zestawu narzędzi, a brak trwałych wolumenów może dodatkowo skutkować utratą danych. Potrzebne są więc trwałe przechowywanie danych, kopie konfiguracji i sprawdzona procedura odtworzenia. Backup umożliwia odbudowę systemu, ale nie zapewnia ciągłości jego działania.

Warto też rozróżnić dwa pojęcia: tryb monolityczny opisuje sposób uruchomienia komponentu, natomiast single-node — topologię infrastruktury. Loki może działać jako jeden proces na osobnej maszynie, a Prometheus i Grafana na kolejnych. Taki podział ogranicza konkurencję o CPU, pamięć i dysk, lecz sam w sobie nie zapewnia wysokiej dostępności poszczególnych usług.

Single-node czy HA — praktyczne kryteria wyboru

HA wymaga redundancji całej ścieżki, nie tylko Grafany

Dwie instancje Grafany za load balancerem zabezpieczają dostęp do interfejsu, ale nie wystarczą, jeśli obie korzystają z pojedynczego, niedostępnego źródła danych. W takim wdrożeniu Grafana powinna używać wspólnej bazy PostgreSQL lub MySQL zamiast lokalnego SQLite, a sama baza również wymaga odpowiedniej odporności na awarie. Konfiguracja i provisioning muszą pozostawać spójne między instancjami.

Dla Prometheusa typowym układem HA są dwie niezależne instancje zbierające metryki z tych samych celów. Nie współdzielą one katalogu danych ani nie replikują automatycznie swoich lokalnych baz. Jeśli potrzebny jest wspólny widok z deduplikacją, można rozszerzyć architekturę o Thanos albo przesyłać dane przez remote write do backendu takiego jak Grafana Mimir, z odpowiednio skonfigurowaną obsługą replik HA. Są to dodatkowe elementy architektury, a nie właściwości samego Prometheusa.

W przypadku Loki i Tempo odporność zależy od wybranego trybu wdrożenia, replikacji i redundancji usług uczestniczących w zapisie oraz odczycie. Magazyn obiektowy jest ważnym elementem architektur rozproszonych, ale jego obecność nie usuwa pojedynczych punktów awarii w warstwie przetwarzania. Repliki należy rozmieścić na różnych hostach, a jeśli wymagania obejmują awarię całej strefy — również w różnych strefach dostępności.

Rekomendowana ścieżka rozwoju

Dla małej organizacji: zacznij od wydzielonego hosta i prostych trybów uruchomienia, o ile przerwa w dostępie do telemetrii jest akceptowalna. Oddziel stos obserwowalności od hostów aplikacyjnych, aby restart lub przeciążenie aplikacji nie odbierały jednocześnie narzędzi diagnostycznych. Sama separacja hostów nie chroni jednak przed awarią wspólnej sieci lub lokalizacji.

Dla średniej organizacji: praktycznym wariantem jest osobne środowisko obserwowalności, redundantna Grafana i zbieranie metryk oraz Loki i Tempo skalowane zgodnie z rzeczywistym obciążeniem. Rozproszony tryb wdrożenia warto wybierać wtedy, gdy pojedyncze instancje stają się ograniczeniem albo wymaga tego dostępność. Nie każdy komponent musi przechodzić tę zmianę jednocześnie.

Skalowanie i HA rozwiązują różne problemy: większa maszyna może obsłużyć więcej danych, lecz nadal pozostaje pojedynczym punktem awarii. Z kolei dodatkowe repliki zwiększają odporność, ale nie zawsze zwiększają wydajność proporcjonalnie. O rozbudowie powinny decydować pomiary obciążenia, opóźnienia zapisu i zapytań oraz wymagany czas przywrócenia działania, a nie sam rozmiar organizacji.

Kubernetes ma sens przede wszystkim wtedy, gdy zespół już potrafi go utrzymywać. Osobny namespace w klastrze produkcyjnym daje separację logiczną, ale nie niezależność od awarii klastra. Jeśli organizacja potrzebuje wysokiej dostępności, a nie ma zasobów na utrzymanie rozproszonego backendu, warto rozważyć usługę zarządzaną lub model hybrydowy: lokalne zbieranie telemetrii i zewnętrzne przechowywanie oraz udostępnianie danych.

6. Scenariusze diagnostyki incydentów: od alertu w metrykach do logów i śladów

Alert o rosnącym czasie odpowiedzi wskazuje objaw, ale nie rozstrzyga, czy problem leży w aplikacji, bazie danych, czy zewnętrznym API. W diagnostyce metryki z Prometheusa pomagają określić skalę i moment wystąpienia problemu, logi w Loki dostarczają kontekstu zdarzeń, a ślady w Tempo pokazują przebieg konkretnych żądań. Grafana pozwala zestawić te informacje podczas jednej analizy. Poniższe scenariusze zakładają, że odpowiednia telemetria jest już zbierana, a źródła danych zostały skonfigurowane.

Scenariusz 1: wzrost opóźnień API bez wzrostu liczby błędów

Uruchamia się alert dotyczący wysokiego percentyla czasu odpowiedzi, na przykład p95. Użytkownicy nadal otrzymują poprawne odpowiedzi, ale część operacji trwa znacznie dłużej. Najpierw warto ustalić w metrykach, czy spowolnienie dotyczy całej usługi, konkretnego endpointu, czy tylko części instancji. Równolegle należy sprawdzić natężenie ruchu: wzrost opóźnień przy niezmienionej liczbie żądań sugeruje inny kierunek analizy niż przeciążenie po nagłym skoku ruchu.

W Loki zawężamy wyszukiwanie do tej samej usługi i przedziału czasu. Szukamy ostrzeżeń o przekroczonych czasach oczekiwania, ponowieniach wywołań lub problemach z uzyskaniem połączenia z bazą. Jeżeli log zawiera identyfikator śladu, można przejść do odpowiadającego mu żądania w Tempo. Przy dostępnych exemplarach punktem wejścia do śladu może być również wykres metryki.

W śladzie sprawdzamy, który fragment operacji wydłuża odpowiedź. Długi span wywołania bazy zawęża obszar poszukiwań, ale sam nie dowodzi, że przyczyną jest wolne zapytanie SQL — zależnie od instrumentacji może obejmować także oczekiwanie na połączenie. Hipotezę należy potwierdzić dodatkowymi danymi, na przykład metrykami puli połączeń i logami bazy, oraz porównaniem ze śladem poprawnie działającego żądania.

Scenariusz 2: wzrost błędów HTTP 5xx po wdrożeniu

Po publikacji nowej wersji rośnie udział odpowiedzi 5xx. W Prometheusie sprawdzamy zarówno proporcję błędów, jak i liczbę żądań: kilka nieudanych wywołań przy niewielkim ruchu może dać wysoki odsetek, lecz mieć ograniczony zasięg. Jeśli telemetria pozwala rozróżniać wersje aplikacji, porównujemy nową i poprzednią wersję oraz ustalamy, które operacje zawodzą.

Logi w Loki mogą ujawnić powtarzający się wyjątek, brak wymaganej konfiguracji albo odrzucenie połączenia przez zależną usługę. Wybieramy reprezentatywny błąd i analizujemy jego ślad w Tempo. Pozwala to sprawdzić, czy żądanie zakończyło się błędem wewnątrz aplikacji, czy dopiero po nieudanym wywołaniu kolejnego komponentu.

Przykładowa hipoteza to niezgodność nowej wersji z formatem odpowiedzi zależnego API. Potwierdzeniem byłoby zestawienie logu błędu parsowania z odpowiednim fragmentem śladu oraz brak analogicznego problemu w poprzedniej wersji. Zbieżność incydentu z wdrożeniem jest wskazówką, nie dowodem przyczyny. Po wycofaniu zmiany lub wdrożeniu poprawki trzeba zweryfikować spadek błędów przy porównywalnym ruchu.

Scenariusz 3: sporadyczne timeouty wywołań zewnętrznej usługi

Średni czas odpowiedzi wygląda prawidłowo, ale alert sygnalizuje wzrost liczby timeoutów lub pogorszenie wysokich percentyli. Metryki pomagają ustalić, czy problem dotyczy operacji korzystających z jednej zależności. W logach szukamy komunikatów o timeoutach i kolejnych próbach, a w śladach — czasu poszczególnych wywołań oraz ich wpływu na całe żądanie.

Jeżeli ponowienia są widoczne w instrumentacji, ślad może pokazać, że kilka następujących po sobie prób wyczerpuje budżet czasowy operacji. To uzasadnia sprawdzenie ustawień timeoutów i retry, zamiast automatycznego zwiększania liczby instancji aplikacji. Sam timeout nie przesądza jednak o awarii dostawcy: podobny efekt mogą powodować problemy sieciowe lub wyczerpanie lokalnej puli połączeń.

W każdym z tych scenariuszy należy zachować wspólny zakres czasu i kontekst usługi. Warto też analizować kilka żądań, nie tylko pojedynczy ślad. Brak śladu nie oznacza braku problemu — może wynikać z samplingu lub luk w instrumentacji. Diagnozę uznajemy za potwierdzoną dopiero wtedy, gdy zebrane dane wspierają hipotezę, a podjęte działanie usuwa obserwowany objaw.

7. Retencja, koszty i wydajność: jak utrzymać obserwowalność pod kontrolą

Koszt obserwowalności zależy nie tylko od liczby przechowywanych gigabajtów. Obejmuje również przyjmowanie i przetwarzanie danych, indeksy, zasoby potrzebne do zapytań oraz operacje i transfer w magazynie obiektowym. Najskuteczniejsza optymalizacja zaczyna się przed zapisem danych: od decyzji, które sygnały są potrzebne, z jaką szczegółowością i przez jaki czas.

Retencja dopasowana do wartości danych

Metryki, logi i ślady nie muszą mieć jednakowego okresu przechowywania. Metryki zagregowane są przydatne do analizy trendów, sezonowości i planowania pojemności. Szczegółowe logi aplikacyjne oraz ślady rozproszone często mają największą wartość podczas diagnozowania bieżących problemów. Logi audytowe mogą natomiast wymagać osobnej polityki, wynikającej z obowiązków prawnych lub zasad bezpieczeństwa.

Warto ustalać retencję według przeznaczenia danych, środowiska i krytyczności usługi. Dane diagnostyczne ze środowiska testowego zwykle nie uzasadniają takich samych kosztów jak materiał potrzebny do wyjaśnienia incydentu produkcyjnego. Punktem odniesienia powinien być również czas wykrywania problemów: jeśli nieprawidłowości wychodzą na jaw dopiero przy miesięcznym rozliczeniu, kilkudniowa historia może być niewystarczająca.

W lokalnym magazynie TSDB Prometheusa można ograniczyć retencję czasem i rozmiarem; przy ustawieniu obu ograniczeń usuwanie danych następuje po osiągnięciu któregokolwiek z nich. Limit rozmiaru trzeba pozostawić poniżej pojemności dysku, z zapasem między innymi na WAL i bieżące operacje. W Loki i Tempo retencję danych w magazynie obiektowym egzekwują mechanizmy backendów, w tym compactory. Usunięcie danych nie musi następować dokładnie w chwili przekroczenia okresu retencji, dlatego plan pojemności powinien uwzględniać opóźnienia sprzątania.

Przechowywanie, kompresja i tiering

Prometheus przechowuje lokalne dane szeregów czasowych w skompresowanych blokach TSDB. Loki i Tempo również wykorzystują formaty oraz mechanizmy kompresji ograniczające objętość zapisu. Nie eliminuje to jednak kosztów nadmiarowej telemetrii: duży strumień danych nadal wymaga przepustowości, pamięci i czasu procesora. Wybór mocniejszej kompresji, tam gdzie jest konfigurowalny, warto oceniać pomiarem kosztu zapisu i odczytu, a nie wyłącznie rozmiarem plików.

Magazyn obiektowy dobrze nadaje się do przechowywania bloków Loki i Tempo, ale nie zastępuje bezpośrednio lokalnego dysku Prometheusa. Długoterminowe przechowywanie jego metryk wymaga dodatkowego rozwiązania, na przykład Grafana Mimir lub Thanos. Sama Grafana nie wydłuża historii dostępnej w źródłach danych.

Tiering, czyli przenoszenie starszych danych do tańszych klas przechowywania, ma sens tylko wtedy, gdy pozostaje zgodny ze sposobem odczytu i usuwania danych przez backend. Klasy archiwalne mogą wymagać odtworzenia obiektów przed odczytem, generować dodatkowe opłaty i uniemożliwiać szybkie zapytania. Reguły lifecycle nie powinny też usuwać obiektów wcześniej, niż przewiduje polityka backendu. Archiwum nie jest automatycznie przeszukiwalną historią ani kopią zapasową.

Ograniczanie danych bez utraty użyteczności

W Prometheusie szczególnej kontroli wymaga kardynalność: każda unikalna kombinacja etykiet tworzy osobny szereg czasowy. Identyfikatory użytkowników, żądań czy pełne adresy URL z parametrami mogą gwałtownie zwiększyć ich liczbę. Koszt ograniczają usuwanie zbędnych metryk, rozsądny dobór etykiet i dopasowanie interwału zbierania do dynamiki zjawiska. Trzeba również kontrolować liczbę przedziałów klasycznych histogramów.

W Loki podobny problem powodują etykiety o wysokiej kardynalności. Szczegółowe identyfikatory lepiej pozostawić w treści logu lub odpowiednio wykorzystać metadane strukturalne. Ograniczenie logowania debug na produkcji, eliminacja powtarzalnych komunikatów i filtrowanie niepotrzebnych wpisów przed wysyłką zazwyczaj przynoszą większą oszczędność niż samo skrócenie retencji.

W przypadku Tempo podstawowym narzędziem kontroli wolumenu jest sampling śladów przed ich zapisaniem. Sampling podejmowany na początku obsługi żądania jest prostszy, lecz może pominąć rzadkie błędy. Sampling po zebraniu śladu pozwala uwzględnić jego wynik lub czas trwania, ale wymaga buforowania i dodatkowych zasobów. Polityka powinna zachowywać materiał potrzebny do diagnozy, a nie tylko realizować założony procent redukcji.

Limity i wydajność zapytań

Limity tempa przyjmowania danych, aktywnych serii, strumieni logów oraz równoległych zapytań chronią system przed przeciążeniem. Ich przekroczenie może jednak skutkować odrzucaniem telemetrii. Należy więc monitorować zarówno wykorzystanie limitów, jak i odrzucone dane — inaczej oszczędność zasobów może oznaczać niewidoczną lukę diagnostyczną.

Po stronie odczytu pomagają krótsze zakresy czasu, selektywne filtry i częstotliwość odświeżania dashboardów dopasowana do potrzeb. Reguły nagrywania Prometheusa mogą przyspieszyć powtarzalne obliczenia, lecz tworzą dodatkowe szeregi i same nie zmniejszają ilości surowych danych. Cache ogranicza część powtarzanych odczytów, ale również zużywa zasoby. Skuteczność zmian warto oceniać łącznie: przez koszt, czas odpowiedzi zapytań, ilość odrzucanej telemetrii i możliwość odtworzenia przebiegu rzeczywistego incydentu.

Dobre praktyki operacyjne: etykiety i cardinality, sampling, standaryzacja, alerting, RBAC i kontrola dostępu

Sprawny stos Grafana wymaga wspólnych zasad: jakie dane zbieramy, jak opisujemy usługi, kiedy powiadamiamy dyżurnych i kto może odczytywać telemetrię. Bez tych ustaleń nawet poprawnie skonfigurowane narzędzia szybko wypełniają się niespójnymi etykietami, hałaśliwymi alertami i danymi, które nie powinny być dostępne dla wszystkich użytkowników.

Etykiety: opisuj usługę, nie pojedyncze żądanie

Kardynalność oznacza liczbę unikalnych wartości lub ich kombinacji. W Prometheusie każda unikalna kombinacja nazwy metryki i etykiet tworzy osobną serię czasową. W Loki zestaw etykiet wyznacza strumień logów. Dlatego identyfikator użytkownika, identyfikator żądania czy pełny adres URL z parametrami nie powinny trafiać do etykiet metryk ani etykiet strumieni Loki.

Wybieraj wymiary o kontrolowanej liczbie wartości, takie jak usługa, środowisko, region czy metoda HTTP. Zamiast rzeczywistej ścieżki zawierającej identyfikator zamówienia stosuj szablon trasy. Szczegóły pojedynczego zdarzenia zachowuj w treści logu, metadanych strukturalnych Loki lub atrybutach śladu — zależnie od rodzaju danych i potrzeb diagnostycznych. Nie oznacza to jednak, że można tam bez ograniczeń zapisywać informacje wrażliwe.

Ustal przegląd nowych etykiet przed wdrożeniem instrumentacji. Właściciel usługi powinien umieć uzasadnić, do jakiego zapytania lub alertu potrzebny jest dany wymiar. Monitoruj również przyrost liczby serii i strumieni, aby wychwycić niekontrolowaną zmianę po aktualizacji aplikacji.

Sampling: świadomie wybieraj, które ślady zachować

Próbkowanie dotyczy przede wszystkim śladów rozproszonych. Head sampling podejmuje decyzję na początku obsługi żądania i ogranicza narzut już podczas instrumentacji. Nie zna jednak końcowego wyniku operacji. Tail sampling ocenia zebrany ślad później, dzięki czemu może preferować błędy lub wysokie opóźnienia, ale wymaga buforowania oraz odpowiedniej organizacji przetwarzania.

Politykę próbkowania dopasuj do krytyczności usługi i ruchu. Zachowuj reprezentatywną próbkę poprawnych żądań, a dla problematycznych operacji ustal odrębne reguły. Pamiętaj, że tail sampling nie odzyska śladów odrzuconych wcześniej przez head sampling. Metryki używane do oceny dostępności i alertowania najlepiej zbierać niezależnie od próbkowania śladów; statystyki wyliczane wyłącznie z zachowanych trace’ów mogą być obciążone błędem selekcji.

Standaryzacja: jeden słownik telemetrii

Wprowadź wspólny zestaw informacji opisujących usługę: nazwę, środowisko, wersję wdrożenia i właściciela. Konwencje semantyczne OpenTelemetry są dobrym punktem odniesienia, ale trzeba też ustalić mapowanie nazw między sygnałami i backendami. Standaryzacja nie wymaga kopiowania wszystkich atrybutów do wszystkich etykiet.

Uzgodnij ponadto jednostki metryk, poziomy logowania, format znaczników czasu i zasady rejestrowania wyjątków. Instrumentację oraz konfigurację obserwowalności traktuj jak kod: wersjonuj je, poddawaj przeglądom i sprawdzaj po zmianach. Usuń lub maskuj sekrety oraz zbędne dane osobowe przed wysłaniem telemetrii do centralnego systemu.

Wdrożenie tych zasad wymaga współpracy osób odpowiedzialnych za aplikacje, infrastrukturę i bezpieczeństwo. W Cognity uczymy, jak skutecznie radzić sobie z podobnymi wyzwaniami — zarówno indywidualnie, jak i zespołowo.

Alerting: powiadomienie musi prowadzić do działania

Alert wymagający reakcji dyżurnego powinien wskazywać problem, na który można odpowiedzieć konkretnym działaniem. Priorytetem są objawy odczuwane przez użytkowników, takie jak wzrost błędów, opóźnień lub tempo zużywania budżetu błędów SLO. Sygnały infrastrukturalne również są potrzebne, lecz nie każdy skok wykorzystania zasobów wymaga natychmiastowego wezwania.

Każda reguła powinna mieć właściciela, poziom ważności, właściwego odbiorcę i odnośnik do procedury postępowania. Stosuj grupowanie powiadomień, wyciszenia serwisowe oraz odpowiedni czas utrzymywania się warunku. Osobno określ zachowanie przy braku danych i błędzie zapytania — brak telemetrii nie jest dowodem poprawnego działania. Regularnie testuj całą drogę od reguły do dostarczenia powiadomienia.

RBAC i dostęp: dashboard nie jest granicą bezpieczeństwa

Przydzielaj uprawnienia zgodnie z zasadą najmniejszych przywilejów. Oddziel odczyt danych od edycji dashboardów, zarządzania alertami i administracji źródłami danych. Korzystaj z centralnego uwierzytelniania, grup użytkowników oraz osobnych kont serwisowych dla automatyzacji; okresowo przeglądaj dostęp i unieważniaj nieużywane tokeny.

Uprawnienia do folderu lub dashboardu nie zastępują kontroli dostępu do danych źródłowych. Zakres RBAC i uprawnień do źródeł danych zależy od edycji Grafany. Wymaganą izolację zespołów lub tenantów trzeba egzekwować również na poziomie backendów i warstwy pośredniczącej. Loki i Tempo nie zapewniają wbudowanej warstwy uwierzytelniania, dlatego ich endpointy należy odpowiednio zabezpieczyć. W konfiguracji wielodostępnej to zaufana warstwa powinna ustalać tożsamość tenanta, a nie dowolny nagłówek przesłany przez klienta.

Grafana i Prometheus w firmie – 10 praktycznych zastosowań monitorowania danych w czasie rzeczywistym 24 listopada 2026

Alerty w Grafanie i Prometheusie – jak automatycznie wykrywać awarie i problemy z wydajnością? 22 listopada 2026