Co to jest observability? Definicja i pierwsze kroki

Co to jest observability? To zdolność do wyjaśnienia, dlaczego system zachowuje się źle, wyłącznie na podstawie telemetrii, którą już emituje, także w przypadku awarii, których nikt nie przewidział. Monitoring mówi, że opóźnienie w checkout przekroczyło 800 ms. Observability pozwala zapytać, który klient, która zależność i który deploy za tym stoją, bez wdrażania nowego kodu o trzeciej w nocy, żeby się tego dowiedzieć.

Oto scenariusz, który pokazuje różnicę. Alert: p99 API płatności wzrosło z 180 ms do 1.4 s. Dashboard CPU, pamięci i wskaźnika błędów jest zielony. Każdy gotowy panel mówi, że usługa działa, a każdy klient mówi, że nie działa. To, co zrobisz w ciągu następnych dziesięciu minut, jest właśnie tematem tego artykułu.

Dlaczego definicja ma znaczenie przed narzędziami?

Pojęcie pochodzi z teorii sterowania: system jest obserwowalny, jeśli na podstawie jego wyjść zewnętrznych można wnioskować o jego stanie wewnętrznym. Branża przejęła je, a dostawcy narzędzi rozciągnęli je tak, że zaczęło oznaczać po prostu „produkt z dashboardami”. Tę nadinterpretację można pominąć.

Roboczą definicją dla zespołu inżynierskiego jest wersja węższa i bardziej użyteczna. System jest obserwowalny, gdy w produkcji możesz odpowiedzieć na nowe pytanie o jego zachowanie, bez wdrażania nowej instrumentacji. Kluczowe słowo to „nowe”. Alert progowy odpowiada na pytanie, które ktoś zapisał kwartał temu. System obserwowalny odpowiada na to, które zadajesz właśnie teraz.

To nie jest test czystości. Nikt nie ma idealnie obserwowalnego systemu, a celem nie jest wynik. Celem jest krótsza droga od „coś jest nie tak” do „ta zmiana to spowodowała”. Czas do wykrycia i czas do zrozumienia to różne liczby, a większość zespołów śledzi tylko pierwszą z nich.

Czym observability różni się od monitoringu?

Monitoring to zbiór kontroli sprawdzających znane tryby awarii: CPU powyżej 90% przez pięć minut, wskaźnik błędów powyżej 1%, kolejka dłuższa niż 10 000 wiadomości. Jest tani, niezawodny i nadal potrzebny. Observability go nie zastępuje.

Różnica widoczna jest wtedy, gdy awaria jest nowa. Monitoring powstaje na bazie przeszłych incydentów. Observability służy do następnego, którego z definicji jeszcze nie widziałeś.

Prosty test: weź ostatnie trzy incydenty i zapytaj, jak znaleziono ich przyczynę źródłową.

• Jeśli ktoś przeczytał gotowy dashboard i odpowiedź tam była, to monitoring wykonał swoją pracę.

• Jeśli ktoś przeszukiwał logi na sześciu hostach, postawił hipotezę, dodał linijkę logu i wdrożył poprawkę, żeby ją potwierdzić, to była luka w observability.

• Jeśli prawdziwa odpowiedź pochodziła ze zrzutu ekranu od klienta, masz oba problemy naraz.

Nie ma sensu spierać się, czy to rywale. To warstwy. Monitoring to czujka dymu. Observability to możliwość przejścia się po budynku po pożarze i ustalenia, który obwód go zapoczątkował.

Trzy sygnały i miejsca, w których każdy z nich zawodzi

Logi, metryki i ślady to standardowa trójka. Każdy odpowiada na inne pytanie i każdy ma tryb awarii, o którym przewodniki dostawców zwykle milczą.

Metryki to wartości liczbowe agregowane w czasie: liczba żądań, wskaźnik błędów, percentyle opóźnień, nasycenie. Są tanie w przechowywaniu i szybkie w zapytaniach, dlatego na nich opiera się alerting. Ich słabością jest agregacja. P99 na poziomie 1.4 s mówi, że coś jest wolne. Nie powie, że każde wolne żądanie należy do jednego klienta na jednym shardzie.

Logi to znaczniki czasu opisujące pojedyncze zdarzenia. Niosą najwięcej szczegółów i najmniej struktury, o ile tej struktury nie wymusisz. Ich słabością są wolumen i koszt. Nieustrukturyzowane logi przeszukuje tylko ktoś, kto już wie, jakiego ciągu znaków szukać, więc stają się narzędziem monitoringu przebranym za narzędzie do debugowania.

Ślady śledzą pojedyncze żądanie przez granice usług, z osobnym spanem dla każdego przeskoku i jego czasu trwania. Tylko one pokazują kształt żądania: to wywołanie czekało 900 ms na zależność, która trzykrotnie ponowiła próbę. Ich słabością jest pokrycie. Jedna usługa, która gubi kontekst śledzenia, przerywa łańcuch, a ślad z dziurą jest gorszy niż brak śladu, bo wygląda wiarygodnie.

Posiadanie wszystkich trzech nie jest tym samym co bycie obserwowalnym. Chodzi o korelację. Musisz przejść od skoku metryki do śladów, które się do niego przyczyniły, a od śladu do logów tego konkretnego żądania. Jeśli trzy sygnały żyją w osobnych narzędziach bez wspólnego identyfikatora, masz trzy systemy monitoringu i inżyniera, który jest ich łącznikiem.

Dlaczego kardynalność decyduje o tym, czy można cokolwiek debugować?

Kardynalność to liczba różnych wartości, jakie może przyjąć pole. status_code ma około dwudziestu wartości. customer_id ma setki tysięcy. request_id ma jedną wartość na każde żądanie.

Pola, których najbardziej potrzebujesz podczas incydentu, to pola o wysokiej kardynalności. Pytanie „który klient jest dotknięty” to pytanie o customer_id. „Który build obsługuje wolne żądania” to pytanie o deploy_version. Jeśli model przechowywania karze pola o wysokiej kardynalności, wyceniając każdą unikalną serię albo po cichu je odrzucając, nie zadasz pytania, które rozwiązuje incydent.

To prawdziwa granica architektoniczna między konfiguracją opartą wyłącznie na metrykach a konfiguracją obserwowalną. Metryki wstępnie agregowane wyrzucają wymiary, których będziesz potrzebować później. Szerokie, ustrukturyzowane zdarzenia je zachowują, a krojenie danych odbywa się po fakcie.

Tak wygląda użyteczne zdarzenie na krawędzi usługi: jeden ustrukturyzowany rekord na żądanie, z kontekstem wystarczającym do podziału po wszystkim, czym będziesz się później interesować.

logger.info("request.completed", {
  trace_id: span.traceId,
  route: "/v1/payments",
  customer_id: ctx.customerId,
  deploy_version: process.env.BUILD_SHA,
  flag_variant: flags.get("new-ledger-path"),
  db_ms: timings.db,
  upstream_ms: timings.upstream,
  status: res.statusCode,
  duration_ms: elapsed,
});

Zwróć uwagę na wariant flagi funkcji. Wiele incydentów opisanych w publicznych post-mortemach zaczyna się od zmiany, a ewaluacja flagi jest zmianą. Jeśli wariantu nie ma w zdarzeniu, nie zapytasz, czy wolne żądania to te, które trafiły na nową ścieżkę.

Jak wygląda incydent z observability i bez niego?

Wróćmy do scenariusza z płatnościami. Ten sam alert, to samo p99 na poziomie 1.4 s.

Bez observability pętla wygląda tak: otwierasz dashboard usługi i nic nie znajdujesz. Otwierasz dashboard bazy i znowu nic. Pytasz w kanale incydentu, czy coś zostało wdrożone. Ktoś przypomina sobie zmianę konfiguracji, ktoś inny się z nią nie zgadza. Czterdzieści minut później cofasz ostatni deploy, żeby sprawdzić, czy to pomoże. Nie pomaga, bo przyczyną było włączenie flagi dla podzbioru klientów.

Z observability pętla wygląda inaczej: grupujesz wolne żądania według flag_variant i widzisz, że 100% z nich trafia na new-ledger-path. Grupujesz według customer_id i widzisz, że trzech dużych klientów odpowiada za większość ruchu. Otwierasz jeden ślad i widzisz, jak wywołanie ledgera rozgałęzia się na 40 sekwencyjnych zapytań. Łączny czas to kilka minut. Wyłączasz flagę, a nie cofasz cały deploy.

Warto zauważyć, czego druga pętla nie potrzebowała. Nie potrzebowała przygotowanego dashboardu. Nie potrzebowała, by ktoś z góry przewidział „wariant flagi” jako ciekawy wymiar. Potrzebowała, by dane były na miejscu, szerokie i możliwe do zapytania.

To jest argument zespołu Honeycomb streszczony w jednym akapicie i on się broni. Nie oznacza jednak, że takie podejście jest darmowe.

Ile to kosztuje i kto może pominąć drogą wersję?

Telemetria jest najpierw problemem wolumenu danych, a dopiero potem problemem narzędzi. Według ankiety Grafana Labs o observability z 2025 roku, w której wzięło udział 1 255 praktyków, średnia organizacja korzysta z ośmiu różnych narzędzi observability, a koszt jest najczęściej wskazywanym kryterium przy wyborze nowych. Te dwa fakty są ze sobą powiązane. Zespoły mnożą narzędzia, bo każde rozwiązuje wycinek problemu, a potem płacą za nakładające się pozyskiwanie danych w każdym z nich.

Praktyczne zasady, które sprawdzają się w większości zespołów:

• Instrumentuj przez OpenTelemetry, a nie przez zastrzeżonego agenta. Collector daje jedno miejsce do próbkowania, filtrowania i routingu. Zmiana backendu staje się zmianą konfiguracji, a nie projektem re-instrumentacji.

• Próbkuj ślady świadomie. Zachowuj każdy błąd i każde wolne żądanie, a zdrowe, szybkie próbkuj. Próbkowanie head-based na stałym poziomie 1% odrzuci dokładnie ten ślad, którego potrzebujesz.

• Nadawaj logom strukturę w momencie zapisu. Parsowanie tekstu wolnego w czasie zapytania to kosztowny sposób na uzyskanie pól.

• Ustal politykę retencji dla każdego sygnału. Metryki na rok, szerokie zdarzenia na dwa tygodnie, logi debugowe na trzy dni. Nikt nigdy nie potrzebował logów debugowych sprzed kwartału.

Pomiń podejście pełnej platformy, jeśli masz kilka usług i jedną rotację on-call. Mały zespół zyska większość korzyści z ustrukturyzowanych logów, metryk RED i śladów na dwóch lub trzech kluczowych ścieżkach. Rozbudowana, wielofunkcyjna umowa zwraca się dopiero wtedy, gdy usług jest na tyle dużo, że nikt nie trzyma całej topologii w głowie, a w naszym doświadczeniu dzieje się to po przekroczeniu 30 lub 40 usług.

Które narzędzia warto sprawdzić?

Wybór narzędzia zależy od tego, ile chcesz utrzymywać samodzielnie, jaką masz kardynalność i na ile może pozwolić sobie rachunek. Krótki, subiektywny przegląd:

Datadog to najszersza komercyjna opcja: metryki, logi, ślady i profilowanie pod jednym dachem, z mocną korelacją między nimi. Cena tej integracji to rachunek, który rośnie wraz z liczbą hostów, metrykami niestandardowymi i wolumenem logów. Warto, jeśli chcesz jednego dostawcy i masz na to budżet. Sprawdź pozycję metryk niestandardowych, zanim podpiszesz umowę.

Grafana to domyślny wybór, gdy chcesz otwartych komponentów, które możesz hostować samodzielnie albo kupić jako zarządzany stos. Dobrze współpracuje z metrykami w stylu Prometheus i potokami OpenTelemetry. Kompromis jest operacyjny: sam składasz więcej elementów, a wskaźnik rozproszenia narzędzi z przytoczonej wyżej ankiety dotyczy również Ciebie.

SigNoz to otwartoźródłowa opcja natywna dla OpenTelemetry, która trzyma logi, metryki i ślady w jednym magazynie. Ma to znaczenie dla wspomnianej wcześniej korelacji, bo wspólny magazyn zamienia przejście od metryki przez ślad do logu w zapytanie, a nie w przełączanie zakładek. To rozsądny wybór dla zespołów, które chcą hostować samodzielnie, bez sklejania czterech projektów.

Better Stack łączy monitoring dostępności, alerting incydentów i zarządzanie logami w cenie dopasowanej do mniejszych zespołów. To sensowny pierwszy krok, jeśli przechodzisz od „dowiadujemy się od klientów” do czegoś uporządkowanego, i mniej odpowiedni dla dużej siatki usług z wysokimi wymaganiami wobec śladów.

Jak zacząć, nie próbując zagotować oceanu?

Nie zaczynaj od oceny narzędzi. Zacznij od ostatnich trzech incydentów i jednego szczerego pytania: o co chcieliśmy móc zapytać?

Sekwencja, która działa w zespole od 50 do 200 inżynierów:

1. Wybierz jedną krytyczną ścieżkę żądań i zainstrumentuj ją end-to-end przez OpenTelemetry. Checkout, logowanie, cokolwiek, co budzi Cię o trzeciej w nocy.

2. Emituj jedno szerokie, ustrukturyzowane zdarzenie na żądanie na krawędzi usługi, z klientem, wersją, wariantami flag i czasami zależności.

3. Zdefiniuj jedno SLO na tej ścieżce i alarmuj na szybkości zużycia budżetu błędów, a nie na surowych progach. Alerty oparte na zużyciu budżetu wzywają Cię, gdy klienci są dotknięci, a telemetria z kroku 2 podpowiada, dlaczego.

4. Przeprowadź game day. Wywołaj awarię, na którą nie masz alertu, i sprawdź, ile czasu zajmie znalezienie jej komuś, kto nie napisał tego kodu. Ta liczba jest Twoją linią bazową.

5. Rozszerzaj się na zewnątrz po jednej ścieżce naraz, dopiero gdy pierwsza ścieżka zwróciła się w prawdziwym incydencie.

Observability kupuje się jak platformę, a przyjmuje jak nawyk. Nawyk to pytanie „co musiałbym wiedzieć, żeby to wyjaśnić?” zadawane na code review, przed incydentem, a nie w jego trakcie.

Otwórz ostatni przegląd incydentu. Znajdź zdanie „potem dodaliśmy logowanie, żeby potwierdzić”. Każde takie zdanie oznacza pytanie, na które system nie potrafił odpowiedzieć w produkcji. Ile ich jest zapisanych i które z nich nadal pozostają bez odpowiedzi?