Overvågning af svartider

Hvorfor svartid fortjener sin egen alarm

Standard uptime-alamer bygger på et binært signal: oppe eller nede. Gråzonen imellem – oppe, men langsomt – er der, hvor de fleste moderne fejl reelt lever. En forkert konfigureret databaseforespørgsel varer pludselig 4 sekunder i stedet for 50ms. Memory leaks skaber udsving i garbage collection. Eksterne API'er, som backend'et kalder på, begynder at flimre. Ingen af disse ting ødelægger siden fuldstændigt, men gør den ubrugelig – og det er tidlige varsler om et større nedbrud en time eller to senere.

Overvågning af svartider fanger nedbremsningen, før det bliver til et nedbrud. Du konfigurerer en tærskel pr. monitor, og når svartiden overskrider den ved flere på hinanden følgende check, får du en alarm. Inden alarmen udløses, har du stadig tid til at undersøge sagen, skalere op, throttling af problematiske kald eller rulle det deploy tilbage, der udløste problemet.

Sådan fungerer tærskler i DiagnoSEO Uptime Monitoring

Hver monitor kan konfigureres med to parametre: rt_threshold_ms og rt_threshold_breaches. Førstnævnte er svartiden i millisekunder, du finder acceptabel. Sidstnævnte angiver, hvor mange efterfølgende checks der skal overskride tærsklen, før en alarm sendes. Som standard er tærsklen slået fra og antallet af overskridelser sat til tre.

Det to-parametre design beskytter mod falske positiver. Netværksjitter sker. Garbage collection-pauser sker. Et enkelt spring op til 1 sekund, når basis er 200ms, er ikke værd at få en alarm klokken 3 om natten for. Men tre på hinanden følgende 1-sekunders svar er – det er vedvarende nedbremsning, ikke et enkelt udfald. Vælg tærsklen baseret på observeret normalt adfærd plus en komfortabel margin: hvis p95 normalt er 400ms, så sæt tærsklen til 1000ms. Hvis p95 er 50ms (internt API), så brug 200ms.

Hvad det fungerer godt sammen med

Svartidsalarmer virker bedst i kombination med andre monitor-signaleringer. Det fulde billede: Svartids-tærskel siger, at systemet degraderer; HTTP-statuskode markerer, når det faktisk bryder sammen; SSL/domæne-advarsler – ved tidsbaserede fejl; DNS-ændringsalarmer – ved konfigurationsdrift. Sammen giver de fire signaler på samme monitor en komplet observability frem for blot et binært "virker det?"

Dashboardet hjælper også her. Hver monitor viser en sparkline for de seneste svartider – en hurtig visuel indikator for mønstre i forringelse. Det udvidede view viser gennemsnit for 24 timer, 7 dage og 30 dage. Hvis du ser gennemsnittet gradvist stige uge efter uge – er det et tidligt tegn, der er værd at undersøge, før tærskelalarmen udløses.

Praktiske tærskler per sidetype

• Marketing landingpages: 1500ms er rimeligt. De er tunge med billeder og tracking-scripts; absolut hastighed betyder mindre end stabilitet.
• Produktsider/ecommerce kategorier: 800-1200ms. Langsom e-handel dræber konverteringer; strammere tærskler fanger problemer hurtigere.
• Applikationsdashboards: 500-800ms. Brugere forventer hurtighed. Langsomme dashboards får produktet til at virke defekt.
• Offentlige API'er: 200-400ms for simple endpoints, højere for compute-tunge. Segmentér dem.
• Interne microservice health checks: 50-100ms. De bør næsten være øjeblikkelige; langsomhed betyder næsten altid et reelt problem.

Lige meget hvad du vælger, så vælg ikke én gang for altid og glem det. Reevaluér hvert kvartal baseret på de tendenser, du faktisk ser. Hvis du konstant får tærskelalarmer, der ikke afspejler reelle problemer – tærsklen er for stram. Hvis du får nedbrud uden tidligere tærskel-alarm – så var tærsklen for løs.

Routing af alarmer

Tærskelalarmer sendes via de samme kanaler som nedetid/gendannelsesalarmer: Email, Telegram, Slack, Discord, SMS. De respekterer også samme natlige stilletid. De logges i samme alarmtabel. Den eneste forskel er hændelsestypen ("threshold" i stedet for "down") og indholdet i beskeden – her fremgår den aktuelle svartid og den konfigurerede tærskel, så du straks kan se størrelsen af overskridelsen.

Konfiguration

Redigér enhver monitor. I formularen sætter du "Svartids-tærskel (ms)" til det ønskede tal. Justér eventuelt "efterfølgende overskridelser", hvis standarden på 3 ikke passer til dit tolerance-niveau. Gem. Fra næste cyklus sammenlignes hvert check med tærsklen, og efter det valgte antal overskridelser får du besked.

Ofte stillede spørgsmål

• Hvilke svartids-metrikker registreres?

  Time To First Byte (TTFB) – millisekunder mellem afsendelse af anmodning og modtagelse af den første byte i svaret. Plus den samlede tid for at downloade det fulde svar. TTFB er den mest nyttige enkeltmetrik for serverens sundhed.

• Hvad er en "god" svartid?

  Afhænger af placering og indhold. For en statisk side med CDN: under 100ms er fremragende, under 300ms er ok. For dynamiske apps: under 500ms er ok, under 1000ms acceptabelt, over 2000ms virker langsomt. Sammenlign med din egen historiske base i stedet for absolutte tal.

• Kan jeg få en alarm, hvis svartid overskrider tærsklen?

  Ja. Hver monitor har en valgfri svartids-tærskel. Hvis 3 på hinanden følgende checks overskrider tærsklen, får du en "slow response" alarm. Kravet om 3 checks beskytter mod falske alarmer fra enkeltstående netværkstab.

• Hvor måles svartiden fra?

  Fra vores 13 geografiske check-punkter (Europa, Nordamerika, Asien, Sydamerika, Oceanien). Ved single-region monitorer tages tiden fra nærmeste region. For multi-region måles hver region separat – nyttigt til at opdage regionale CDN-problemer.

• Viser dashboardet svartids-trends?

  Ja – 30-dages glidende gennemsnit, daglige max/min og percentiler (p50, p95). Nyttigt til kapacitetsplanlægning: hvis p95 stiger fra 800ms til 1500ms på en måned, er dine servere pressede, selvom uptime % stadig er 100%.