Atsako laiko stebėsena

Kodėl atsako laikas nusipelno atskiro įspėjimo

Standartiniai pasiekiamumo įspėjimai remiasi dvejetainiu signalu: veikia arba neveikia. Pilkoji zona tarp jų – veikia, bet lėtai – yra ta vieta, kur didžioji dalis šiuolaikinių sutrikimų iš tiesų ir gyvena. Netinkamai sukonfigūruota užklausa į duomenų bazę pradeda trukti 4 sekundes vietoj 50 ms. Atminties nutekėjimas sukelia šiukšlių surinkimo šuolius. Išorinis API, į kurį kviečia backend'as, ima svyruoti. Nė vienas iš šių dalykų visiškai nesugadina puslapio, bet padaro jį praktiškai nenaudojamą – ir tai yra ankstyvieji signalai apie gedimą, kuris ateis po valandos ar dviejų.

Atsako laiko stebėsena pastebi lėtėjimą dar prieš jam tampant gedimu. Pasirenki slenkstį kiekvienam monitoriui, ir jei atsako laikas jį viršija per kelis iš eilės tikrinimus, gauni įspėjimą. Prieš gaudamas įspėjimą dar turi laiko išanalizuoti problemą, padidinti pajėgumą, apriboti problematišką iškvietimą ar atsukti deploy'ų, kuris tai sukėlė.

Kaip veikia slenksčiai DiagnoSEO Uptime Monitoring

Kiekvienam stebėsenos taškui galima konfigūruoti du parametrus: rt_threshold_ms ir rt_threshold_breaches. Pirmasis – tai atsako laikas milisekundėmis, kurį laikai priimtinu. Antrasis – kiek iš eilės tikrinimų turi viršyti slenkstį, kad būtų išsiųstas įspėjimas. Pagal nutylėjimą slenkstis yra išjungtas, o iš eilės viršijimų skaičius – trys.

Dviejų parametrų dizainas saugo nuo klaidingų įspėjimų. Tinklo šuoliai pasitaiko. Šiukšlių surinkimo pauzės taip pat. Vienkartinis šuolis iki 1 sekundės kai bazinis yra 200 ms, neverta pažadinimo trečią nakties. Tačiau trys iš eilės 1 sekundės atsakai – jau taip: tai užsitęsęs lėtėjimas, o ne mirksnis. Pasirink slenkstį remdamasis stebimu normaliu elgesiu plius saugus rezervas: jeigu p95 dažniausiai – 400 ms, slenkstį – 1000 ms. Jei p95 – 50 ms (vidinis API), slenkstį – 200 ms.

Su kuo puikiai dera

Atsako laiko įspėjimai geriausiai veikia kartu su kitais monitoriaus signalais. Pilnas vaizdas: atsako laiko slenkstis parodo, kad sistema degraduoja; HTTP kodas parodo, kada tikrai lūžta; SSL/domeno įspėjimai – apie laikrodžio sukeltas avarijas; DNS pakeitimų įspėjimai – apie konfigūracijos nuokrypius. Kartu visi šie keturi signalai tame pačiame monitoriuje dvejetainį „ar veikia“ paverčia tikru stebimumu.

Prietaisų skydelis taip pat padeda. Kiekvienas monitorius rodo paskutinių atsako laikų „sparkline“ – greitą vizualinį degradacijos modelio indikatorių. Išplėstiniame rodinyje matosi vidurkiai per 24 val., 7 d. ir 30 d. Jei pamatai, kad vidurkis pamažu kyla savaitė po savaitės – tai ankstyvas signalas, verta ištirti dar prieš viršijant slenkstį.

Praktiniai slenksčiai pagal puslapio tipą

• Marketingo nukreipimo puslapiai: 1500 ms – protinga riba. Jie sunkūs dėl paveikslėlių ir sekimo skriptų; svarbu daugiau stabilumas nei absoliutus greitis.
• Produktų/e-komercijos kategorijų puslapiai: 800-1200 ms. Lėtas e-komercijos puslapis žudo konversiją; griežtesni slenksčiai leidžia greičiau pastebėti problemas.
• Programų prietaisų skydeliai: 500-800 ms. Vartotojai tikisi spartos. Lėti dashboard'ai leidžia produktui atrodyti sugedusiam.
• Viešieji API: 200-400 ms paprastiems endpoint'ams, daugiau skaičiavimų reikalaujantiems šiek tiek daugiau. Suskirstyk pagal sluoksnius.
• Vidiniai mikroservisų health check'ai: 50-100 ms. Turėtų būti beveik akimirksniški; lėtumas beveik visada reiškia rimtą problemą.

Ką bepasirinktum, nesirink vieną kartą ir nepamiršk. Persvarstyk kas ketvirtį pagal realius stebimus trendus. Jei nuolat gauni įspėjimų apie viršijimus, kurie neatspindi realių problemų – slenkstis per griežtas. Jei gauni sutrikimą be ankstesnio slenksčio įspėjimo – slenkstis buvo per laisvas.

Įspėjimų maršrutizavimas

Slenksčio viršijimo įspėjimai siunčiami tais pačiais kanalais, kaip ir down/atkūrimo įspėjimai: El. paštas, Telegram, Slack, Discord, SMS. Gerbiamas tas pats naktinio tylos laikotarpis. Visi jie žymimi toje pačioje įspėjimų lentelėje. Vienintelis skirtumas – įvykio tipas („threshold“ vietoj „down“) ir žinutės turinys – nurodomas dabartinis atsako laikas ir nustatytas slenkstis, tad iš karto matai viršijimo dydį.

Konfigūracija

Redaguok bet kurį monitorių. Formoje nustatyk „Atsako laiko slenkstis (ms)“ norimai reikšmei. Papildomai gali pritaikyti „iš eilės viršijimai“, jei 3 pagal nutylėjimą netinka tolerancijai. Išsaugok. Nuo kito ciklo kiekvienas tikrinimas lygina atsako laiką su slenksčiu, o po nustatyto iš eilės viršijimų skaičiaus gauni pranešimą.

Dažniausiai užduodami klausimai

• Kokie atsako laiko metrikai yra fiksuojami?

  Time To First Byte (TTFB) — milisekundės nuo užklausos išsiuntimo iki pirmo atsakymo baito gavimo. Plius visas laikas pilnam atsakymui parsiųsti. TTFB yra naudingiausias pavienis serverio sveikatos metrikas.

• Koks yra „geras“ atsako laikas?

  Priklauso nuo vietos ir turinio. Statiniam puslapiui su CDN: žemiau 100 ms yra puiku, žemiau 300 ms yra OK. Dinaminėms aplikacijoms: žemiau 500 ms yra OK, žemiau 1000 ms priimtina, virš 2000 ms jau atrodo nerangiai. Lygink su savo istoriniais duomenimis, o ne vien tik su absoliučiais skaičiais.

• Ar galiu gauti įspėjimą, kai atsako laikas viršija slenkstį?

  Taip. Kiekvienas monitorius turi pasirenkamą atsako laiko slenkstį. Jei 3 tikrinimai iš eilės viršys slenkstį, gausi „slow response“ įspėjimą. 3 tikrinimų reikalavimas apsaugo nuo klaidingų perspėjimų dėl pavienių tinklo praradimų.

• Iš kur matuojamas atsako laikas?

  Iš mūsų 13 geografinių tikrinimo taškų (Europa, Šiaurės Amerika, Azija, Pietų Amerika, Okeanija). Vieno regiono monitoriui rezultatai gaunami iš artimiausio regiono. Kelių regionų atveju kiekvienas regionas matuojamas atskirai — naudinga aptikti regioninius CDN sutrikimus.

• Ar prietaisų skydelyje matyti atsako laiko tendencijos?

  Taip — 30 dienų slenkantis vidurkis, kasdieniai max/min ir percentiliai (p50, p95). Naudinga planuojant pajėgumus: jei p95 per mėnesį išaugo nuo 800 ms iki 1500 ms, serveriai perkraunami nors uptime % išlieka 100%.