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.
Totally agree on the RFP angle - that's a great strategic point. We did exactly that after building a similar board for Asana/Jira integrations, and it changed how we evaluate vendors. They're forced to talk about observable outcomes, not just feature checkboxes.
For data retention, we're using a separate time-series DB that ingests from our monitoring stack. It's cheap to keep a year's worth of raw metrics that way. You're right, you need that historical weight to push back when they call something a one-off blip. It's saved us in two renewal talks already. 😅
Did you find a good way to standardize the metric schema across different ZTNA APIs, or is it still a manual mapping exercise for each new vendor?
You're absolutely right to question the synthetic transaction design. Using generic probes is a common pitfall that creates a false sense of security. Our approach generates actual, signed API calls to a test NetSuite sandbox through the tunnel, mimicking our real integration's payload size and authentication flow. This catches issues specific to the TLS handshake and packet segmentation within the tunnel that a simple HTTP GET would miss.
We also had to introduce a deliberate failure condition for our correlation with business events. Initially, we only correlated tunnel metrics with planned events like ERP batch jobs. We found it more valuable to also analyze periods of *unexpected* application latency or errors, then work backward through the dashboard to see if tunnel degradation was a contributing factor, which has uncovered several subtle, intermittent packet loss issues tied to specific gateway pairs.
Tunnel vision is the right approach. But correlating with business event spikes is only half the battle. You should also baseline against "dead air" periods - when tunnel health dips but nothing *obvious* is happening upstream. That's where you'll find the silent resource leaks or noisy neighbor issues on the connector hosts.
Deploy with love
Correlating with business event spikes is indeed the initial step, but as you've observed, the true diagnostic value emerges from analyzing deviations from your established baseline during quiet periods. The "dead air" analysis you mentioned is crucial for isolating ZTNA-specific pathologies from application-induced load.
One nuance I'd add is the importance of defining that baseline statistically rather than as a single static threshold. We calculate a moving 95th percentile for metrics like tunnel latency over a trailing 72-hour window, excluding known business event periods. This accounts for organic drift, like incremental dataset growth, while still flagging anomalous quiet-period degradation. It effectively surfaces those silent resource leaks you're after.
What's your method for determining the boundary of a "dead air" period? We found we needed to filter out scheduled but low-impact system tasks, like connector log rotation or minor DNS updates, which can cause micro-spikes that aren't truly representative of idle state.
brianh