Overvåkning av responstid

Hvorfor responstiden fortjener sin egen varsling

Standard oppetidsvarsler baserer seg på et binært signal: oppe eller nede. Gråsonen imellom – oppe, men tregt – er området der de fleste moderne feil faktisk lever. En feilkonfigurert databasforespørsel begynner å ta 4 sekunder i stedet for 50ms. Memory leak gir hopp i garbage collection. Et eksternt API som backend kaller til, begynner å flimre. Ingen av disse tingene ødelegger siden fullstendig, men de gjør den ubrukelig – og dette er tidlige varselsignaler på et større havari som kan oppstå om en time eller to.

Overvåking av responstid fanger opp tregheter før de utvikler seg til nedetid. Du setter en terskel per overvåker, og når responstiden overskrider denne i flere påfølgende sjekker, får du et varsel. Før varslet sendes, har du fortsatt tid til å undersøke, skalere opp, throttle problematiske kall eller rulle tilbake deployen som trigget det.

Hvordan terskler fungerer i DiagnoSEO Uptime Monitoring

Hver overvåker kan konfigureres med to parametre: rt_threshold_ms og rt_threshold_breaches. Den første er responstiden i millisekunder som du anser som akseptabel. Den andre bestemmer hvor mange påfølgende sjekker som må overskride terskelen før varslet går. Som standard er terskelen avskrudd, og antall overskridelser er tre.

Designet med to parametre beskytter mot falske positiver. Nettverksstøy skjer. Garbage collection-pauser skjer. Et enkelt hopp til 1 sekund rundt normale 200ms er ikke verdt telefonen kl. 03 om natten. Men tre påfølgende 1-sekunders-responser er det – fordi det er varig treghet, ikke et blaff. Velg terskel basert på observerte normale data pluss en trygg margin: Om p95 vanligvis er 400 ms, bruk terskel på 1000 ms. Hvis p95 er 50 ms (internt API), valg 200 ms.

Hva det fungerer godt med

Varsler om responstid fungerer best i kombinasjon med andre monitor-signaler. Det komplette bildet: terskel for responstid sier at systemet degraderer; HTTP-kode sier når det faktisk knekker; SSL-/domenvarsler – om feil som drives av tid; varsler om DNS-endringer – om konfigurasjonsdrift. Sammen gjør fire signaler på samme overvåker det binære "fungerer det" til full observability.

Dashbordet hjelper også her. Hver overvåker viser en sparkline over siste responstider – et raskt visuelt signal om mønstre i degradering. Utvidet visning viser gjennomsnitt for 24t, 7d og 30d. Om du ser et snitt som kryper opp uke etter uke – er det et tidlig signal verdt å undersøke, før du passerer terskel for varsel.

Praktiske terskler etter sidetype

• Landingpages for markedsføring: 1500 ms er fornuftig. Disse er tunge på bilder og tracker-skript; stabilitet er viktigere enn ren hastighet.
• Produktsider/kategorier innen ecommerce: 800–1200 ms. Treg nettbutikk dreper konverteringer; strammere terskler fanger problemer raskere.
• App-dashboards: 500–800 ms. Brukere forventer responsivitet. Trege dashboards får produktet til å virke ødelagt.
• Offentlige API-er: 200–400 ms for enkle endepunkt, høyere for tunge beregninger. Lagdeling er lurt.
• Interne mikrotjenesters health-checks: 50–100 ms. Bør være nærmest umiddelbare; treghet betyr nesten alltid et reelt problem.

Uansett hva du velger – ikke velg én gang og glem det. Revurder kvartalsvis ut fra trendene du faktisk ser. Om du hele tiden får varsler om overskridelser som ikke representerer faktiske problemer – terskelen er for streng. Om du får driftsstans uten at terskelvarsling gikk på forhånd – terskelen var for romslig.

Varslingsruting

Varsler om terskeloverskridelse sendes via de samme kanalene som down/recovery-varsler: E-post, Telegram, Slack, Discord, SMS. De respekterer samme nattestillhet. Loggføres i samme varselstabell. Den eneste forskjellen er hendelsestypen ("threshold" i stedet for "down") og meldingsinnhold – dette inkluderer aktuell responstid og angitt terskel, så du umiddelbart ser hvor mye over grensen det er.

Konfigurasjon

Rediger hvilken som helst overvåker. I skjemaet setter du "Terskel for responstid (ms)" til ønsket tall. Tilpass eventuelt "påfølgende overskridelser" hvis standard 3 ikke passer din toleranse. Lagre. Fra neste syklus sammenlignes hver sjekkens responstid mot terskelen, og etter angitt antall påfølgende overskridelser får du varsling.

Ofte stilte spørsmål

• Hvilke responstidsmetrikker måles?

  Time To First Byte (TTFB) — millisekunder mellom å sende forespørselen og motta første byte av svaret. Pluss total tid for å hente hele svaret. TTFB er den mest nyttige enkeltmetrikken for serverens helse.

• Hva er en "god" responstid?

  Avhenger av sted og innhold. For statisk nettside med CDN: under 100 ms er flott, under 300 ms er OK. For dynamiske apper: under 500 ms er OK, under 1000 ms akseptabelt, over 2000 ms virker tregt. Sammenlign med egen historisk base istedenfor absolutte tall.

• Kan jeg få varsel om responstid overskrider terskelen?

  Ja. Hver overvåker har en valgfri terskel for responstid. Hvis tre påfølgende sjekker overskrider terskelen, mottar du et varsel om "treg respons". Kravet om tre sjekker forhindrer falske alarmer fra enkeltstående nettverksfall.

• Hvor måles responstiden fra?

  Fra våre 13 geografiske sjekkpunkter (Europa, Nord-Amerika, Asia, Sør-Amerika, Oseania). For single-region-overvåker kommer tidene fra nærmeste region. For multi-region måles hver region uavhengig – nyttig for å oppdage CDN-problemer i regioner.

• Viser dashboardet trender i responstid?

  Ja – 30-dagers glidende gjennomsnitt, daglige maks/min og percentiler (p50, p95). Nyttig til kapasitetsplanlegging: om p95 har gått fra 800 ms til 1500 ms på én måned, er serverne dine overbelastet selv om oppetid % holder seg på 100 %.