Syntetisk övervakning: Automatisk mätning av laddningstider från flera regioner

Vad syntetisk övervakning visar

Synthetic Monitoring utför automatiskt och regelbundet fastställda kontroller av en webbplats. En Kontrollera Där beskrivs bland annat målet, tidsplanen, mätpunkterna och framgångskriterierna. Varje mätning vid en mätpunkt ger ett eget resultat: Konfigurationen ska alltså inte likställas med en enskild mätning.

Ett engångstest av den globala prestandan visar däremot endast en ögonblicksbild under just detta körningsförhållanden. Upprepade Övervakning av webbplats visar om en avvikelse uppstår på nytt och hur resultaten utvecklas över tid. För att sådana jämförelser ska vara meningsfulla måste målet, mätmiljön och platsen förbli identifierbara.

En offentlig mätpunkt i ett molnbaserat datacenter testar webbplatsen från en viss region och infrastruktur. Dess anslutning motsvarar dock inte automatiskt en privat internetanslutning på plats. Routing, nätverksfördröjning och avståndet till den levererande infrastrukturen kan påverka resultatet; en långsam testkörning avser därför i första hand just denna specifika mätväg.

En privat repetition svarar på en annan fråga: Den kan kontrollera om en applikation är tillgänglig från ett privat nätverk. Detta är till exempel relevant för interna tjänster, men bevisar inte att de är tillgängliga från det offentliga internet. Omvänt innebär en lyckad offentlig kontroll inte att åtkomsten fungerar från alla företagsnätverk.

Vid planeringen är det därför värt att formulera varje kontroll som en konkret fråga: Går det att nå produktsidan från en viktig målregion, och visas det förväntade innehållet där? Svaret gäller för de valda mätpunkterna och testförhållandena. Det är en reproducerbar indikation, men ingen fullständig bild av alla besökare och deras enheter.

HTTP, webbläsare och kundresor

En HTTP-kontroll hämtar data från en slutpunkt och utvärderar till exempel statuskoden eller svaret. För en produktsida kan den snabbt visa att servern inte svarar som förväntat. Om den rapporterar HTTP 200 innebär det dock endast att det kontrollerade svarskriteriet är uppfyllt: det är fortfarande oklart om gränssnittet är synligt och kan användas.

En webbläsarkontroll laddar samma produktsida i en automatiserad webbläsare. Den kan kontrollera om en förväntad rubrik visas och registrera webbläsarrelaterade mätvärden. Om denna kontroll misslyckas, trots att HTTP-statusen är framgångsrik, är det värt att undersöka rendering och sidinnehåll. Skillnaden i sig bevisar dock inte någon specifik orsak till felet.

En Resekontroll går utöver att ladda sidan och utför definierade steg. Vid en inloggning öppnar den till exempel inloggningssidan, loggar in med ett lämpligt testkonto och kontrollerar därefter ett förväntat element. Det är först detta sista kriterium som visar för den testade processen att det inte bara var möjligt att nå inloggningssidan.

Även en lyckad testrunda bekräftar endast de steg och villkor som faktiskt har genomförts. En otestad återställning av lösenord eller en annan webbläsare kan ändå orsaka problem. Välj därför ut ett fåtal affärskritiska processer och formulera ett verifierbart resultat för varje steg, istället för att dra slutsatser om hela tjänsten utifrån att en sida har laddats framgångsrikt.

En kompletterande visuell granskning kan undersöka förändringar i visningen som inte upptäcks vid en enskild elementkontroll. För detta ändamål kan man till exempel jämföra skärmdumpar; avvikelser måste därefter klassificeras, eftersom inte varje synlig förändring är ett fel. Ytterligare metoder beskrivs i artikeln om Visuell verifiering och automatiserade webbplatsgranskningar.

Att skilja mellan olika laddningstider på rätt sätt

„Utan ytterligare specificering avser “laddningstid” inte någon entydigt jämförbar storhet. När en sida öppnas är det först och främst tiden fram till det första svar från servern som är av intresse: den hjälper till att bedöma fördröjningar innan svaret anländer. Den anger dock inte när webbläsaren har visat något synligt eller när sidan har bearbetats fullständigt.

Den första synliga renderingen avser en senare fas: webbläsaren visar innehåll för första gången. Det kan redan vara en kort text eller något annat tidigt element, medan det viktigaste innehållet på sidan fortfarande saknas. Att sidan blir synlig tidigt innebär därför inte automatiskt att produktsidan är snabbt användbar.

Der Största innehållsrika målningen (LCP) mäter när det största relevanta innehållselementet blir synligt inom det synliga området. På en produktsida kan det till exempel vara den stora produktbilden. Jämför LCP endast med LCP-värden som är märkta som sådana och notera webbläsar- och nätverksförhållandena; tiden till serverns svar mäts i en annan fas.

Die Manusets längd är å sin sida inte automatiskt laddningstiden för en enskild sida. Ett skript kan hämta flera sidor, vänta på element och genomföra en inloggning. Vid Grafana-k6-webbläsarkontroller omfattar den angivna skripttiden normalt inte k6:s startfas; även sådana verktygsbegränsningar ingår i tolkningen.

Interaction to Next Paint, förkortat INP, avser reaktionen på interaktioner. En simulerad process kan därvid endast undersöka de interaktioner som den faktiskt utför. Ett automatiserat klick under fastställda förhållanden ger därför ingen bild av hur upplevelsen fördelar sig bland alla verkliga besökare som använder andra enheter, anslutningar och navigationsvägar.

Mätplan för målregioner

Börja mätplanen med de sidor och processer vars eventuella avbrott skulle påverka din verksamhet. Det kan till exempel vara en produktsida, inloggningen eller ett gränssnitt. Välj sedan mätregioner utifrån dina målmarknader: En ytterligare plats är särskilt användbar om den täcker en viktig användarregion eller kompletterar en befintlig regional övervakning.

För en en liknande kontroll Notera webbläsare och version, enhetsinställningar, nätverksförhållanden och cache-status. Dokumentera dessutom intervall och tidsgräns samt det förväntade svaret eller det synliga elementet. På så sätt går det senare att se om en avvikelse kan sammanfalla med en förändrad mätmiljö.

Tabellen nedan är ett teoretiskt exempel, inte en uppmätt eller allmänt rekommenderad driftsplan. Du måste anpassa intervallen och larmvillkoren efter din webbplats betydelse och möjligheterna hos den valda tjänsten.

Tabellen är bara en utgångspunkt: Ange den konkreta tidsgränsen och övriga mätvillkor i kontrollkonfigurationen. Ett regionalt larm är fortfarande meningsfullt även om andra platser rapporterar utan problem. Tänk på att en mätpunkt i molnet inte automatiskt motsvarar en privat internetanslutning i samma region.

Konfigurera kontroller och testförfaranden

För en egen testsida kan du först skapa en HTTP-kontroll som kontrollerar den förväntade statuskoden. Lägg till en webbläsarkontroll som hämtar samma sida och väntar på en förväntad rubrik. Den första kontrollen undersöker svaret från slutpunkten; den andra ger dessutom en indikation på om det förväntade innehållet visas i webbläsaren.

Registrera för varje körning mätplatsen, tidpunkten, resultatet och den relevanta varaktigheten. Om webbläsarkontrollen misslyckas trots att HTTP-kontrollen lyckades, undersök innehållet och renderingen istället för att omedelbart anta att det rör sig om ett specifikt fel. Kontrollera även om rubriken har ändrats avsiktligt eller om tidsgränsen har valts för kort.

För att registrera sig klickar man på en Resan webbläsarens anrop för inmatningar och en kontroll efter inloggningen. Använd ett separat testkonto med så få behörigheter som möjligt och kontrollera ett stabilt, icke-personligt element i det inloggade området. Att inloggningssidan laddas korrekt är i sig inte tillräckligt för att bekräfta att inloggningen fungerar.

Välj stabila selektorer och vänta specifikt på förväntat innehåll, istället för att enbart förlita dig på en fast paus. Spara inloggningsuppgifterna i hemlighetshanteringen hos den tjänst som används, inte i skriptet eller i loggarna. Kontrollera efter ändringar i gränssnittet om selektorer och framgångskriterier fortfarande stämmer överens med det avsedda förloppet.

Begränsa testförloppen till säkra åtgärder: En regelbundet utförd kundresa ska inte utlösa några riktiga beställningar eller betalningar. Om ett skrivande steg är oundvikligt krävs en testmiljö som uttryckligen är avsedd för detta eller en kontrollerad testprocess. Fastställ dessutom vem som ska utreda ett misslyckat testförlopp och hantera testdata.

Jämföra verktyg och verksamhetsmodeller

När du väljer verktyg bör du skilja mellan en hanterad övervakningstjänst och ett verktyg som inledningsvis endast utför ett test. Det avgörande är inte enbart om en webbläsare stöds: du behöver dessutom lämpliga platser, regelbunden körning, lagring av resultat och ett larmsystem som passar din verksamhet.

Grafana Cloud Syntetisk övervakning kopplar samman kontrollkonfigurationer med offentliga och privata mätpunkter och stöder k6-baserade webbläsarkontroller. Offentliga och privata mätpunkter ger svar på olika frågor om tillgänglighet. Kontrollera även i förväg vilka kontrollfrekvenser som är tillgängliga: webbläsar- och skriptkontroller omfattas av andra begränsningar än vissa enkla slutpunktskontroller.

Det som utförs lokalt k6-webbläsarmodul måste hanteras separat. För detta behöver du k6 och en Chromium-baserad webbläsare; en lokal skriptkörning konfigurerar varken automatiska regionala mätpunkter eller ett permanent schema. För distribuerad övervakning måste du dessutom organisera körning, infrastruktur och resultathantering eller använda en lämplig tjänst.

AWS CloudWatch Synthetics kör schemalagda Canaries. De Funktionen för flera platser replikerar en Canary till utvalda AWS-regioner och sammanställer resultaten i en primär region. Kontrollera före införandet de dokumenterade minimiversionerna för de Node.js-Puppeteer- eller Playwright-runtimes som stöds, samt den specifika regionala tillgängligheten för denna funktion.

Egendrivna mätstationer ger dig större kontroll över plats och omgivning, men kräver också underhåll, uppdateringar och övervakning av mätinfrastrukturen. Jämför de faktiska platserna som erbjuds, de användningsberoende kostnaderna och villkoren för datalagring för alla driftsmodeller. Klargör särskilt var skärmdumpar och loggar lagras och om detta överensstämmer med dina dataskyddsriktlinjer.

Att på ett meningsfullt sätt utvärdera regionala resultat

Jämför regionala resultat för samma sida och samma tidsperiod. Webbläsare, version, nätverksförhållanden och cache-status bör stämma överens; annars kan skillnaden bero på mätmiljön snarare än på leveransen. En mätpunkt i molnet avspeglar dessutom en specifik plats och nätverksväg, inte alla anslutningar i en region.

För upprepade framgångsrika mätningar visar Median medelvärdet av de sorterade resultaten. En övre percentil, till exempel den 95:e percentilen, synliggör långsammare körningar: 95 procent av de granskade värdena ligger högst vid detta värde. Notera tidsperioden och antalet mätningar så att det framgår hur omfattande utvärderingen är.

Vid ett fåtal körningar kan en enskild långsam anropning påverka den övre percentilen kraftigt. Kontrollera därför tidsförloppet och jämför flera mätfönster innan du drar slutsatsen att det rör sig om en bestående regional försämring. Även ett byte av mätpunkt eller webbläsarversion bör beaktas som en möjlig faktor som påverkar utvärderingen.

Stanna misslyckade försök visas separat, till exempel som antal fel och andel av alla körningar. En laddningstidsstatistik som endast innehåller lyckade anrop kan annars felaktigt få en region med frekventa timeouts att se bra ut. Vid ett misslyckande utan giltigt laddningstidsvärde går det inte att enkelt använda en normal laddningstid.

Real User Monitoring kompletterar den kontrollerade testningen med erfarenheter från verkliga besökare. Chrome UX Report tillhandahåller tillgängliga fältdata över ett rullande 28-dagarsfönster; inte alla sidor eller användargrupper omfattas av rapporten. Denna långsiktiga översikt ersätter därför varken en aktuell syntetisk varning och kan inte heller direkt jämställas med ett enskilt testkörning.

Larm och regional felsökning

En global larmsignal kan sammanställa upprepade fel från flera platser. Detta underlättar att skilja en omfattande incident från ett isolerat fel vid en mätpunkt. Fastställ samtidigt ett regionalt larmvillkor: Om en viktig målmarknad slutar fungera får framgången i andra regioner inte dölja problemet.

Välj antal upprepningar och tidsintervall som passar processens betydelse. Flera misslyckade tester i rad kan fånga upp kortvariga avvikelser, men fördröjer rapporteringen. Övervaka även mätpunkterna själva och undersök om ett prov har fallit bort eller om andra tester på samma plats också är påverkade.

Om en produktsida endast är långsam på en plats, börja med att jämföra liknande körningar och tidpunkten för avvikelsen. Undersök därefter DNS-upplösning, CDN-leverans, resursernas laddningstider och serverns svarstid. Olika nätverksvägar och avståndet till infrastrukturen kan påverka de regionala utgångsnivåerna; mätvärdet i sig identifierar ännu inte någon orsak.

När det gäller resurser från andra Origins kan detaljerna i webbläsarmätningen vara begränsade. Utan lämplig Timing-Allow-Origin-I vissa fall kan enskilda värden i Resource Timing API vara noll. Det betyder inte automatiskt att anslutningen var extremt snabb; kontrollera först vilka uppgifter den externa servern tillhandahåller för mätningen.

För nästa analysnivå kopplar du samman tidpunkt, region och den berörda processen med tillgängliga loggar och spår. På så sätt kan man till exempel söka efter en långsam förfrågan utan att redan dra slutsatsen att korrelationen är ett bevis på orsaken. Hur mätvärden, loggar och spår samverkar förklaras i artikeln om Observabilitet inom webbhotell.

Bedriva övervakning kontinuerligt

Börja med enkla endpoint-kontroller för viktiga, offentligt tillgängliga mål och komplettera med riktade webbläsartester för affärskritiska sidor eller inloggningar. En HTTP-kontroll kan köras oftare, medan den mer omfattande webbläsartesten kontrollerar utvalda funktioner. Du anpassar intervallen efter önskad upptäcktstid, tjänstgränser och kostnader, inte efter ett fast minutvärde.

Bestäm för varje kontroll en Behörighet: Vem tar emot larmet, vem kontrollerar den berörda tjänsten och vem sköter mätpunkten? Ange även när ett larm vidarebefordras och var de tillhörande resultaten finns. En kontroll utan åtgärd vid upprepade fel ger visserligen data, men löser inte problemet.

Kontrollera efter ändringar i gränssnittet om selektorer och förväntat innehåll fortfarande stämmer överens med flödet. Vänta på det nödvändiga elementet i skriptet istället för att enbart förlita dig på en fast fördröjning. Dokumentera ändringar i webbläsaren, nätverksprofilen eller cacheinställningarna så att senare jämförelser inte oavsiktligt blandar ihop olika mätförhållanden.

Behandla skärmdumpar och loggar som potentiellt känsliga uppgifter: De kan innehålla information från ett möte eller uppgifter från applikationen. Begränsa åtkomst och lagring i enlighet med syftet och kontrollera vad testet faktiskt spelar in. För inloggningar använder du ett begränsat testkonto och hanterar inloggningsuppgifter som hemligheter istället för i skriptet.

Kontrollera regelbundet om Mätplatser passar dina målmarknader och om avgifter, datalagring och dataskyddskrav fortfarande möjliggör driften. Vid egen drift av testmiljöer tillkommer dessutom uppdatering och övervakning av miljön. Ett lokalt startat k6-webbläsarskript i sig utgör inte en permanent distribuerad övervakningsinfrastruktur.