tutorial

Monitoring NIPAP with Vigilmon: Web UI, Backend Daemon TCP Checks, API Health & SSL Alerts

How to monitor NIPAP IP address management with Vigilmon — web UI availability, nipapd backend TCP checks, allocation API heartbeats, and SSL certificate alerts.

NIPAP is the IP address management backbone for ISPs, enterprise networking teams, and data centers managing thousands of IP allocations across VRFs, VLANs, and sites. When NIPAP goes down, network engineers can't look up or allocate IP prefixes, Ansible and Terraform automation workflows that call nipapd for prefix allocation silently break, and new infrastructure provisioning stalls. The failure is often invisible: the nipapd backend daemon can die while the web UI nginx proxy continues to serve cached pages, or the PostgreSQL connection pool can exhaust while the daemon process keeps running. Vigilmon gives you full-stack visibility into NIPAP: web UI availability, nipapd backend TCP health, PostgreSQL connectivity, and the allocation API health that your automation depends on.

What You'll Build

  • A monitor on the NIPAP web UI to catch Django server failures
  • A TCP monitor on the nipapd backend daemon port to verify daemon health
  • A heartbeat monitor that verifies the full allocation API pipeline is operational
  • SSL certificate monitoring for HTTPS NIPAP deployments
  • An alerting setup that catches both UI failures and backend daemon stalls

Prerequisites

  • A running NIPAP instance (nipapd daemon + nipap-www web UI) accessible via HTTP or HTTPS
  • NIPAP web UI on its configured port (default 1337 or a custom port behind a proxy)
  • nipapd listening on port 1337 (TCP, XML-RPC by default) or your configured port
  • A free account at vigilmon.online

Step 1: Verify NIPAP's Health Endpoints

NIPAP consists of two components: nipapd (the backend daemon handling all prefix operations via XML-RPC on TCP) and nipap-www (the Django web frontend). Verify both are accessible:

# Check web UI availability
curl -I http://nipap.example.com/

# Expect: HTTP 200 with the NIPAP web interface

# Check nipapd TCP connectivity (the backend daemon)
nc -zv nipap.example.com 1337
# Expect: Connection succeeded
# or
curl -v telnet://nipap.example.com:1337

The web UI returns HTTP 200 when the Django web server (served via nginx or gunicorn) is running and nipapd is reachable for prefix queries. The nipapd daemon listens on TCP port 1337 by default — a successful TCP connection confirms the daemon is running and accepting connections.

nipapd is the source of truth: The web UI is a thin client over the nipapd XML-RPC API. If nipapd is down, the web UI will show an error page even if nginx is healthy — making the nipapd TCP check more authoritative than the HTTP UI check alone.

Step 2: Create a Vigilmon HTTP Monitor for the Web UI

The web UI monitor confirms that the Django/nginx stack is running and nipapd is reachable for prefix queries:

  1. Log in to Vigilmon → Add Monitor → HTTP.
  2. URL: http://nipap.example.com/ (or https://nipap.example.com/ if using HTTPS).
  3. Check interval: 60 seconds.
  4. Response timeout: 15 seconds.
  5. Expected status: 200.
  6. Keyword: NIPAP (appears in the page title of the NIPAP web interface).
  7. Click Save.

This monitor catches:

  • nginx web server failures or container restarts
  • Django application startup failures
  • nipapd connectivity failures (the web UI returns an error page if it can't reach nipapd)
  • PostgreSQL connectivity failures routed through nipapd

Prefix list check: For a more specific check, monitor a page that loads actual prefix data. If your NIPAP instance is internal-only and accessible from your monitoring location, try the prefix list URL (e.g., /prefix/list or the root dashboard) with keyword Prefix — this confirms nipapd is returning real data, not just accepting connections.

Alert sensitivity: Set alerts to trigger after 2 consecutive failures. Django/nginx combinations can occasionally return transient errors during cache flushes or connection pool resets.

Step 3: Create a TCP Monitor for the nipapd Backend Daemon

The nipapd daemon is the heart of NIPAP — without it, no prefix lookups or allocations are possible, regardless of whether the web UI is reachable. Monitor the TCP port directly to detect daemon failures that the HTTP UI check might miss:

  1. Add Monitor → TCP.
  2. Host: nipap.example.com (or the IP address of your NIPAP host).
  3. Port: 1337 (the default nipapd XML-RPC port, or your configured port).
  4. Check interval: 60 seconds.
  5. Response timeout: 10 seconds.
  6. Label: nipapd backend daemon.
  7. Click Save.

Verify the nipapd port locally:

# Confirm nipapd is listening on port 1337
ss -tlnp | grep 1337
# or
netstat -tlnp | grep nipapd

This monitor fires when:

  • nipapd process crashes or is killed by OOM
  • nipapd fails to restart after a host reboot (not configured in systemd)
  • PostgreSQL startup order causes nipapd to fail its DB connection and exit
  • A firewall change blocks port 1337

When the TCP monitor fires but the HTTP monitor is green, nginx is serving cached responses while nipapd has died — new prefix queries and allocations will fail even though the web UI looks healthy.

TCP vs HTTP monitoring: The TCP check connects to port 1337 but does not send an XML-RPC request — it only confirms the port is open and accepting connections. nipapd could be accepting connections but failing to query PostgreSQL. The allocation API heartbeat (Step 5) provides the deeper check.

Step 4: Create a Vigilmon HTTP Monitor for the Prefix List Page

Monitor the prefix list page for both HTTP 200 and the keyword "Prefix" to confirm the full stack — web server → nipapd → PostgreSQL — is returning real data:

  1. Add Monitor → HTTP.
  2. URL: http://nipap.example.com/ (adjust to your specific prefix list page URL if different).
  3. Check interval: 5 minutes.
  4. Response timeout: 15 seconds.
  5. Expected status: 200.
  6. Keyword: Prefix (appears in the NIPAP web interface when prefix data is loading).
  7. Click Save.

Differentiate from Step 2: Use different keywords — the web UI monitor in Step 2 uses NIPAP (in the page title, present even on error pages), while this monitor uses Prefix (only present when actual prefix data loads successfully). This distinguishes between "web server running" and "full stack operational."

Step 5: Set Up Heartbeat Monitoring for the Allocation API

The most critical NIPAP health signal for automation teams is whether the nipapd JSON-RPC/XML-RPC API can perform prefix operations. Ansible playbooks, Terraform providers, and custom scripts that call nipapd for IP allocation fail silently when nipapd is running but not responding correctly. Set up a scheduled API health check:

In Vigilmon:

  1. Add Monitor → Heartbeat.
  2. Name: NIPAP allocation API health.
  3. Expected interval: 65 minutes.
  4. Grace period: 5 minutes.
  5. Copy the generated heartbeat URL.

Create a scheduled script using the NIPAP Python client:

# Install the NIPAP CLI/Python client if not already installed
# pip install pynipap

# /usr/local/bin/nipap-api-health-check.sh
#!/bin/bash

NIPAP_HOST="nipap.example.com"
NIPAP_PORT="1337"
HEARTBEAT_URL="https://api.vigilmon.online/heartbeat/YOUR_HEARTBEAT_ID"

# Use nipap CLI to perform a simple prefix search
# This exercises the full nipapd → PostgreSQL pipeline
RESULT=$(python3 -c "
import pynipap
from pynipap import Prefix, VRF, NipapError

# Connect to nipapd
pynipap.xmlrpc_uri = 'http://${NIPAP_HOST}:${NIPAP_PORT}/RPC2'
a = pynipap.AuthOptions({'authoritative_source': 'nipap-health-check'})

try:
    # List prefixes with a simple filter — exercises the full DB query path
    prefixes = Prefix.list({})
    print('OK: found {} prefixes'.format(len(prefixes)))
    exit(0)
except NipapError as e:
    print('FAIL: {}'.format(str(e)))
    exit(1)
")

if [ $? -eq 0 ]; then
  echo "$RESULT"
  curl -fsS "$HEARTBEAT_URL"
else
  echo "NIPAP API health check failed: $RESULT"
  exit 1
fi

Add to crontab on any host with nipapd access:

0 * * * * /usr/local/bin/nipap-api-health-check.sh

A successful prefix list query confirms nipapd is running, its PostgreSQL connection is healthy, and the IP allocation data is accessible. A missed heartbeat means automation tools calling nipapd for IP allocation are silently failing.

XML-RPC alternative: If you don't have the Python NIPAP client available, use curl with a raw XML-RPC request to nipapd. However, the Python pynipap library is the recommended approach as it matches how Ansible and Terraform integrations call nipapd.

Step 6: Monitor SSL Certificates

If NIPAP's web UI is exposed via HTTPS (recommended for any network-accessible deployment), SSL certificate expiry breaks web access and any automation using HTTPS to reach the nipap-www interface:

  1. Add Monitor → SSL Certificate.
  2. Domain: nipap.example.com.
  3. Alert when expiry is within: 30 days.
  4. Alert again: 14 days, 7 days, 3 days, 1 day.
  5. Click Save.

Internal CA: Enterprise networks often use internal certificate authorities for NIPAP deployments. If using an internal CA, monitor the certificate expiry date directly with openssl s_client -connect nipap.example.com:443 2>/dev/null | openssl x509 -noout -dates and set calendar reminders alongside Vigilmon alerts, since internal CA renewals may require manual processes.

Step 7: Configure Alerting

In Vigilmon under Settings → Notifications, configure your alert channels:

| Monitor | Trigger | Action | |---|---|---| | Web UI (NIPAP keyword) | Non-200 or NIPAP missing | Check nginx/gunicorn status; may indicate nipapd is down | | Prefix list (Prefix keyword) | Prefix keyword missing | nipapd not returning data; check nipapd status and PostgreSQL | | nipapd TCP (port 1337) | Connection refused or timeout | nipapd daemon has crashed; check systemctl status nipapd; restart | | Allocation API heartbeat | Heartbeat missed | Full API pipeline failure; check nipapd logs and PostgreSQL connection | | SSL certificate | < 30 days to expiry | Renew certificate; check nginx config for the certificate path |

Alert after: 2 consecutive failures for HTTP monitors. 1 failure for the TCP monitor — port 1337 closed means nipapd is down immediately. 1 missed heartbeat for the allocation API.

Common NIPAP Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | nipapd process crash / OOM kill | TCP monitor fires; web UI shows error page | | PostgreSQL connectivity failure | nipapd may stay up; prefix queries fail; heartbeat missed | | nipapd fails to start after reboot | TCP monitor fires; web UI unreachable | | Web UI serving stale cached pages while nipapd is down | HTTP keyword NIPAP passes; TCP monitor fires; reveals the discrepancy | | PostgreSQL connection pool exhaustion | nipapd accepting connections; queries timeout; heartbeat missed | | Firewall blocks port 1337 | TCP monitor fires; Ansible/Terraform integrations break | | SSL certificate expires | SSL monitor alerts; web UI HTTPS access fails | | nipapd PostgreSQL auth failure after password rotation | TCP monitor green; heartbeat missed; list_prefix returns auth error | | DNS misconfiguration | All monitors fire simultaneously |

NIPAP is infrastructure-layer critical: when network engineers can't look up IP allocations and Ansible playbooks can't request new prefixes, infrastructure provisioning stops. The silent failures are the most dangerous — nipapd accepting TCP connections while failing to query PostgreSQL, or the web UI appearing healthy while the backend daemon has died. Vigilmon's layered monitoring (HTTP UI + TCP daemon + API heartbeat) gives you independent signals for each layer, so you know exactly which component has failed and can restore IP address management before any automation workflows are blocked.

Start monitoring NIPAP in under 5 minutes — register free at vigilmon.online.

Monitor your app with Vigilmon

Free plan — 5 monitors, no credit card required. Up and running in 60 seconds.

Start free →
← Back to all articles