Observability (obserwowalność) - 3 filary: metryki (co się dzieje), logi (dlaczego), tracing (gdzie jest problem). Monitoring proaktywny wykrywa trendy przed awarią.
Monitoring to kluczowy zmysł SRE: bez niego inżynier reaguje na awarie dopiero po zgłoszeniach od użytkowników. Nowocześnie mówimy: obserwowalność.
- Trzy filary obserwowalności – metryki agregują stan liczbowy usługi, logi rejestrują szczegółowe zdarzenia, a ślady (traces) obrazują przepływ żądania w sieci.
- Proaktywne wykrywanie anomalii – zamiast reagowania po wystąpieniu awarii, inżynierowie analizują trendy wzrostu latencji i zużycia zasobów.
- Sygnały wczesnego ostrzegania – rosnąca saturacja kolejek oraz skoki błędów pozwalają podjąć interwencję, zanim użytkownicy odczują spadek jakości.
- Metodyki pomiarowe (RED i USE) – metodyka RED mierzy parametry żądań aplikacji (częstość, błędy, czas), a USE bada nasycenie zasobów sprzętowych.
- Zintegrowany stos telemetryczny – platforma łączy systemy Prometheus i Loki do zbierania danych oraz Grafanę do ich czytelnej wizualizacji na dashboardach.
Observability (obserwowalność): Podejście do monitoringu oparte na trzech filarach - metrykach (co się dzieje), logach (dlaczego) i tracingu (gdzie jest problem); monitoring proaktywny wykrywa trendy przed awarią.
Observability - 3 filary: Metrics (liczby: CPU%, latency p99, req/s - dashboards, alerting, trends), Logs (zdarzenia tekstowe: error, trace, audit - root cause, debugging), Traces (ścieżka żądania przez mikroserwisy: span, trace ID - latency breakdown, dependency map; OpenTelemetry, Jaeger, Tempo).
Komplementarność: metryka mówi "co" (latency↑), logi "dlaczego" (DB timeout), tracing "gdzie" (span w usłudze B) - razem dają pełny obraz; te elementy się nie zastępują, lecz uzupełniają.
Reaktywny vs Proaktywny: reaktywny = alert, gdy już upadło; proaktywny = wykrywanie trendów (wzrost p95, dysk 80%), sezonowość, capacity planning - leading indicators.
RED method (usługi): Rate (req/s), Errors (error rate), Duration (latency) - Golden Signals; USE (zasoby): Utilization, Saturation, Errors - dla infrastruktury.
Wykrywanie przed użytkownikiem: alerty na leading indicators (saturation, errors, latency) - nie na trailing (downtime); RED method (Rate, Errors, Duration) dla każdej usługi.
Narzędzia (wykład 2): Prometheus (metrics), Loki (logs), Tempo/Jaeger (traces) - ekosystem Grafana Labs; unified observability stack.
Terminy: observability, metrics, logs, traces, leading/lagging indicators, SLI, SLO, RED method, USE method.
Monitoring to absolutny fundament pracy SRE - bez niego działacie po ciemku, reagując na problemy dopiero, gdy użytkownicy zaczną dzwonić. Dzisiejsze podejście do monitoringu nosi nazwę observability, czyli obserwowalności, i opiera się na trzech filarach. Pierwszy filar to metryki - liczby, które mówią, co się dzieje: zużycie CPU, opóźnienia odpowiedzi, liczba błędów. Drugi filar to logi - tekstowe zapisy zdarzeń, które pomagają zrozumieć, dlaczego coś poszło nie tak. Trzeci filar to tracing - ścieżka żądania przez system, która pokazuje, gdzie występuje problem. Kluczowa różnica między podejściem reaktywnym a proaktywnym polega na tym, kiedy reagujecie. Podejście reaktywne oznacza doraźne reagowanie na kryzysy – oczekiwanie na awarię i naprawianie szkód po fakcie. Podejście proaktywne polega na wykrywaniu trendów: widzicie, że latencja rośnie albo dysk się zapełnia, i reagujecie zanim problem dotknie użytkowników. Do mierzenia tych trendów służą metody RED (Rate, Errors, Duration) i USE (Utilization, Saturation, Errors). Narzędzia, których będziemy używać, to Prometheus do metryk, Grafana do wizualizacji, Loki do logów i Tempo do tracingu - wszystkie z ekosystemu Grafana Labs.
Wyjaśnienie skrótów użytych na slajdzie:
APM – Application Performance Monitoring – zaawansowane narzędzia do profilowania i monitorowania wydajności kodu aplikacji w czasie rzeczywistym.
RED – Rate, Errors, Duration – metodyka monitorowania usług sieciowych skoncentrowana na liczbie zapytań, odsetku błędów i czasie ich trwania.
USE – Utilization, Saturation, Errors – metodyka monitorowania zasobów sprzętowych autorstwa Brendana Gregga (wykorzystanie, nasycenie, błędy).
TSDB – Time Series Database – baza danych szeregów czasowych przechowująca próbki metryk powiązane z precyzyjnymi stemplami czasu.
