I was conducting a routine review of our Zscaler Internet Access logs in our SIEM, correlating session information with user complaints about poor VPN and SaaS application performance. While the firewall logs pointed to latency and packet loss, they lacked the granular, user-centric view needed to pinpoint the exact location of the infrastructure problem. This is where I finally dove deeper into ZDX, specifically the Digital Experience Monitoring capabilities, and it turned out to be an excellent source of truth.
The process essentially involves using ZDX to isolate performance metrics by location. In our deployment, each major branch office has its own subnet range, which ZDX automatically maps based on the user's source IP. From the ZDX dashboard, you can then filter and compare these sites across several key internet health metrics. The most revealing data points for us were:
* **Internet Round Trip Time (RTT) by Location:** This isn't just the latency to Zscaler. ZDX can show the full-path RTT from the user endpoint to the final application, giving you a true measure of the "last mile" internet quality at each branch.
* **Wi-Fi vs. Wired Experience Score:** A breakdown per office showing if the issue is localized to the wireless network or pervasive across wired connections, which immediately ruled out our wireless controllers for several sites.
* **ISP Performance Trends:** ZDX charts the historical performance for each location, allowing you to see if the degradation is a sudden event or a chronic issue that has been building.
By exporting this data for a set period and comparing offices, I was able to generate a clear, data-backed ranking. For example, the data for our top three offending sites looked something like this in the exported report:
```
Location Avg. Internet RTT Exp. Score (Wired) % Packet Loss
Branch_A 187 ms 4.2 1.8%
Branch_B 89 ms 8.7 0.1%
Branch_C 342 ms 2.1 4.5%
```
The outcome was that Branch_C, which had been somewhat vocal, was actually third-worst. The true worst performer, Branch_A, had become acclimated to the poor performance and rarely submitted tickets. This data provided the objective evidence needed to engage their local ISP with specifics—we could show the sustained packet loss and high latency originating from their circuit, rather than our internal network. It also helped us justify the business case for a secondary internet link at that location for failover. This use case has become a standard part of our monthly compliance and operational review, as it directly supports our service continuity objectives.
Logs don't lie.
Great point about using the Internet RTT by location to measure the "last mile." That's the killer feature for us, too. It helped us catch a weird issue where our regional hub had great latency to the ZEN, but the actual SaaS app performance was terrible for users there. Turns out the ISP's peering to the cloud provider's region was saturated during business hours. ZDX showed the full-path breakdown, so we knew to look beyond our own circuit.
Have you tried correlating those ZDX location metrics with the ZIA session data you mentioned, like the SSL handshake times? We built a quick Grafana dashboard that pulls both data sources together. Seeing a spike in RTT *and* a corresponding jump in SSL negotiation times from a specific office subnet is a dead giveaway for local ISP issues. It saved us a ton of time arguing with the provider, we just sent them the graphs.
— francesc