Syntetisk overvågning: Automatisk måling af indlæsningstider fra flere regioner

Hvad Synthetic Monitoring viser

Synthetic Monitoring udfører automatisk og regelmæssigt fastlagte kontroller af et websted. En Tjek Her beskrives blandt andet målet, tidsplanen, målepunkterne og succeskriterierne. Hver udførelse ved et målepunkt giver et eget resultat: Konfigurationen kan altså ikke sidestilles med en enkelt måling.

En engangs-global præstationstest viser derimod kun et øjebliksbillede under forholdene ved netop dette løb. Gentagen Overvågning af hjemmeside viser, om en afvigelse opstår igen, og hvordan resultaterne udvikler sig over tid. For at sådanne sammenligninger skal være meningsfulde, skal målet, målemiljøet og placeringen forblive genkendelige.

Et offentligt målepunkt i et cloud-datacenter tester hjemmesiden fra en bestemt region og infrastruktur. Dets forbindelse svarer dog ikke automatisk til en privat internetforbindelse på stedet. Routing, netværksforsinkelse og afstanden til den infrastruktur, der leverer indholdet, kan påvirke resultatet; en langsom test beskriver derfor i første omgang netop denne konkrete målerute.

En privat prøve besvarer et andet spørgsmål: Den kan kontrollere, om en applikation er tilgængelig fra et privat netværk. Dette er f.eks. relevant for interne tjenester, men beviser ikke, at de er tilgængelige fra det offentlige internet. Omvendt siger en vellykket offentlig kontrol ikke noget om, hvorvidt adgangen fungerer fra ethvert virksomhedsnetværk.

I forbindelse med planlægningen er det derfor en god idé at formulere hver enkelt test som et konkret spørgsmål: Kan produktsiden nås fra en vigtig målregion, og vises det forventede indhold der? Svaret gælder for de valgte målepunkter og testbetingelser. Det er en reproducerbar indikation, men ikke et fuldstændigt billede af alle besøgende og deres enheder.

HTTP, browsere og brugerrejser

En HTTP-kontrol forespørger et slutpunkt og vurderer for eksempel statuskoden eller svaret. For en produktside kan den hurtigt vise, at serveren ikke svarer som forventet. Hvis den returnerer HTTP 200, er det dog kun det kontrollerede svar-kriterium, der er opfyldt: Det er stadig uklart, om brugergrænsefladen er synlig og kan betjenes.

En browser-check indlæser den samme produktside i en automatiseret browser. Den kan kontrollere, om en forventet overskrift vises, og registrere browserrelaterede måleværdier. Hvis denne kontrol mislykkes, selvom HTTP-status er »succes«, er det værd at undersøge rendering og sideindhold. Forskellen i sig selv beviser dog ikke en bestemt årsag til fejlen.

En Rejseoversigt går ud over blot at indlæse siden og udfører definerede trin. Ved en login-proces åbner den for eksempel login-siden, logger ind på en passende testkonto og kontrollerer derefter et forventet element. Først dette sidste kriterium viser for den testede proces, at det ikke blot var muligt at få adgang til login-siden.

Selv en vellykket brugerrejse bekræfter kun de trin og betingelser, der rent faktisk er blevet gennemført. En ikke-testet adgangskode-nulstilling eller en anden browser kan stadig give problemer. Vælg derfor nogle få forretningsmæssigt vigtige processer, og formuler et verificerbart resultat for hvert trin, i stedet for at drage konklusioner om hele tjenesten ud fra et vellykket sidebesøg.

En supplerende visuel kontrol kan afdække ændringer i visningen, som en enkelt elementkontrol ikke fanger. Til dette formål kan man f.eks. sammenligne skærmbilleder; afvigelser skal derefter vurderes, da ikke alle synlige ændringer er fejl. Yderligere tilgange beskrives i artiklen om Visuel verifikation og automatiserede kontrol af websteder.

At skelne korrekt mellem indlæsningstider

„Uden yderligere præcisering henviser “indlæsningstid« ikke til en entydigt sammenlignelig størrelse. Når en side åbnes, er det først og fremmest tiden indtil det første svar fra serveren, der er relevant: Den hjælper med at vurdere forsinkelser, inden svaret modtages. Den angiver dog ikke, hvornår browseren har vist noget synligt eller har behandlet siden fuldstændigt.

Den første synlige rendering beskriver en senere fase: Browseren viser indhold for første gang. Det kan allerede være en kort tekst eller et andet tidligt element, mens det vigtigste indhold på siden endnu mangler. En tidlig synlig start er derfor ikke automatisk ensbetydende med en produktside, der hurtigt kan tages i brug.

Der Største indholdsrige maling (LCP) tager højde for, hvornår det største relevante indholdselement bliver synligt i det synlige område. På en produktside kan det f.eks. være det store produktbillede. Sammenlign LCP kun med LCP-værdier, der er mærket som sådan, og noter browser- og netværksforholdene; tiden indtil serverens svar måles i en anden fase.

Die Manuskriptets varighed er dog ikke nødvendigvis den samme som indlæsningstiden for en enkelt side. Et script kan åbne flere sider, vente på elementer og gennemføre en login-proces. Ved Grafana-k6-browser-tjek omfatter den angivne scriptvarighed normalt ikke k6’s opstartsfase; også sådanne værktøjsbegrænsninger skal tages med i betragtning ved fortolkningen.

Interaction to Next Paint, forkortet INP, vedrører reaktionen på interaktioner. En simuleret proces kan i den forbindelse kun undersøge de interaktioner, som den rent faktisk udfører. Et automatiseret klik under fastlagte betingelser giver derfor ikke et billede af fordelingen af oplevelserne hos alle reelle besøgende, der bruger andre enheder, forbindelser og navigationsmåder.

Måleplan for målregioner

Start måleplanen med de sider og processer, hvis nedbrud ville have betydning for din virksomhed. Det kan være en produktside, login-siden og et grænseflade. Vælg derefter måleområder ud fra dine målmarkeder: En ekstra placering er især nyttig, hvis den dækker et vigtigt brugerområde eller supplerer en eksisterende regional overvågning.

For en en tilsvarende kontrol Notér browser og version, enhedsvisning, netværksforhold og cache-tilstand. Dokumenter desuden interval og tidsgrænse samt det forventede svar eller det synlige element. På den måde kan man senere se, om en afvigelse kunne hænge sammen med ændringer i målemiljøet.

Den følgende tabel er et konceptuelt eksempel, ikke en målt eller generelt anbefalet driftsplan. Du skal tilpasse intervallerne og alarmbetingelserne til din hjemmesides betydning og den valgte tjenestes muligheder.

Tabellen er kun udgangspunktet: Indtast den konkrete tidsgrænse og de øvrige målebetingelser i check-konfigurationen. En regional alarm er stadig relevant, selvom andre lokationer rapporterer uden problemer. Husk, at et cloud-målepunkt ikke automatisk svarer til en privat internetforbindelse i samme region.

Opsætning af kontroller og testforløb

Hvis du vil teste din egen side, kan du først oprette en HTTP-kontrol, der tjekker den forventede statuskode. Tilføj derefter en browserkontrol, der åbner den samme side og venter på en forventet overskrift. Den første kontrol undersøger svar fra slutpunktet; den anden giver desuden en indikation af, om det forventede indhold vises i browseren.

Registrer for hver kørsel måleplaceringen, tidspunktet, resultatet og den relevante varighed. Hvis browser-tjekket mislykkes, selvom HTTP-tjekket er vellykket, skal du undersøge indholdet og gengivelsen i stedet for straks at antage, at der er tale om en bestemt fejl. Kontroller også, om overskriften er blevet ændret bevidst, eller om tidsgrænsen er sat for kort.

For at tilmelde sig skal man udfylde en Rejse browseropkaldet om indtastninger og en kontrol efter login. Brug en separat testkonto med så få rettigheder som muligt, og kontroller et stabilt, ikke-personrelateret element i det område, hvor du er logget ind. Det faktum, at loginsiden åbnes uden problemer, er i sig selv ikke nok til at bekræfte, at login-funktionen virker.

Vælg stabile selektorer og vent målrettet på forventet indhold i stedet for udelukkende at stole på en fast pause. Gem adgangsoplysninger i den anvendte tjenestes hemmelighedsadministration og ikke i scriptet eller i logfilerne. Kontroller efter ændringer i brugergrænsefladen, om selektorer og succeskriterier stadig passer til den tilsigtede proces.

Begræns testforløb til sikre handlinger: En rejse, der udføres regelmæssigt, må ikke udløse reelle bestillinger eller betalinger. Hvis et skrivende trin er uundgåeligt, kræver det et testmiljø, der udtrykkeligt er beregnet til dette formål, eller en kontrolleret testproces. Fastlæg desuden, hvem der skal undersøge en mislykket testkørsel og varetage testdataene.

Sammenligning af værktøjer og driftsmodeller

Når du vælger et værktøj, skal du skelne mellem en administreret overvågningstjeneste og et værktøj, der i første omgang kun udfører en test. Det afgørende er ikke kun, om en browser understøttes: Du har også brug for passende placeringer, regelmæssig udførelse, opbevaring af resultater og et alarmeringssystem, der passer til din virksomhed.

Grafana Cloud Syntetisk overvågning Forbinder check-konfigurationer med offentlige og private prober og understøtter k6-baserede browser-checks. Offentlige og private målepunkter giver svar på forskellige spørgsmål om tilgængelighed. Tjek også på forhånd de tilgængelige kontrolfrekvenser: Browser- og script-kontroller er underlagt andre begrænsninger end nogle enkle endpoint-kontroller.

Det lokalt udførte k6-browsermodul skal adskilles herfra. Til det har du brug for k6 og en Chromium-baseret browser; en lokal scriptkørsel opretter hverken automatisk regionale målepunkter eller en fast tidsplan. Til distribueret overvågning skal du yderligere organisere udførelse, infrastruktur og resultatadministration eller benytte en passende tjeneste.

AWS CloudWatch Synthetics udfører planlagte canaries. De Multilokationsfunktion replikerer en Canary i udvalgte AWS-regioner og samler resultaterne i en primær region. Kontroller inden implementeringen de dokumenterede minimumsversioner for de understøttede Node.js-Puppeteer- eller Playwright-runtimes samt den specifikke regionale tilgængelighed af denne funktion.

Selvdrivne målere giver dig større kontrol over placering og omgivelser, men kræver også vedligeholdelse, opdateringer og overvågning af måleinfrastrukturen. Sammenlign de faktisk tilbudte placeringer, de brugsafhængige omkostninger og betingelserne for datalagring for alle driftsmodeller. Afklar især, hvor skærmbilleder og logfiler gemmes, og om dette er i overensstemmelse med dine krav til databeskyttelse.

At udvurdere regionale resultater på en meningsfuld måde

Sammenlign regionale resultater for den samme side og den samme periode. Browser, version, netværksforhold og cache-tilstand bør være ens; ellers kan en forskel skyldes målemiljøet og ikke selve leveringen. Et cloud-målepunkt afspejler desuden en bestemt placering og netværksrute, ikke alle forbindelser i en region.

Ved gentagne vellykkede målinger viser Median den midterste værdi blandt de sorterede resultater. Et øvre percentil, f.eks. det 95. percentil, gør de langsommere gennemløb synlige: 95 procent af de betragtede værdier ligger højst på dette niveau. Notér i den forbindelse tidsperioden og antallet af målinger, så det fremgår, hvor bredt analysen er.

Når der kun er få kørsler, kan en enkelt langsom opkaldstid have stor indflydelse på det øverste percentil. Du bør derfor undersøge tidsforløbet og sammenligne flere målevinduer, før du konkluderer, at der er tale om en vedvarende regional forringelse. Også et skift af målepunkt eller browserversion skal medtages som en mulig afbrydelse i analysen.

Stop mislykkede løb vises separat, for eksempel som antal fejl og andel af alle udførelser. En indlæsningstidsstatistik, der kun indeholder vellykkede opkald, kan ellers få et område med hyppige timeouts til at se bedre ud, end det egentlig er. Ved en fejl uden en gyldig indlæsningstidsværdi kan man ikke blot indsætte en normal indlæsningstid.

Real User Monitoring supplerer den kontrollerede test med erfaringer fra reelle besøgende. Chrome UX-rapporten stiller tilgængelige feltdata til rådighed over et rullende 28-dages vindue; ikke alle sider eller brugergrupper er omfattet heraf. Dette langsigtede perspektiv erstatter derfor hverken en aktuel syntetisk alarm, og det kan heller ikke umiddelbart sidestilles med en enkelt testkørsel.

Alarmer og regional fejlfinding

En global alarm kan samle gentagne fejl fra flere lokationer. Det hjælper med at skelne mellem en bredere hændelse og en isoleret fejl på et enkelt målepunkt. Fastlæg samtidig en regional alarmbetingelse: Hvis et vigtigt målmarked svigter, må succesen i andre regioner ikke skjule problemet.

Vælg gentagelser og tidsintervaller, der passer til procesens karakter. Flere mislykkede test i træk kan opfange kortvarige afvigelser, men forsinker alarmeringen. Overvåg også selve målepunkterne, og undersøg, om en prøve er svigtet, eller om andre test på samme sted også er berørt.

Hvis en produktside kun er langsom på én lokation, skal du starte med at sammenligne lignende kørsler og tidspunktet for afvigelsen. Undersøg derefter DNS-opløsning, CDN-levering, ressourceindlæsningstider og serverrespons. Forskellige netværksruter og afstanden til infrastrukturen kan påvirke de regionale udgangsniveauer; måleværdien alene identificerer endnu ikke årsagen.

For ressourcer fra andre Origins kan detaljerne i browsermålingen være begrænsede. Uden en passende Timing-Allow-Origin-I nogle tilfælde kan enkelte værdier i Resource Timing API’en være nul. Det betyder ikke nødvendigvis, at forbindelsen var ekstremt hurtig; tjek først, hvilke oplysninger den eksterne server stiller til rådighed til målingen.

På det næste undersøgelsesniveau sammenkæder du tidspunkt, region og den berørte proces med tilgængelige logfiler og sporinger. På den måde kan man f.eks. søge efter en langsom forespørgsel uden at drage en konklusion om årsagen ud fra en sammenhæng. Hvordan metrics, logfiler og sporinger spiller sammen, forklares i artiklen om Observabilitet inden for hosting.

Gennemføre løbende overvågning

Start med enkle endpoint-kontroller af vigtige, offentligt tilgængelige mål, og suppler med målrettede browser-forløb for forretningskritiske sider eller login-processer. En HTTP-kontrol kan køre oftere, mens den mere omfattende browsertest tjekker udvalgte funktioner. Du tilpasser intervallerne efter den ønskede opdagelsestid, servicegrænser og omkostninger, ikke efter en fast minutværdi.

Bestem for hver check en Kompetence: Hvem modtager alarmen, hvem kontrollerer den berørte tjeneste, og hvem varetager målepunktet? Notér også, hvornår en alarm videresendes, og hvor de tilhørende resultater kan findes. En kontrol uden reaktion på gentagne fejl leverer ganske vist data, men løser ikke problemet.

Efter ændringer i brugergrænsefladen skal du kontrollere, om selektorer og forventet indhold stadig passer til forløbet. Vent i scriptet på det nødvendige element, i stedet for udelukkende at stole på en fast forsinkelse. Dokumenter ændringer i browser, netværksprofil eller cacheindstillinger, så senere sammenligninger ikke ubevidst blander forskellige målebetingelser sammen.

Behandl skærmbilleder og logfiler som potentielt følsomme data: De kan indeholde indhold fra en session eller oplysninger fra applikationen. Begræns adgangen og opbevaringen i overensstemmelse med formålet, og kontroller, hvad testen rent faktisk registrerer. Til login bruger du en begrænset testkonto og administrerer adgangsoplysninger som hemmeligheder i stedet for i scriptet.

Kontroller regelmæssigt, om Målesteder om de stadig passer til dine målmarkeder, og om takster, datalagring og krav til databeskyttelse fortsat muliggør driften. Ved selvdrevne testmiljøer kommer opdatering og overvågning af miljøet oveni. Et lokalt kørt k6-browserskript udgør i sig selv ikke en permanent distribueret overvågningsinfrastruktur.