Opóźnienia, Ruch, Błędy, Nasycenie

Cztery liczby pokrywają większość operacji

Z książki Google SRE. Cztery sygnały, które mierzysz na każdym poziomie usługi. Jeśli dobrze zinstrumentujesz te cztery, wykryjesz większość problemów produkcyjnych, zanim zrobią to użytkownicy.

Opóźnienie (Latency): jak długo trwa obsługa żądania? Raportuj rozkłady, a nie tylko średnie. p99 (99. percentyl opóźnienia) ma większe znaczenie niż średnia, ponieważ to opóźnienia w ogonie (tail latency) są postrzegane przez użytkowników jako „wolność”. Usługa ze średnim opóźnieniem 50 ms i p99 wynoszącym 5 000 ms ma realny problem, którego większość użytkowników nigdy nie zauważy, ale 1% najbardziej dotkniętych osób odczuje go zdecydowanie.

Ruch (Traffic): ile żądań na sekundę? Łączna liczba żądań, per endpoint, per kod statusu, per region. Baza jest znana; alarmuj przy anomalii (nagły spadek = problem z wejściem; nagły wzrost = nagły ruch lub atak).

Błędy (Errors): wskaźnik nieudanych żądań. Rozróżniaj błędy 4xx (błędy klienta, nie Twoja wina) od błędów 5xx (błędy serwera, Twoja wina). Śledź wskaźnik błędów jako procent ruchu, a nie jako wartości bezwzględne, aby alarmy działały niezależnie od poziomu obciążenia.

Nasycenie (Saturation): jak bardzo obciążony jest system? Wykorzystanie CPU, pamięć, głębokość puli połączeń, długość kolejki. To wskaźnik wyprzedzający. Nasycenie rośnie, zanim opóźnienia lub błędy się pogorszą. Warstwa (tier) przy 90% nasycenia jest o jedną złą minutę od załamania kolejki.

W przypadku warstwy proxy

Każdy sygnał manifestuje się na warstwie brzegowej (edge layer):

- Opóźnienie na proxy: czas ręcznego uścisku TLS, czas połączenia z górnym węzłem (upstream), łączny czas żądania-odpowiedzi. Mierzone osobno, ponieważ dotyczą różnych części ścieżki.

- Ruch na proxy: łączna liczba żądań/sek, rozkład per backend (gorący backend wskazuje na nierównomierność w równoważeniu obciążenia), rozkład per kod statusu.

- Błędy na proxy: 4xx od klientów (Twoi użytkownicy trafiający na błędne końcówki), 5xx od backendów (Twoje usługi zawieszają się), błędy wewnętrzne proxy (502 = backend niedostępny, 504 = przekroczony limit czasu backendu).

- Nasycenie na proxy: liczba sesji TLS, głębokość puli połączeń do góry (upstream), CPU samego proxy (kończenie TLS jest obciążające dla CPU).

Wskazówka: nagły wzrost 502 przy niskiej opóźnieniu backendu oznacza, że backend rozłącza się przed wysłaniem odpowiedzi (reset połączenia, awaria, OOM). Wzrost 504 oznacza, że backend jest wolny, ale nadal odpowiada. Czytaj kod błędu; mówi on, gdzie znajduje się źródło awarii.

Czytanie sygnałów

Twoja tablica pokazuje następujące dane z ostatnich 10 minut:

- Ruch: w przybliżeniu stabilny na poziomie 800 żądań/s (brak nagłego skoku)

- Opóźnienia: p50 stabilne na poziomie 40 ms, p99 wzrosło z 200 ms do 2 500 ms w ciągu 5 minut i nadal rośnie

- Błędy: wskaźnik 4xx stabilny na poziomie 0,3% (normalne tło); wskaźnik 5xx wzrósł z 0,1% do 1,2% (głównie 504 Gateway Timeout)

- Nasycenie: CPU backendu wzrósł z 45% do 78% w ciągu tych samych 5 minut; CPU proxy stabilny na poziomie 30%

Kiedy skalować, kiedy opróżniać, kiedy eskalować alert

Decyzje dotyczące pojemności wymagają wyzwalaczy

Obserwacja metryk jest łatwa. Dyscypliną jest wiedza, kiedy należy podjąć na ich podstawie działania.

Skaluj w górę, gdy: nasycenie przekroczy utrzymujący się próg (np. CPU backendu >70% przez 5 minut), lub głębokość kolejki wzrośnie powyżej wartości docelowej, lub opóźnienie p99 przekroczy SLO. Wyzwalacz powinien zadziałać, zanim coś się zepsuje, a nie w momencie awarii.

Opróżnij replikę, gdy: jest ona konsekwentnie wolna / błędna, podczas gdy inne repliki są zdrowe (jedna rozgrzana replika często wskazuje na problem na poziomie hosta, a nie aplikacji), lub podczas wdrażania nowej wersji, lub podczas eleganckiego wycofywania repliki.

Eskaluj alert do człowieka, gdy: SLO jest przekraczane szybciej, niż budżet błędów może to wytrzymać, lub wyzwalacz nasycenia zadziała, a autoskalowanie nie zdołało go pochłonąć, lub pojawi się wzorzec kaskadowy (wzrost zarówno wskaźnika błędów, jak i wskaźnika ponowień).

Nie eskaluj alertu, gdy: pojedyncza zła minuta rozwiązuje się sama, lub zadania wsadowe w tle powodują oczekiwane okresowe wahania, lub szum przekracza próg (próg jest nieprawidłowy, a nie system).

SLO i tempo zużycia budżetu błędów

SLO (service level objective, czyli cel poziomu usługi) definiuje akceptowalną wydajność: „wskaźnik sukcesu >= 99,9% w oknie 28-dniowym”. Uzupełnieniem (0,1%) jest budżet błędów.

Tempo zużycia (burn rate): jak szybko zużywasz budżet błędów. Jeśli zużyjesz 10% budżetu w 1 godzinę, tempo jest 240 razy szybsze niż zrównoważone (1 godzina to 1/672 z 28-dniowego okna; zużycie 10% w tym oknie = 10% × 672 = 6720% prognozowane dla całego okna, przy dozwolonych tylko 100%).

Alerty oparte na tempie zużycia w wielu oknach czasowych: alarmuj, gdy zarówno krótkie okno (5 minut przy tempie 14,4x), jak i długie okno (1 godzina przy tempie 6x) zużywają budżet szybciej niż tempo zrównoważone. Wykrywa zarówno nagłe awarie, jak i powolne pogarszanie się wydajności.

Dlaczego to ma znaczenie dla pojemności: usługa działająca przy SLO 99,9% z 1% zapasu może pochłonąć drobne wahania. Usługa na poziomie 99,93% (ledwo spełniająca SLO) jest o jeden zły dzień od naruszenia limitu. Decyzje dotyczące pojemności powinny dążyć do komfortowego marginesu SLO, a nie do minimum, które go spełnia.

Decyzja dotycząca pojemności pod obserwacją

Twoja usługa ma SLO wynoszące 99,9% udanych żądań w ciągu 28 dni. Obecny stan z monitoringu z ostatniej godziny:

- Wskaźnik sukcesu: 99,5% (utrzymywany przez 30 minut)

- CPU backendu: średnio 82% w całej flocie (cel: 70%)

- Opóźnienie p99: 800 ms (cel SLO: <500 ms)

- Ruch: 1400 żądań/s, wzrost z poziomu bazowego 1000 żądań/s (40% powyżej normy; trend nadal rośnie)

- Autoskalowanie: skonfigurowane tak, aby dodawać repliki, gdy CPU przekracza 80% przez 5 minut; obecnie trwa proces skalowania w górę, który doda 3 repliki w ciągu ~90 sekund

Zaprojektuj plan obserwowalności wdrożenia

Synteza

Teraz możesz zaprojektować /health, które wykrywa rzeczywiste awarie, /version, które pozwala weryfikować wdrożenia, dashboardy czterech sygnałów złotych na poziomie proxy oraz progi pojemności powiązane z tempem zużycia SLO.

Zastosuj wszystkie cztery.

Twoja drużyna wdraża search.example.com (usługę wyszukiwania z lekcji o trybach awarii). Drużyna chce wdrożyć obserwowalność, która wykrywa problemy, zanim zrobią to użytkownicy, wraz z jasną macierzą decyzji o eskalacji lub jej braku. SLO: 99,9% udanych żądań, p99 opóźnienia < 300 ms, w oknie 28-dniowym.

Zakończenie kursu

Zakończenie kursu

Ukończyłeś/aś wszystkie pięć lekcji:

- Proksy i źródła: kształt warstwy brzegowej, którego używa niemal każdy publiczny serwis webowy

- Be Stanowe Skalowanie Poziome: dlaczego warstwa bezstanowa mnoży się tanio i jak ją rozmiarować

- Rozdzielenie Ruchu Przyjmującego i Wysyłającego: dlaczego jeden serwer staje się dwoma oraz tryb awarii, który to wymusza

- Tryby Awarii i Zakres Wpływu: punkty pojedynczej awarii (SPOF), kaskady, postmortemy, beznagannego działania pozycje

- Obserwowalność i Pojemność (ten temat): co mierzyć, aby problemy ujawniły się, zanim zrobią to użytkownicy

Główna oś: system rozproszony w skali webowej nie jest magią. To mały zestaw wzorców (proksy odwrotny, repliki bezstanowe, rozdzielenie ruchu przyjmującego/wysyłającego, grodzie i wyłączniki obwodu, cztery sygnały złote) skomponowanych z rozwagą. Gdy rozpoznasz te wzorce, zobaczysz je w każdej architekturze produkcyjnej.

Lekcje towarzyszące: pięć lekcji o geometrii-* przekształca ten sam materiał w teorię grafów i geometrię. Pasują one dobrze w dowolnej kolejności.

Bardzo dobrze.