Válaszidő-figyelés

Miért érdemel a válaszidő külön figyelmeztetést

A szokásos rendelkezésre állási riasztások bináris jelzésen alapulnak: működik vagy nem működik. A szürke zóna a kettő között – működik, de lassan – az a hely, ahol a legtöbb modern hiba valójában megjelenik. Egy rosszul konfigurált adatbázis-lekérdezés 50 ms helyett 4 másodpercig tart. Memóriaszivárgás miatt ugrik a szemétgyűjtés ideje. A backend által hívott külső API ingadozni kezd. Ezek egyike sem teszi teljesen használhatatlanná az oldalt, de elégtelenné teszi azt – és ezek órákkal korábban jelennek meg, mint a tényleges leállás.

A válaszidő monitorozása még azelőtt észleli a lassulást, hogy abból hiba lenne. Monitoronként állíthatsz be küszöbértéket, és ha a válaszidő több egymást követő ellenőrzésben túllépi azt, akkor kapsz figyelmeztetést. Mielőtt a riasztás elindul, van még időd vizsgálódni, skálázni, leszabályozni a problémás hívást, vagy visszavonni azt a deployt, amely ezt okozta.

Hogyan működnek a küszöbök a DiagnoSEO Uptime Monitoringban

Minden monitornál két paraméter adható meg: rt_threshold_ms és rt_threshold_breaches. Az első az általad elfogadhatónak tartott válaszidő ezredmásodpercben. A második, hogy hány egymást követő lépésnek kell túllépnie ezt, hogy riasztás induljon. Alapértelmezésben a küszöb ki van kapcsolva, a túllépések száma pedig három.

A kétparaméteres kialakítás védi monitorozást a téves pozitív találatoktól. Hálózati jitter előfordul. A szemétgyűjtés szünetei megtörténnek. Egyetlen 1 másodperces ugrás 200 ms átlag mellett nem éri meg, hogy éjjel 3-kor riasztást kapj. De három egymás utáni 1 mp-es válasz már igen – az már tartós lassulás, nem pillanatnyi kilengés. A küszöbértéket a megfigyelt normál működés és egy kényelmes ráhagyás alapján válaszd: ha a p95 érték általában 400 ms, a küszöb legyen 1000 ms. Ha a p95 50 ms (belső API), a küszöb legyen 200 ms.

Mivel érdemes kombinálni

A válaszidő-figyelmeztetések más monitorjelek mellett működnek a leghatékonyabban. Teljes kép: a válaszidő küszöb mutatja, ha a rendszer degradálódik; a HTTP kód, ha tényleg megtörik; az SSL/domain figyelmeztetések időalapú hibákat jeleznek; a DNS-változás riasztások konfigurációs eltéréseket. Négy ilyen jel egy monitoron a bináris "működik-e" helyett tényleges átláthatóságot ad.

A dashboard szintén segíti ezt. Minden monitor megmutatja a legutóbbi válaszidők szikragrafikonját – gyors vizuális visszajelzés a degradációs mintákra. A kibővített nézet mutatja a 24h, 7 nap és 30 napos átlagokat. Ha látod, hogy az átlag hétről hétre kúszik felfelé – ez korai jel, amit érdemes kivizsgálnod, mielőtt elérné a riasztás küszöbét.

Gyakorlati küszöbök oldal-típus szerint

• Marketing landing oldalak: 1500 ms ésszerű. Ezek tele vannak képekkel és követőkódokkal; az abszolút gyorsaság kevésbé fontos, mint a stabilitás.
• Termékoldalak/e-kereskedelmi kategóriák: 800–1200 ms. A lassú webshop visszaveti a konverziót; szigorúbb küszöbökkel gyorsabban csíped el a hibákat.
• Alkalmazás dashboardok: 500–800 ms. A felhasználók gyorsaságot várnak. A lassú dashboard miatt a termék hibásnak tűnik.
• Publikus API: 200–400 ms egyszerű végpontoknál, számításigényesebb esetekben ennél magasabb lehet. Rangsorold ezeket!
• Belső mikroszervizes egészség-ellenőrzések: 50–100 ms. Szinte azonnali reakció elvárt; bármilyen lassúság szinte biztosan valós hibát jelent.

Bármit is választasz, ne tedd meg egyszer, majd felejtsd el. Értékeld újra negyedévente, a látott trendek alapján. Ha folyamatosan olyan figyelmeztetéseket kapsz, amelyek nem jelentenek valódi problémát, akkor túl szűk lett a küszöb. Ha hiba van riasztás előzetes küszöb-átlépés nélkül, akkor túl laza volt a küszöb.

Riasztás irányítása

A küszöb-átlépéses figyelmeztetések ugyanazokon a csatornákon érkeznek, mint a downtime/up riasztások: Email, Telegram, Slack, Discord, SMS. Ugyanazt az éjszakai csendet tiszteletben tartják. Mind bekerülnek az azonos riasztástáblába. Az egyetlen különbség az esemény típusa ("threshold" a "down" helyett) és az üzenet tartalma – megadja az aktuális válaszidőt és a beállított küszöböt, így rögtön látod, mennyivel lépte túl azt.

Beállítás

Szerkeszd bármelyik monitort. Az űrlapon állítsd be a "Válaszidő küszöb (ms)" mezőt a kívánt értékre. Opcionálisan módosítsd a "sorozatos átlépések" számát, ha az alapértelmezett 3 nem illik a tűrésedhez. Mentsd el. Innentől minden lekérdezés összeveti a válaszidőt a küszöbbel, és a konfigurált számú átlépés után kapsz értesítést.

Gyakran ismételt kérdések

• Milyen válaszidő-mutatót rögzítünk?

  Time To First Byte (TTFB) — az az ezredmásodperc, ami az első bájt válasz beérkezéséig eltelik a kérés elküldése után. Plusz a teljes válasz letöltésének ideje. A TTFB a leghasznosabb egyszerű mutató a szerver állapotára.

• Mi számít „jó” válaszidőnek?

  Függ a földrajzi helytől és tartalomtól. Statikus oldal CDN-nel: 100 ms alatt kiváló, 300 ms alatt jó. Dinamikus alkalmazásnál: 500 ms alatt jó, 1000 ms alatt elfogadható, 2000 ms fölött már lassúnak látszik. Saját múltbeli adataidhoz viszonyítsd, ne abszolút értékekhez.

• Kaphatok riasztást, ha a válaszidő átlépi a küszöböt?

  Igen. Minden monitorhoz beállítható válaszidő-küszöb. Ha 3 egymást követő ellenőrzés túllépi a küszöböt, "lassú válasz" figyelmeztetést kapsz. A 3 ellenőrzéses feltétel megakadályozza a téves riasztásokat pillanatnyi hálózati zavarok esetén.

• Honnan mérjük a válaszidőt?

  A 13 földrajzi tesztpontunkról (Európa, Észak-Amerika, Ázsia, Dél-Amerika, Óceánia). Egy régiós monitor esetén a legközelebbi régió eredménye jelenik meg. Több régiós monitor minden régiót külön mér – ez hasznos a CDN regionális problémáinak felfedezéséhez.

• Mutat-e a dashboard válaszidő-trendeket?

  Igen – 30 napos gördülő átlag, napi max/min és percentilisek (p50, p95). Segít a kapacitástervezésben: ha a p95 800 ms-ról 1500 ms-ra nőtt egy hónap alatt, a szervereid túlterheltek, még ha az uptime % 100 is marad.