External Tools Integration

NetXMS data can be consumed by external tools, dashboards, and analytics platforms. This page describes methods for making NetXMS monitoring data available to third-party applications.

Data Access Methods

Method Best For

REST API

Programmatic access from scripts and applications

Grafana Plugin

Visualization in Grafana dashboards

Fanout Drivers

Continuous data replication to InfluxDB or ClickHouse

NXShell

Ad-hoc queries and bulk operations via Python

Direct Database Access

Custom SQL queries against the NetXMS database

Direct Database Access

For advanced analytics and custom reporting, you can query the NetXMS database directly.

Direct database access is read-only. Never modify data in the NetXMS database directly — use the API or management console instead.

Common Database Tables

Table Content

nodes

Node objects and their properties (IP, platform, agent version, status)

interfaces

Network interface configuration

object_properties

General properties for all object types (name, status, comments)

object_custom_attributes

Custom attributes assigned to objects

idata / idata_sc_* / idata_<node_id>

Historical DCI data. The layout depends on the installation: a single idata table, TimescaleDB storage-class hypertables (idata_sc_default, idata_sc_7, …​), or legacy per-node tables.

tdata / tdata_sc_* / tdata_<node_id>

Historical table DCI data (same layout variants)

alarms

Active and historical alarm records

event_log

Event history with parameters

snmp_trap_log

SNMP trap history

dci_summary_tables

Summary table definitions

Example Queries

Node inventory:

SELECT n.id, op.name, n.primary_ip,
       n.platform_name, n.agent_version
FROM nodes n
JOIN object_properties op ON n.id = op.object_id
WHERE op.is_deleted = 0
ORDER BY op.name;

Active alarms summary by severity:

SELECT
  CASE current_severity
    WHEN 0 THEN 'Normal'
    WHEN 1 THEN 'Warning'
    WHEN 2 THEN 'Minor'
    WHEN 3 THEN 'Major'
    WHEN 4 THEN 'Critical'
  END AS severity,
  COUNT(*) AS count
FROM alarms
WHERE (alarm_state & 15) < 2
GROUP BY current_severity
ORDER BY current_severity DESC;

The mask is needed because sticky acknowledgement sets an extra bit in alarm_state (a sticky-acknowledged alarm has state 17); comparing the raw value would miss such alarms.

Connection Examples

PostgreSQL:

psql -h db-host -U netxms -d netxms_db \
  -c "SELECT op.name, primary_ip FROM nodes n JOIN object_properties op ON n.id = op.object_id"

MySQL:

mysql -h db-host -u netxms -p netxms_db \
  -e "SELECT op.name, primary_ip FROM nodes n JOIN object_properties op ON n.id = op.object_id"

Push Data into NetXMS

External tools can push data into NetXMS through several mechanisms.

Push DCIs via nxapush

The nxapush command-line tool sends data to NetXMS DCIs via the local agent:

nxapush DCI_Name=value

Multiple values can be pushed at once:

nxapush DCI_One=42 DCI_Two=100

This requires:

  • A DCI configured with the Push origin type on the target node

  • The nxapush tool installed (part of the NetXMS agent distribution)

  • A running NetXMS agent on the same host

Push DCIs via nxpush

The nxpush command-line tool sends values directly to the server, without requiring a local agent:

nxpush -H server_address -u user -P password node_name:DCI_Name=value

Node and DCI can be specified by ID or object name; to specify the node by DNS name or IP address, prefix it with @.

Generate External Events

External tools can send events to NetXMS using nxevent:

nxevent -u admin -P password server_address EVENT_NAME "param1"

The built-in web API has no endpoints for pushing DCI values or injecting events — use the command-line tools above. Other integration needs (querying objects, alarms, and collected data) are covered by the web API with Bearer token authentication; see REST API.

Webhook Integration

NetXMS can send webhook notifications to external systems when alarms or events occur. This is configured through notification channels:

  1. Create a notification channel with the Webhook driver

  2. Configure the driver: URL, Method (POST, PUT, or PATCH), ContentType, TemplateFile (path to a file containing the request body template), optional [Headers] section, and success/retry criteria (SuccessHttpCodes, RetryHttpCodes, SuccessJsonPath together with SuccessValue — SuccessValue is mandatory whenever SuccessJsonPath is set, otherwise the channel fails to start)

  3. Use the channel in EPP rules via notification actions

The body template file supports only the ${recipient}, ${subject}, and ${body} placeholders; %-style event macros are not expanded in the template and appear verbatim. Macro expansion happens in the EPP action’s message text, which is delivered to the template as ${body}:

{"recipient": "${recipient}", "subject": "${subject}", "message": "${body}"}

See Notifications and Notification Drivers Reference for details.

See Notifications for notification channel configuration.

Integration Patterns

CMDB Synchronization

Synchronize NetXMS object data with a Configuration Management Database:

  1. Use the REST API or NXShell to export node inventory data

  2. Map NetXMS object properties to CMDB fields

  3. Schedule periodic synchronization via cron or a scheduled task

  4. Use custom attributes in NetXMS to store CMDB references (CI ID)

ChatOps (Slack, Teams, Telegram)

Integrate NetXMS alarms with chat platforms:

  • Configure a notification channel with the appropriate driver (Telegram, Slack webhook)

  • Create EPP rules that send alarm notifications to chat channels

  • Use the REST API to build a chatbot that queries NetXMS data

NetXMS includes built-in notification channel drivers for Telegram and Slack.

Event Correlation with External SIEM

Forward NetXMS events to a SIEM system:

  • Forward events through an event forwarder driver (isc, snmptrap, or otlp) using the Forward event EPP action

  • Use the REST API to query event and alarm data

  • Configure fanout drivers to send metric data alongside events

Next Steps