How to Monitor Netmaker VPN Infrastructure with Vigilmon

Netmaker gives DevOps teams a self-hosted, WireGuard-based mesh VPN with a management API and dashboard — but running your own VPN controller means you own the availability story too. If the Netmaker server goes down, every remote node loses its ability to reconfigure its tunnels, and eventually, your VPN fabric silently degrades.

This tutorial shows you how to monitor Netmaker's control plane, data-plane tunnels, and background jobs with Vigilmon so you catch problems before your team does.

Why Netmaker needs external monitoring

A self-hosted Netmaker deployment has several independent layers that can fail independently:

Netmaker server — the REST API that nodes poll for network configuration updates. If it's unreachable, nodes can't join, and peers stop syncing keys.
Netclient daemons — the WireGuard-management agent on each peer. A crashed daemon means the node is silently excluded from the mesh.
MQTT broker (MQ) — Netmaker uses an embedded MQTT broker (Mochi MQ or Mosquitto) for push-based peer updates. A failed MQ means stale routing tables.
DNS (CoreDNS) — Netmaker's optional DNS integration lets nodes resolve each other by name. A down CoreDNS breaks service-to-service communication even when WireGuard is fine.

Docker's HEALTHCHECK and Kubernetes readiness probes detect failures within a single pod, but they don't tell you whether Netmaker's API is actually reachable from outside the cluster, or whether the MQTT broker is accepting connections.

What you'll need

A running Netmaker deployment (Docker Compose or Kubernetes)
A free Vigilmon account

Step 1: Expose a health endpoint on the Netmaker API

Netmaker exposes a ping route at /api/server/health. You can verify it with:

curl -s https://your-netmaker-domain.example.com/api/server/health
# Returns: {"status":"ok"}

This is the primary endpoint Vigilmon will poll. It checks that the API server is up, the database connection is live, and the core request pipeline is functional.

If you're proxying Netmaker through nginx, confirm the route is accessible without authentication:

location /api/server/health {
    proxy_pass http://netmaker:8081;
    proxy_set_header Host $host;
    # No auth_request here — health check must be unauthenticated
}

Step 2: Set up HTTP monitoring for the Netmaker API

Log in to vigilmon.online and click Monitors → New Monitor
Choose HTTP / HTTPS
Set the URL to https://your-netmaker-domain.example.com/api/server/health
Set check interval to 1 minute
Under Expected response:
- Status code: 200
- Response body contains: "status":"ok"
Save the monitor

Vigilmon will now probe the Netmaker API from multiple regions every minute. You'll get an alert if the API returns a non-200 status, the body doesn't match, or the request times out.

Step 3: Monitor the Netmaker dashboard (UI)

The Netmaker UI is a separate static frontend. It can be down while the API is up (or vice versa). Monitor it independently:

Add a second HTTP monitor targeting https://dashboard.your-netmaker-domain.example.com
Expected status code: 200
Set a meaningful name like Netmaker Dashboard

This catches CDN misconfigurations, nginx misconfiguration, or frontend deployment failures that leave your team locked out of the management interface.

Step 4: Monitor the MQTT broker with a TCP check

Netmaker's MQTT broker listens on port 8883 (TLS) or 1883 (plain). TCP monitoring verifies the port is open and accepting connections — a lightweight check that works without MQTT credentials.

In Vigilmon, add a TCP Port monitor
Hostname: your-netmaker-domain.example.com
Port: 8883
Name it Netmaker MQ

If the broker crashes, this fires immediately. Node-push updates stop working without the broker, causing peers to drift out of sync until they do a full pull from the API.

Step 5: Send a heartbeat from Netmaker's backup/sync job

If you run a cron job to back up Netmaker's SQLite or PostgreSQL database, or to rotate WireGuard keys, use a Vigilmon heartbeat to verify those jobs run on schedule.

Add this to your backup script:

#!/bin/bash
# netmaker-backup.sh

# Back up Netmaker DB
sqlite3 /etc/netmaker/netmaker.db ".backup /backup/netmaker-$(date +%Y%m%d).db"

if [ $? -eq 0 ]; then
  # Signal Vigilmon that the backup completed successfully
  curl -s "https://vigilmon.online/api/heartbeat/YOUR_HEARTBEAT_ID" \
    --max-time 10 \
    --retry 3 \
    --silent
fi

Set up the heartbeat in Vigilmon:

Go to Monitors → New Monitor → Heartbeat
Name it Netmaker DB Backup
Set the expected interval to match your cron schedule (e.g., 24 hours)
Copy the heartbeat URL into your script

If the backup job fails or the machine running it goes offline, Vigilmon fires an alert after the interval expires.

Step 6: Monitor CoreDNS (if enabled)

Netmaker's optional CoreDNS integration lets mesh nodes resolve each other by hostname. If CoreDNS goes down, service-to-service DNS inside the mesh breaks. Add a TCP check on the DNS port:

Add a TCP Port monitor
Hostname: your-netmaker-domain.example.com
Port: 53
Name it Netmaker CoreDNS

For production deployments that rely on internal DNS, this check is critical — DNS failures cause cascading application errors that are slow and painful to diagnose.

Step 7: Set up alert channels and a status page

Alert channels — route Netmaker alerts where your on-call team watches:

Go to Alert Channels → Add Channel
Choose Slack, Discord, email, or webhook
Assign channels to all four monitors (API, Dashboard, MQ, CoreDNS)

Public status page — useful if your Netmaker deployment serves customers or remote contractors:

Go to Status Pages → New Status Page
Name it Netmaker VPN Status
Add all monitors
Publish the page

Share the status URL in your team's #devops channel so anyone can check VPN health without pinging the on-call engineer.

Complete monitoring setup summary

| Monitor | Type | Endpoint | What it catches | |---------|------|----------|-----------------| | Netmaker API | HTTP | /api/server/health | API crash, DB failure, cold start | | Netmaker Dashboard | HTTP | / | Frontend down, CDN/nginx misconfiguration | | MQTT Broker | TCP | port 8883 | MQ crash, peer-update failures | | CoreDNS | TCP | port 53 | Internal DNS failure | | DB Backup Job | Heartbeat | cron schedule | Missed backup, disk full, job crash |

What to do when an alert fires

API down — check Docker logs with docker compose logs netmaker; most common causes are disk full, DB lock, or OOM kill
MQ down — restart the Mochi MQ container; check for port conflicts on 8883
CoreDNS down — restart the CoreDNS container; check /etc/netmaker/Corefile for configuration errors
Heartbeat missed — SSH to the backup host and run the script manually; check cron logs with journalctl -u cron

Next steps

SSL expiry monitoring — Vigilmon checks your TLS certificate and alerts you before it expires. Add your-netmaker-domain.example.com to the SSL monitor list.
On-call rotation — use Vigilmon's alert routing to send API-down alerts to a specific on-call schedule instead of the whole team.

Start monitoring your Netmaker deployment for free at vigilmon.online — no credit card required.