Observability to zdolność systemu do odpowiadania na pytania o własny stan bez dokładania nowego kodu — oparta na trzech sygnałach telemetrycznych: logach, metrykach i trace’ach. Nie jest nazwą narzędzia ani zamiennikiem monitoringu; rozstrzyga, czy po awarii da się dojść do przyczyny, zamiast zgadywać na podstawie dashboardu. Różnica jest praktyczna, nie terminologiczna.
Na skróty
Czego dowiesz się z artykułu:
- Jakie pytanie rozstrzyga każdy z trzech sygnałów i czego żaden z nich nie zastąpi
- Kiedy warto dołożyć trace’y, a kiedy wystarczą metryki i logi
- Jak retencja i próbkowanie decydują o rachunku za obserwowalność
- Od czego zacząć, jeśli w organizacji nie ma jeszcze żadnego spójnego stacku
Dla kogo jest ten artykuł:
- Inżynierowie DevOps i SRE wdrażający obserwowalność od zera
- Zespoły platform engineering budujące wspólny stack dla wielu zespołów
- Administratorzy przechodzący z rozproszonych narzędzi na jedno rozwiązanie
Czas czytania: 6 minut
Trzy sygnały i to, co każdy z nich rozstrzyga
Metryki to liczby agregowane w czasie: liczba żądań, opóźnienie, zużycie pamięci, długość kolejki. Odpowiadają na pytanie „czy jest źle” — i robią to tanio, bo agregacja redukuje objętość danych niezależnie od ruchu. Nie powiedzą jednak, dlaczego jest źle: wykres opóźnienia, który skacze, pokazuje objaw i nic więcej.
Logi to zdarzenia z kontekstem — zapis tego, co konkretnie stało się w danym momencie w danym procesie. Odpowiadają na pytanie „co się stało”. Ich siłą jest szczegół, a słabością koszt: objętość logów rośnie wprost z ruchem, a wyszukiwanie po pełnym tekście jest najdroższą operacją w całym stosie.
Trace’y opisują pojedyncze żądanie w drodze przez wiele usług — każdy odcinek tej drogi jako osobny span z własnym czasem i rodzicem. Odpowiadają na pytanie „gdzie to się stało”. W architekturze rozproszonej to jedyny sygnał, który pokazuje, że z dwustu milisekund opóźnienia sto osiemdziesiąt zjada jedno wywołanie trzy warstwy niżej.
Dokumentacja projektu OpenTelemetry (opentelemetry.io) nazywa te trzy sygnały pierwotnymi i podkreśla rzecz, którą w praktyce łatwo przegapić: wartość pojawia się dopiero przy korelacji. Metryka bez możliwości zejścia do trace’u, a trace’u do logów konkretnego spanu, zostawia inżyniera w tym samym miejscu, w którym był z samym monitoringiem.
Kiedy który sygnał płaci za siebie
Kolejność wdrożenia nie jest kwestią gustu. Metryki wchodzą pierwsze, bo bez nich nie ma na czym oprzeć alertowania ani budżetu błędu — a to one, zgodnie z podręcznikiem Google SRE (sre.google), rozstrzygają, kiedy w ogóle wypada kogoś budzić. Logi są zwykle już obecne, tylko rozproszone; porządkowanie ich polega częściej na ujednoliceniu formatu i identyfikatorów niż na dołożeniu nowego narzędzia.
Trace’y są inwestycją o innym profilu. Wymagają instrumentacji kodu albo automatycznego agenta, propagacji kontekstu przez każdą granicę usługi i dyscypliny przy nazewnictwie spanów. Zwracają się tam, gdzie żądanie przechodzi przez kilka niezależnie wdrażanych komponentów. W monolicie z jedną bazą danych ten sam wysiłek przyniesie znacznie mniej niż poprawienie logowania zapytań.
Praktyczna reguła: jeśli na pytanie „która usługa spowolniła” potrafisz odpowiedzieć bez trace’ów w ciągu kilku minut, trace’y nie są Twoim najpilniejszym brakiem. Jeśli odpowiedź wymaga telekonferencji trzech zespołów — są.
Jest też warunek wstępny, który bywa pomijany, a bez niego żaden z trzech sygnałów nie skorelowuje się z pozostałymi: wspólny identyfikator żądania przenoszony przez wszystkie warstwy i wpisywany do każdego logu. Dołożenie go kosztuje jeden nagłówek i jedno pole w formacie logu, a bez niego przejście z metryki do konkretnego logu pozostaje ręcznym dopasowywaniem znaczników czasu. To najtańsza pojedyncza zmiana, jaką można zrobić przed wyborem jakiegokolwiek narzędzia.
Retencja, próbkowanie i rachunek za obserwowalność
Największe zaskoczenie przy wdrożeniach obserwowalności to nie trudność techniczna, a rachunek. Mechanizm jest prosty: koszt rośnie z iloczynu objętości sygnału i czasu jego przechowywania, a oba te czynniki łatwo ustawić domyślnie na „maksimum” i o tym zapomnieć.
Trzy decyzje, które warto podjąć świadomie na starcie:
- Różne okresy retencji dla różnych sygnałów. Zagregowane metryki warto trzymać długo, bo są tanie i służą do porównań rok do roku. Surowe logi debugowe rzadko są przydatne po tygodniu. Jeden wspólny okres dla wszystkiego jest najdroższym z możliwych wyborów.
- Próbkowanie trace’ów, ale nie wyłącznie losowe. Próbkowanie ogonowe — decyzja o zachowaniu trace’u podjęta po jego zakończeniu, na podstawie błędu lub wysokiego opóźnienia — zachowuje przypadki, które rzeczywiście wymagają analizy, i odrzuca te nudne. Losowy jeden procent działa odwrotnie: najczęściej gubi dokładnie te żądania, których szukasz.
- Kardynalność etykiet jako limit, nie jako szczegół. Etykieta z identyfikatorem użytkownika albo żądania w metryce tworzy osobny szereg czasowy dla każdej wartości. To najszybsza znana droga do przewrócenia bazy metryk i jednocześnie najczęstszy błąd pierwszego miesiąca.
Czwarta decyzja jest organizacyjna: ustalenie, kto płaci. Dopóki koszt telemetrii jest kosztem wspólnym, nikt nie ma powodu ograniczać własnego logowania.
Czytaj także
- Od monitoringu do observability: kompletny przewodnik po Serilog, ELK i Grafana — ta sama droga opisana od strony konkretnych narzędzi i konfiguracji
- AIOps — jak AI zmienia monitoring i operacje IT — co da się zrobić z zebraną telemetrią, gdy sygnałów jest już więcej, niż człowiek przeczyta
- Budowa pipeline CI/CD od podstaw: co się zmienia w 2026 — kontekst dla zespołów, które obserwowalność wdrażają razem z automatyzacją wdrożeń
Rozwijaj kompetencje
Temat łączy się ze szkoleniami Observability Stack — Grafana, Prometheus, Loki, Tempo oraz Obserwowalność systemów i inżynieria niezawodności. Sprawdź program i skontaktuj się z nami, żeby dopasować zakres do stanu Twojego środowiska.
Najczęściej zadawane pytania (FAQ)
Czym observability różni się od monitoringu?
Monitoring sprawdza z góry ustalone warunki i mówi, czy są spełnione. Obserwowalność pozwala zadać systemowi pytanie, którego nie przewidziano przy projektowaniu dashboardów. W praktyce monitoring wykrywa znane tryby awarii, a obserwowalność służy do rozbrajania nieznanych.
Czy można zacząć od trace’ów, pomijając metryki?
Można technicznie, ale to zwykle zły wybór kolejności. Bez metryk nie ma na czym oprzeć alertowania, więc trace’y zbierają się dla awarii, o których nikt nie wie na czas. Metryki wskazują, kiedy i gdzie warto w ogóle zajrzeć w trace.
Ile danych trzeba przechowywać?
Tyle, ile potrzeba do odpowiedzenia na pytania, które naprawdę zadajecie po incydencie. Warto to sprawdzić empirycznie: przejrzyjcie kilka ostatnich analiz poincydentalnych i sprawdźcie, jak stare dane były w nich faktycznie potrzebne. Zwykle okres okazuje się krótszy od ustawionego domyślnie.
Czy OpenTelemetry zastępuje dotychczasowe narzędzia?
Nie zastępuje backendów do przechowywania i analizy — standaryzuje sposób zbierania i przesyłania sygnałów. Dzięki temu zmiana dostawcy przestaje oznaczać ponowną instrumentację aplikacji, co jest głównym argumentem za wdrażaniem go od początku, a nie po pierwszej migracji.