Valenius exposes a Prometheus-compatible metrics endpoint and ships an official Zabbix template — one HTTP item a minute, no agent on the backend, no scripts on the Zabbix server. Backend health, license runway and every WireGuard® gateway land in the monitoring system your team already watches. Included in both editions.
VPN problems rarely announce themselves. A license quietly runs out, a gateway stops answering, handshakes go stale on one site — and the first alert you get is a phone call from someone who cannot work. These are exactly the states a monitoring system is good at catching, provided something hands it the numbers.
Validity, expiry date and seat usage are all exported as plain numbers, so your monitoring system can warn you thirty days out and escalate at seven — instead of you discovering the problem on the morning it expires.
Is the backend answering, is its database reachable, how long does a query take, what does request latency look like at the 95th percentile, are 5xx responses climbing? All of it is visible before users start noticing anything.
Each Pro-managed WireGuard® server reports in every 30 seconds. If one stops, you see it as a gateway that is down — and, separately, as data that has gone stale, so “the server is dead” never gets confused with “the poller is stuck”.
Peers configured versus peers actually connected, plus the age of the oldest handshake on each gateway. A site that slowly loses its peers shows up as a trend long before anyone raises a ticket about it.
Gateway CPU, memory, load average and connection-tracking table usage come along with the peer data — so the host running out of room is a warning you act on, not a post-mortem you write.
You already run something that pages the right person at 3am, with escalation, maintenance windows and on-call rotas configured. Valenius feeds that, instead of asking your team to watch yet another panel.
Plenty of tools publish a metrics endpoint and leave the rest to you. Valenius ships the finished Zabbix side too — items, triggers, discovery, value maps, a dashboard and a traffic graph, in one importable file.
The template polls a single HTTP agent item once a minute. Everything else — roughly twenty control-plane and license items, plus per-gateway items and triggers discovered automatically — is parsed out of that one payload by Zabbix’s built-in Prometheus preprocessing. A deployment with five hundred peers is still one request, not five hundred.
Nothing is installed on the Valenius host and no external script runs on the Zabbix server. The host needs no interface at all, because every item is an HTTP agent or dependent item rather than an agent or SNMP poll.
7.0, so any 7.x import works
GET /api/v1/metrics · Prometheus text exposition formatmonitoring:readGET /api/v1/monitoring/status — the same data as small JSONintegrations/zabbix/template_valenius_http.yaml in the repoThe endpoint is ordinary HTTP, so you can verify it before touching Zabbix at all — and confirm that it refuses anyone without a token.
# does it answer, and with the right content type? curl -sSi -H "Authorization: Bearer vlnm_..." \ https://vpn.example.com/api/v1/metrics | head -20 # and without a token it must refuse — expect 401 curl -sSi https://vpn.example.com/api/v1/metrics | head -1
No agent to deploy, no exporter to run, no script to schedule. Mint a token, import a file, set two macros.
Open Monitoring in the admin panel’s left nav and create a token. Optionally restrict it to your monitoring server’s IP or CIDR range and give it an expiry. The full value is shown exactly once.
In Zabbix, Data collection → Templates → Import and pick template_valenius_http.yaml. Create a host for your backend — no interface needed — and link the template Valenius by HTTP.
Point {$VALENIUS.URL} at your backend and paste the token into {$VALENIUS.TOKEN} as Secret text. A minute later, Latest data fills up and gateway discovery starts finding your servers.
Triggers ship with sensible defaults and every threshold is a macro, so tightening or loosening one is a field on the host — not a fork of the template.
The Zabbix template is the ready-made path, not the only one. The format underneath is plain Prometheus text exposition — the closest thing monitoring has to a lingua franca — so anything that scrapes Prometheus reads Valenius without an adapter.
Add a scrape job with a bearer token and you have history, alerting rules and dashboards in the stack you already run. Grafana Alloy works the same way.
All of them ingest the Prometheus format natively. One implementation on our side means you are not waiting for us to build an integration for your particular tool.
For a simple “is it healthy” check there is a small JSON summary at /api/v1/monitoring/status — status, version, license, database, gateway and peer counts, nothing to parse.
The same JSON is what support will ask you to paste into a ticket. It is also perfectly reasonable as the input to a nightly report or a Slack digest you write yourself.
If you run Zabbix for your customers, a VPN platform that hands you a finished template is worth more than one that hands you a metrics URL and a shrug. Import once, link the template to a host per backend, and the customer VPN is monitored to the same standard as their servers — with the same escalation paths and the same reports.
Because the token plane is separate from everything else, a monitoring credential is safe to treat as infrastructure. It cannot list clients, read configs or change anything — so it can live in your monitoring server’s configuration without becoming a key to the customer’s VPN.
Monitoring systems collect credentials and keep them in config files for years. That is a good reason for a monitoring token to be the least powerful thing in your deployment — and for the data it returns to be boring by design.
A monitoring token is not an admin login with fewer rights, and not a management API key with a box unticked. It carries exactly one scope — read metrics — and there is no path from it to anything else.
Labels never carry hostnames, usernames, e-mail addresses, WireGuard® public keys or client IP addresses — only opaque identifiers and counts. Key material never leaves through a monitoring scope, by construction.
The license identity exported to your monitoring system is an internal license id, not the name of the organisation it belongs to. What ends up in a shared NMS is a number, not a customer list.
There is no open metrics port, not even bound to localhost. Self-hosted deployments sit behind reverse proxies where “localhost” is rarely what people assume, so the endpoint always demands a token.
If the database is unreachable the endpoint still answers, still reports that the backend is up, and says the database is down. A monitoring endpoint that returns an error in a crisis tells you nothing at the moment you need it most.
Observability stays part of the open-source core. Community installs get the endpoint, the token plane and the template; Pro adds the per-gateway detail, because that data comes from the Pro sidecar and does not exist without one.
The metrics endpoint and the Zabbix template are in the free Community edition. Start there — the same template keeps working when you move to Pro, it just discovers more.