NetXMS · vesely.sk

Review scope and evidence labels

This page is written as a technical technology profile, not as a copy of the official NetXMS manual. It summarizes what NetXMS is, how it is typically structured, where it can support operational evidence, and where expectations must stay realistic.

Important evidence labels used below:

Official documentation — based on NetXMS project documentation or official website material.
Source code — based on the public NetXMS GitHub repository or repository metadata.
Release notes — based on a published NetXMS release page.
Author analysis — interpretation for governance, architecture or operational risk context on this site.
Lab validation: not yet performed — proposed or plausible usage that still needs controlled local verification before it should be treated as operational evidence.

Version information reflects the version reviewed for this research entry and is not updated automatically.

Technology snapshot

Field	Value
Category	Network and infrastructure monitoring
Deployment	On-premises, cloud-hosted or distributed deployments
Core model	Server, database, agents, proxies, management clients and integrations
Reviewed release	NetXMS 6.2.2
Release evidence	GitHub release `release-6.2.2`, published 30 July 2026 according to GitHub API metadata
Source availability	Open source
Primary repository language	C++ according to GitHub repository metadata
Interfaces	Desktop client, web interface, mobile/client tooling, REST/Java/API integrations
Automation	Event Processing Policy, NXSL scripting, object tools, scheduled tasks and external integrations
Main use	Monitoring, discovery, topology, events, alarms, telemetry and operational visibility
Licence	Mixed licensing: NetXMS `COPYING` describes LGPL libraries, GPL components and bundled third-party libraries
Review status	Technical profile reviewed from public sources; lab validation is partial/not yet documented here

What NetXMS is

NetXMS is an open-source platform for network and infrastructure monitoring. It is designed to collect status, performance, topology and event information from servers, network devices, applications and supporting infrastructure. Evidence: Official documentation; Source code.

Operationally, it is a monitoring and management system rather than a single-purpose metric collector. It can poll devices, collect metrics, receive events, apply rules, create alarms, notify people or systems, and provide data through dashboards, clients and integrations. Evidence: Official documentation.

NetXMS works with an object model of monitored infrastructure: nodes, interfaces, services, zones, sensors, access points, clusters, business services and other monitored objects. The value of the system depends heavily on how these objects are discovered, named, grouped, validated and governed. Evidence: Official documentation; Author analysis.

What NetXMS is not

NetXMS should not be described as a replacement for every operational or security platform.

It is not:

an EDR replacement,
a full SIEM by itself,
a primary ITSM/helpdesk system,
an automatically authoritative CMDB,
a vulnerability scanner,
a compliance product that makes an organisation NIS2- or GDPR-compliant by installation alone.

It can, however, provide useful signals, telemetry and evidence to those systems when configured and governed correctly. Evidence: Author analysis.

Architecture

A typical NetXMS deployment is built from several roles.

NetXMS Server

The server is the central control and processing component. It coordinates polling, object configuration, event handling, alarm processing, user access, automation and integration logic. Evidence: Official documentation.

Database

The database stores configuration, object data, historical metrics, event and alarm information, audit data and other operational records. This makes database retention, backup, integrity and recovery part of the monitoring-system design, not an afterthought. Evidence: Author analysis.

NetXMS Agent

The agent is an optional but important component on monitored Windows, Linux or Unix systems. It can extend monitoring beyond network-level polling by exposing system metrics, logs, actions, file-related functions and proxy capabilities. Evidence: Official documentation.

Proxy and distributed monitoring

Proxy agents and zones are important for distributed sites, restricted networks, overlapping address ranges or NAT-like environments. A proxy can mediate monitoring traffic between the central server and remote devices or agents. Evidence: Official documentation; Author analysis.

Management clients and integrations

NetXMS is operated through management clients, web UI, API clients and integrations. The public project README explicitly mentions desktop clients, a web interface, REST API, Java library and integrations such as Grafana, InfluxDB and ClickHouse fanout scenarios. Evidence: Source code.

                    ┌──────────────────┐
                    │ Web / Desktop UI │
                    │ API consumers    │
                    └────────┬─────────┘
                             │
                    ┌────────▼─────────┐
                    │   NetXMS Server  │
                    │ Polling / EPP /  │
                    │ Alarms / Scripts │
                    └──────┬─────┬─────┘
                           │     │
                     ┌─────▼─┐ ┌─▼────────────┐
                     │ DB    │ │ Integrations │
                     └───────┘ └──────────────┘
                           │
             ┌─────────────┼──────────────┐
             │             │              │
        ┌────▼────┐   ┌────▼─────┐   ┌────▼─────┐
        │ Agents  │   │ SNMP     │   │ Proxy /  │
        │ Servers │   │ Devices  │   │ Zones    │
        └─────────┘   └──────────┘   └──────────┘

Core data model and terminology

Node

A monitored server, workstation, switch, router, firewall, printer, sensor or another network-reachable object. Evidence: Official documentation.

DCI — Data Collection Item

A Data Collection Item defines a specific metric or collected value. It includes the source, collection interval, data type, retention, transformation and threshold logic. NetXMS supports simple values and more complex collection structures such as lists or tables. Evidence: Official documentation.

Template

A reusable monitoring configuration for metrics, thresholds, policies and agent-side behaviour. Templates are important for keeping larger deployments consistent. Evidence: Official documentation; Author analysis.

Event

An internal event can originate from polling, metric thresholds, SNMP traps, syslog, scripts or external integrations. An event is not automatically an alarm. Evidence: Official documentation.

Alarm

An alarm is an operational problem representation created or updated by event-processing logic. It should be treated as a signal that needs context, not as automatic proof of a confirmed incident. Evidence: Official documentation; Author analysis.

Event Processing Policy

The Event Processing Policy is a deterministic rule set that decides how events are handled: ignored, transformed into alarms, assigned severity, used for notification or used to trigger actions. Evidence: Official documentation.

Polling

NetXMS uses different polling concepts for status, configuration, topology, ICMP checks, routing and instance discovery. This distinction matters because each poll type answers a different question about the monitored object. Evidence: Official documentation.

Data collection methods

NetXMS can collect data from multiple classes of sources. Based on public project material and documentation, relevant collection and integration methods include:

NetXMS Agent,
SNMP,
ICMP,
SSH,
HTTP/HTTPS web services,
JSON/XML/plain-text web responses,
Windows-specific counters and logs,
MQTT,
Modbus TCP,
EtherNet/IP,
network device drivers,
NXSL scripts,
internal server metrics,
push/API-style external data,
event/log sources such as traps or syslog.

The project README also references broad protocol support, REST/Java integration, Grafana, InfluxDB and ClickHouse fanout scenarios. Evidence: Source code.

Source	Typical use
Agent	CPU, memory, filesystem, processes, services, logs, local actions
SNMP	Switches, routers, firewalls, printers, UPS and environmental devices
ICMP	Reachability and latency
SSH	Command output from devices or systems
Web service	JSON, XML or HTTP endpoint monitoring
MQTT	Sensors and IoT-style telemetry
Modbus / EtherNet/IP	Industrial and energy-related devices
Push/API	Data from external applications
Syslog / traps	Asynchronous events from devices
NXSL	Custom collection, transformation and automation logic

Discovery and topology

Discovery is useful, but it should not be confused with authoritative asset identity.

NetXMS can use discovery and topology information from network data, device tables, protocol responses and event sources. Passive techniques can use existing network information; active techniques can probe ranges; event-assisted discovery can use incoming messages as hints. Evidence: Official documentation.

Important risks and design considerations:

overlapping address ranges,
duplicate objects,
zones and proxy nodes,
discovery exclusions,
naming standards,
devices that respond differently through different protocols,
discovered IP address versus verified business asset,
integration with CMDB or ITSM tools such as GLPI.

For GLPI-style workflows, discovering an IP address is not the same as proving asset ownership, lifecycle state or contractual identity. Evidence: Author analysis.

Events, alarms and notifications

A simplified event lifecycle is:

Input → Event Queue → EPP rule → Action / Alarm → Notification → Resolution

Typical event sources include:

status polling,
configuration polling,
DCI threshold violations,
SNMP traps,
syslog,
Windows Event Log,
NXSL scripts,
API input.

Typical actions include:

creating or updating an alarm,
sending a notification,
running an NXSL script,
running an external command,
triggering an object tool,
passing context to an external helpdesk or workflow system.

The public project README describes policy-based event processing, alarm creation/termination, script execution, command execution, multi-channel notifications and escalation support. Evidence: Source code.

Important distinctions:

event ≠ alarm,
threshold violation ≠ confirmed security incident,
node down ≠ confirmed business-service outage,
alert volume ≠ risk visibility.

Security model

NetXMS is security-sensitive infrastructure because it can observe and sometimes control operational systems. Its security model must therefore be reviewed as part of deployment, not after deployment.

Transport security

Relevant design topics include encrypted agent/server communication, certificate validation, trusted certificate authorities, agent tunnels, shared secrets and SNMPv3 for network devices. Evidence: Official documentation; Author analysis.

Authentication and authorization

Public project material describes flexible authentication, LDAP integration, certificate and smart-card options, RADIUS/LDAP use, two-factor authentication, fine-grained access control and audit logging. Evidence: Source code.

Operational design should separate:

administrators,
read-only users,
operators,
automation/service accounts,
script maintainers,
users allowed to run object tools or remote commands,
users allowed to change Event Processing Policy.

Secret handling

A NetXMS deployment may contain or reference sensitive operational credentials:

SNMP community strings or SNMPv3 secrets,
agent shared secrets,
SMTP credentials,
API credentials,
SSH keys,
integration tokens,
database credentials.

For each secret class, the deployment should define who can read it, who can rotate it, whether it appears in exports or logs, and how it is protected in backups. Evidence: Author analysis.

Security-relevant releases and advisories

Because NetXMS can become operationally privileged, release notes should be monitored. The reviewed release is 6.2.2 according to the public GitHub release metadata. This page does not replace vendor advisories or release notes. Evidence: Release notes; Author analysis.

Version-aware research status

Reviewed against:

NetXMS release metadata: release-6.2.2.
GitHub release publication timestamp: 30 July 2026.
Source repository metadata reviewed: 1 August 2026.
Administrator documentation: public NetXMS documentation available at review time.
Lab validation status: partial / not documented in this entry.

Potential documentation drift should be expected. If release notes, source code and documentation disagree, the research entry should mark the conflict explicitly instead of silently choosing one version of the claim. Evidence: Author analysis.

Integrations

Official or directly documented integration surface

Public project material and documentation indicate integration paths such as:

REST API,
Java API/library,
Grafana-related usage,
notification channels,
external helpdesk-style workflows,
web services,
InfluxDB and ClickHouse fanout scenarios,
scripts and command execution.

Lab or site-specific integration research

These scenarios should be tracked separately from official product capabilities. The table below uses public research-status wording instead of implementation promises.

Integration scenario	Research status	Validation status
NetXMS → GLPI asset discovery	Design candidate	Lab validation required
NetXMS → GLPI ticketing	Design candidate	Lab validation required
NetXMS → SecurityPlatform	Architecture concept	Implementation evidence not yet published
NetXMS → Wazuh or evidence layer	Architecture concept	Implementation evidence not yet published
Windows Event Log ingestion	Product capability relevant to this research	Deployment evidence not documented in this entry
SNMP discovery for switches, firewalls and printers	Product capability relevant to this research	Deployment evidence not documented in this entry

This distinction prevents mixing product capability with site-specific implementation evidence. Evidence: Author analysis.

Operational use cases

Server monitoring

Typical targets include CPU, memory, filesystems, services, processes, local logs and Windows Event Logs. Evidence: Official documentation; Author analysis.

Network equipment monitoring

Typical targets include interface state, bandwidth, errors/discards, device CPU/memory, temperature, power supplies, topology data, SNMP traps and configuration-related evidence. Evidence: Official documentation; Author analysis.

Firewall monitoring

Useful signals may include availability, interface state, VPN status, session count, CPU/RAM, security-relevant syslog and configuration drift. Evidence: Author analysis.

Printer monitoring

Useful signals may include toner, paper, errors, page count, model and serial number. Evidence: Author analysis.

UPS and environmental monitoring

Useful signals may include battery state, voltage, temperature, runtime and power events. Evidence: Author analysis.

Distributed branch monitoring

Relevant concepts include zones, proxy agents, overlapping address ranges, agent tunnels and buffering or behaviour during connectivity loss. Evidence: Official documentation; Author analysis.

Deployment patterns

Small installation

NetXMS Server + Database + Web/Desktop Client

Suitable for a small environment or lab, but still requires backup, update and access-control discipline.

Agent-based enterprise deployment

Central Server → Agents on managed servers

Useful when server-level metrics, log monitoring, local checks or controlled actions are required.

Multi-site deployment

Central Server → Site Proxy → Local devices

Useful for branches or network segments where direct central access is not appropriate.

Restricted or NAT environment

Agent-initiated Tunnel → Central Server

Useful where inbound access to monitored sites is restricted or impossible. Evidence: Official documentation; Author analysis.

Hardening checklist

Recommendation	Reason	Verification method	Evidence
Prefer SNMPv3 over SNMPv1/v2c	Stronger authentication and privacy model	Review device credentials and SNMP profiles	`Author analysis`
Do not use default `public` communities	Reduces trivial data exposure	Search configuration and device templates	`Author analysis`
Restrict SNMP access by source IP	Limits unauthorized polling	Device ACL review	`Author analysis`
Require agent authentication	Reduces rogue or misconfigured agent risk	Agent policy and server configuration review	`Official documentation`
Use certificate validation for tunnels where applicable	Reduces impersonation risk	Certificate and tunnel configuration review	`Official documentation`
Separate admin and read-only accounts	Limits operational blast radius	Rights and group review	`Source code` `Author analysis`
Restrict NXSL, object tools and remote commands	These functions can become privileged execution paths	User rights review and test account validation	`Author analysis`
Limit who can change Event Processing Policy	A bad rule can suppress important alarms or create noise	Change-control review	`Author analysis`
Protect database and backups	Monitoring data can contain sensitive infrastructure context	Backup storage and restore test review	`Author analysis`
Define retention	Prevents uncontrolled database growth	Database retention settings and size trend review	`Author analysis`
Audit configuration changes	Supports incident review and accountability	Audit log review	`Source code` `Author analysis`
Monitor the NetXMS server itself	Monitoring infrastructure is a critical dependency	Self-monitoring dashboard and alert test	`Author analysis`
Review release notes regularly	Monitoring software is security-sensitive	Scheduled update review	`Release notes`
Test restore procedures	Backups without restore tests are not evidence	Restore drill	`Author analysis`
Do not treat obfuscation as cryptographic secret protection	Secrets require explicit protection and rotation	Secret storage review	`Author analysis`

NetXMS should not be called “NIS2-compliant” by itself. A tool can support selected controls, but compliance depends on configuration, governance, evidence retention and operational process. Evidence: Author analysis.

NetXMS can support selected operational and evidentiary controls, including:

availability monitoring,
anomaly and threshold visibility,
operational incident evidence,
alerting,
audit records,
distributed infrastructure monitoring,
retained telemetry for after-action analysis.

GDPR relevance depends on whether monitored logs, IP addresses, user names, device names or operational records can identify people or reveal personal-data processing context. Relevant governance questions include purpose limitation, access rights, retention, minimisation, exports, backups and security of processing. Evidence: Author analysis.

NIST SP 800-137 is useful background for continuous monitoring because it frames monitoring as ongoing awareness of security state, vulnerabilities and threats to support risk-based decisions. Evidence: External standard.

Limitations and risks

High flexibility increases configuration complexity.
Incorrect Event Processing Policy can create alarm noise or suppress important events.
Automatic discovery can create duplicate or misleading objects.
SNMPv1/v2c has a weaker security model than SNMPv3.
Remote commands and object tools increase the impact of compromised privileged accounts.
The monitoring system can become a critical infrastructure dependency.
Without retention governance, the database can grow significantly.
Metric availability does not automatically mean correct interpretation.
Monitoring does not prove asset ownership or authoritative identity.
A NetXMS alarm is not automatically a confirmed security incident.

Strengths

Broad infrastructure and network monitoring scope.
Flexible event processing and automation model.
Strong fit for mixed environments with servers, network devices and branch sites.
Support for agents, SNMP, web services, scripts and integrations.
Useful evidence source for operational resilience and security governance.
Open-source availability enables source-level review where needed.

Recommended next research pages

The main /research/netxms/ page should stay a readable technical profile. Deeper runbooks can become separate pages or articles later:

NetXMS architecture,
agents and proxies,
discovery and topology,
data collection,
events and alarms,
SNMPv3 monitoring,
Windows Event Log monitoring,
security hardening,
API and integrations,
GLPI integration,
deployment patterns,
troubleshooting,
backup and recovery,
upgrade strategy.

Further research directions

Future NetXMS research should add controlled lab evidence for a real installation, including SNMPv3 configuration, agent tunnel hardening, Windows Event Log monitoring and backup/restore validation.

NetXMS-to-GLPI integration should remain a separate research track until at least one workflow is validated with stable identifiers, reconciliation rules and audit evidence. A dedicated flat Research entry such as netxms-glpi-integration can be added later once implementation evidence exists.

The reviewed release should be updated deliberately when future NetXMS release notes justify a new review cycle. Version metadata in this entry is a dated research snapshot, not an automatically refreshed product catalogue.

Scientific literature entries intentionally preserve publication titles and selected bibliographic text in the language used by the original source where that helps readers match the entry to the linked record. Future bibliography work should add a curated English commentary layer without replacing canonical original-language titles or excerpts.