Sytuacja, którą zna wielu administratorów pracujących z produkcyjnym Linuxem: dashboard nie pokazuje alarmów, podstawowe metryki CPU i RAM wyglądają poprawnie, a użytkownicy zgłaszają spowolnienia, timeouty lub losowe błędy aplikacji.

To są kosztowne incydenty. Nie dlatego, że od razu powodują niedostępność usługi, tylko dlatego, że potrafią trwać tygodniami i stopniowo obniżać zaufanie użytkowników. Z perspektywy biznesu to moment, w którym formalnie „nie ma awarii”, ale realnie spada sprzedaż, rośnie liczba zgłoszeń i rośnie koszt pracy zespołu.

Brak alertów nie oznacza braku problemu

Klasyczny monitoring infrastruktury Linux dobrze łapie rzeczy twarde: host down, pełny dysk, padniętą usługę, wysokie zużycie CPU. Gorzej radzi sobie z tym, co dzieje się pomiędzy warstwami: chwilowe opóźnienia DNS, kolejki połączeń, timeouty między usługami, krótkie piki I/O albo saturacja puli połączeń.

W praktyce warto przyjąć jedną zasadę: monitoring to sygnał, nie pełna widoczność.

Jeżeli chcesz zamknąć ten problem systemowo, łącz monitoring infrastruktury z codzienną administracją Linux i kontrolą zmian w warstwie bezpieczeństwa.

Typowy scenariusz incydentu „szarej awarii”

Najczęściej wygląda to tak:

  1. Użytkownik zgłasza, że „co trzecie żądanie mieli 15–20 sekund”.
  2. APM pokazuje wzrost czasu odpowiedzi tylko dla części endpointów.
  3. Host ma niski load average, więc pierwsza diagnoza brzmi: „u mnie działa”.
  4. Po czasie okazuje się, że problem pojawia się tylko przy konkretnych zapytaniach i tylko przy większej liczbie równoległych połączeń.

To nie jest klasyczna awaria typu on/off. To degradacja jakości usługi: losowa, trudna do powtórzenia i bardzo kosztowna operacyjnie.

Od czego zacząć, żeby nie stracić pół dnia

1. Najpierw oś czasu, potem hipotezy

Nie zaczynaj od top. Najpierw zbierz:

  • dokładny przedział czasu zgłoszeń,
  • zakres użytkowników (wszyscy czy tylko część),
  • wspólny mianownik (endpoint, lokalizacja, typ operacji).

Bez tego porównujesz „średnie z doby” do problemu, który trwał kilka minut.

2. Potwierdź objaw na żywo

Potrzebujesz jednego prostego testu, który odtwarza problem. Np. seria równoległych zapytań do endpointu albo powtarzalne zapytanie SQL wywoływane przez aplikację.

Dopiero gdy objaw jest mierzalny, narzędzia systemowe mają sens.

3. Sprawdź cztery wąskie gardła w tej kolejności

Kolejność naprawdę skraca diagnozę:

  1. sieć i połączenia
  2. I/O i pamięć
  3. kolejki aplikacyjne
  4. zależności zewnętrzne (DNS, API, SMTP, LDAP)

Timeouty: gdzie realnie giną sekundy

Timeout to efekt końcowy, nie przyczyna.

DNS, który „czasem” odpowiada wolno

Objaw: raz szybkie odpowiedzi, raz kilka sekund ciszy zanim w ogóle powstanie połączenie.

Sprawdzam:

  • retransmisje i timeouty resolvera
  • nadmiarowe lookupy po stronie aplikacji
  • krótkie „dziury” sieciowe

Monitoring, który sprawdza tylko „czy DNS działa”, tego nie zobaczy.

Saturacja puli połączeń

Objaw: niski CPU, ale część żądań kończy się timeoutem lub 502/504.

Typowe sygnały:

  • ss -s pokazuje dużą liczbę oczekujących socketów
  • backlog rośnie
  • pula połączeń do bazy albo backendu jest za mała

Metryki hosta wyglądają poprawnie, ale usługa zaczyna degradować się dla użytkownika.

IO wait w krótkich pikach

Objaw: co kilka minut aplikacja „przysiada”, ale średnie metryki są OK.

Tu liczą się krótkie próbki:

  • iostat -x 1
  • vmstat 1

Szukasz skoków await, kolejek I/O i wa.

Jeżeli zgrywa się to z backupem, snapshotem VM albo logrotate — masz przyczynę.

Kolejki i narastanie opóźnień

Często problem nie leży w systemie, tylko w aplikacji:

  • kolejka rośnie szybciej niż konsumenci
  • worker działa, ale wolniej
  • retry policy robi lawinę

Host nie generuje alarmów, ale użytkownik czeka 40 sekund w kolejce.

Dlatego obok narzędzi systemowych potrzebujesz:

  • długości kolejki
  • czasu przetwarzania
  • liczby retry
  • odrzuconych połączeń

Mismatch: aplikacja kontra system

To klasyczna pułapka.

System mówi: „mam zasoby”
Aplikacja mówi: „nie mogę ich wykorzystać”

Przykłady:

  • brak indeksu SQL → wolny endpoint mimo wolnego CPU
  • blokady w bazie → długie odpowiedzi bez sygnałów w systemie
  • problemy TLS po zmianach bezpieczeństwa

Dlatego takie incydenty zawsze wymagają spojrzenia na całość: system, sieć i aplikację jednocześnie.

Jak wygląda pierwsza godzina dobrej diagnozy

To jest moment, który robi różnicę.

  1. Potwierdzasz realny wpływ na użytkownika
  2. Zawężasz problem do konkretnego scenariusza
  3. Uruchamiasz minimalny zestaw narzędzi (vmstat, iostat, ss)
  4. Szukasz korelacji w czasie, nie „średnich”
  5. Testujesz jedną hipotezę naraz

Największy błąd: skakanie między pięcioma teoriami bez ich falsyfikacji.

Dlaczego te problemy są ignorowane

Bo:

  • nie ma statusu „DOWN”
  • monitoring wygląda dobrze
  • problem jest „nieregularny”

A biznesowo to:

  • spadek konwersji
  • więcej porzuconych operacji
  • rosnący support
  • stały koszt pracy zespołu wynikający z powracających diagnoz

Szare awarie są droższe niż klasyczne awarie.

Jak zwiększyć widoczność bez rewolucji

Największy efekt dają proste zmiany:

  1. Percentyle (p95/p99), nie średnia
  2. Alerty na degradację jakości
  3. Korelacja metryk systemowych i aplikacyjnych
  4. Testy syntetyczne ścieżek użytkownika

To zwykle pierwszy moment, kiedy „niewidzialne problemy” zaczynają być widoczne.

Najważniejsza zasada operacyjna

Jeżeli użytkownik mówi, że system działa źle, a monitoring mówi, że jest dobrze — to monitoring jest niepełny, nie użytkownik.

W środowiskach Linux przewagę ma ten zespół, który potrafi diagnozować problemy widoczne dla użytkownika wcześniej niż klasyczne alerty infrastrukturalne.