Is het Zscaler of de wifi? Root cause-analyse in minuten
Een Teams-gesprek hapert, en de eerste zin in het ticket luidt bijna altijd hetzelfde: "Dat zal wel aan Zscaler liggen." Vaak klopt dat niet. Maar het tegendeel bewijzen kost de helpdesk uren. Het kan sneller.
Elk IT-team kent het beeld. Een medewerker belt, het videogesprek hapert, de cloud-app laadt traag. Omdat Zscaler als beveiligingslaag inline in de datastroom zit en al het verkeer inspecteert, is het het meest zichtbare element van de keten, en dus de eerste verdachte. De reflex "het is Zscaler" is begrijpelijk, maar het is een gok, geen diagnose.
In werkelijkheid is de oorzaak net zo vaak een overbelast thuiswifi, een zwakkere ISP-verbinding, een laptop die zwaar op de CPU leunt, of een applicatie die zelf net problemen heeft. Alleen: dat moet de helpdesk eerst moeizaam aantonen. En tot dat bewijs er is, blijft de verdenking hangen bij de beveiligingsgateway, die objectief niets fout doet.
Waarom de schuldvraag zo duur is
Het klassieke proces kost op meerdere plekken tegelijk tijd. De eerste lijn neemt het ticket aan, maar kan de netwerkketen zelf niet inzien en escaleert. De tweede lijn opent meerdere weergaven: het ZDX-dashboard, misschien een apart netwerkmonitoringtool, het apparaatoverzicht. Hij correleert tijdstempels met de hand, controleert of er op het moment van het incident een policy gold, en formuleert uiteindelijk een inschatting die hij aan de gebruiker moet uitleggen.
Elke van deze overdrachten kost minuten tot uren. En omdat de verdenking zonder harde bevinding in de ruimte staat, komt die bij twijfel terecht bij het securityteam, dat op zijn beurt moet bewijzen dat alles correct werkt. Uiteindelijk lag het aan de wifi in het thuiskantoor, maar er hebben vier mensen aan gewerkt.
Zscaler levert de gegevens al: ZDX
Zscaler Digital Experience, kortweg ZDX, meet de digitale gebruikerservaring end-to-end. Het legt apparaatmetrieken vast (CPU, geheugen, wifisignaal), de lokale netwerkverbinding, het pad via de internetprovider en het pad door de Zscaler-cloud naar de doelapplicatie. De ZDX Deep Trace toont elke afzonderlijke hop met latency en pakketverlies. Daarmee is de informatie over waar het precies knelt technisch aanwezig.
Het probleem zit niet in de gegevens, maar in de toegang en de interpretatie. De Deep Trace is een tool voor specialisten. Hij toont ruwe waarden over het hele traject, maar zegt niet in één zin: "De wifi van de gebruiker is het knelpunt, Zscaler valt niet op." Precies die vertaling van meetwaarde naar uitspraak is de stap die in de dagelijkse praktijk tijd kost en beheerdersrechten vereist die de helpdesk vaak niet heeft.
Connectivity Triage Map: de keten samenbrengen, de oorzaak benoemen
Hier komt Connectivity Triage Map van CentaurNexus in beeld. De module brengt via de officiële Zscaler OneAPI de volledige ZDX-keten samen en vult deze aan met de actuele policystatus voor de betrokken gebruiker en applicatie. Uit deze signalen vormt het een oordeel in gewone taal: de oorzaak ligt bij de ISP, de wifi, het apparaat of Zscaler.
Het verschil zit niet in toegang tot nieuwe gegevens, maar in de diagnose in plaats van de ruwe gegevens. In plaats van vijf tabbladen te openen en tijdstempels te vergelijken, ziet de medewerker een benoemde bevinding en daaronder, uitklapbaar, het Deep Trace-bewijs hop voor hop. Wie dieper wil controleren, ziet de keten; wie alleen moet handelen, ziet het oordeel.
- Gebruiker en applicatie uit het ticket selecteren (een naam volstaat, geen Zscaler-beheerconsole nodig).
- Connectivity Triage Map haalt de ZDX-keten en de policystatus via de OneAPI op en beoordeelt ze.
- Het oordeel in gewone taal verschijnt: ISP, wifi, apparaat of Zscaler, met het zwakste punt van de keten.
- De ZDX Deep Tracing toont desgewenst elke hop met latency en pakketverlies als bewijs.
- De bevinding kan worden geëxporteerd als bewijs en bij het ticket, de gebruiker of de provider worden gevoegd.
Gewone taal, ook voor de eerste lijn
De praktische hefboom zit in wie de analyse kan uitvoeren. Omdat Connectivity Triage Map het resultaat in begrijpelijke taal formuleert, hoeft niet elk geval te escaleren naar een netwerkspecialist. Een eerstelijnsmedewerker leest "knelpunt in de lokale wifi, Zscaler valt niet op" en kan direct de juiste aanbeveling geven: dichter bij de router gaan zitten, bandbreedte controleren, apparaat ontlasten. De escalatie vervalt precies in de gevallen waarin ze nooit nodig zou zijn geweest.
De bevinding als bewijs
Een vaak onderschat punt: als de oorzaak buiten de eigen invloedssfeer ligt, bijvoorbeeld bij een internetprovider of een thuiswerkaansluiting, heeft de IT een stevig bewijs nodig om het onderwerp door te geven. Een exporteerbare Connectivity Triage Map-bevinding met ZDX Deep Tracing-bewijs is precies dat bewijs. Hij documenteert navolgbaar op welk punt van de keten de latency of het pakketverlies optrad, en haalt de speculatie uit de discussie.
CentaurNexus scheidt tenantcontexten, kent rechten rolgebonden toe en logt processen navolgbaar. De helpdesk ziet zijn vrijgegeven gebied zonder brede Zscaler-beheerdersrechten. Voor EU-klanten verloopt de productie-omgeving volledig op STACKIT in de EU; privacy- en datapaden zijn gedocumenteerd in de privacyverklaring.
Bekijk Connectivity Triage Map aan de hand van een echt geval
In de voorbereide demo doorlopen we een root cause-analyse van begin tot eind: van de melding "het hapert" tot het oordeel in gewone taal met ZDX Deep Tracing-bewijs, zonder brede Zscaler-beheerdersrechten.
Voorbereide demo openenZDX en CentaurNexusAgent vullen elkaar aan
ZDX levert de digitale ervaring over applicatie, netwerkpad en apparaat. CentaurNexusAgent vult dit beeld aan met de eindpuntsignalen die nodig zijn voor de ondersteunde CentaurNexus-workflow, wanneer deze informatie niet via OneAPI beschikbaar is. CentaurNexusAgent vult de ZDX-context aan met eindpuntsignalen voor ondersteunde CentaurNexus-workflows.
De Connectivity Triage Map verbindt de beschikbare signalen tot een navolgbare oorzaak-gevolgketen. Ze toont of de sterkste aanwijzing bij het apparaat, het lokale netwerk, het Zscaler-pad of de applicatie ligt. Bron, gegevensleeftijd en coverage blijven onderdeel van het resultaat.
Een bevinding moet tot de volgende actie leiden
Een diagnose is voor de helpdesk pas nuttig als ze de volgende controlestap verklaart. Een lokaal wifisignaal leidt tot een andere maatregel dan een onbereikbare App Connector of een centrale dienststoring. De medewerker ziet de onderbouwde inschatting en kan gericht oplossen of overdragen.
Bij de acceptatie worden volledige, gedeeltelijk beschikbare en bewust ontbrekende bronnen getest. Zo blijft de Connectivity Triage Map ook begrijpelijk wanneer een tenant niet elke ZDX- of agentbron levert.
Veelgestelde vragen
Doorslaggevend is het bekijken van de volledige keten van het apparaat via wifi, ISP en Zscaler tot de applicatie. Zscaler ZDX levert precies deze hop-voor-hopmetrieken. Connectivity Triage Map van CentaurNexus brengt de ZDX-keten plus de policystatus automatisch samen en benoemt het zwakste punt in gewone taal, in plaats van dat een analist de ruwe gegevens handmatig bij elkaar zoekt.
Zscaler Digital Experience (ZDX) meet de gebruikerservaring end-to-end. De Deep Trace toont elke netwerkhop tussen apparaat en doelapplicatie met latency en pakketverlies, plus apparaat- en wifimetrieken. Zo wordt zichtbaar of het knelpunt lokaal, bij de provider of in het cloudpad ligt.
Nee. CentaurNexus leest via de officiële Zscaler OneAPI en levert de bevinding rolgebonden aan. Eerste en tweede lijn zien het oordeel en de Deep Trace zonder volledige toegang tot het Zscaler-beheer nodig te hebben. Alle toegang is tenantgescheiden en auditeerbaar.
Vaak is dat helemaal niet het geval: Zscaler zit inline in de datastroom en controleert het verkeer, waardoor het het meest zichtbare element van de keten is en het eerste dat verdacht wordt. Net zo vaak ligt de oorzaak bij een overbelaste wifi, een zwakkere ISP-verbinding, een overbelast apparaat of een applicatie met eigen problemen. Connectivity Triage Map brengt de ZDX-keten en de policystatus samen en benoemt de werkelijke oorzaak, in plaats van het bij een vermoeden te laten.
Nee. De beveiligingsgateway is slechts één schakel in een keten waartoe ook het apparaat, de lokale wifi, de internetprovider en de applicatie zelf behoren. Welke schakel werkelijk het zwakke punt is, verschilt per geval. Precies daarom helpt een oordeel in gewone taal over de hele keten meer dan een reflexmatig vermoeden.
Dichter bij de router gaan zitten, de beschikbare bandbreedte controleren en CPU-intensieve achtergrondapplicaties sluiten lost een groot deel van de dagelijkse klachten op, omdat de lokale wifi of een overbelast apparaat veelvoorkomende oorzaken zijn. Blijft het probleem daarna bestaan, dan loont het de moeite om de IT een echte root cause-controle over de volledige verbinding te laten uitvoeren.
Ja. Een exporteerbare bevinding met ZDX Deep Trace-bewijs documenteert hop voor hop precies waar latency of pakketverlies optrad. Zo wordt van een discussie op basis van een vermoeden een discussie op basis van bewijs, ongeacht of uiteindelijk de ISP, de wifi, het apparaat of soms ook Zscaler zelf de oorzaak blijkt te zijn.
- Zscaler: Viewing Diagnostics Session Results – officiële ZDX-documentatie.
- Zscaler: About API Clients – officiële beschrijving van OneAPI en rollen.
- CentaurNexus voor helpdesk en 2nd line: gebruikers-, apparaat- en toegangscontext zonder brede beheerdersrechten.