Monitoring czasu odpowiedzi

Czemu czas odpowiedzi zasługuje na własny alert

Standardowe alerty uptime opierają się na sygnale binarnym: up lub down. Szara strefa pomiędzy - up, ale wolno - to miejsce, gdzie naprawdę żyje większość nowoczesnych awarii. Źle skonfigurowane zapytanie do bazy zaczyna trwać 4 sekundy zamiast 50ms. Memory leak powoduje skoki garbage collection. Zewnętrzne API, do którego woła backend, zaczyna migotać. Żadna z tych rzeczy nie psuje strony całkowicie, ale czyni ją niezdatną do użytku - i są to wczesne sygnały awarii oddalonej o godzinę lub dwie.

Monitoring czasu odpowiedzi łapie spowolnienie zanim stanie się awarią. Konfigurujesz próg per monitor, a gdy czas odpowiedzi przekracza go w kilku kolejnych sprawdzeniach, dostajesz alert. Zanim alert leci, masz jeszcze zapas, by zbadać sprawę, doskalować, throtlować problematyczne wywołanie lub wycofać deploy, który to uruchomił.

Jak działają progi w DiagnoSEO Uptime Monitoring

Każdy monitor można skonfigurować z dwoma parametrami: rt_threshold_ms i rt_threshold_breaches. Pierwszy to czas odpowiedzi w milisekundach, który uważasz za akceptowalny. Drugi to ile kolejnych sprawdzeń musi go przekroczyć, by alert poleciał. Domyślnie próg jest wyłączony, a liczba przekroczeń to trzy.

Dwuparametrowy design chroni przed false positive'ami. Jitter sieciowy się zdarza. Pauzy garbage collection się zdarzają. Pojedynczy skok do 1 sekundy przy bazowych 200ms nie jest wart pagera o 3 nad ranem. Ale trzy kolejne 1-sekundowe odpowiedzi już tak - to utrwalone spowolnienie, nie mignięcie. Wybierz próg na podstawie obserwowanego normalnego zachowania plus wygodny margines: jeśli p95 to normalnie 400ms, próg 1000ms. Jeśli p95 to 50ms (wewnętrzne API), próg 200ms.

Z czym dobrze się łączy

Alerty czasu odpowiedzi działają najlepiej w kombinacji z innymi sygnałami monitora. Pełen obraz: próg czasu odpowiedzi mówi, że system się degraduje; kod HTTP mówi, kiedy faktycznie pęka; ostrzeżenia SSL/domeny - o awariach napędzanych zegarem; alerty zmian DNS - o driftie konfiguracji. Razem cztery sygnały na tym samym monitorze zamieniają binarne "czy działa" na pełną observability.

Dashboard też w tym pomaga. Każdy monitor pokazuje sparkline ostatnich czasów odpowiedzi - szybki wizualny wskaźnik wzorców degradacji. Widok rozwinięty pokazuje średnie czasów 24h, 7d i 30d. Jeśli widzisz średnią pełzającą w górę tydzień po tygodniu - to wczesny sygnał wart zbadania, zanim przekroczy próg alertu.

Praktyczne progi po typie strony

• Landing page'e marketingowe: 1500ms jest rozsądne. Są ciężkie obrazami i skryptami trackerskimi; bezwzględna szybkość liczy się mniej niż stabilność.
• Strony produktowe/kategorie ecommerce: 800-1200ms. Wolny ecom zabija konwersje; ciaśniejsze progi łapią problemy szybciej.
• Dashboardy aplikacyjne: 500-800ms. Użytkownicy oczekują żywości. Wolne dashboardy sprawiają, że produkt wydaje się popsuty.
• Publiczne API: 200-400ms dla prostych endpointów, wyżej dla compute-heavy. Tier'uj je.
• Wewnętrzne mikroserwisowe health checki: 50-100ms. Powinny być niemal natychmiastowe; powolność prawie zawsze oznacza prawdziwy problem.

Cokolwiek wybierzesz, nie wybieraj raz i nie zapominaj. Re-ewaluuj kwartalnie na podstawie trendów, które faktycznie widzisz. Jeśli ciągle dostajesz alerty przekroczenia, które nie reprezentują prawdziwych problemów - próg jest za ciasny. Jeśli dostajesz awarię bez poprzedzającego alertu progu - próg był za luźny.

Routing alertów

Alerty przekroczenia progu lecą tymi samymi kanałami co alerty down/recovery: Email, Telegram, Slack, Discord, SMS. Respektują tę samą ciszę nocną. Są logowane w tej samej tabeli alertów. Jedyna różnica to typ zdarzenia ("threshold" zamiast "down") i treść komunikatu - mówi aktualny czas odpowiedzi i skonfigurowany próg, więc od razu widzisz wielkość przekroczenia.

Konfiguracja

Edytuj dowolny monitor. W formularzu ustaw "Próg czasu odpowiedzi (ms)" na wybraną liczbę. Opcjonalnie dostosuj "kolejne przekroczenia", jeśli domyślne 3 nie pasuje do tolerancji. Zapisz. Od następnego cyklu każde sprawdzenie porównuje czas odpowiedzi z progiem, a po skonfigurowanej liczbie kolejnych przekroczeń dostajesz powiadomienie.

Najczęściej zadawane pytania

• Jaki metryk czasu odpowiedzi jest rejestrowany?

  Time To First Byte (TTFB) — milisekundy między wysłaniem żądania a otrzymaniem pierwszego bajtu odpowiedzi. Plus całkowity czas pobrania pełnej odpowiedzi. TTFB to najbardziej użyteczny pojedynczy metryk dla zdrowia serwera.

• Jaki jest "dobry" czas odpowiedzi?

  Zależy od lokalizacji i treści. Dla strony statycznej z CDN: poniżej 100ms to świetnie, poniżej 300ms jest OK. Dla dynamicznych aplikacji: poniżej 500ms jest OK, poniżej 1000ms akceptowalne, powyżej 2000ms wygląda na powolne. Porównuj z własną historyczną bazą zamiast absolutnymi liczbami.

• Czy mogę dostać alert gdy czas odpowiedzi przekroczy próg?

  Tak. Każdy monitor ma opcjonalny próg czasu odpowiedzi. Jeśli 3 kolejne checki przekroczą próg, dostajesz alert "slow response". Wymóg 3 checków zapobiega false alarms od pojedynczych zaników sieci.

• Skąd mierzony jest czas odpowiedzi?

  Z naszych 13 geograficznych punktów checków (Europa, Ameryka Północna, Azja, Ameryka Południowa, Oceania). Dla monitora single-region czasy pochodzą z najbliższego regionu. Dla multi-region każdy region jest mierzony niezależnie — przydatne do wykrywania problemów regionalnych CDN.

• Czy dashboard pokazuje trendy czasu odpowiedzi?

  Tak — 30-dniowa średnia krocząca, dzienne max/min i percentyle (p50, p95). Przydatne do planowania pojemności: jeśli p95 wzrósł z 800ms do 1500ms w ciągu miesiąca, Twoje serwery się przeciążają mimo że uptime % zostaje na 100%.