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
MasterServersconfiguration 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.