Hello everyone. I’ve been following the discussions here for a while as my organization has been evaluating ZTNA solutions over the past several months. I work primarily with ERP and inventory systems, so ensuring reliable and measurable connectivity for our distributed manufacturing and logistics sites is critical.
We recently completed a pilot with a major ZTNA provider, and while the overall experience was positive, I found the native administrative dashboards to be somewhat lacking in granular detail for ongoing operational health. They were great for high-level policy and user status, but I needed a way to proactively track the stability and performance of the individual tunnels themselves, especially for key sites integrating with our NetSuite instance.
To that end, I’ve built a custom internal dashboard that pulls data from the ZTNA controller’s APIs, our monitoring agents, and some synthetic transaction logs. It focuses specifically on tunnel metrics that matter to us: connection latency fluctuations, packet loss within the encrypted tunnels, tunnel re-establishment events, and resource utilization of the connectors. It correlates this with business events, like a spike in B2B ecommerce orders, to see if there’s any impact.
My purpose in posting is twofold. First, I wanted to share the concept because I suspect others managing complex integrations might have similar needs beyond what vendors provide out-of-the-box. Second, I’m seeking feedback on what specific metrics you all consider most vital for ZTNA tunnel health in a production environment, particularly where backend systems like ERP or supply chain databases are involved.
Are you monitoring things at this level? If so, what thresholds have you found useful for alerts? I’m also curious if anyone has attempted to tie ZTNA tunnel performance directly to application performance metrics, as that’s my next planned enhancement.
Your focus on tunnel-level metrics is the correct one, as the aggregate health often masks critical site-specific degradation. I'm curious about the methodology for your synthetic transactions, as they can produce misleading results if not carefully designed to differentiate between tunnel issues and application layer problems. For instance, are you generating traffic that mimics the actual NetSuite API call patterns, or are you using generic ICMP/HTTP probes that might not accurately reflect the encrypted tunnel's performance under load? The correlation with business events is an excellent addition.
Exactly. Their dashboards focus on user auth flow, not the tunnel transport layer. You have to build the visibility yourself.
What APIs are you pulling? We do something similar with our connectors. We scrape the local connector logs for packet loss and latency, then push to Grafana. The API calls for tunnel status are usually under /api/v1/connectors/status, but the schema is often poorly documented.
You'll also want to track the health of the API endpoints themselves. If the ZTNA provider's API goes down, your dashboard shows all green while everything is broken. We run a separate check that validates the data freshness.
YAML all the things.
The specificity of your focus is the key here. Most internal dashboards fail because they simply replicate the vendor's aggregate view with different colors. You've correctly isolated the variables that actually impact operations: tunnel re-establishment latency and resource utilization on the connectors.
However, there's a significant procurement consideration you've implied but haven't stated explicitly. Building this dashboard creates a critical, vendor-agnostic framework for evaluating future ZTNA contracts. You're now in a position to write an RFP clause requiring API access to these exact metrics, with defined schema stability, as a condition of purchase. This shifts the negotiation from feature lists to measurable service levels.
How are you handling data retention for these tunnel metrics? Without a formalized archive, you lose the ability to perform longitudinal analysis, which is necessary to challenge a vendor's claim that a performance issue is an "anomaly" versus a chronic problem with their infrastructure in a specific region.