Monitoring NetXMS with Vigilmon

NetXMS is an enterprise-grade open-source monitoring platform designed for network teams, ISPs, and data centers managing hundreds to thousands of devices. It provides SNMP polling, native agent collection, network topology mapping, event correlation, and escalation policies — the full NOC toolkit. But NetXMS, like all monitoring tools, has a blind spot: it cannot monitor itself. If the NetXMS server process fails, or if data collection silently stops writing to the database, your NOC is dark without knowing it. Vigilmon provides the external watchdog layer that confirms NetXMS WebUI is reachable, the core server is accepting connections, the REST API is functional, and the event processing pipeline is actually running.

What You'll Set Up

• HTTP uptime monitor for the NetXMS WebUI (port 8080)
• TCP port monitor for the NetXMS server process (port 4701)
• REST API health check confirming the API module is loaded
• SSL certificate expiry alerts for HTTPS WebUI deployments
• Cron heartbeat that verifies NetXMS event processing and database writes are operational

Prerequisites

• NetXMS server running with WebUI accessible (default port 8080 HTTP)
• NetXMS server port 4701 accessible from your monitoring vantage point (or from the server itself via a local check script)
• A free Vigilmon account

Step 1: Monitor the NetXMS WebUI Availability

NetXMS serves its web management client on port 8080 by default. Add a Vigilmon HTTP monitor:

1. Log in to vigilmon.online and click Add Monitor.
2. Set Type to HTTP / HTTPS.
3. Enter the URL: http://your-netxms-host:8080/
4. Set Check interval to 1 minute.
5. Set Expected HTTP status to 200.
6. Under Keyword check, enter NetXMS to confirm the correct application is responding.
7. Click Save.

The keyword check for NetXMS ensures you're confirming the management interface — not a generic Tomcat welcome page or a different application that happens to return 200 on that port.

Step 2: Monitor the NetXMS Server Process via TCP

The NetXMS WebUI can remain responsive while the core NetXMS server process has stopped collecting data. The server process listens on TCP port 4701 for agent and console connections — if this port is closed, the server is not processing monitoring data, even if the web interface still loads.

Add a TCP port monitor:

1. Click Add Monitor → TCP Port.
2. Enter the host: your-netxms-host
3. Set the port to 4701.
4. Set Check interval to 1 minute.
5. Click Save.

A successful TCP connection to port 4701 confirms the NetXMS server process is running and accepting connections. Port 4700 is used for encrypted native agent communications — add a second TCP monitor for port 4700 if you want to verify the encrypted agent channel separately.

Step 3: Validate the NetXMS REST API

NetXMS includes a REST API served by the WebUI component. Confirming the API is functional is a higher-quality signal than checking the static web UI, because the API is what NOC automation, dashboards, and integrations depend on.

Add an HTTP monitor for the API:

1. Click Add Monitor → HTTP / HTTPS.
2. Enter the URL: http://your-netxms-host:8080/api/v2/sessions
3. Set Method to GET.
4. Set Expected HTTP status to 401.
5. Under Keyword check, enter Unauthorized or leave blank — a 401 is sufficient to confirm the API module is loaded and responding.
6. Set Check interval to 5 minutes.
7. Click Save.

Monitoring for a 401 (rather than 200) is correct here — an unauthenticated probe to the sessions endpoint returns 401 when the API is working normally. A 404 or 503 indicates the API module failed to load or the WebUI is misconfigured.

If you have a dedicated monitoring API user, you can instead monitor GET /api/v2/alarms with valid credentials and expect 200, which gives you a richer health signal.

Step 4: SSL Certificate Alerts for HTTPS Deployments

NetXMS WebUI is commonly deployed behind a reverse proxy (nginx or Apache) that terminates TLS. For 24/7 NOC teams, an expired SSL certificate on the web management interface locks operators out of the monitoring dashboard — exactly when they need it most during an incident.

1. If your NetXMS WebUI is accessible over HTTPS (via a proxy or native TLS), open or create an HTTPS monitor for it.
2. Enable Monitor SSL certificate under the SSL section.
3. Set Alert when certificate expires in less than 30 days.
4. Click Save.

For NetXMS deployments used by remote NOC teams over VPN or public internet, a 30-day lead time is the minimum — some organizations use 45 days to account for certificate authority processing delays.

Step 5: Heartbeat Monitoring for NetXMS Data Collection Health

The most critical thing to verify in any monitoring system is that it is actually collecting data and writing it to the database. NetXMS can enter a state where the UI is responsive and the server is accepting connections, but DCI (Data Collection Item) polling has stalled due to a database write failure, a thread deadlock, or an agent communication breakdown.

NetXMS's built-in Event Processing Policy (EPP) provides the mechanism to send this heartbeat. Configure it as follows:

On the NetXMS server:

1. Create a NetXMS Script DCI on a monitored node (or on the NetXMS server node itself) that runs periodically — for example, every 60 minutes — and executes a small NXSL script:

// NXSL script: send Vigilmon heartbeat
result = AgentExecuteAction("NXSL.Script", "curl -s https://vigilmon.online/heartbeat/YOUR_TOKEN");

Or use a NetXMS server-side action of type "Execute command" in the EPP triggered by a scheduled timer event:

2. In the NetXMS Management Client, go to Event Processing Policy.
3. Create a rule triggered by a timer or a scheduled script execution event.
4. Set the action to Execute command on management server:

curl -s "https://vigilmon.online/heartbeat/YOUR_TOKEN"

5. Set the timer interval to 60 minutes.

In Vigilmon:

1. Click Add Monitor → Cron Heartbeat.
2. Set the expected ping interval to 70 minutes.
3. Use the heartbeat URL you configured above.

When this heartbeat fires successfully, it proves that:

• NetXMS's scheduling engine is running.
• The EPP is processing events.
• The database is responding to DCI writes.
• The scripting engine or server-side action execution is functional.

These are exactly the components that process real monitoring alerts — if they break, your alert pipeline is broken, whether or not the WebUI remains reachable.

Step 6: Configure Alert Channels

1. Go to Alert Channels in Vigilmon and add email, Slack, PagerDuty, or a webhook.
2. Set Consecutive failures before alert to 2 for WebUI and API monitors — WebUI restarts after configuration changes can take 30–60 seconds.
3. Set Consecutive failures before alert to 1 for the TCP port monitor and heartbeat — these are binary signals with no expected transient failures.

For NOC teams, add a dedicated alert channel for the NetXMS heartbeat monitor separate from your standard alert routing — a failure here means all of your downstream monitoring alerts are also silent.

Summary

| Monitor | Target | What It Catches | |---|---|---| | WebUI availability | http://host:8080/ + keyword NetXMS | Web interface down, wrong app | | Server process | TCP port 4701 | NetXMS server process failure | | REST API | GET /api/v2/sessions → 401 | API module failure | | SSL certificate | HTTPS WebUI cert | Certificate expiry locking out NOC | | Cron heartbeat | EPP-triggered hourly ping | Data collection stall, database write failure |

NetXMS is the platform your operations team trusts to know when everything else is broken — that trust only holds if NetXMS itself is healthy. With Vigilmon monitoring the WebUI, server process, REST API, and data collection pipeline externally and independently, you have the watchdog layer that ensures your monitoring platform is always ready when your network needs it.