Praćenje vremena odziva

Zašto vrijeme odgovora zaslužuje vlastiti alert

Standardni alerti uptime-a temelje se na binarnom signalu: gore ili dolje. Siva zona između - gore, ali sporo - tamo stvarno živi većina modernih kvarova. Loše konfiguriran upit prema bazi počne trajati 4 sekunde umjesto 50ms. Memory leak uzrokuje skokove u garbage collectionu. Vanjski API na koji backend zove počinje povremeno zatajivati. Ništa od ovoga ne kvari stranicu potpuno, ali ju čini neupotrebljivom - i to su rani signali kvara koji je udaljen sat ili dva.

Nadzor vremena odgovora hvata usporenja prije nego se pretvore u kvar. Konfiguriraš prag po monitoru, a kad vrijeme odgovora prijeđe prag u nekoliko uzastopnih provjera, dobivaš alert. Prije nego što alert stigne, imaš još malo vremena da istražiš slučaj, proširiš resurse, ograničiš problematični poziv ili povučeš deploy koji je to pokrenuo.

Kako funkcioniraju pragovi u DiagnoSEO Uptime Monitoring

Svaki monitor možeš konfigurirati s dva parametra: rt_threshold_ms i rt_threshold_breaches. Prvi je vrijeme odgovora u milisekundama koje smatraš prihvatljivim. Drugi je koliko uzastopnih provjera mora prijeći prag da bi alert bio poslan. Po defaultu je prag isključen, a broj prijelaza je tri.

Dizajn s dva parametra štiti od lažnih pozitivnih signala. Mrežni jitter se događa. Pauze zbog garbage collectiona događaju se. Pojedinačan skok na 1 sekundu kod osnovnih 200ms nije vrijedan poziva u 3 ujutro. Ali tri uzastopna odgovora od 1 sekunde već jesu - to je trajno usporenje, ne samo kratak skok. Odaberi prag na temelju uobičajenog ponašanja koje primjećuješ plus prikladna margina: ako je p95 normalno 400ms, prag 1000ms. Ako je p95 50ms (interni API), prag 200ms.

S čime se dobro kombinira

Alerti na vrijeme odgovora najbolje funkcioniraju u kombinaciji s drugim signalima monitora. Potpuna slika: prag vremena odgovora govori da se sustav degradira; HTTP kod daje signal kad se stvarno lomi; SSL/domenske opomene - o kvarovima vezanim uz vrijeme; alerti na promjene DNS-a - o driftanju konfiguracije. Zajedno četiri signala na istom monitoru mijenjaju binarno "radi li" u punu nadziranost.

Dashboard tome doprinosi. Svaki monitor prikazuje sparkline posljednjih vremena odgovora - brzi vizualni pokazatelj obrazaca degradacije. Prošireni prikaz prikazuje prosjeke vremena za 24h, 7d i 30d. Ako vidiš da prosjek puzi prema gore iz tjedna u tjedan - to je rani signal koji vrijedi istražiti prije nego što prijeđe prag alerta.

Praktični pragovi po tipu stranice

• Marketinške landing stranice: 1500ms je razumno. Teške su zbog slika i trackera; apsolutna brzina manje znači od stabilnosti.
• Proizvodne/kategorijske stranice za ecommerce: 800-1200ms. Spori ecommerce ubija konverzije; uži pragovi hvataju probleme brže.
• Aplikacijski dashboardi: 500-800ms. Korisnici očekuju brzinu. Spori dashboardi čine da proizvod djeluje pokvaren.
• Javni API: 200-400ms za jednostavne endpointove, više za teške računske. Razvrstaj ih.
• Interni health-check mikroservisa: 50-100ms. Trebali bi biti gotovo trenutačni; usporenje gotovo uvijek znači stvarni problem.

Što god odabrao, nemoj odabrati jednom i zaboraviti. Preispitivaj kvartalno na temelju trendova koje zapravo vidiš. Ako stalno dobivaš alertove zbog prekoračenja koji nisu stvarni problemi - prag je preuzak. Ako dobiješ kvar bez prethodnog alerta na prag - prag je bio preširok.

Routanje alertova

Alerti zbog prekoračenja praga idu istim kanalima kao alerti down/recovery: Email, Telegram, Slack, Discord, SMS. Poštuju istu tišinu noću. Logirani su u istoj tablici alerta. Jedina razlika je tip događaja ("threshold" umjesto "down") i sadržaj poruke - prikazuje trenutno vrijeme odgovora i konfigurirani prag, pa odmah vidiš veličinu prekoračenja.

Konfiguracija

Uredi bilo koji monitor. U formi postavi "Prag vremena odgovora (ms)" na željeni broj. Po želji prilagodi "uzastopna prekoračenja" ako ti defaultna 3 ne odgovaraju. Spremi. Od sljedećeg ciklusa svaka provjera uspoređuje vrijeme odgovora s pragom, a nakon podešenog broja uzastopnih prekoračenja dobivaš obavijest.

Najčešća pitanja

• Koja metrika vremena odgovora se bilježi?

  Time To First Byte (TTFB) — milisekunde između slanja zahtjeva i dolaska prvog bajta odgovora. Plus ukupno vrijeme preuzimanja cijelog odgovora. TTFB je najkorisnija pojedinačna metrika za zdravlje servera.

• Koje je "dobro" vrijeme odgovora?

  Ovisi o lokaciji i sadržaju. Za statičku stranicu s CDN-om: ispod 100ms je odlično, ispod 300ms je OK. Za dinamičke aplikacije: ispod 500ms je OK, ispod 1000ms prihvatljivo, iznad 2000ms djeluje sporo. Uspoređuj sa svojom vlastitom povijesnom bazom, a ne s apsolutnim brojkama.

• Mogu li dobiti alert kad vrijeme odgovora prijeđe prag?

  Da. Svaki monitor ima opcionalni prag vremena odgovora. Ako 3 uzastopne provjere prijeđu prag, dobivaš alert "slow response". Zahtjev za 3 provjere sprječava lažne alarme zbog pojedinačnih mrežnih padova.

• Odakle se mjeri vrijeme odgovora?

  Iz naših 13 geografski raspoređenih točaka provjere (Europa, Sjeverna Amerika, Azija, Južna Amerika, Oceanija). Za single-region monitor vremena dolaze iz najbliže regije. Za multi-region svaki region se mjeri zasebno — korisno za otkrivanje regionalnih problema s CDN-om.

• Prikazuje li dashboard trendove vremena odgovora?

  Da — 30-dnevni pomični prosjek, dnevni maksimum/minimum i percentili (p50, p95). Korisno za planiranje kapaciteta: ako ti p95 poraste s 800ms na 1500ms tijekom mjeseca, tvoji serveri su preopterećeni iako uptime % ostaje 100%.