"Är sajten uppe?" låter som en enkel fråga, men svaret beror helt på vad du menar med uppe. En server kan svara på varje förfrågan medan besökarna ändå inte kan logga in, söka eller handla. Skillnaden mellan upptidsövervakning och syntetisk övervakning handlar just om detta glapp. Här förklarar vi vad var och en gör, och när du behöver vilken.
Vad upptidsövervakning är
Upptidsövervakning kontrollerar att en server svarar. Ett verktyg skickar med jämna mellanrum en förfrågan till en URL och kontrollerar svaret, oftast statuskoden. Får den HTTP 200 räknas sajten som uppe. Får den timeout, ett anslutningsfel eller en 5xx-kod räknas den som nere. Det är snabbt, billigt och utmärkt på att fånga de stora katastroferna: servern kraschar, domänen slutar peka rätt eller hela sajten faller.
Vad syntetisk övervakning är
Syntetisk övervakning går ett steg längre och härmar en riktig användare. I stället för att bara hämta en URL styr den en webbläsare genom ett flöde: öppna sidan, klicka på en knapp, fyll i ett formulär, vänta på ett resultat. Efter varje steg kontrollerar den att något förväntat faktiskt hände, till exempel att sökresultat visas eller att en betalknapp laddas. Den mäter inte bara om servern lever, utan om själva funktionen fungerar.
Varför en 200 OK missar trasiga flöden
Statuskoden 200 betyder bara att servern lyckades leverera ett svar. Den säger ingenting om innehållet. Servern kan glatt svara 200 medan sidan innehåller ett JavaScript-fel som gör knappen död, ett tomt sökresultat på grund av en trasig databas, eller ett inloggningsformulär som avvisar alla lösenord. För besökaren är sajten trasig. För upptidsmonitorn är allt grönt. Det här glappet är exakt varför butiker upptäcker kassafel genom arga kundmejl i stället för genom sina verktyg.
När upptidsövervakning räcker
Upptidsövervakning är rätt verktyg när du vill veta att en tjänst över huvud taget lever. Det passar utmärkt för:
- Enkla sajter och landningssidor utan interaktiva funktioner.
- API-slutpunkter där ett statuskodssvar räcker som hälsokontroll.
- Att snabbt fånga totala avbrott, DNS-problem och serverkrascher.
- Att övervaka många endpoints billigt och ofta.
När du behöver syntetisk övervakning
Så fort intäkter eller kritiska funktioner beror på ett flöde behöver du syntetisk övervakning. Det gäller:
- Kassor och betalflöden i en webbutik.
- Inloggning, registrering och andra formulär.
- Sök, filter och andra JavaScript-tunga funktioner.
- Allt där "sidan laddar" inte är samma sak som "det fungerar".
Vad var och en kostar och kräver
Skillnaden märks också i drift. En upptidskontroll är lätt: den skickar en förfrågan och läser ett svar på bråkdelar av en sekund, så du kan köra den ofta och på många adresser utan att det märks. En syntetisk kontroll måste starta en riktig webbläsare, ladda sidan, köra JavaScript och vänta på varje steg. Den är tyngre och tar längre tid, och den kräver lite underhåll eftersom flödet måste uppdateras när du bygger om kassan eller byter tema. Därför är den vanliga strategin att köra upptidsövervakning brett på allt och reservera syntetiska flöden för de handfull resor där ett fel faktiskt kostar pengar.
Larm som går att lita på
Oavsett vilken typ du väljer är larmkvaliteten avgörande. Ett verktyg som larmar vid varje tillfällig nätverksstörning tränar dig snabbt att ignorera larmen, och då missar du det verkliga avbrottet. Nyckeln är att bekräfta en misslyckad kontroll från en oberoende andra plats innan larmet går. Om bara en av två platser ser felet är det troligen ett lokalt nätverksproblem, inte att din sajt är nere. Ser båda felet är det verkligt.
De kompletterar varandra
Det här är inte ett antingen-eller. Upptidsövervakning ger dig bred, billig täckning och fångar de stora avbrotten snabbt. Syntetisk övervakning ger dig djup på de få flöden som verkligen betyder något. Tillsammans täcker de både "svarar servern?" och "kan kunden faktiskt handla?".
Så gör Ravnsight
Ravnsight gör båda. Vi kör snabba upptidskontroller för bred täckning och syntetiska flöden i en riktig webbläsare för dina kritiska köp- och inloggningsresor. Lika viktigt är hur vi hanterar larm: en misslyckad kontroll bekräftas alltid från en andra plats innan vi larmar. Om ett avbrott sammanfaller med en driftstörning ser du det i tidslinjen, men vi säger att det är korrelerat, inte att vi definitivt vet orsaken. Resultatet är färre falsklarm och ett tydligt svar på den fråga som faktiskt betyder något: fungerar sajten för dina besökare?
