Another week, another vendor telling me my data lives in the cloud and I should be happy about the black box. Netskope's ZTNA tunnels are critical for our remote access fabric, but their own health metrics felt like they were being reported through a keyhole. The portal dashboards are fine for a high-level glance, but I needed something I could pipe into our existing alerting and trend over time. So, like any self-respecting engineer who doesn't enjoy clicking through five layers of SaaS UI, I wired up the Netskope REST API to Grafana.
It's not magic, just the usual slog of API wrangling. The key endpoints are under `/api/v1/infrastructure/tunnel-status` and `/api/v1/infrastructure/tunnel-summary`. You'll need a valid API token with appropriate permissions. The data comes back as JSON, which Telegraf's `http` input can parse with a bit of JSONv2 processor massage. I'm pushing everything into a PostgreSQL table because, frankly, Prometheus feels like overkill for this and I already have a timescale hypertable sitting there. Here's the core of the Telegraf config:
```toml
[[inputs.http]]
urls = ["https://tenant.goskope.com/api/v1/infrastructure/tunnel-status"]
method = "GET"
headers = {"Authorization" = "Token $NETSKOPE_API_TOKEN"}
data_format = "json"
json_v2 = [
{
measurement_name = "netskope_tunnel"
timestamp_path = "timestamp"
timestamp_format = "unix_ms"
tags = [
{path = "tunnel_name"},
{path = "tunnel_type"},
{path = "connector_name"},
{path = "status"}
]
fields = [
{path = "latency", type = "float"},
{path = "bytes_in", type = "int"},
{path = "bytes_out", type = "int"},
{path = "active_sessions", type = "int"}
]
}
]
```
The dashboard itself has four core panels:
* Tunnel status matrix (color-coded by up/down/degraded) per connector
* Latency trend (95th percentile) over the last 24 hours, because averages lie
* Total bandwidth throughput per tunnel cluster
* Session count vs. connector CPU/memory (pulled from a separate infra metric source) to spot resource contention
The real value wasn't in the pretty lines, but in setting alert rules on the latency spikes and session drops that the Netskope console only shows you after the fact. Now, when the network team starts fiddling with the SD-WAN, I get a screaming alert in PagerDuty before the help desk tickets roll in. It also finally gave me a clear view of the cost/performance trade-off for the different tunnel sizes we're running.
Biggest gotcha? The API's `tunnel-summary` can have a slight delay, so don't try to correlate it with sub-second precision against your own SNMP data. And for the love of all that's holy, cache the API token and rotate it properly. Don't hardcode it.
-- old salt