Glossary

Common terms used throughout the NetXMS documentation.

Action

A response that NetXMS executes when an event processing policy (EPP) rule matches. Actions include sending notifications, executing scripts, forwarding events, and running agent commands. See Actions.

Agent

A lightweight service (nxagentd) installed on monitored systems. Collects metrics, executes actions, and reports data to the NetXMS server. See Agent Configuration.

Alarm

A persistent notification generated by an event processing policy rule. Alarms have severity levels and lifecycle states (Outstanding, Acknowledged, Resolved, Terminated). See Alarms.

Auto-Apply Rule

A script-based rule that automatically applies templates to objects matching specified criteria. See Auto-Apply Rules.

Auto-Bind Rule

A script-based rule that automatically adds objects to containers based on matching criteria.

Business Service

A logical object representing a business process or IT service. Business services aggregate the status of their components for SLA reporting. See Business Services and SLA.

Cluster

An object representing a group of nodes working together. NetXMS tracks cluster resources and performs resource-aware monitoring. See Cluster Monitoring.

Collector

A container object with data collection capabilities — it can hold DCIs directly while also grouping other objects.

Condition

An object that periodically evaluates an NXSL script over DCI values on a schedule. When the evaluation result changes state, activation and deactivation events are generated.

Configuration Poll

A periodic process that discovers and updates the configuration of managed nodes, including interfaces, software inventory, and supported capabilities.

Container

An organizational object used to group other objects in the object tree. Containers can have auto-bind rules for automatic object placement.

DCI (Data Collection Item)

A single metric configured for collection on a node. DCIs define what to collect, how often, where to store it, and what thresholds to apply. See Data Collection Concepts.

EPP (Event Processing Policy)

An ordered set of rules that determine how NetXMS responds to events. Rules can generate alarms, execute actions, and filter or transform events. See Event Processing Policy.

Event

A notification generated by NetXMS when something significant occurs — a threshold is crossed, a node goes down, a configuration changes, etc. Events are processed by the EPP. See Events.

External Metric

A custom agent metric defined by a command line in the agent configuration file. The command is executed directly by default, or through the shell when defined with the shell form (ExternalMetricShellExec). See External Metrics.

Helpdesk Integration

Bidirectional integration between NetXMS alarms and external ticketing systems (e.g., Jira, ServiceNow). See Helpdesk Integration.

Hook

An NXSL script that runs automatically during specific server operations (configuration poll, node creation, etc.). See Server Hooks.

License

The license key that enables Enterprise Edition features. See Licensing.

Maintenance Mode

An object state in which polling and data collection continue, but events are correlated to the maintenance event and skipped by EPP rules by default — no alarms are raised unless a rule explicitly processes correlated events.

Master Server

A server listed in the agent’s MasterServers configuration parameter. Master servers have full control over the agent.

Metric

A result of measuring something on a monitored system (e.g., System.CPU.Usage). A metric is the measured value; a DCI is the configuration entity that collects it.

MIB (Management Information Base)

A structured definition of SNMP objects available on a network device. NetXMS uses MIBs to resolve OID numbers to human-readable names. See MIB Management.

Node

A primary managed object representing a network device, server, or virtual machine. Nodes are the main targets for monitoring. See Object Model.

Notification Channel

A configured delivery method for notifications (email, SMS, messaging services, custom scripts). See Notifications.

NXSL (NetXMS Scripting Language)

The built-in scripting language used for automation, data transformation, event filtering, and custom logic throughout NetXMS. See NXSL Reference and Scripting Overview.

NXShell

A Python/Jython command-line tool for scripting NetXMS server operations. See NXShell.

Object

Any entity in the NetXMS object tree (node, container, subnet, template, dashboard, etc.). See Object Model.

Policy

A configuration template pushed from the server to agents. Policies include log parser definitions, agent configuration snippets, and file delivery rules. See Agent Policies.

Script Library

A centralized repository of named NXSL scripts stored in the server database. Library scripts can be referenced by name from any scripting context. See Script Library.

SNMP (Simple Network Management Protocol)

A standard protocol for monitoring and managing network devices. NetXMS supports SNMP v1, v2c, and v3. See SNMP Configuration.

Status Poll

A periodic check of node reachability and operational status. Status polls use ICMP, agent, and SNMP checks.

Subagent

A loadable module that extends the agent with additional monitoring capabilities (database monitoring, log parsing, etc.). See Subagents.

Template

A reusable set of DCIs and policies that can be applied to multiple nodes. See Template Concepts.

Threshold

A condition defined on a DCI that triggers an event when the collected value crosses a specified boundary. See Thresholds.

Tunnel

An agent-initiated encrypted connection to the server, used when agents are behind firewalls or NAT. See Agent Tunnels.

Zone

A logical grouping of subnets with a unique zone identifier. Zones prevent IP address conflicts when monitoring multiple networks with overlapping address spaces. See Zones and Subnets.

Zone Proxy

An agent within a remote zone that relays communication between the server and nodes in that zone. The relevant proxy types must be enabled in the agent configuration. See Zones and Subnets.