Sledování doby odezvy

Proč si doba odezvy zaslouží vlastní upozornění

Standardní uptime alerty se opírají o binární signál: běží nebo neběží. Šedá zóna mezi tím – běží, ale pomalu – je místo, kde skutečně žije většina moderních výpadků. Špatně nastavený dotaz do databáze začne místo 50 ms trvat 4 sekundy. Únik paměti způsobuje skoky při garbage collection. Externí API, na které volá backend, začne kolísat. Nic z toho stránku úplně nezničí, ale činí ji nepoužitelnou – a jsou to rané signály havárie vzdálené hodinu či dvě.

Monitoring doby odezvy zachytí zpomalení ještě dřív, než se z něj stane havárie. Nastavíš si práh pro každý monitor zvlášť a když doba odezvy několikrát za sebou překročí tento práh, dostaneš upozornění. Než upozornění přijde, máš ještě čas vše prověřit, navýšit kapacitu, omezit problémové volání nebo zrušit nasazení, které problém spustilo.

Jak fungují prahy v DiagnoSEO Uptime Monitoring

Každý monitor lze nastavit pomocí dvou parametrů: rt_threshold_ms a rt_threshold_breaches. První znamená dobu odezvy v milisekundách, kterou považuješ za akceptovatelnou. Druhý znamená, kolik po sobě jdoucích kontrol ji musí překročit, aby došlo k upozornění. Výchozí nastavení je práh vypnutý a počet překročení tři.

Dvouparametrový design chrání před falešně pozitivními výsledky. Síťový jitter se stává. Pauzy při garbage collection také. Jednorázový skok na 1 sekundu u běžných 200 ms nestojí za upozornění ve tři ráno. Ale tři po sobě jdoucí 1sekundové odpovědi už ano – to je trvalejší zpomalení, ne záblesk. Práh vyberte na základě pozorovaného normálního chování plus malou rezervu: pokud je p95 běžně 400 ms, nastavte práh na 1000 ms. Pokud je p95 50 ms (interní API), práh 200 ms.

S čím si nejlépe rozumí

Práh doby odezvy funguje nejlépe ve spojení s dalšími signály monitoru. Kompletní obrázek: práh doby odezvy říká, že se systém degraduje; HTTP kód ukazuje, kdy skutečně padá; SSL/domain warningy – ukazují havárie spojené s časem; DNS změnová upozornění – ukazují na posun konfigurace. Čtyři signály na jednom monitoru mění binární „jede/ne“ na plnou observabilitu.

Pomáhá i dashboard. Každý monitor ukazuje sparkline posledních dob odezvy – rychlý vizuální ukazatel vzorců degradace. Rozšířený pohled ukazuje průměry za 24h, 7d a 30d. Když vidíš průměr, který týden po týdnu stoupá – je to včasný signál k prozkoumání, než překročí práh pro upozornění.

Praktické prahy dle typu stránky

• Marketingové landing page: 1500 ms je rozumné. Jsou plné obrázků a tracking skriptů; absolutní rychlost je méně důležitá než stabilita.
• Produktové stránky/kategorie e-commerce: 800–1200 ms. Pomalý e-commerce zabíjí konverze; užší prahy odhalí problém rychleji.
• Aplikační dashboardy: 500–800 ms. Uživatelé očekávají svižnost. Pomalé dashboardy budí dojem nefungujícího produktu.
• Veřejná API: 200–400 ms pro jednoduché endpointy, výše pro náročnější. Rozdělte je na úrovně.
• Interní microservices health-checky: 50–100 ms. Ty mají být téměř okamžité; pomalost téměř vždy značí skutečný problém.

Cokoliv si nastavíš, nenastavuj to jednou provždy a nezapomeň. Vyhodnoť znovu každé čtvrtletí podle trendů, které skutečně vidíš. Pokud stále dostáváš upozornění, která nereprezentují skutečné problémy – práh je příliš přísný. Pokud přijde havárie bez předchozího upozornění – byl moc volný.

Směrování upozornění

Upozornění na překročení prahu jsou posílána stejnými kanály jako upozornění na pád/obnovení: Email, Telegram, Slack, Discord, SMS. Podle stejného nastavení nočního ticha. Jsou logována do stejné tabulky alertů. Jediný rozdíl je typ události ("threshold" místo "down") a obsah zprávy – obsahuje aktuální dobu odezvy a nastavený práh, takže hned vidíš míru překročení.

Nastavení

Uprav jakýkoliv monitor. Ve formuláři zadej „Práh doby odezvy (ms)“ na zvolené číslo. Volitelně uprav „počet po sobě jdoucích překročení“, pokud ti výchozí 3 nevyhovuje. Ulož. Od příštího cyklu každá kontrola porovná dobu odezvy s prahem a po nastaveném počtu po sobě jdoucích překročení dostaneš oznámení.

Nejčastější dotazy

• Jaké metriky doby odezvy se zaznamenávají?

  Time To First Byte (TTFB) — milisekundy mezi odesláním požadavku a přijetím prvního bajtu odpovědi. K tomu celkový čas stažení celé odpovědi. TTFB je nejrelevantnější samostatná metrika pro zdraví serveru.

• Jaká je „dobrá“ doba odezvy?

  Záleží na lokalitě a obsahu. Pro statickou stránku s CDN: pod 100 ms je skvělé, pod 300 ms v pořádku. Pro dynamické aplikace: pod 500 ms je v pořádku, pod 1000 ms akceptovatelné, nad 2000 ms už je to pomalé. Porovnávej se svou vlastní historickou základnou místo absolutních hodnot.

• Mohu dostat upozornění, když čas odezvy překročí práh?

  Ano. Každý monitor má volitelný práh doby odezvy. Pokud 3 kontroly za sebou překročí práh, dostaneš upozornění „pomalá odezva“. Požadavek na 3 kontroly zamezí falešným poplachům od jednorázových výpadků sítě.

• Odkud se měří doba odezvy?

  Z našich 13 geografických měřicích bodů (Evropa, Severní Amerika, Asie, Jižní Amerika, Oceánie). Pro single-region monitor jsou hodnoty z nejbližšího regionu. Pro multi-region je každý region měřen samostatně – vhodné pro detekci regionálních CDN problémů.

• Ukazuje dashboard trendy dob odezvy?

  Ano – 30denní klouzavý průměr, denní maximum/minimum a percentily (p50, p95). Vhodné pro plánování kapacity: když p95 stouplo z 800 ms na 1500 ms během měsíce, tvé servery jsou přetížené i když uptime % zůstává na 100 %.