Understanding Event Processing Policy

The Event Processing Policy (EPP) is the central rules engine in NetXMS. It determines what happens when events are generated — whether to create alarms, send notifications, execute scripts, or perform other automated actions.

Event Processing Modes

NetXMS Event Processor can process events from the event queue in either sequential or parallel mode.

Sequential Mode (Default)

In sequential mode, events are processed one by one in the order they arrive. This guarantees events will be processed in the same sequence as they are generated. For installations where many events can be generated in a short period of time, this mode can become a bottleneck.

Parallel Mode

Parallel processing mode allows events to be processed by multiple threads simultaneously, increasing throughput and processing performance.

Configure parallel mode using these server configuration variables:

Variable Default Description

Events.Processor.PoolSize

1

Number of event processing threads (1 = sequential mode, 2-128 = parallel mode; out-of-range values are silently clamped to this range). Changes require a server restart.

Events.Processor.QueueSelector

%z

Macro expression used to bind events to processing queues. Changes require a server restart.
EPP rules can read/write persistent storage and custom attributes, create/terminate alarms, and run scripts that check other node statuses. When using parallel processing, care must be taken to avoid race conditions.

Correct operation is ensured by properly setting Events.Processor.QueueSelector. This parameter contains macros that are expanded by the dispatcher thread when the event is taken off the main event queue. Events that produce the same queue selector string will be processed sequentially by the same thread, ensuring no race conditions between those events.

For example, the default value %z (zone UIN) ensures all events from the same zone are processed by the same thread. If your installation uses a single zone, you may want to use %i (source object ID) instead, so events from different objects can be processed in parallel while events from the same object are always sequential.

How the EPP Works

When an event is generated, NetXMS processes it through the EPP rules in order from top to bottom. Each rule defines a set of matching criteria and one or more actions to execute when the criteria are satisfied.

The processing flow:

  1. An event is generated (by threshold, poll, trap, script, etc.)

  2. The EPP evaluates rules starting from rule 1

  3. For each rule, the server checks whether the event matches the rule’s filter criteria

  4. If the event matches, the configured actions execute

  5. If the rule has the Stop Processing flag set, no further rules are evaluated for this event

  6. If the flag is not set, the next rule is evaluated

  7. Processing continues until all rules have been evaluated or a Stop Processing rule matches

Rule ordering matters. Rules are evaluated top to bottom, and the Stop Processing flag controls whether subsequent rules see the event.

A rule with no filter criteria configured at all is skipped during processing — it does not match every event.

Multiple users can edit the Event Processing Policy at the same time. When the policy is saved, changes from concurrent editors are merged on the server side. If the server detects conflicting changes to the same rules, the client shows a conflict dialog offering to reload the policy.

Rule Structure

Each EPP rule consists of:

Component Description

Rule Number

Ordinal position in the policy (determines evaluation order)

Comments

Free-form text documenting the rule’s purpose; displayed as the rule header in the policy editor (rules have no separate name field)

Events

Which events this rule matches

Source Objects

Which objects (nodes, subnets, etc.) this rule applies to, with optional exclusions

Severity Filter

Which event severities this rule matches

Time Filter

When this rule is active (day of week, time of day)

Filtering Script

NXSL script for custom matching logic (also the place to match event tags via $event→hasTag())

Actions

What to do when the rule matches

Flags

Rule options: Stop Processing, Rule is disabled, negation of the source object, event, and time frame filters, Accept correlated events, and treating the alarm termination key as a regular expression

For details on each filter type and action, see the EPP Reference.

Alarm Correlation with Keys

Alarm keys are the mechanism for correlating related events. The typical pattern:

  1. A failure event (e.g., SYS_NODE_DOWN) matches a rule that generates an alarm with key NODE_DOWN_%i (where %i is the source object ID)

  2. The corresponding recovery event (e.g., SYS_NODE_UP) matches a different rule that terminates alarms matching key NODE_DOWN_%i

A rule can either terminate or resolve alarms with a matching key. The shipped default policy uses termination for its correlation rules — for example, the node-up rule terminates node-down alarms. Resolving instead keeps the alarm visible in the Resolved state until it is terminated manually or by timeout. Either way, when a problem is detected and later recovers, the corresponding alarm is closed automatically. See Common EPP Patterns for concrete examples of alarm correlation rules.

Default Policy

NetXMS ships with a default EPP that handles common scenarios:

  • Node up/down alarm correlation

  • Interface up/down alarm correlation

  • Service up/down alarm correlation

  • Threshold alarm correlation

  • Agent communication alarm correlation

  • SNMP communication alarm correlation

The default policy provides a working baseline. Customize it by adding rules for your notification requirements, custom events, and environment-specific logic.

Next Steps

  • How to Create EPP Rules — step-by-step procedures for building and managing rules

  • EPP Reference — filter criteria, actions, and macro reference

  • Alarms — alarm lifecycle, states, and management

  • Notifications — notification channels and recipient configuration

  • Actions — automated response actions