Nadzor časa odziva

Zakaj si čas odziva zasluži svoj lasten alarm

Standardni alarmi za dosegljivost temeljijo na binarnem signalu: deluje ali ne deluje. Siva cona vmes – deluje, a počasi – je v resnici prostor, kjer nastaja večina sodobnih izpadov. Slabo nastavljena poizvedba v bazo podatkov traja 4 sekunde namesto 50 ms. Puščanje pomnilnika povzroča skoke pri čiščenju smeti. Zunanji API, ki ga kliče backend, začne nihati. Nobena od teh stvari strani povsem ne pokvari, vendar jo naredi neuporabno – in to so zgodnji znaki okvar, ki se bodo zgodile čez uro ali dve.

Monitoring časa odziva ujame upočasnitev, preden postane izpad. Po pragu nastaviš posamezen monitor, in če je čas odziva presežen v nekaj zaporednih preverjanjih, prejmeš alarm. Še preden alarm sproži, imaš čas, da pogledaš težavo, skaliraš, zaviraš problematičen klic ali povrneš deploy, ki ga je povzročil.

Kako delujejo pragovi v DiagnoSEO Uptime Monitoring

Vsak monitor lahko nastaviš z dvema parametroma: rt_threshold_ms in rt_threshold_breaches. Prvi je čas odziva v milisekundah, ki ga šteješ za sprejemljivega. Drugi določa, kolikokrat zapored mora biti ta prag presežen, da se pošlje alarm. Privzeto je prag onemogočen, število prekoračitev pa je tri.

Dvoparametrski dizajn ščiti pred lažnimi alarmi. Mrežni jitter se zgodi. Zamiki zaradi čiščenja smeti se zgodijo. Enkraten skok na 1 sekundo, če je običajno 200 ms, ni vreden klica ob treh zjutraj. A trije zaporedni 1-sekundni odzivi že – to je obstojna upočasnitev, ne le zasvet. Prag izberi glede na normalno opazovano vedenje in varnostni rob: če je p95 običajno 400 ms, nastavi prag 1000 ms. Če je p95 50 ms (notranji API), prag 200 ms.

S čim gre najbolje skupaj

Alarmi časa odziva najbolje delujejo v kombinaciji z drugimi signali monitorja. Celovita slika: prag časa odziva pokaže, da se sistem slabša; HTTP koda pove, kdaj se zares zlomi; SSL/domain opozorila o časovnih napakah; DNS spremembe – o odmiku konfiguracije. Vse štiri signale na istem monitorju pretvorijo binarno "ali dela" v pravo opaznost sistema.

Dashboard k temu pomaga. Vsak monitor prikazuje sparkline zadnjih časov odziva – hiter vizualni pokazatelj vzorcev degradacije. Razširjen pogled prikaže povprečje za 24 ur, 7 dni in 30 dni. Če vidiš, da povprečje tedensko počasi raste – je to zgodnji znak, vreden pozornosti, še preden kaj preseže prag alarma.

Praktični pragovi po tipu strani

• Marketinške landing strani: 1500 ms je smiselno. Obremenjene so s slikami in sledilnimi skriptami; absolutna hitrost ni tako pomembna kot stabilnost.
• Izdelčne strani/kategorije ecommerce: 800–1200 ms. Počasni ecom uničuje konverzije; ožji pragovi ujamejo težave prej.
• Aplikacijske nadzorne plošče: 500–800 ms. Uporabniki pričakujejo odzivnost. Počasen dashboard daje vtis, da je izdelek pokvarjen.
• Javni API-ji: 200–400 ms za enostavne končne točke, več za zahtevnejše. Uredite po stopnjah.
• Notranji mikroservisni health check-i: 50–100 ms. Morali bi biti skoraj takojšnji; počasnost skoraj vedno pomeni pravo težavo.

Karkoli izbereš, ne nastavi enkrat in pozabi. Ponovno preveri četrtletno glede na dejanske trende, ki jih opaziš. Če stalno prejemaš alarme zaradi prekoračitev, ki ne pomenijo resničnih težav – je prag preozek. Če pride do izpada brez predhodnega alarma na pragu – je prag bil preohlapen.

Usmerjanje alarmov

Alarmi za prekoračitve praga so poslani po enakih kanalih kot down/recovery alarmi: Email, Telegram, Slack, Discord, SMS. Upoštevajo isto nočno tišino. Zabeleženi so v isti tabeli alarmov. Edina razlika je vrsta dogodka ("threshold" namesto "down") in vsebina sporočila – pove trenutni čas odziva in nastavljeni prag, tako da takoj vidiš za koliko je bil prekoračen.

Nastavitve

Uredi želeni monitor. V obrazcu nastavi "Prag časa odziva (ms)" na izbrano vrednost. Opcijsko prilagodi "zaporedne prekoračitve", če privzeta nastavitev 3 ni ustrezna za tvojo toleranco. Shrani. Od naslednjega cikla naprej vsaka preverba primerja čas odziva s pragom, in po nastavljeni številu zaporednih prekoračitev prejmeš obvestilo.

Pogosta vprašanja

• Katere metrike časa odziva se beležijo?

  Time To First Byte (TTFB) — milisekunde med pošiljanjem zahteve in prejemom prvega bajta odgovora. Poleg tega tudi skupni čas prenosa celotnega odgovora. TTFB je najbolj uporaben posamezni kazalnik za zdravje strežnika.

• Kakšen je "dober" čas odziva?

  Odvisno je od lokacije in vsebine. Za statično stran na CDN: pod 100 ms je odlično, pod 300 ms je OK. Za dinamične aplikacije: pod 500 ms je OK, pod 1000 ms sprejemljivo, nad 2000 ms se že zdi počasi. Primerjaj z lastnimi zgodovinskimi podatki namesto s popolnimi številkami.

• Ali lahko prejmem alarm, če čas odziva preseže prag?

  Da. Vsak monitor ima opcijski prag časa odziva. Če 3 zaporedni pregledi presežejo prag, prejmeš alarm "slow response". Zahteva 3 pregledov preprečuje lažne alarme zaradi posameznih mrežnih izpadov.

• Od kod se meri čas odziva?

  Iz naših 13 geografskih kontrolnih točk (Evropa, Severna Amerika, Azija, Južna Amerika, Oceanija). Pri monitorju za eno regijo je čas iz najbližje regije. Pri multi-region monitorju se vsaka regija meri posebej – uporabno za zaznavanje regionalnih težav s CDN-jem.

• Ali dashboard prikazuje trende časa odziva?

  Da – 30-dnevno drseče povprečje, dnevni maksimum/minimum in percentili (p50, p95). Uporabno za načrtovanje zmogljivosti: če p95 zraste iz 800 ms na 1500 ms v enem mesecu, se tvoji strežniki preobremenjujejo, čeprav ostaja uptime % na 100%.