Co to jest observability? Praktyczny przewodnik dla zespołów

Jest 2 w nocy. Endpoint checkout zwraca błędy 500 dla mniej więcej jednego żądania na dwadzieścia, a wszystkie dashboardy są zielone. Ta luka między tym, co mówi system ("wszystko działa"), a tym, co mówią użytkownicy ("nie działa"), to dokładnie to, co observability ma zamykać. Co to jest observability? To zdolność zrozumienia tego, co system robi wewnętrznie, na podstawie danych, które emituje: logów, metryk i traces. Ma to być na tyle dobre, by odpowiedzieć na pytania, których nie zaplanowano z wyprzedzeniem.

Ostatnia część tego zdania to cała istota. Reszta artykułu to szczegóły.

Observability a monitoring: pytanie, na które nie napisano alertu

Monitoring odpowiada na pytania, które już znamy. Obciążenie CPU powyżej 90%? Odsetek błędów powyżej 2%? Rosnąca kolejka? Wybierasz metryki, ustawiasz progi i alarm się uruchamia, gdy któryś zostanie przekroczony.

Observability odpowiada na pytanie, którego nie znaliśmy. Dlaczego tylko żądania jednego klienta, na jednej wersji aplikacji, po konkretnym deployu, trwają cztery sekundy dłużej? Nikt nie ma na to alertu, bo nikt tego nie przewidział.

Oba podejścia nie są więc rywalami. Monitoring to warstwa alertów. Observability pozwala badać problem, gdy alert się uruchomi albo gdy klient napisze, a żaden alert nie zadziałał. Jeśli jedynym narzędziem jest ściana gotowych dashboardów, masz monitoring. Jeśli możesz dzielić dane produkcyjne według dowolnego wymiaru i prześledzić jedno żądanie przez wiele usług bez wdrażania nowego kodu, masz observability.

Trzy sygnały: metryki, logi i traces

Większość definicji zaczyna się od "trzech filarów". Ta etykieta brzmi trochę sztywno, ale trzy typy danych są realne i każdy dobrze radzi sobie z inną funkcją.

• Metryki to liczby w czasie: liczba żądań na sekundę, latencja p95, zużycie pamięci. Tanie w przechowywaniu, szybkie w zapytaniach, świetne do pytania "czy coś jest nie tak?". Słabe w odpowiedzi na pytanie "które żądanie i dlaczego?".

• Logi to znaczniki czasu zapisane dla pojedynczych zdarzeń: płatność nie przeszła, uruchomiono ponowienie, flaga funkcji została przełączona. Niosą szczegóły, ale nieustrukturyzowane logi na obciążonej usłudze szybko stają się stogiem siana.

• Traces śledzą pojedyncze żądanie, gdy przechodzi przez usługi. Każdy przeskok to span z czasem startu, czasem trwania i atrybutami. Trace to najbliższa rzecz do stack trace'u w systemie rozproszonym.

Ankieta Grafana z 2025 roku, w której wzięło udział 1255 praktyków, pokazuje, gdzie zespoły faktycznie są. Ankieta Grafana o observability wykazała, że 95% respondentów korzysta z metryk, a 87% z logów, ale tylko 57% z traces. Traces to sygnał najbardziej pomocny przy rozproszonych błędach, a zarazem ten, który najmniej zespołów ma skonfigurowany.

Warto pominąć skrót mówiący, że metryki pokazują co, logi dlaczego, a traces gdzie. Brzmi to ładnie, ale w praktyce zawodzi: dobry, ustrukturyzowany log często mówi więcej o "gdzie" niż źle zainstrumentowany trace.

Co sprawia, że system jest obserwowalny w praktyce

Emitowanie danych jest konieczne, ale nie wystarcza. System jest obserwowalny, gdy dane mają trzy cechy.

Wysoka kardynalność. Możesz filtrować po ID użytkownika, kliencie, SHA builda, regionie i fladze funkcji. Jeśli narzędzie zmusza cię do agregowania wstępnie po nazwie usługi i kodzie statusu, nie znajdziesz jednego klienta w złym stanie.

Kontekst łączący sygnały. ID trace'u w każdej linii logu pozwala przejść od wolnego spanu do dokładnych logów, które on wygenerował. Bez tego połączenia czytasz dwie osobne historie i zgadujesz, jak się łączą.

Dość szczegółów, by były użyteczne, ale nie tyle, by były nie do opłacenia. Tu większość zespołów ma problem. W tej samej ankiecie Grafana respondenci wymienili ponad 100 różnych narzędzi, usług i projektów, a średni zespół korzystał z ośmiu. Koszt był jednym z najważniejszych kryteriów wyboru. Zbieranie wszystkiego jest łatwe. Płacenie za to to część, którą ludzie odkrywają później.

Punkt startowy z OpenTelemetry, neutralnym dostawcowo standardem instrumentacji, wygląda tak. To minimalny przykład w Pythonie, który tworzy span i dołącza atrybuty, których będziesz potrzebować o 2 w nocy:

from opentelemetry import trace

tracer = trace.get_tracer("checkout")

def charge(order):
    with tracer.start_as_current_span("charge_card") as span:
        span.set_attribute("order.id", order.id)
        span.set_attribute("tenant.id", order.tenant_id)
        span.set_attribute("app.version", APP_VERSION)
        result = payment_client.charge(order)
        span.set_attribute("payment.provider", result.provider)
        return result

Te trzy atrybuty decydują o tym, czy masz "checkout jest wolny", czy "checkout jest wolny dla klienta 4412 w wersji 3.8.1". Primer OpenTelemetry wyjaśnia te koncepcje dokładniej i warto go przeczytać choć raz, nawet jeśli dostawca robi za ciebie całe podłączenie.

Czym różnią się narzędzia observability (i czym nie)

Pod marketingiem większość platform przyjmuje te same trzy sygnały. Różnią się modelem cenowym, mocą zapytań i tym, ile instrumentacji wykonują za ciebie.

• Platformy all-in-one łączą metryki, logi, traces, alerty i więcej. Są wygodne, ale rachunki naliczane za użycie rosną razem z ruchem.

• Stosy open source, takie jak Prometheus, Loki, Tempo i Grafana, dają kontrolę i brak licencji za host, kosztem samodzielnego uruchamiania i strojenia.

• Backendy natywne dla OpenTelemetry przyjmują standardowy format bezpośrednio, więc zmiana dostawcy nie oznacza ponownej instrumentacji każdej usługi.

Datadog to punkt odniesienia w kategorii all-in-one: szerokie pokrycie, dopracowany interfejs i rachunek, który warto przeglądać co miesiąc. Warto, jeśli chcesz jednego dostawcy i masz budżet. Pomiń go, jeśli kluczowa jest przewidywalność kosztów.

Grafana to pragmatyczny wybór open source. Możesz zacząć od dashboardów nad danymi, które już masz, a potem dołożyć logi i traces. Trzeba jednak zainwestować trochę czasu inżynierskiego.

SigNoz jest zbudowany wokół OpenTelemetry od początku i zestawia metryki, logi i traces w jednym interfejsie open source. To rozsądny wybór dla zespołu, który chce widoku w jednym miejscu bez ceny all-in-one.

New Relic leży między tymi światami: hostowana platforma z darmowym planem, który jest na tyle hojny, by przeprowadzić prawdziwą ocenę. Oceń go według tego, czy twój zespół potrafi odpowiedzieć w nim na prawdziwe pytanie produkcyjne, a nie według dema.

Żadne z nich nie uczyni systemu obserwowalnym samo z siebie. Narzędzie to interfejs zapytań, a produktem jest instrumentacja.

Część, którą pomija większość poradników: observability kończy się na granicy kodu

Oto luka, którą zauważysz przy pierwszym poważnym użyciu takiego narzędzia. Trace mówi, że charge_card trwało 3,9 sekundy i że wolna była część wywołująca payment_client. Nie mówi, co tak naprawdę robi payment_client, kto go napisał ani dlaczego ponawia próbę trzy razy bez żadnego backoffu.

Po to wychodzisz z narzędzia observability i idziesz czytać kod. W małej usłudze zajmuje to dziesięć minut. W repozytorium liczącym 100 tysięcy linii, za które odpowiada czterech zespołów, czytanie bywa najdłuższą częścią incydentu. Wiesz dokładnie, który span jest wolny, a mimo to tracisz godzinę na ustalenie, jak połączony jest kod za nim.

To problem przekazania między danymi z runtime a kodem źródłowym i dlatego myślimy o observability oraz rozumieniu kodu jak o dwóch połowach jednego procesu:

1. Observability mówi gdzie w runtime: która usługa, który span, który klient.

2. Rozumienie kodu mówi dlaczego w źródłach: która funkcja, jaka polityka ponowień, jaka konfiguracja.

Zespoły, które domykają tę pętlę (nazwa spanu wskazuje plik, plik wskazuje właściciela i wyjaśnienie), skracają czas między "alert się uruchomił" a "rozumiemy poprawkę". To w dużej mierze kwestia dyscypliny. Nazywaj spany od funkcji, wpisuj ścieżkę repo w atrybut spanu i prowadź krótką notatkę architektoniczną dla każdej usługi. Asystent AI, który odpowie na pytanie "gdzie ustawiona jest polityka ponowień dla płatności?", ma wtedy konkretny punkt zaczepienia.

Trzy błędy, przez które zespoły uznają, że observability nie działa

Traktowanie dashboardów jako celu. Dashboard to zapisana odpowiedź na stare pytanie. Zespoły, które budują czterdzieści dashboardów i nigdy nie ćwiczą ad hoc zapytań, kończą z monitoringiem w ładniejszym opakowaniu. Na każdym incydencie pytaj: odpowiedzieliśmy z dashboardu, czy przez eksplorację surowych danych?

Zbyt wczesne albo nigdy niestosowane próbkowanie. Trzymanie 100% traces na obciążonej usłudze szybko staje się drogie, a losowe zachowanie 1% wyrzuca rzadkie, błędne żądanie, na którym ci zależy. Częstym kompromisem jest próbkowanie ogonowe (tail-based sampling): zachowuje wolne i błędne traces, a większość zdrowych odrzuca. Ustal to przed pierwszą fakturą, a nie po niej.

Dryf nazw atrybutów. Jedna usługa zapisuje user_id, inna userId, trzecia uid. Zapytanie, które ma objąć wszystkie trzy, zwraca jedną trzecią obrazu. Uzgodnij krótką konwencję nazw dla atrybutów klienta, użytkownika, wersji i flag i zapisz ją w repozytorium, gdzie ludzie ją znajdą.

Żadnego z tych problemów nie rozwiąże narzędzie. To nawyki, a nawyki naprawia się taniej niż zmienia dostawcę.

Realistyczny sposób startu bez gotowania oceanu

Jeśli dziś nie masz nic, nie próbuj instrumentować wszystkiego w pierwszym tygodniu. Sekwencja, która działa w zespołach od 5 do 50 inżynierów, wygląda tak:

1. Wybierz jeden krytyczny przepływ użytkownika. Checkout, rejestrację albo główne wywołanie API, a nie cały system.

2. Dodaj ustrukturyzowane logi z ID żądania. JSON, jedno zdarzenie w linii, ID trace'u lub żądania w każdej linii.

3. Zainstrumentuj ten przepływ trace'ami OpenTelemetry. Dołącz atrybuty klienta, wersji i flag z przykładu powyżej.

4. Zdefiniuj dwa lub trzy cele poziomu usług (SLO). Na przykład: 99,5% żądań checkout kończy się sukcesem w czasie poniżej 800 ms. Alerty wiesz, na czym je oprzeć, a nie na obciążeniu CPU.

5. Przejrzyj jeden prawdziwy incydent na podstawie danych. Czy udałoby się znaleźć przyczynę bez nowego kodu? Jeśli nie, luka, którą znalazłeś, to twoje kolejne zadanie instrumentacyjne.

Krok 5 jest tym, który zwykle się pomija, a jedynie on pokazuje, czy jesteś obserwowalny. Reszta to hydraulika.

Co zrobilibyśmy naprawdę

Jeśli twój zespół ma mniej niż 20 inżynierów, zacznij od instrumentacji OpenTelemetry i backendu, którego cenę da się przewidzieć. Instrumentacja jest przenośna, więc wybór backendu da się odwrócić. Nie kupuj największej platformy tylko dlatego, że zrobił to konkurent.

Jeśli już płacisz za platformę all-in-one, nie wyrywaj jej. Sprawdź, co wysyłasz, wyłącz logi, których nikt nie przegląda, i przeznacz oszczędności na instrumentację przepływów, które mają znaczenie.

Niezależnie od wyboru zapisz, jak span mapuje się z powrotem na kod. Dashboard pokaże ci pożar. Ktoś i tak musi przeczytać źródła, żeby dowiedzieć się, dlaczego się zaczął.