Vasteaikojen seuranta

Miksi vasteajan hälytys ansaitsee oman ilmoituksensa

Vakioseurannan uptime-hälytykset perustuvat binaariseen signaaliin: ylhäällä tai alhaalla. Harmaa alue niiden välissä – ylhäällä, mutta hidas – on paikka, jossa suurin osa nykyaikaisista häiriöistä oikeasti piilevät. Huonosti konfiguroitu tietokantakysely alkaa kestää 4 sekuntia 50 ms sijaan. Muistivuoto aiheuttaa garbage collection -piikkejä. Ulkoinen API, johon backend soittaa, alkaa pätkiä. Mikään näistä ei riko sivua täysin, mutta tekee siitä käyttökelvottoman – ja nämä ovat varhaisia merkkejä viiveellä lähestyvästä isommasta häiriöstä.

Vasteajan seuranta nappaa hidastelun ennen kuin siitä tulee vika. Konfiguroit kynnyksen monitorikohtaisesti, ja kun vasteaika ylittää sen useammassa peräkkäisessä tarkistuksessa, saat hälytyksen. Ennen kuin hälytys menee läpi, sinulla on vielä aikaa tutkia tilanne, skaalata, rajoittaa ongelmakutsua tai perua laukaisun aiheuttanut julkaisu.

Miten kynnykset toimivat DiagnoSEO Uptime Monitoringissa

Jokainen monitori voidaan säätää kahdella parametreilla: rt_threshold_ms ja rt_threshold_breaches. Ensimmäinen on vasteaika millisekunneissa, jonka hyväksyt. Toinen määrittää, kuinka monen peräkkäisen tarkistuksen täytyy ylittää raja, ennen kuin hälytys lähetetään. Oletuksena kynnys on pois päältä ja ylitysten määrä kolme.

Kaksiparametrinen muotoilu torjuu harhatulkinnat. Verkkojen värähtelyä sattuu. Garbage collection -viiveitä tulee. Yksittäinen 1 sekunnin piikki 200 ms normaalista ei ole yön kolmen aikaan pagerin arvoinen. Mutta kolme peräkkäistä 1 sekunnin vastausta jo on – pysyvä hidastelu, ei sattuma. Valitse kynnys havaittujen normaaliarvojen ja reilun marginaalin perusteella: jos p95 on tyypillisesti 400 ms, kynnys 1000 ms. Jos p95 on 50 ms (sisäinen API), kynnys 200 ms.

Mihin tämä yhdistyy hyvin

Vasteaikojen hälytykset toimivat parhaiten yhdessä muiden valvontainfojen kanssa. Kokonaiskuva: vasteajankynnys kertoo, että järjestelmä heikkenee; HTTP-koodi kertoo, milloin se oikeasti hajosi; SSL-/verkkotunnusvaroitukset kertovat kellosta johtuvista vioista; DNS-muutoshälytykset konfiguraation muutoksista. Yhdessä neljä signaalia yhdellä monitorilla muuttavat binäärisen "toimiiko" täydeksi havainnointitasoksi.

Myös Dashboard auttaa tässä. Jokainen monitori näyttää sparkline-viivan viimeisimmistä vasteajoista – nopea visuaalinen indikaattori heikentymiskaavoista. Laajennettu näkymä näyttää 24h, 7d ja 30d vasteaikojen keskiarvot. Jos huomaat, että keskiarvo hiipii ylöspäin viikko viikolta – se on aikainen varoitusmerkki, johon kannattaa tarttua ennen kuin se ylittää hälytyskynnyksen.

Käytännön kynnykset sivutyypeittäin

• Markkinoinnin laskeutumissivut: 1500 ms on järkevä. Niissä on paljon kuvia ja seurantaskriptejä; ehdoton nopeus on vähemmän tärkeä kuin vakaus.
• Tuotesivut / verkkokauppojen kategoriat: 800-1200 ms. Hidas verkkokauppa tappaa konversiot; tiukemmat kynnystasot löytävät ongelmat nopeammin.
• Sovellusten hallintapaneelit: 500-800 ms. Käyttäjät odottavat nopeutta. Hidas dashboard saa tuotteen vaikuttamaan rikkinäiseltä.
• Julkiset API:t: 200-400 ms yksinkertaisille endpointseille, korkeampi rajapinta raskaille laskutoiminnoille. Jaottele tason mukaan.
• Sisäiset mikropalveluiden health checkit: 50-100 ms. Näiden pitäisi olla lähes välittömiä; hitaus on lähes aina oikea ongelma.

Mitä valitsetkin, älä tee sitä kerran ja unohda. Tarkista tasot uudelleen neljännesvuosittain oikeiden trendien perusteella. Jos saat jatkuvasti hälytyksiä, jotka eivät kuvaa todellisia ongelmia – kynnys on liian tiukka. Jos tulee vika ilman ennakoivaa hälytystä – kynnys on ollut liian löysä.

Hälytysten reititys

Kynnysarvon ylityshälytykset lähetetään samoja kanavia pitkin kuin down/recovery-hälytykset: sähköposti, Telegram, Slack, Discord, SMS. Ne kunnioittavat samaa yörauhaa. Kaikki kirjataan samaan hälytystaulukkoon. Ainoa ero on tapahtuman tyyppi ("threshold" downin sijaan) ja viestin sisältö – siinä näkyy nykyinen vasteaika ja asetettu kynnys, joten näet heti ylityksen suuruuden.

Asetukset

Muokkaa mitä tahansa monitoria. Aseta lomakkeeseen "Vasteajan kynnys (ms)" sopivaan arvoon. Halutessasi voit säätää "peräkkäiset ylitykset", jos oletusarvo 3 ei ole sopiva. Tallenna. Seuraavasta jaksosta alkaen jokainen tarkistus vertaa vasteaikaa kynnykseen, ja määritetyn määrän peräkkäisiä ylityksiä jälkeen saat ilmoituksen.

Usein kysytyt kysymykset

• Mitä vasteajan mittareita tallennetaan?

  Time To First Byte (TTFB) — millisekunnit pyynnön lähettämisestä ensimmäisen vastausbaitin saamiseen. Lisäksi koko vasteen latauksen aika. TTFB on hyödyllisin yksittäinen mittari palvelimen kunnon arviointiin.

• Mikä on "hyvä" vasteaika?

  Riippuu sijainnista ja sisällöstä. Staattiselle sivulle CDN:n kautta: alle 100 ms on loistava, alle 300 ms on OK. Dynaamisille sovelluksille: alle 500 ms on OK, alle 1000 ms hyväksyttävissä, yli 2000 ms tuntuu hitaalta. Vertaa omiin historiallisiin arvoihisi ennemmin kuin ehdottomiin numeroihin.

• Voinko saada hälytyksen jos vasteaika ylittää kynnyksen?

  Kyllä. Jokaisessa monitorissa on valinnainen vasteajan kynnys. Jos 3 peräkkäistä tarkistusta ylittää kynnyksen, saat hälytyksen "hidas vaste". Kolmen tarkistuksen vaatimus estää virhehälytykset satunnaisista verkkokatkoksista.

• Mistä vasteaika mitataan?

  Meidän 13 maantieteellisestä tarkistuspisteestä (Eurooppa, Pohjois-Amerikka, Aasia, Etelä-Amerikka, Oseania). Yksialue-monitorilla ajat ovat lähimmästä alueesta. Monialue-monitorissa jokainen alue mitataan erikseen – hyödyllistä alueellisten CDN-ongelmien tunnistamiseen.

• Näyttääkö dashboard vasteajan trendejä?

  Kyllä – 30 päivän liukuva keskiarvo, päivittäiset maksimi/minimi ja prosenttipisteet (p50, p95). Hyödyllinen kapasiteetin suunnitteluun: jos p95 kasvaa 800 ms:stä 1500 ms:iin kuukaudessa, palvelimesi ylikuormittuvat vaikka uptime-% pysyy 100:ssa.