Observability (obserwowalność) to zdolność do zrozumienia, co dzieje się wewnątrz systemu, patrząc wyłącznie na to, co system wypluwa na zewnątrz — czyli na jego dane telemetryczne. Termin przywędrował z teorii sterowania, gdzie oznacza, czy stan układu da się wywnioskować z jego wyjść. W IT chodzi o to samo: dobrze obserwowalny system pozwala odpowiedzieć na pytanie „dlaczego to się zepsuło?” nawet jeśli wcześniej nikt nie przewidział tej konkretnej awarii. Klasycznie opiera się na trzech filarach: metrykach (liczby w czasie, np. zużycie CPU, liczba żądań na sekundę), logach (zapisy zdarzeń, zwykle tekstowe) i tracingu (śledzenie pojedynczego żądania w jego wędrówce przez wiele usług).
Po co Ci to
Im bardziej rozproszony system (mikroserwisy, kontenery, kolejki), tym trudniej zgadnąć, gdzie leży problem. Pojedyncze kliknięcie użytkownika może przejść przez dziesięć usług, dwie bazy i message brokera. Klasyczny monitoring odpowiada na pytania, które zadałeś z góry („alarm, gdy CPU przekroczy 90%”). Observability ma Ci pozwolić zadawać pytania, których wcześniej nie przewidziałeś — bo prawdziwe awarie rzadko czytają Twoją listę alertów.
W praktyce zbierasz telemetrię z aplikacji i infrastruktury, wysyłasz ją do jakiegoś backendu i tam ją przeszukujesz, korelujesz i wizualizujesz. Coraz częściej robi się to przez OpenTelemetry (OTel) — otwarty standard, który ujednolica sposób zbierania metryk, logów i traców, żebyś nie był przywiązany do jednego dostawcy.
Przykład z życia
Użytkownicy zgłaszają, że checkout w sklepie „czasem muli”. Metryki w Grafanie pokazują, że p99 latencji skoczył z 200 ms do 3 s. Otwierasz trace tego żądania w Jaeger i widzisz, że 2,8 s zżera jeden span — wywołanie do payment-service. Wchodzisz w logi tej usługi przefiltrowane po trace_id:
kubectl logs -l app=payment-service | grep "abc123def"
i znajdujesz timeout connecting to fraud-check. Trzy filary zagrały razem: metryka pokazała że jest źle, trace gdzie, a log dlaczego.
Częste błędy i mity
- „Mamy monitoring, więc mamy observability” — nie. Monitoring mówi, czy coś działa; observability pozwala dociec, czemu nie.
- Logowanie wszystkiego — rachunek za przechowywanie potrafi przebić koszt samej aplikacji. Sampluj traces i ustalaj poziomy logów z głową.
- Brak korelacji — metryki, logi i traces żyjące w trzech osobnych narzędziach bez wspólnego
trace_idto trzy oddzielne ślepe zaułki.
Pojęcia powiązane: monitoring, OpenTelemetry, distributed tracing, SRE, SLI/SLO, Prometheus, Grafana, APM, telemetria, cardinality.