Reageerimisaja jälgimine

Miks vastuseaeg väärib omaette hoiatust

Tavalised uptime-hoiatused põhinevad binaarsignaalil: üleval või maas. Hall ala nende vahel – üleval, aga aeglane – on koht, kus enamik tänapäevaseid tõrkeid tegelikult tekivad. Halvasti seadistatud andmebaasipäring hakkab kestma 4 sekundit 50 ms asemel. Mäluleke põhjustab garbage collection'i hüppeid. Väline API, mida backend kutsub, hakkab tõrkuma. Ükski neist ei riku lehte täielikult, kuid muudab selle kasutamiskõlbmatuks – ning need on varased märgid tõrkest, mis on veel tunni või kahe kaugusel.

Vastuseaja monitoorimine tabab aeglustumise enne, kui see muutub tõrkeks. Sa seadistad iga monitori jaoks künnise ja kui vastuseaeg ületab selle mitmel järjestikusel kontrollimisel, saad hoiatuse. Enne kui hoiatus tuleb, on sul aega olukorda uurida, skaleerida, piirata probleemseid päringuid või tagasi keerata deploy, mis selle põhjustas.

Kuidas töötavad künnised DiagnoSEO Uptime Monitoringus

Iga monitori saab seadistada kahe parameetriga: rt_threshold_ms ja rt_threshold_breaches. Esimene näitab vastuseaja millisekundites, mida pead aktsepteeritavaks. Teine määrab, mitu järjestikust ikkontrolli peab künnist ületama, et hoiatus saadetakse. Vaikimisi on künnis välja lülitatud ning ületuste arv on kolm.

Kahesüsteemne disain kaitseb valepositiivsete eest. Võrgu jitter juhtub. Garbage collection'i pausid juhtuvad. Üksik 1-sekundine hüpe 200 ms baasiga pole väärt äratust kell 3 öösel. Aga kolm järjestikust 1-sekundilist vastust juba tähendavad püsivat aeglust, mitte juhuslikku sähvatust. Vali künnis oma tavapärase käitumise ja mugava puhvri alusel: kui p95 on tavaliselt 400 ms, vali künniseks 1000 ms. Kui p95 on 50 ms (sisemine API), siis künnis 200 ms.

Millega kombineerida

Vastuseaja hoiatused töötavad kõige paremini koos teiste monitori signaalidega. Täielik pilt: vastuseaja künnis näitab, et süsteem degradeerub; HTTP kood annab teada, kui tegelikult miski katki läheb; SSL/domeeni hoiatused märgivad kellaajast sõltuvaid tõrkeid; DNS muudatuste hoiatused – konfiguratsiooni triivi. Kõik neli signaali ühes monitoris muudavad binaarse "kas töötab" täisväärtuslikuks jälgitavuseks.

Ka dashboard aitab selles. Iga monitor kuvab viimaste vastusaegade sparkline'i – kiire visuaalne viide degradatsioonimustritele. Laiendatud vaade näitab 24h, 7d ja 30d vastusaegade keskmisi. Kui näed, et keskmine tõuseb nädalast nädalasse – see on varajane märk, mida tasub uurida juba enne, kui see hoiatuskünnise ületab.

Praktilised künnised lehe tüüpide kaupa

• Turunduslikud maandumislehed: 1500 ms on mõistlik. Need on rasked piltide ja tracker-skriptidega; absoluutne kiirus pole nii tähtis kui stabiilsus.
• Toote-/e-poe kategooria lehed: 800-1200 ms. Aeglane e-pood tapab konversioonid; kitsamad künnised aitavad probleeme kiiremini avastada.
• Rakenduste dashbordid: 500-800 ms. Kasutajad ootavad reageerimiskiirust. Aeglane dashboard jätab tootele vigase mulje.
• Avalikud API-d: 200-400 ms lihtsate endpoint'ide puhul, rohkem kui vajatakse arvutusi. Jaga need tasemete kaupa.
• Sisemised mikroteenuste health check'id: 50-100 ms. Peaksid olema peaaegu kohesed; aeglus tähistab peaaegu alati tõelist probleemi.

Ükskõik mida valid, ära tee seda üks kord ja unusta. Hinda künniseid kord kvartalis, põhinedes tegelikel trendidel. Kui saad pidevalt hoiatusi, mis reaalseid probleeme ei tähenda – künnis on liiga range. Kui tekib tõrge ilma eelneva künnise hoiatuseta – künnis oli liiga lõtv.

Hoiatuste suunamine

Künnise ületamise hoiatused saadetakse samade kanalite kaudu nagu down/recovery hoiatused: Email, Telegram, Slack, Discord, SMS. Öörahu reeglid kehtivad samuti. Hoiatused on logitud samasse hoiatuste tabelisse. Ainus erinevus on sündmuse tüüp ("threshold" "down"'i asemel) ning teate sisu – see näitab jooksva vastusaja ja seadistatud künnise, et näeksid kohe, kui palju künnist ületati.

Seadistamine

Muuda ükskõik millist monitori. Vormis määra "Vastuseaja künnis (ms)" soovitud väärtusele. Soovi korral kohanda "järjestikused ületused", kui vaikimisi 3 ei sobi sinu tolerantsiga. Salvesta. Järgmisest tsüklist alates võrreldakse vastusaega künnisega, ja pärast seadistatud järjestikust ületust saad teavituse.

Korduma kippuvad küsimused

• Millist vastuseaja mõõdikut registreeritakse?

  Time To First Byte (TTFB) — millisekundid alates päringu saatmisest kuni esimese vastusbaidi saabumiseni. Lisaks kogu täisvastuse allalaadimise aeg. TTFB on üks kasulikumaid mõõdikuid serveri tervise hindamiseks.

• Milline on "hea" vastuseaeg?

  Sõltub asukohast ja sisust. Staatilise lehe puhul CDN-iga: alla 100 ms on suurepärane, alla 300 ms on hea. Dünaamiliste rakenduste puhul: alla 500 ms on hea, alla 1000 ms vastuvõetav, üle 2000 ms tundub aeglane. Võrdle pigem oma ajaloolise andmestikuga kui absoluutsete arvudega.

• Kas saan hoiatuse, kui vastuseaeg ületab künnise?

  Jah. Iga monitoril saab seada vabatahtliku vastuseaja künnise. Kui 3 järjestikust kontrolli ületab selle, saad hoiatuse "slow response". Nõue kolmele tulemusele takistab üksikutest võrguhäiretest tulenevaid valehäireid.

• Kust mõõdetakse vastuseaega?

  Meie 13 geograafilisest kontrollpunktist (Euroopa, Põhja-Ameerika, Aasia, Lõuna-Ameerika, Okeaania). Single-region monitoridel võetakse aeg lähimast regioonist. Multi-region monitoride puhul mõõdetakse iga regiooni iseseisvalt – mugav regionaliseeritud CDN-i probleemide leidmiseks.

• Kas dashboard näitab vastuseaja trende?

  Jah — 30-päevane libisev keskmine, päeva max/min ning percentiilid (p50, p95). Hea mahutavusplaneerimiseks: kui p95 tõusis kuuga 800 ms-lt 1500 ms-ni, on serverid ülekoormatud kuigi uptime % on jätkuvalt 100%.