Nexodus is Red Hat's open-source network connectivity solution designed for distributed workloads and hybrid cloud environments. It builds a secure, peer-to-peer mesh network across machines, VMs, containers, and cloud instances — no VPN concentrator required. But when your services depend on Nexodus connectivity to reach each other across data centers or cloud regions, you need visibility into whether those peer links and relay nodes are actually healthy. Vigilmon gives you that visibility with uptime monitoring, heartbeat checks, and alerting across your Nexodus mesh.
What You'll Set Up
- HTTP uptime monitors for the Nexodus API server and control plane
- TCP connectivity checks for Nexodus relay nodes
- Cron heartbeat monitors for peer-to-peer connectivity verification scripts
- SSL certificate monitoring for Nexodus API endpoints
- Alert channels for on-call notification when mesh connectivity degrades
Prerequisites
- Nexodus deployed (self-hosted or Red Hat managed) with at least two connected devices
nexctlCLI installed and authenticated- A free Vigilmon account
Step 1: Monitor the Nexodus API Server
The Nexodus control plane exposes a REST API that devices use to register, exchange keys, and discover peers. If the API server is unreachable, new devices cannot join and existing peers cannot update their endpoints.
- Log in to vigilmon.online and click Add Monitor.
- Set Type to
HTTP / HTTPS. - Enter your Nexodus API URL:
https://api.nexodus.example.com/api/v1/health(or your self-hosted endpoint). - Set Check interval to
1 minute. - Set Expected HTTP status to
200. - Click Save.
The Nexodus API exposes a health endpoint at /api/v1/health that returns {"status":"ok"} when the control plane is operational. Use this rather than the root URL to get a meaningful signal.
If you are running a self-hosted Nexodus stack, also monitor the underlying infrastructure components separately — the PostgreSQL database, Redis cache, and the Nexodus controller service.
Step 2: Check Relay Node Reachability with TCP Monitors
Nexodus uses relay nodes (STUN/TURN-style) when direct peer-to-peer connections cannot be established due to NAT or firewall restrictions. If relay nodes are down, connectivity between restricted peers silently degrades.
Add a TCP monitor for each relay node:
- Click Add Monitor → TCP Port.
- Enter the relay node IP or hostname.
- Set Port to the Nexodus relay port (default
51820for WireGuard-based transport, or your configured port). - Set Check interval to
1 minute. - Click Save.
For a self-hosted relay fleet, add one TCP monitor per relay node IP. This catches situations where the host is up but the Nexodus relay service has crashed.
You can list your relay nodes with:
nexctl relay list
Step 3: Heartbeat Monitoring for Peer Connectivity
Nexodus ensures mesh connectivity, but individual peer links can silently fail if WireGuard keys expire, NAT mappings age out, or firewall rules change. A connectivity verification script that pings a known peer and signals Vigilmon on success gives you end-to-end coverage that API health alone cannot provide.
- In Vigilmon, click Add Monitor → Cron Heartbeat.
- Set the expected ping interval to
5 minutes. - Copy the heartbeat URL:
https://vigilmon.online/heartbeat/YOUR_TOKEN.
Create a connectivity check script on each device:
#!/bin/bash
# /usr/local/bin/nexodus-peer-check.sh
PEER_IP="100.64.0.2" # IP of a known peer in the Nexodus mesh
VIGILMON_URL="https://vigilmon.online/heartbeat/YOUR_TOKEN"
if ping -c 1 -W 3 "$PEER_IP" > /dev/null 2>&1; then
curl -sf "$VIGILMON_URL" > /dev/null
else
echo "$(date): Peer $PEER_IP unreachable" >> /var/log/nexodus-check.log
fi
Schedule it with cron:
*/5 * * * * /usr/local/bin/nexodus-peer-check.sh
If the peer becomes unreachable and the script stops pinging Vigilmon, you get an alert after the expected interval — before your application layer notices the outage.
Step 4: Monitor Device Registration Status
Nexodus tracks all registered devices. You can expose a lightweight status endpoint from a small sidecar that queries nexctl and reports device health:
#!/usr/bin/env python3
# nexodus_health_server.py
from http.server import HTTPServer, BaseHTTPRequestHandler
import subprocess
import json
class HealthHandler(BaseHTTPRequestHandler):
def do_GET(self):
if self.path != '/health':
self.send_response(404)
self.end_headers()
return
try:
result = subprocess.run(
['nexctl', 'device', 'list', '--output', 'json'],
capture_output=True, text=True, timeout=10
)
devices = json.loads(result.stdout)
online = [d for d in devices if d.get('online', False)]
status = 200 if len(online) > 0 else 503
body = json.dumps({
'status': 'ok' if status == 200 else 'degraded',
'total_devices': len(devices),
'online_devices': len(online)
}).encode()
except Exception as e:
status = 503
body = json.dumps({'status': 'error', 'message': str(e)}).encode()
self.send_response(status)
self.send_header('Content-Type', 'application/json')
self.end_headers()
self.wfile.write(body)
def log_message(self, format, *args):
pass # suppress access logs
if __name__ == '__main__':
HTTPServer(('127.0.0.1', 9100), HealthHandler).serve_forever()
Run this sidecar as a systemd service and add a Vigilmon HTTP monitor pointing to http://localhost:9100/health. When all devices go offline (network partition, controller crash), the monitor returns 503 and Vigilmon alerts.
Step 5: SSL Certificate Monitoring for the API Endpoint
Nexodus API servers use TLS for all client communication. A lapsed certificate causes all device authentication to fail simultaneously — devices cannot refresh keys, peers cannot update endpoints, and new nodes cannot join.
Enable certificate monitoring on the API endpoint monitor you created in Step 1:
- Open the monitor for
https://api.nexodus.example.com/api/v1/health. - Enable Monitor SSL certificate.
- Set Alert when certificate expires in less than
21 days. - Click Save.
For self-hosted deployments where you manage certificates manually or via cert-manager, the 21-day window gives you enough runway to renew before expiry causes an outage.
Step 6: Configure Alert Channels
- Go to Alert Channels in Vigilmon and connect Slack, PagerDuty, email, or a webhook.
- For relay monitors, set Consecutive failures before alert to
2— brief network hiccups can cause single-probe failures. - For the heartbeat monitor, leave the threshold at
1— a missed heartbeat already represents 5+ minutes of connectivity loss.
For team routing, create separate alert channels for:
- Infrastructure on-call (relay nodes, API server)
- Network operations (peer connectivity heartbeats)
This ensures the right person gets paged when connectivity degrades.
Summary
| Monitor | Target | What It Catches |
|---|---|---|
| HTTP | Nexodus API /api/v1/health | Control plane outage |
| TCP | Relay node port 51820 | Relay service crash |
| Cron heartbeat | Peer connectivity script | Silent peer-to-peer link failure |
| HTTP sidecar | Device registration status | Mass device disconnection |
| SSL | API endpoint certificate | Certificate expiry |
Nexodus abstracts away the complexity of secure peer-to-peer networking across clouds and data centers — but that abstraction can make failures invisible until applications start timing out. With Vigilmon covering the API server, relay nodes, and active peer links, you get alerting at every layer of the Nexodus stack before users notice a problem.