Server Configuration

This page is a reference for NetXMS server configuration, including the configuration file, server configuration variables, audit log forwarding, thread pools, and inter-server communication.

For step-by-step maintenance procedures (modifying variables, housekeeping schedule tuning, thread pool tuning, debug logging), see Server Maintenance Tasks.

Configuration File

The main server configuration file is netxmsd.conf. On Linux, it is typically located at /etc/netxmsd.conf; on Windows, at C:\NetXMS\etc\netxmsd.conf.

This file is read only at server startup. Changes require a server restart to take effect.

Commonly Used Parameters

The parameters below cover typical setups. For the complete list of netxmsd.conf parameters, see Configuration File Reference.

Parameter Default Description

DBDriver

(none)

Database driver to use (pgsql.ddr, mysql.ddr, mariadb.ddr, mssql.ddr, oracle.ddr, informix.ddr, odbc.ddr, sqlite.ddr)

DBServer

127.0.0.1

Database server address

DBName

netxms_db

Database name

DBLogin

netxms

Database login name

DBPassword

(empty)

Database password, plain text or obfuscated with nxencpasswd (obfuscated values are detected automatically)

DBSchema

(default)

Database schema (PostgreSQL and Oracle)

LogFile

/var/log/netxmsd.log

Path to the server log file; special values: {syslog} (syslog on UNIX, Event Log on Windows), {systemd}, {stdout}

LogHistorySize

4

Number of rotated log files to keep

LogRotationMode

2

Log rotation mode: 0=no rotation, 1=daily, 2=by size

MaxLogSize

16M

Maximum log file size before rotation (when mode=2)

DebugLevel

0

Debug level (0-9); higher values produce more verbose output

DataDirectory

(platform-dependent)

Path to server data directory

LibraryDirectory

(platform-dependent)

Path to server library directory (database drivers, device drivers)

ListenAddress

*

IP address to listen on for client connections (* = all interfaces)

DumpDirectory

/var/tmp (UNIX), C:\ (Windows)

Directory for crash dumps
Example configuration (Linux)
DBDriver = pgsql.ddr
DBServer = localhost
DBName = netxms_db
DBLogin = netxms
DBPassword = secret
LogFile = /var/log/netxmsd
LogRotationMode = 1
LogHistorySize = 7
Example configuration (Windows)
DBDriver = pgsql.ddr
DBServer = db-server.example.com
DBName = netxms_db
DBLogin = netxms
DBPassword = secret
LogFile = C:\NetXMS\log\netxmsd.log

Obfuscated Database Password

To avoid storing the database password in plain text, use the nxencpasswd utility:

nxencpasswd <login> [<password>]

Where <login> is the database login name and <password> is the database password. If <password> is omitted, you will be prompted to enter it. The utility outputs an obfuscated string. Put the obfuscated string into the regular DBPassword parameter — the server detects obfuscated values and decodes them automatically:

DBPassword = <obfuscated_string>

Server Configuration Variables

In addition to the configuration file, NetXMS maintains a set of server configuration variables stored in the database. These can be modified at runtime through the management client (Configuration > Server Configuration) or via the nxdbmgr command-line tool (see Modifying Variables via CLI).

Commonly Used Variables

Variable Default Description

Client.MinViewRefreshInterval

300

Minimum refresh interval for client views (ms)

DataCollection.DefaultDCIPollingInterval

60

Default DCI polling interval (seconds)

DataCollection.DefaultDCIRetentionTime

30

Default DCI data retention time (days)

Events.Processor.PoolSize

1

Number of event processor threads

ICMP.CollectPollStatistics

1

Collect ICMP poll statistics for nodes

ICMP.PingSize

46

ICMP ping packet size (bytes)

ICMP.PingTimeout

1500

ICMP ping timeout (ms)

ICMP.PollingInterval

60

ICMP poll interval (seconds)

Objects.StatusCalculation.CalculationAlgorithm

1

Algorithm for status calculation (1=most critical, 2=single threshold, 3=multiple thresholds)

Server.Security.IntruderLockoutThreshold

0

Failed login attempts before lockout (0=disabled)

Server.Security.IntruderLockoutTime

30

Account lockout time (minutes)

ThreadPool.DataCollector.MaxSize

250

Maximum threads in data collector pool

ThreadPool.Main.MaxSize

256

Maximum threads in main server pool

ThreadPool.Poller.MaxSize

250

Maximum threads in poller pool

See Server Configuration Variables Reference for the complete list. Each variable has a description, data type, and restart requirement indicator.

Polling Intervals

Each poll type runs on its own interval, controlled by a server configuration variable. Changes take effect without a server restart.

Poll Type Variable Default Units

Status

Objects.StatusPollingInterval

60

seconds

Configuration

Objects.ConfigurationPollingInterval

3600

seconds

Topology

Topology.PollingInterval

1800

seconds

Routing table

Topology.RoutingTable.UpdateInterval

300

seconds

ICMP

ICMP.PollingInterval

60

seconds

Instance discovery

DataCollection.InstancePollingInterval

600

seconds

Automatic binding

Objects.AutobindPollingInterval

3600

seconds

Passive network discovery

NetworkDiscovery.PassiveDiscovery.Interval

900

seconds

Any of these intervals can be overridden for an individual object by setting a custom attribute named SysConfig:<variable> on it — for example, setting SysConfig:Objects.ConfigurationPollingInterval to 900 makes the server run configuration polls of that object every 15 minutes regardless of the global setting. See Server Configuration Overrides for the full list of supported override attributes.

The default polling interval and retention time for DCIs are separate settings (DataCollection.DefaultDCIPollingInterval and DataCollection.DefaultDCIRetentionTime, see above). They apply to every DCI whose collection schedule or history retention is set to Server default. This is the initial setting for DCIs created in the Data Collection view; DCIs created from the MIB Explorer get a custom interval and retention time instead. Changes take effect without a server restart: the new polling interval is used from the next scheduling check, and the new retention time at the next housekeeper run. DCIs with a custom interval, an advanced schedule, a custom retention time, or Do not save to the database are not affected.

Beacon Hosts

In a monitoring system, when the server loses network connectivity, every monitored node appears to go down simultaneously. Without a way to distinguish between "everything on the network failed" and "the server itself lost connectivity," the Event Processing Policy would raise a flood of false node-down alarms and notifications.

Beacon hosts give the server a way to check its own network connectivity. The server pings a configured list of well-known, stable hosts. Each round tests the hosts in list order, sending one ICMP request and waiting up to Beacon.Timeout for the reply, and stops at the first host that responds; the poller then waits Beacon.PollingInterval before the next round. As long as at least one beacon host responds, the server considers its own network link healthy. If none of them responds in a polling round, the server concludes that it has lost connectivity rather than that every monitored host has failed simultaneously — there is no hysteresis, a single round with all beacons silent is enough.

When the server detects connectivity loss, it generates a SYS_NETWORK_CONN_LOST event with CRITICAL severity on the management node — in an HA cluster, on the management node of the server that detected the loss, not on the server cluster object. While connectivity is down, and provided topology-based event correlation is enabled (Events.Correlation.TopologyBased), the event correlation engine marks SYS_NODE_DOWN and SYS_AP_DOWN events, as well as SYS_NODE_UNREACHABLE events caused by agent tunnel loss, as correlated to that event. SYS_NODE_UNREACHABLE events for nodes behind a failed proxy, router, or switch are correlated to the down event of that intermediate node instead.

Correlation only sets the root event of these events; it does not stop status polling. Node statuses still change, and the events are still generated and written to the event log. Alarms and notifications are suppressed only because Event Processing Policy rules skip correlated events unless Accept correlated events is enabled in the rule. Recovery events such as SYS_NODE_UP are not correlated, so rules matching them still fire for every node when connectivity returns.

When any beacon host becomes reachable again, the flag is cleared and a SYS_NETWORK_CONN_RESTORED event (NORMAL severity) is generated, and normal event correlation resumes for new events. A node that went down during the outage and is still down does not generate a new down event — its only down event is the correlated one. The default Event Processing Policy keeps an alarm with the key NET_CONN_LOST active between these two events.

Choose beacon hosts according to which connectivity loss should be detected: hosts that are highly available and unlikely to all fail at once, located beyond the link whose failure would otherwise make all monitored nodes appear down. The default gateway or a core router detects loss of the server’s local link; for a server that monitors remote sites over the internet, the beacons have to be beyond the internet uplink — for example, a well-known public DNS server. Using two or three hosts from different network segments provides reliable detection without unnecessary traffic.

Beacon host configuration requires a server restart to take effect. Host names in Beacon.Hosts are resolved once, when the server starts.

For the full list of beacon variables (Beacon.Hosts, Beacon.PollingInterval, Beacon.Timeout), see Beacon variables reference.

Audit Log Forwarding

NetXMS can forward audit log entries to external systems via syslog or LEEF (Log Event Extended Format) for integration with SIEM solutions.

Syslog Forwarding

Variable Default Description

AuditLog.External.Facility

13

Syslog facility code (default 13 = log audit)

AuditLog.External.Port

514

Target syslog server UDP port

AuditLog.External.Severity

5

Syslog severity code (default 5 = notice)

AuditLog.External.Server

none

Syslog server address; forwarding is disabled while the value is none

AuditLog.External.Tag

netxmsd-audit

Syslog message tag

AuditLog.External.UseUTF8

0

Set to 1 to encode forwarded messages in UTF-8

Set AuditLog.External.Server to the IP address or hostname of your syslog server. Once set, all audit log entries (login/logout, configuration changes, object modifications) are forwarded as syslog messages.

Changes to AuditLog.External.* variables require a server restart to take effect, except AuditLog.External.UseUTF8, which is applied immediately.

LEEF Forwarding

Forwarding of audit log records in LEEF (Log Event Extended Format), used by IBM QRadar and other SIEM systems, is provided by a separate loadable server module. To enable it, load the module and add a [LEEF] section in netxmsd.conf:

Module = leef.nxm

[LEEF]
Server = qradar.example.com

The [LEEF] section supports the following parameters:

Parameter Default Description

Server

127.0.0.1

Destination server address

Port

514

Destination UDP port

Vendor

Raden Solutions

Vendor name in the LEEF header

Product

NetXMS

Product name in the LEEF header

ProductVersion

(server version)

Product version in the LEEF header

EventCode

0

Event code (EventID) in the LEEF header

Facility

13

Syslog facility code

Severity

5

Syslog severity code

Separator

^

Attribute separator character; a literal character or xNN hexadecimal notation

RFC5424Timestamp

true

Use RFC 5424 timestamp format in the syslog header

An optional ExtraData subsection within [LEEF] defines additional static name=value attributes appended to every record:

[LEEF/ExtraData]
site = HQ

Each forwarded audit record carries the LEEF attributes devTimeFormat, devTime, result, description, usrName, identSrc, and object (when the record is associated with an object), followed by any configured extra data attributes.

Housekeeping Variables

Variable Default Description

Housekeeper.DisableCollectedDataCleanup

0

Set to 1 to skip cleanup of expired collected DCI data

Housekeeper.StartTime

02:00

Time to run the housekeeping process (HH:MM format)

Housekeeper.Throttle.HighWatermark

250000

Combined length of the database writer queues (general and collected-data writers) at which the housekeeper pauses deletions; 0 disables throttling

Housekeeper.Throttle.LowWatermark

50000

Combined database writer queue length at or below which a paused housekeeper resumes

For schedule tuning instructions, see Adjusting the Housekeeping Schedule.

Thread Pool Variables

Variable Default Description

ThreadPool.Agent.BaseSize

32

Base agent connection pool threads

ThreadPool.Agent.MaxSize

256

Maximum agent connection pool threads

ThreadPool.AIOperator.BaseSize

4

Base AI operator threads

ThreadPool.AIOperator.MaxSize

16

Maximum AI operator threads

ThreadPool.AITasks.BaseSize

4

Base AI task threads

ThreadPool.AITasks.MaxSize

16

Maximum AI task threads

ThreadPool.Client.BaseSize

16

Base client session request threads

ThreadPool.Client.MaxSize

2048

Maximum client session request threads (default is 8 × MaxClientSessions from netxmsd.conf)

ThreadPool.DataCollector.BaseSize

10

Base data collector threads

ThreadPool.DataCollector.MaxSize

250

Maximum data collector threads

ThreadPool.Discovery.BaseSize

8

Base network discovery threads

ThreadPool.Discovery.MaxSize

64

Maximum network discovery threads

ThreadPool.FileTransfer.BaseSize

2

Base file transfer threads

ThreadPool.FileTransfer.MaxSize

16

Maximum file transfer threads

ThreadPool.Global.Responsiveness

12

Number of 5-second maintenance cycles between pool resize decisions, for all pools (1–24). Not listed in the server configuration — create it to change the value (netxms#3831)

ThreadPool.Global.WaitTimeHighWatermark

100

Average queue wait time above which a pool grows (milliseconds). Not listed in the server configuration — create it to change the value (netxms#3831)

ThreadPool.Global.WaitTimeLowWatermark

50

Average queue wait time below which a pool may shrink (milliseconds). Not listed in the server configuration — create it to change the value (netxms#3831)

ThreadPool.Main.BaseSize

8

Base main pool threads

ThreadPool.Main.MaxSize

256

Maximum main pool threads

ThreadPool.MobileDevices.BaseSize

4

Base mobile device session threads

ThreadPool.MobileDevices.MaxSize

256

Maximum mobile device session threads

ThreadPool.Poller.BaseSize

10

Base poller threads

ThreadPool.Poller.MaxSize

250

Maximum poller threads

ThreadPool.Scheduler.BaseSize

1

Base scheduler threads

ThreadPool.Scheduler.MaxSize

64

Maximum scheduler threads

ThreadPool.Syncer.BaseSize

1

Base syncer threads

ThreadPool.Syncer.MaxSize

1

Maximum syncer threads (1 disables pool creation)

All ThreadPool.* variables take effect only after a server restart.

For tuning guidance, see Thread Pool Tuning.

Inter-Server Communication (ISC) Variables

NetXMS provides an Inter-Server Communication (ISC) protocol for server-to-server interaction on TCP port 4702. It is disabled by default.

Variable Default Description

EnableISCListener

false

Enable the ISC listener on port 4702 (requires server restart)

Events.ReceiveForwardedEvents

false

Accept and process events forwarded by remote servers

For setup instructions, see Setting Up ISC.

See Server Hooks for automated responses to server events.