Synthetisch vs real user monitoring: wat elk opvangt

Wat elk van de twee doet

Synthetische monitoring, ook wel actieve of proactieve monitoring genoemd, stuurt een verzoek dat u zelf hebt gedefinieerd vanaf een machine die u beheert, met een interval dat u instelt. Dat verzoek kan zo klein zijn als een HTTP GET of zo uitgebreid als een geschreven browsersessie die inlogt, een item aan een winkelmandje toevoegt en afrekent. Elke run levert een resultaat op, of er nu iemand de site bezocht of niet.

Real user monitoring, meestal afgekort tot RUM, is passief. Een klein script op uw pagina's meldt wat de browser tijdens dat bezoek heeft gemeten: navigatietijden, het laden van resources, fouten en de Core Web Vitals zoals de bezoeker die ervoer. Het levert alleen data op in verhouding tot uw verkeer, en het levert niets op wanneer er niemand is.

Wat synthetisch opvangt en RUM mist

• Storingen om 4 uur 's nachts, of op elke pagina met weinig verkeer. Laadt niemand de pagina, dan heeft RUM niets te melden, en een totale storing is precies het geval waarin de beacon niet kan worden verstuurd
• Beschikbaarheid vanaf plekken waar u nog geen gebruikers heeft, waardoor u ontdekt dat een nieuwe markt u niet kan bereiken
• Een schone baseline. Hetzelfde script, vanaf dezelfde locatie, op hetzelfde interval, zodat een verandering in het cijfer een verandering in de site is en niet in wie er toevallig langskwam
• Meerstaps-flows die u echte gebruikers niet zou willen laten doorlopen, zoals een checkout die een echte bestelling zou aanmaken, of een login die u tegen een testaccount kunt laten draaien
• Verval- en configuratiefouten die een browser nooit bereiken: certificaten, DNS-records, blacklistvermeldingen, open poorten
• De eerste mislukking na een deployment, voordat het verkeer dat haar zou hebben blootgelegd, er is

Wat RUM opvangt en synthetisch mist

• De echte verdeling van apparaten, netwerken en locaties. Een synthetische controle vanaf een datacenterverbinding zal nooit een middenklasse-telefoon op mobiele data nabootsen
• Scripts van derden, cookiebanners en personalisatie die alleen laden bij echte sessies met echte cookies
• Problemen die een deel van de gebruikers treffen: één browserversie, één regio, één A/B-variant
• Welke trage pagina's ertoe doen, gewogen naar hoeveel mensen ze zien
• Field Core Web Vitals, wat zoekmachines gebruiken, in tegenstelling tot de labwaarden die een synthetische run oplevert

Wanneer u beide nodig heeft

De twee beantwoorden verschillende vragen, dus de scheiding is meestal duidelijk. Gebruik synthetisch voor alles waarvoor u iemand zou alarmeren: beschikbaarheid, responstijd tegen een drempel, verval van certificaat en domein, en de kritieke flows waarmee u geld verdient. Die moeten waar zijn om 4 uur 's nachts met nul verkeer, en daarvoor is een stabiele baseline nodig om tegen te alarmeren.

Gebruik RUM om te beslissen wat u repareert. Is een pagina traag voor sommige mensen, dan vertelt RUM u wie en hoeveel, wat precies de informatie is die een prioriteringsargument nodig heeft en die een synthetische controle niet kan leveren.

Een praktische opzet is synthetische controles die de meldingen en de uptimeregistratie aansturen, RUM die de performance-backlog aanstuurt. Kunt u er maar één draaien, draai dan synthetisch: een niet-gemonitorde storing is duurder dan een ongemeten trage pagina, en RUM kan niet rapporteren over een pagina die niet is geladen.

Waar transactiemonitoring past

Een transactiecontrole is synthetische monitoring op zijn meest gedetailleerd: een opgenomen browserscript dat stap voor stap een echte gebruikersreis doorloopt en faalt op de stap die kapot ging, in plaats van op de site als geheel. Het vangt precies de klasse fouten op die een simpele beschikbaarheidscontrole als gezond rapporteert, waarbij de homepage 200 teruggeeft terwijl het inlogformulier erachter kapot is.

Omdat het synthetisch is, draait het volgens een schema zonder dat er verkeer nodig is, en omdat het een echte browser aanstuurt, oefent het de JavaScript, de afhankelijkheden van derden en de redirects uit die een gewone HTTP-controle overslaat. De transactiemonitoring van HostTracker werkt op deze manier, en de handleiding voor de transactiecontrole behandelt hoe een script wordt opgenomen en wat elke stap rapporteert.

Een meting omzetten in een melding

Geen van beide benaderingen is nuttig tot er iets met het resultaat gebeurt. Een synthetische controle is de moeite waard omdat die draait of u nu kijkt of niet, en omdat een mislukking u meteen kan bereiken: HostTracker voert zijn controles uit vanaf 300+ controlepunten in 158 steden over 13 monitortypes, en stuurt meldingen via e-mail, sms, spraakoproep, Slack, Telegram en meer wanneer een resultaat verandert. Combineer dat met welke RUM u al verzamelt en u heeft beide helften: een melding wanneer de site kapot gaat, en bewijs over voor wie hij traag was. De rest van het onderdeel over monitoringbegrippen behandelt de termen waarop deze twee rusten.