Basic Concepts

This section covers the fundamental concepts you need to understand when working with NetXMS.

Objects

Everything NetXMS monitors is represented as an object. Objects are organized in a hierarchical tree, similar to a file system with folders and files.

The most common object types you will encounter:

Node

Represents a physical or virtual host — a server, router, switch, firewall, workstation, or any other IP-addressable device. Nodes are the primary targets for monitoring and contain most of the collected data.

Interface

A network interface on a node (Ethernet port, VLAN interface, loopback, etc.). Interfaces are created automatically when NetXMS polls the device configuration.

Container

An organizational folder used to group objects logically. For example, your administrator might create containers like "Data Center 1", "Branch Offices", or "Web Servers".

Subnet

An IP subnet, usually created automatically. Subnets appear under the Entire Network section of the object tree.

Cluster

A logical group of nodes that work together as a cluster. NetXMS can track cluster resources and display aggregated status.

For more detail on the object hierarchy, see Objects.

Object Status

Every object has a status that reflects its current condition. Status is indicated by color in the management console: green (Normal), cyan (Warning), yellow (Minor), orange (Major), and red (Critical); navy blue indicates Unknown status, grey Unmanaged, brown Disabled, and pink Testing.

Status propagates upward through the object tree. If a node is in Critical status, its parent container also shows Critical status (unless other siblings have an even higher severity).

For the full status reference table and status calculation details, see Object Status.

Maintenance Mode

Maintenance mode is a special state in which alarms and notifications for an object are suppressed while polling and data collection continue. This is useful during planned maintenance windows — DCI data continues to be collected (preserving trend data), but no alarms are raised for expected disruptions. Events generated during maintenance are marked as related to the maintenance and are skipped by event processing rules by default.

To enter maintenance mode, right-click an object and select Maintenance  Start maintenance…​. You can optionally provide a comment describing the reason for maintenance. To enter maintenance for a fixed duration, select Maintenance  Start maintenance for period; to plan a future maintenance window, select Maintenance  Schedule maintenance…​. To exit, right-click the object and select Maintenance  End maintenance.

Maintenance mode requires the "Control maintenance mode" access right. Contact your administrator if this option is not available.

Unmanaged Status

Objects can be set to unmanaged status. In this state the object is not polled, DCIs are not collected, and no data is updated. This is useful for objects that are temporarily or permanently unavailable and do not need active monitoring.

Alarms

When NetXMS detects a problem, it can raise an alarm. Alarms represent conditions that require operator attention.

Each alarm has:

  • A severity level (Normal, Warning, Minor, Major, or Critical)

  • A state — Outstanding (new, unacknowledged), Acknowledged (operator is aware), Resolved, or Terminated

  • A source — the object for which the alarm was generated

  • A message describing the problem

  • A timestamp indicating when the alarm was created

  • Optionally, a helpdesk reference if integrated with a ticketing system

As an operator, your typical alarm workflow is:

  1. Review outstanding alarms in the Alarms perspective

  2. Investigate the problem (check the source object, view related data)

  3. Acknowledge the alarm to indicate you are working on it

  4. Resolve or terminate the alarm once the problem is fixed

Some alarms are closed automatically when the underlying condition clears — for example, the default event processing policy terminates a node-down alarm when the node comes back online.

See Working with Alarms for the full operator workflow.

Events

Events are notifications generated by NetXMS when something significant happens. Examples include:

  • A node changes status (goes up or down)

  • A threshold is crossed on a collected metric

  • A configuration change is detected

  • An SNMP trap is received from a network device

Events are processed by the server’s Event Processing Policy (EPP), which determines what actions to take — such as raising an alarm, sending a notification, or running a script. EPP configuration is an administrative task; as an operator, you see the resulting alarms and can browse the event log for troubleshooting.

Data Collection Items (DCIs)

A DCI is a single metric configured for collection on a node. Examples of DCIs:

  • CPU utilization percentage

  • Free disk space on a specific volume

  • Network interface traffic (bytes in/out)

  • Number of active database connections

  • Response time of a web service

Each DCI has a polling interval (how often data is collected) and can have thresholds that activate when values cross defined boundaries, generating events.

Metrics can be collected from multiple data sources (called origins):

Origin Description

Internal

Metrics generated inside the NetXMS server process (server statistics, response times, object status).

NetXMS Agent

Data collected from NetXMS agent installed on the target node. Provides OS-level metrics such as CPU, memory, disk, and process information.

SNMP

Data collected from network devices using the SNMP protocol.

Web Service

Data obtained from JSON, XML, or plain text retrieved via HTTP/HTTPS.

Push

Values pushed by external systems using the nxpush tool or API, or from NXSL scripts.

Windows Performance Counters

Data collected via NetXMS agent running on Windows machines using native performance counter paths.

Script

Values generated by NXSL scripts stored in the Script Library.

SSH

Data obtained from output of commands executed through SSH connections.

MQTT

Data obtained by subscribing to MQTT broker topics.

Network Device Driver

Vendor-specific metrics provided by SNMP device drivers.

Modbus

Values read from Modbus TCP registers on industrial equipment.

EtherNet/IP

Attributes read from industrial automation devices using the EtherNet/IP (CIP) protocol.

SM-CLP

Data collected using the Server Management Command Line Protocol.

NETCONF

Data collected from network devices using the NETCONF protocol.

Cloud Connector

Metrics obtained from cloud provider monitoring services through a cloud connector.

OTLP

Values received via the OpenTelemetry protocol (OTLP).

Traffic Observer

Network traffic statistics collected by traffic observers.

DCIs collect either single values (e.g., System.CPU.Usage) or tables (e.g., FileSystem.Volumes). Lists (e.g., FileSystem.MountPoints) are a separate agent metric type used by the server for instance discovery and configuration polling, not a DCI data type.

Each threshold is a combination of a condition and an event pair. When a condition becomes true, an activation event is generated; when it becomes false again, a deactivation event is generated. Multiple thresholds can be defined for a single DCI.

As an operator, you interact with DCIs primarily through:

  • Data Collection view — shows the most recently collected value for each DCI on a node

  • Graphs — historical trend charts of DCI data over time

  • Dashboards — visual layouts combining graphs, status indicators, and other elements

Polling

NetXMS uses periodic polls to collect information from monitored objects:

Status Poll

Checks whether a node is reachable and operational. Uses ICMP ping, agent connection, and/or SNMP to determine status.

Configuration Poll

Discovers the configuration of a node — its interfaces, IP addresses, supported protocols, software inventory, and other properties. Runs less frequently than status polls.

Topology Poll

Discovers network connections between devices using protocols like LLDP, CDP, and STP. Used to build topology maps.

Instance Discovery Poll

Discovers dynamic instances for DCIs that monitor multiple items (e.g., disk volumes, network interfaces, database instances).

Polling is configured and managed by administrators. As an operator, you see the results of polling reflected in object properties, status changes, and collected data.

Dashboards

Dashboards are customizable visual layouts that display monitoring data. They can include:

  • Status overview maps

  • Performance graphs

  • Alarm summaries

  • Custom web content

  • Tables of collected values

  • Network topology views

Dashboards are typically created by administrators and accessed by operators through the management console. Dashboard configuration is described in the Administrator Guide.

Network Maps

Network maps provide a visual representation of your infrastructure and its connections. Maps can show:

  • Automatically generated Layer 2 or Layer 3 topology

  • Custom layouts with manually placed objects

  • Status of nodes and links using color coding

  • IP addresses, interface names, and link utilization

For more details, see Topology.

Zones

NetXMS tracks IP topology and assumes that IP addresses are unique across the monitored network. However, in multi-site environments it is common to have overlapping IP address ranges (e.g., multiple sites using 192.168.0.0/24 internally).

Zones solve this problem. A zone is a group of IP subnets that form a non-overlapping IP address space. Zone objects exist only when zoning is enabled on the server (this is the default on new installations); when zoning is disabled, subnets appear directly under Entire Network and there are no zone objects. When zoning is enabled, the default zone (Zone 0) contains subnets directly reachable by the NetXMS server.

For all other zones, the server communicates through zone proxy agents — NetXMS agents deployed within each remote zone that relay communication between the server and local nodes.

As an operator, you may see zone information in:

  • The Entire Network tree, where subnets are organized by zone

  • Object properties, which show the zone assignment for each node

  • The Object Browser filter, where the @ prefix searches by zone

Zone configuration (creating zones, assigning proxies) is an administrative task described in the Administrator Guide.

What to Read Next