Object Model

NetXMS represents all monitored infrastructure as a hierarchical tree of objects. Each object models a physical or logical entity — a host, network interface, subnet, container, or cluster — and carries its own configuration, access rights, and data collection items.

For tasks like creating, finding, and managing objects, see Managing Objects. For object property and permission details, see Object Properties Reference.

Object Tree

Objects are organized in a directed acyclic graph (DAG), meaning an object can have multiple parents. For example, a node can simultaneously belong to a subnet (under Entire Network), a container (under Infrastructure Services), and one or more templates.

The tree has seven top-level root objects, each serving a distinct purpose:

Root Object Purpose

Entire Network

Root of the IP topology tree. Contains zones when zoning is enabled, or subnets auto-created from discovered interface addresses when zoning is disabled.

Infrastructure Services

Default root for organizing monitored infrastructure. Contains containers, nodes, clusters, and other objects arranged by the administrator.

Templates

Root for data collection and policy templates. Templates are applied to nodes to configure what data to collect and which agent policies to push.

Assets

Root for hardware asset management objects. Asset objects link to nodes to track physical inventory.

Network Maps

Root for custom network map objects.

Dashboards

Root for dashboard objects.

Business Services

Root for business service definitions used in SLA/availability tracking.

Object Classes

Every object in the tree belongs to a class that determines its properties, capabilities, and which child classes it can contain. For a complete reference of all object classes with type identifiers and valid children, see Object Classes Reference.

Infrastructure Objects

Class Description Valid Children

Zone

Group of IP networks without overlapping addresses. Commonly used in multi-site environments, especially where different locations reuse the same private address space.

Subnet

Subnet

IP subnet, typically auto-created from interface addresses discovered during configuration polls.

Node

Node

Physical or virtual host, network device, or any SNMP/agent-reachable endpoint. Created manually or via network discovery.

Interface, Network Service, VPN Connector

Interface

Network interface on a managed device. Usually auto-created during configuration polls; can also be created manually. Properties include IP address, MAC address, speed, admin/oper status.

 — 

Cluster

Logical grouping that aggregates data from member nodes. Supports cluster resource tracking and shared DCI instances.

Node

Chassis

Physical chassis containing blades or modules. Nodes representing chassis modules can have images displayed atop the chassis image in the Chassis view.

Node

Circuit

Represents a network circuit or link composed of one or more interfaces. Interfaces are added via the Bind operation. Generates events when the state of underlying interfaces changes. Useful for modelling multilink interfaces, site-to-site links, or virtual circuits. Supports auto-bind rules for automatic interface binding.

Interface (via bind)

Collector

Container with data collection capabilities. Combines the organizational role of a container with the ability to hold DCIs.

Access Point, Chassis, Circuit, Cloud Domain, Cluster, Collector, Condition, Container, Mobile Device, Node, Rack, Resource, Sensor, Subnet, Traffic Observer, Wireless Domain

Sensor

Physical data acquisition device attached to a gateway node. Configured with a gateway node, Modbus unit ID, device address, and MAC address. Device classes include UPS, water and electricity meters, temperature, humidity, and CO2 sensors, power supply, current sensor, and water leak and smoke detectors.

 — 

Wireless Domain

Wireless infrastructure domain managing wireless controllers and their access points.

Access Point, Node

Access Point

Wireless access point discovered from a managed wireless controller.

 — 

Mobile Device

Registered mobile device managed through the NetXMS mobile agent.

 — 

Cloud Domain

Cloud infrastructure connector that provides resource discovery and monitoring for a cloud environment.

Resource

Resource

Cloud resource discovered and managed by a Cloud Domain. Can contain nested resources to represent hierarchical cloud structures.

Resource

Traffic Observer

External traffic analysis instance connected through a traffic connector. Discovers observation points and matches observed hosts to managed nodes. Can be created only when the TRAFFIC server component is registered by a connector module.

Observation Point

Observation Point

Single monitored interface (observation point) of a traffic observer, with point type, sampling rate, and state reported by the analyzer.

 — 

Organizational Objects

Class Description

Container

Grouping object for building logical hierarchies (e.g., by location, function, or service). Accepts the same child classes as Infrastructure Services and Collector: containers, nodes, clusters, collectors, racks, chassis, circuits, conditions, sensors, mobile devices, subnets, wireless domains, access points, cloud domains, resources, and traffic observers. Supports auto-bind scripts for automatic object placement.

Rack

Visual representation of a physical equipment rack. Nodes and chassis placed inside appear in the rack visualization view.

Condition

Evaluates NXSL expressions over DCI values and generates events when the expression changes state. Input values from DCIs are accessible as $1, $2, etc. in the script. When the script result transitions from false to true, an activation event is generated; a transition back to false generates a deactivation event. Polling interval is configured by the Objects.Conditions.PollingInterval server configuration variable (default: 60 seconds).

Template Group

Grouping object for organizing templates in a hierarchical structure.

Asset Objects

Class Description

Asset

Hardware asset record. Can be linked to infrastructure objects (Node, Rack, Chassis, Access Point, Mobile Device, Sensor) for inventory tracking.

Asset Group

Grouping object for organizing assets in a hierarchical structure.

Network Map Objects

Class Description

Network Map

Visual representation of network topology or custom layout of monitored objects.

Network Map Group

Grouping object for organizing network maps.

Dashboard Objects

Class Description

Dashboard

Customizable visualization panel displaying charts, maps, tables, and other widgets. Can contain nested dashboards.

Dashboard Template

Dashboard template that applies dashboard layouts to target objects via auto-bind rules, similar to how data collection templates work.

Dashboard Group

Grouping object for organizing dashboards in a hierarchical structure.

Service Objects

Class Description

Network Service

Checks network service availability from the parent node. Supported types: user-defined (custom), SSH, POP3, SMTP, FTP, HTTP, HTTPS, Telnet, TLS, POP3S, SMTPS.

VPN Connector

Represents a VPN tunnel endpoint between two nodes. Used for topology calculations across VPN links.

Business Service

Models a business service for SLA/availability tracking. Status is calculated from check objects and child services.

Business Service Prototype

Template for auto-creating business service instances based on DCI instance discovery.

Template

Defines a set of DCIs and agent policies that can be applied to multiple nodes. See Templates.

Object Class Details

Rack

A Rack object visualizes a physical equipment rack. Node and Chassis objects can be assigned to a rack in their properties dialog, specifying:

  • Position in the rack (starting rack unit)

  • Height (number of occupied rack units)

  • Orientation: full depth, front only, or rear only

Rack numbering can be configured as top-to-bottom or bottom-to-top. Front and rear images can be selected from the Image Library.

Rack visualization is available in the object detail view under the Rack tab. Left-clicking a rack unit displays a pop-up with brief information about the node or chassis. Right-clicking displays the node or chassis context menu. Double-clicking a chassis opens the Chassis view in a separate tab.

Status of occupied rack units is indicated by a color rectangle on the left edge of the rack.

Racks also support passive elements (patch panels, filler panels, organisers, and PDUs) that occupy rack units but are not monitored objects.

Chassis

A Chassis object visualizes a rack-mount chassis with plug-in modules. Chassis visualization is available in the object detail view under the Chassis tab.

Each node representing a chassis module can have an image displayed atop the chassis image. Module status is indicated by a color rectangle in the upper left corner of its image. Left-clicking a module displays a pop-up with brief node information. Right-clicking displays the node context menu.

Module image size and position on the chassis image can be configured:

  • Vertical size and position: specified in mm or rack units (RU)

  • Horizontal size and position: specified in mm or horizontal pitch units (HP)

Size calculation assumes 44.45 mm height per rack unit and 482.6 mm full width (including mounting brackets). Position (0, 0) is the upper left corner of the chassis image.

Use a graphic editor (e.g., GIMP) to determine position values. Open the chassis image and set the image width to 483 mm using Image > Scale Image. The status bar shows mouse cursor coordinates in mm.

Chassis module images should be uploaded via the Image Library.

Circuit

A Circuit object represents a network circuit or link composed of one or more node interfaces. Circuits can be created under Infrastructure Services. Existing node interfaces are added to a circuit manually using the Bind operation (and removed using Unbind) or automatically using auto-bind rules.

Circuits generate events when the state of underlying interfaces changes. As an event source, a circuit can have alarms associated with it. Referencing multiple interfaces allows circuits to represent:

  • Multilink interfaces

  • Site-to-site links

  • Virtual circuits

  • Aggregated links

Circuit properties include:

  • Automatic Bind Rules tab for automatic interface binding based on NXSL scripts

  • Map Appearance tab for configuring images used on network maps

  • Trusted Objects tab for defining objects that can access this circuit from scripts

Condition

A Condition object evaluates an NXSL script against DCI values and generates events based on the result. This allows modelling complex status checks that depend on multiple metrics.

Condition properties include:

  • Events and Status tab: configure activation and deactivation events, the event source object, and the status values for active and inactive states

  • Data tab: select DCIs whose values are passed to the condition script as $1, $2, etc.

  • Script tab: write the NXSL script that determines whether the condition is active or inactive

  • Map Appearance tab: configure images for display on network maps

  • Trusted Objects tab: define objects that can access this condition from scripts

The condition polling interval is set by the Objects.Conditions.PollingInterval server configuration variable (default: 60 seconds). Events are generated only on state transitions: an activation event when the script result changes from false to true, and a deactivation event when it changes back. The object status is set to the status value configured for the active or inactive state on the Events and Status tab.

Object Status

Object status is the primary indicator of health. For compound objects it is calculated from multiple inputs:

  1. Child object statuses — statuses of all children, as transformed by their propagation settings

  2. Most critical active alarm — the highest-severity active alarm on the object

  3. Status DCIs — data collection items with the Use this DCI for status calculation option enabled

  4. Module status — status provided by server extension modules

Polling results set status directly only on leaf objects such as interfaces and network services; problems detected by polls on other objects surface as events and alarms, which then influence status.

Nr Status Description

0

Normal

Everything is operating correctly.

1

Warning

Warning condition(s) detected.

2

Minor

Minor problem(s) detected.

3

Major

Major problem(s) detected.

4

Critical

Critical problem(s) detected.

5

Unknown

Object status cannot be determined (e.g., agent unreachable and no SNMP).

6

Unmanaged

Object is set to unmanaged and is not polled.

7

Disabled

Interface is administratively disabled.

8

Testing

Interface is in testing mode.

Status Calculation

Status calculation determines how an object computes its own status from the statuses of its children. This is configured per object in the object properties dialog under the Status Calculation tab, or globally via server configuration variables.

Value Algorithm Description

0

Default

Uses the global setting (most critical by default).

1

Most critical

The object takes the worst (highest-severity) status among all its children.

2

Single threshold (%)

The object enters a problem status if the percentage of children with that status or worse exceeds a single configurable threshold.

3

Multiple thresholds

Separate percentage thresholds for each severity level. The resulting status is the most critical level whose threshold is met.
Example: Single threshold at 75%

A container has 4 nodes: 1 Normal, 3 Warning. Since 75% of nodes (3 out of 4) have Warning status or worse, the container status becomes Warning.

Example: Multiple thresholds

A container uses thresholds: Warning 80%, Minor 50%, Major 25%, Critical 35%. If 30% of nodes are in Major or worse, the Major threshold (25%) is exceeded. If 55% are in Minor or worse, the Minor threshold (50%) is also exceeded. The container status is Major (the most critical status whose threshold is met).

Status Propagation

Status propagation controls how an object’s status is transformed before being passed to its parent. This is configured per object in the object properties dialog, or globally via the Objects.StatusCalculation.PropagationAlgorithm server configuration variable.

Value Algorithm Description

0

Default

Uses the global setting (unchanged by default).

1

Unchanged

Propagates the status value without modification.

2

Fixed value

When the object is in a problem state (Warning through Critical), propagates a fixed status value. Normal and Unknown statuses pass through unchanged.

3

Relative offset

Adds or subtracts a configurable offset to the status severity level before propagating. For example, an offset of -1 reduces Warning to Normal.

4

Translated

Maps each status level to a configured target status using a translation table. For example, Warning can be mapped to Normal, while Critical remains Critical. The per-object Status Calculation property page labels this option Severity based.

Status Calculation Walkthrough

Consider a three-level hierarchy:

Container A
├── Node 1 (agent down → Critical)
│   ├── Interface eth0 (up → Normal)
│   └── Interface eth1 (down → Critical)
├── Node 2 (all OK → Normal)
│   ├── Interface eth0 (up → Normal)
│   └── Interface eth1 (up → Normal)
└── Node 3 (threshold alarm → Warning)
    └── Interface eth0 (up → Normal)

With default settings (most critical + unchanged propagation):

  1. Node 1 status: the worst of its most critical active alarm (Critical, raised for the agent failure) and child statuses (Critical from eth1) = Critical

  2. Node 2 status: all Normal = Normal

  3. Node 3 status: Warning from threshold alarm, children Normal = Warning

  4. Container A status: worst of Node 1 (Critical), Node 2 (Normal), Node 3 (Warning) = Critical

If Node 1 has a fixed propagation of Warning:

  1. Container A sees Node 1 as Warning (not Critical), Node 2 as Normal, Node 3 as Warning = Warning

This allows isolating the impact of known-problematic nodes on container status.

Unmanaged State

Setting an object to unmanaged stops all polling and data collection for it. No events are generated and no alarms are created, with one exception: SNMP traps, syslog messages, and Windows events from unmanaged nodes are still processed when the SNMP.Traps.ProcessUnmanagedNodes server configuration variable is enabled. Use this for decommissioned equipment or objects you want to exclude from monitoring temporarily.

To change the managed state: right-click the object and select Unmanage (or Manage to return it to the managed state).

Maintenance Mode

While an object is in maintenance mode, polling, data collection, threshold processing, and status calculation all continue unchanged, and events are generated and written to the event log as usual. What changes is event processing: every event from the object is correlated to the SYS_MAINTENANCE_MODE_ENTERED event, and Event Processing Policy rules skip correlated events unless a rule explicitly opts in with the Accept correlated events option. As a result, no alarms are created and no actions are executed for events that occur during maintenance.

When maintenance ends, the server compares DCI threshold, interface, and network service states against the state captured when maintenance started and regenerates events for the differences, so problems that persist past the maintenance window surface normally.

To enter maintenance mode: right-click the object and select Maintenance > Start maintenance…​. Optionally provide a comment describing the maintenance reason. To leave: Maintenance > End maintenance. The Maintenance > Start maintenance for period submenu enters maintenance immediately and schedules the exit automatically; its entries come from the Predefined maintenance periods client preference (Preferences > Objects) and the submenu is empty by default.

Maintenance windows can also be scheduled — see Scheduling.