Monitorovanie času odozvy

Prečo si čas odozvy zaslúži vlastný alert

Štandardné uptime alerty sa zakladajú na binárnom signáli: up alebo down. Sivá zóna medzi tým – up, ale pomalé – je miesto, kde v skutočnosti žije väčšina moderných výpadkov. Zle nastavený dopyt do databázy začne trvať 4 sekundy namiesto 50 ms. Únik pamäte spôsobuje nárasty garbage collection. Externé API, na ktoré sa backend odvoláva, začne haprovať. Ani jedna z týchto vecí stránku úplne nerozbije, ale robí ju nepoužiteľnou – a sú to včasné signály havárie vzdialenej hodinu alebo dve.

Sledovanie času odozvy zachytí spomalenie skôr, než sa stane kritickou chybou. Nastavíš si prah na každom monitore, a keď odozva prekročí tento prah vo viacerých po sebe idúcich meraniach, dostaneš upozornenie. Skôr než príde alert, máš ešte rezervu na vyšetrovanie, zvýšenie kapacity, throttling problémových volaní alebo rollback nasadenia, ktoré to spustilo.

Ako fungujú prahy v DiagnoSEO Uptime Monitoring

Každý monitor môžeš nastaviť dvoma parametrami: rt_threshold_ms a rt_threshold_breaches. Prvý je čas odozvy v milisekundách, ktorý považuješ za akceptovateľný. Druhý určuje, koľko po sebe idúcich kontrol musí tento prah prekročiť, aby sa spustil alert. Predvolene je prah vypnutý a počet prekročení je tri.

Dvojparametrový dizajn chráni pred falošnými pozitívami. Sieťové jittery sa dejú. Pauzy garbage collection sa dejú. Jediné navýšenie na 1 sekundu pri bežných 200 ms nestojí za pager o tretej v noci. Ale tri nasledujúce 1-sekundové odpovede už áno – je to trvalé spomalenie, nie len záblesk. Nastav prah na základe sledovaného bežného správania plus pohodlná rezerva: ak je p95 bežne 400 ms, prah 1000 ms. Ak je p95 50 ms (interné API), prah 200 ms.

S čím sa dobre kombinuje

Alerty času odozvy fungujú najlepšie v kombinácii s inými signálmi monitora. Kompletný obraz: prah odozvy signalizuje, že systém sa degraduje; HTTP kód povie, kedy naozaj pukne; SSL/doménové varovania – o výpadkoch riadených časom; alerty zmien DNS – o drifte konfigurácie. Štyri signály na tom istom monitore menia binárnu otázku „funguje?“ na úplnú observabilitu.

Aj dashboard v tom pomáha. Každý monitor zobrazuje sparkline posledných časov odozvy – rýchly vizuálny indikátor degradačných vzorcov. Rozšírené zobrazenie ukazuje priemery za 24 h, 7 dní a 30 dní. Ak vidíš priemer pomaly stúpať týždeň po týždni – je to včasný signál na preskúmanie skôr, než prekročí prah alertu.

Praktické prahy podľa typu stránky

• Landing page marketingové: 1500 ms je rozumné. Sú ťažké na obrázky a trackery; absolútna rýchlosť je menej dôležitá než stabilita.
• Produktové/kategórie ecommerce stránky: 800–1200 ms. Pomalý e-commerce zabíja konverzie; užšie prahy rýchlejšie chytia problém.
• Aplikačné dashboardy: 500–800 ms. Používatelia očakávajú svižnosť. Pomalý dashboard pôsobí dojmom, že produkt je pokazený.
• Verejné API: 200–400 ms pre jednoduché endpointy, viac pri výpočtovo náročných. Rozdelené podľa vrstiev.
• Interné mikroservisové health checky: 50–100 ms. Mali by byť takmer okamžité; pomalosť takmer vždy znamená reálny problém.

Čokoľvek si zvolíš, nevyber to raz a nezabudni na to. Prehodnocuj kvartálne podľa skutočných trendov. Ak dostávaš neustále alerty prekročenia, ktoré nereprezentujú skutočné problémy – prah je príliš úzky. Ak príde výpadok bez predchádzajúceho alertu z prahu – prah bol príliš voľný.

Routing alertov

Alerty prekročenia prahu sa posielajú tými istými kanálmi ako alerty down/recovery: Email, Telegram, Slack, Discord, SMS. Dodržiavajú rovnaký nočný pokoj. Sú zapisované do tej istej tabuľky alertov. Jediný rozdiel je v type udalosti („threshold“ namiesto „down“) a obsahu správy – píše aktuálny čas odozvy a nastavený prah, takže hneď vidíš veľkosť prekročenia.

Konfigurácia

Edituj ľubovoľný monitor. V formulári nastav pole „Prah času odozvy (ms)“ na zvolenú hodnotu. Voliteľne uprav „počet po sebe idúcich prekročení“, ak predvolený počet 3 nesedí s tvojou toleranciou. Ulož. Od ďalšieho cyklu každá kontrola porovná čas odozvy s prahom a po definovanom počte po sebe idúcich prekročení dostaneš upozornenie.

Najčastejšie otázky

• Aká metrika času odozvy sa zaznamenáva?

  Time To First Byte (TTFB) — milisekundy medzi odoslaním požiadavky a prijatím prvého bytu odpovede. Plus celkový čas stiahnutia celej odpovede. TTFB je najužitočnejšia jediná metrika pre zdravie servera.

• Aký je „dobrý“ čas odozvy?

  Záleží od lokality a obsahu. Pre statickú stránku s CDN: pod 100 ms je výborné, pod 300 ms je OK. Pre dynamické aplikácie: pod 500 ms je OK, pod 1000 ms akceptovateľné, nad 2000 ms už pôsobí pomaly. Porovnávaj s vlastnými historickými údajmi, nie s absolútnymi číslami.

• Môžem dostať alert ak čas odozvy prekročí prah?

  Áno. Každý monitor má voliteľný prah času odozvy. Ak 3 po sebe idúce kontroly prah prekročia, dostaneš alert „pomalá odozva“. Požiadavka 3 kontrol zabráni falošným poplachom spôsobeným jednotlivým výpadkom siete.

• Odkiaľ sa meria čas odozvy?

  Z našich 13 geografických kontrolných bodov (Európa, Severná Amerika, Ázia, Južná Amerika, Oceánia). Pre single-region monitorovania sú časy z najbližšieho regiónu. Pre multi-region sa každý región meria nezávisle – užitočné na detekciu regionálnych CDN problémov.

• Zobrazuje dashboard trendy času odozvy?

  Áno – 30-dňový kĺzavý priemer, denné max/min a percentily (p50, p95). Užitočné pri plánovaní kapacity: ak p95 stúpol z 800 ms na 1500 ms behom mesiaca, servery sú preťažené aj keď uptime % ostáva na 100%.