Observability

Metrics

Agregowane numeryczne dane w czasie. Latency, throughput, error rate, saturation.

Traces

Śledzenie żądania przez wszystkie serwisy. Identyfikacja bottlenecków i błędów.

Logs

Zdarzenia z kontekstem i timestampem. Rich context dla debuggingu.

Profiles

Continuous profiling — CPU/memory heatmaps w czasie. Nowy, 4. filar.

Co to jest Observability i czym różni się od Monitoringu?

Observability (obserwowalność) to miara tego jak dobrze możesz zrozumieć wewnętrzny stan systemu na podstawie jego zewnętrznych sygnałów. Termin pochodzi z teorii sterowania (control theory) i oznacza zdolność do wnioskowania o stanie systemu z jego wyjść. Trzy filary observability: Metrics (metryki) — agregowane, numeryczne dane o systemie (latency p99, error rate, CPU usage). Traces (ślady) — śledzenie pojedynczego żądania przez wszystkie serwisy w systemie rozproszonym. Logs (logi) — zdarzenia z kontekstem w czasie. Monitoring vs. Observability: Monitoring = wiesz co sprawdzać. Wiesz jakie pytania zadać. Tworzysz alerty na znane problemy. Observability = możesz zadawać pytania których jeszcze nie znasz. Eksplorujesz nieznane problemy. Debugging production issues który nigdy wcześniej nie wystąpił. Dlaczego observability jest krytyczne w mikrousługach: jedno żądanie użytkownika może przechodzić przez 10-50 serwisów. Bez distributed tracing — nie wiesz który serwis jest wolny lub błędny. Monolityczne podejście do logów nie skaluje się. OpenTelemetry (OTel) stał się de-facto standardem zbierania sygnałów observability.

Co to jest OpenTelemetry i jak go wdrożyć?

OpenTelemetry (OTel) to CNCF projekt (graduated) — open-source framework do instrumentacji, zbierania i eksportowania danych telemetry (metrics, traces, logs). Jest vendor-neutral — raz instrumentujesz kod, możesz wysyłać do różnych backendów (Jaeger, Tempo, Prometheus, Datadog, New Relic). Komponenty OTel: OTel API — kod w aplikacji wywołuje API do generowania metrics/traces/logs. OTel SDK — implementacja API w danym języku (Java, Python, Go, .NET, JS i inne). OTel Collector — sidecar lub daemon zbierający sygnały, przetwarzający i wysyłający do backendu. Exporters — wysyłają do konkretnych backendów (OTLP, Jaeger, Prometheus). Auto-instrumentation: wiele bibliotek (HTTP, gRPC, databases) jest automatycznie instrumentowanych przez OTel bez zmiany kodu aplikacji. Wdrożenie: Dodaj OTel SDK do aplikacji. Skonfiguruj OTel Collector (DaemonSet na K8s lub sidecar). Skonfiguruj eksportery do Jaeger (traces), Prometheus (metrics), Loki (logs). Użyj Grafana jako unified UI do wszystkich trzech. Semantic Conventions: OTel definiuje standardowe nazwy atrybutów dla HTTP, DB, messaging — zapewnia spójność między serwisami.

Distributed Tracing — jak działa i jak interpretować?

Distributed Tracing (śledzenie rozproszone) śledzi żądanie przez wszystkie serwisy mikroserwisowej architektury, tworząc pełny obraz co się dzieje podczas obsługi jednego requesta. Koncepty: Trace — cała ścieżka żądania od startu do końca. Span — pojedyncza operacja w ramach trace (np. wywołanie bazy danych, wywołanie HTTP do innego serwisu). Parent-child relacja — spany tworzą drzewo. Trace Context Propagation — każde żądanie niesie Trace ID i Span ID w nagłówkach HTTP (W3C TraceContext standard). Jak interpretować trace: Flamegraph / Waterfall view — wizualizacja wszystkich spanów w czasie. Gdzie jest najdłuższy span? Który serwis dodaje latency? Błędy w spanach — które serwisy zwracają błędy? Tail latency: p99 może być 10x wyższe niż p50 — traces pomagają zrozumieć dlaczego (cold starts, garbage collection, lock contention). Narzędzia: Jaeger (CNCF, open-source), Grafana Tempo (open-source, skalowalne), Zipkin (historyczny, uproszczony), Datadog APM / New Relic (komercyjne). Sampling: nie tracuj 100% requestów na dużym ruchu. Head-based sampling (random) lub tail-based sampling (zawsze zapisuj traces z błędami i wysoką latency).

Jak zbudować observability stack — Prometheus, Grafana, Loki?

Observability Stack: Prometheus (metrics): pull-based time-series database. Scrape targets co 15s. PromQL jako language zapytań. Alerty przez Alertmanager. Eksport przez /metrics endpoint. Grafana (visualization): dashboard dla wszystkich sygnałów. Łączy Prometheus (metrics), Loki (logs), Tempo (traces) w jeden UI. Grafana Mimir — skalowana wersja Prometheus dla enterprise. Loki (logs): log aggregation system by Grafana Labs. Index tylko metadata (labels), nie treść logów — tańsze i szybsze niż Elasticsearch dla logów. LogQL jako language zapytań. Promtail jako agent zbierający logi. Grafana Tempo (traces): skalowane distributed tracing storage. Kompatybilne z Jaeger, Zipkin, OTel. Integracja z Loki — jump z loga do trace w jednym kliknięciu. OpenTelemetry Collector jako glue: OTel Collector przyjmuje OTLP, może przekształcać i wysyłać do Prometheus, Loki, Tempo jednocześnie. Alternatywne stack: Datadog — komercyjne, all-in-one. New Relic, Dynatrace — komercyjne enterprise. Elastic Observability (Elasticsearch + Kibana) — rozbudowane, kosztowne. Zalecenie startowe: zacznij od Prometheus + Grafana. Dodaj Loki dla logów. Dodaj Tempo gdy potrzebujesz traces.

SLOs, SLIs, SLAs — jak definiować i mierzyć?

SLOs, SLIs, SLAs — fundamenty reliability engineering: SLA (Service Level Agreement): umowa z klientem dotycząca dostępności. Np. '99.9% uptime per miesiąc' z konsekwencjami finansowymi (credits). Zewnętrzna, prawna umowa. SLO (Service Level Objective): wewnętrzny cel niezawodności który chcesz osiągnąć. Bardziej ambitny niż SLA (żeby mieć bufor). Np. 'latency p99 poniżej 500ms dla 99.5% requestów'. SLI (Service Level Indicator): konkretna metryka którą mierzysz. Np. 'odsetek requestów HTTP 200 do wszystkich requestów w ciągu 5 minut'. Error Budget: Error Budget = 1 - SLO. Jeśli SLO = 99.9% → Error Budget = 0.1% = 43 minuty outage per miesiąc. Zespół może deployować dopóki nie wyczerpie error budget. Jak definiować dobre SLOs: Zaczyn od customer perspective — co klient odczuwa? Latency, availability, throughput. Definiuj na granicy serwisu (co klient widzi), nie wewnętrznie. Zacznij z luźnymi SLOs (99%), zacieśniaj gdy system dojrzewa. Narzędzia: Sloth (SLO generator dla Prometheus), Nobl9, Pyrra. Google SRE Book — fundamentalna lektura dla SLOs i Error Budgets.

Wyślij zapytanie