Synthetische monitoring, eenvoudig gedefinieerd
Synthetische monitoring betekent gescripte, geautomatiseerde verzoeken tegen je live systemen draaien volgens een vast schema — elke minuut, elke vijf minuten — en de resultaten precies zo beoordelen als een echte gebruiker of clienttoepassing zou doen. Het "synthetische" slaat op het verkeer: het wordt gegenereerd door een monitoringrobot, niet door een mens. Maar alles wat het raakt is echt: het echte productie-endpoint, de echte TLS-handshake, de echte database achter de API, de echte responspayload.
Zie het als een onvermoeibare testgebruiker die je belangrijkste workflows de klok rond controleert, vanaf meerdere plekken in de wereld, en meteen zijn hand opsteekt als er iets breekt. Omdat de checks volgens schema draaien in plaats van te wachten op echt verkeer, is synthetische monitoring proactief: het detecteert de storing om 3:04 uur 's nachts, niet wanneer de eerste klant hem om 7:30 uur raakt. Dat verschil — het horen van je tooling in plaats van je gebruikers — is de hele waardepropositie.
Synthetische monitoring vs. Real User Monitoring (RUM)
Synthetische monitoring wordt vaak afgezet tegen Real User Monitoring (RUM), dat de sessies van je werkelijke gebruikers instrumenteert en rapporteert wat zij hebben ervaren. De twee beantwoorden verschillende vragen en zijn complementair, geen concurrenten.
RUM vertelt je wat er echt met echte mensen gebeurde: welke pagina's traag waren in welke browser, op welk netwerk, in welk land. Zijn zwakte is structureel — het heeft verkeer nodig. Als niemand je checkout gebruikt om 3 uur 's nachts, zwijgt RUM terwijl je checkout kapot is, en je eerste datapunt komt met je eerste boze klant. Synthetische monitoring keert dat om: het genereert zijn eigen verkeer, dus de dekking is constant, of gebruikers nu actief zijn of niet. Zijn zwakte is het spiegelbeeld — het test alleen de paden die je hebt gescript, en zegt niets over de duizend echte browser- en netwerkcombinaties die RUM ziet.
De praktische regel: gebruik synthetische monitoring voor beschikbaarheid en correctheid ("werkt het kritieke pad op dit moment?") en RUM voor experience-analyse ("hoe snel voelt het voor echte gebruikers?"). Voor API's — die geen browsersessies hebben om te instrumenteren — is synthetische monitoring niet alleen de betere keuze; het is meestal de enige.
Wat een goede synthetische check werkelijk valideert
Een minimale synthetische check stuurt een HTTP-verzoek en controleert de statuscode. Dat vangt al harde storingen op, maar volwassen synthetische monitoring valideert bij elke run meerdere lagen:
Bereikbaarheid en TLS: de verbinding slaagt, het certificaat is geldig en staat niet op het punt te verlopen. Status en latentie: de responscode is wat je verwacht, en de responstijd blijft binnen een gedefinieerde drempel — een 200 OK in 8 seconden hoort als fout te tellen voor een gebruikersgerichte API. Inhoudelijke correctheid: assertions op de responsbody bevestigen dat de API echte data teruggaf, geen lege array of null-token achter een groene status. Complete workflows: meerstaps-scenario's schakelen verzoeken aan elkaar — authenticeren, aanmaken, verifiëren — en geven waarden tussen stappen door zoals een echte client, wat integratiefouten opvangt tussen services die er individueel gezond uitzien.
Elke laag vangt een foutklasse op waarvoor de vorige blind is. Teams die stoppen bij statuscodes ontdekken "up maar kapot"-incidenten steevast via supporttickets in plaats van via monitors.
Waarom locatie telt: multi-regio checks
Een synthetische check draait ergens vandaan, en dat ergens telt zwaarder dan de meeste teams verwachten. Een monitor die in dezelfde cloudregio draait als je API test bijna niets van het netwerkpad dat je echte gebruikers nemen: DNS-resolutie, CDN-edges, transit-routering en regionale cloudincidenten zijn allemaal onzichtbaar vanuit hetzelfde datacenter.
Dezelfde check vanuit meerdere geografische regio's draaien maakt van locatie een diagnostisch instrument in plaats van een blinde vlek. Als alle regio's tegelijk falen, is je origin down — bel de wachtdienst. Als één regio faalt terwijl de andere slagen, kijk je naar een CDN-, DNS- of routeringsprobleem dat een deel van je gebruikers raakt — een ander probleem, een ander escalatiepad, en cruciaal: een dat je vanuit één waarnemingspunt nooit had gezien. De vergelijking tussen regio's is zelf de diagnose.
Latentievergelijkingen werken hetzelfde: een respons die 80 ms duurt vanuit Amsterdam en 4 seconden vanuit Singapore is niet "up" voor je Aziatische klanten, ook al zou een monitor in één Europese regio perfecte gezondheid rapporteren.
Synthetische monitoring opzetten zonder ruis
De meest voorkomende faalmodus van synthetische monitoring is niet het missen van storingen — het is alertmoeheid. Een monitor die het team oppiept bij elke voorbijgaande netwerkblip leert iedereen binnen een maand om hem te negeren. Een paar configuratieprincipes houden het signaal schoon:
Vereis opeenvolgende fouten vóór een alert. Eén gefaalde check gevolgd door onmiddellijk succes is een blip; twee of drie opeenvolgende fouten zijn een incident. Stem frequentie af op kriticiteit. Omzetkritieke endpoints verdienen checks per minuut; een documentatiesite kan prima met 5 of 10 minuten. Begin met je kritieke pad, niet met alles. Monitor de login, de checkout, de kern-API-operatie — de drie workflows waarvan het falen je geld kost — voordat je elk endpoint dekt. Stuur altijd herstelmeldingen zodat niemand blijft debuggen aan een probleem dat zichzelf al oploste.
Zo opgezet krijgt een synthetische alert zijn betekenis terug: als hij afgaat, is er echt iets mis, en jij wist het vóór je gebruikers. Dat is het hele punt.
