Learn OpenVPN - Observability & Monitoring

#Introduction

Episode 8 introduced logging and the management interface. Now it's time to level up: from reading logs manually to an observability infrastructure that alerts automatically. You don't want to wake up in the morning and only then find out the VPN died overnight.

Episode 19 covers observability and monitoring. You will learn to use openvpn-status.log as a source of structured metrics, expose it to Prometheus with the openvpn exporter, build a Grafana dashboard, and set up alerting for dropped connection detection and certificate expiry warnings.

The goal: VPN health visible on a single screen, and alerts that arrive before users complain — not after.

#Structured Logging

#openvpn-status.log as a Metrics Source

The status file from episode 8 is a goldmine of metrics. Version 3 format displays a complete client list with bytes in and out, plus connection duration:

OpenVPN CLIENT LIST
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
arman,203.0.113.7:51000,104857600,52428800,1723456789
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
10.8.0.5,arman,203.0.113.7:51000,1723456799

The line arman,203.0.113.7:51000,104857600,52428800,1723456789 is one client with traffic metrics and connection time. From lines like this, any monitoring tool can calculate active client counts, throughput, and session duration.

#Making the Log Structured

To make parsing easy, enable a stable status format and avoid status files written by hand:

status /var/log/openvpn-status.log
status-version 3
status-version-txt 3
status-timeout 60

status-timeout 60 makes the status file update every 60 seconds. status-version 3 guarantees the stable format recognized by many tools. With this, exporters and log pipelines can read the data without guessing.

#Metrics to Prometheus

#The Role of the openvpn Exporter

Prometheus pulls metrics from an HTTP endpoint provided by an exporter. For OpenVPN, openvpn_exporter reads the status file and exposes metrics like openvpn_active_clients, openvpn_client_bytes_received, and openvpn_client_bytes_sent:

openvpn_exporter -openvpn.status_paths /var/log/openvpn-status.log

openvpn_exporter -openvpn.status_paths /var/log/openvpn-status.log serves metrics on port 9176 by default. The exporter can also read the management interface for additional data — exactly what was opened in episode 8.

#Adding a Target in Prometheus

Add the exporter target to the Prometheus configuration:

scrape_configs:
  - job_name: openvpn
    static_configs:
      - targets:
          - vpn1.example.com:9176
          - vpn2.example.com:9176

The two targets vpn1 and vpn2 collect metrics from two servers at once. Prometheus then evaluates alert rules and stores time series that can be queried in Grafana.

#Grafana Dashboard

#Building a Single View

Grafana turns metrics into graphs. A good VPN dashboard shows: active client count over time, inbound and outbound throughput, the list of connected clients, and connection history. All this data is available from the exporter metrics.

A common Prometheus query for displaying active clients:

sum(openvpn_active_clients)

sum(openvpn_active_clients) sums the active clients from all servers. Add per-server graphs with labels, and throughput graphs from byte deltas with the rate function.

#Annotations and Panels

Grafana panels can be distinguished per environment with target labels. Annotations can mark deployment or maintenance times, so anomaly spikes are easy to link to operational events. A dashboard becomes a communication tool between network and platform teams.

#Alerting

#Detecting a Client Count Drop

The most basic alert: the active client count drops drastically outside normal hours. This can indicate a dead server or a mass disruption event:

groups:
  - name: openvpn
    rules:
      - alert: OpenVPNClientCountDrop
        expr: |
          sum(openvpn_active_clients) < 5
        for: 5m
        labels:
          severity: warning

The rule sum(openvpn_active_clients) < 5 for 5m triggers an alert if active clients stay below 5 for 5 minutes. The threshold and duration are tuned to the organization's profile — an empty office network on weekends will surely trigger false alerts.

#Monitoring Certificate Expiry

Expired certificates are a common reason clients fail to connect. Alerting based on node_exporter and blackbox can't catch this; use the prometheus ssl_exporter or a script that exports the server certificate's expiry date:

openssl x509 -in /etc/openvpn/server/server.crt -noout -enddate

openssl x509 -in ... -noout -enddate displays the certificate's end-of-validity date. Turn this output into a Prometheus metric, then create an alert rule that fires 30 days before expiry.

#Log-Based Alerting with Loki

Loki makes alerting from logs easy. A real example: monitor error patterns in journald and trigger an alert when repeated errors appear:

{job="systemd-journal"} |~ "TLS Error|Fatal error"

{job="systemd-journal"} |~ "TLS Error|Fatal error" selects log lines containing error patterns. With alert rules in Loki or Grafana, every error spike immediately notifies the team.

#Conclusion

Key takeaways:

• openvpn-status.log version 3 is a stable, structured metrics source.
• openvpn_exporter exposes status metrics to Prometheus.
• Grafana unifies metrics into a readable dashboard.
• Client drop alerts detect disruptions faster.
• Certificate expiry must be monitored and alerted on.
• Loki enables alerting based on log error patterns.

In the next episode, episode 20, we will discuss OpenVPN Access Server and CloudConnexa — managing a VPN through a web UI with LDAP, RADIUS, and SAML SSO integration, using CloudConnexa for zero-trust network access, and comparing when to choose self-hosted versus managed services. After this episode, you'll know the commercial options around OpenVPN.