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 system would generate a flood of false node-down alerts and change node statuses incorrectly.

Beacon hosts solve this problem by giving the server a way to check its own network connectivity. The server periodically sends ICMP pings to a configured list of well-known, stable hosts. If at least one beacon host responds, the server knows its own network link is healthy and any node-down events are genuine. If all beacon hosts become unreachable at the same time, the server concludes that it has lost connectivity rather than that every monitored host has failed simultaneously.

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 server cluster object). While connectivity is down, the event correlation engine treats all node-down and access-point-down events as consequences of the server’s own connectivity loss rather than independent failures — provided topology-based event correlation is enabled (Events.Correlation.TopologyBased). This prevents a cascade of false alarms in the Event Processing Policy.

When any beacon host becomes reachable again, the flag is cleared and a SYS_NETWORK_CONN_RESTORED event (NORMAL severity) is generated. Normal event correlation resumes, and genuine node-down conditions are processed as usual.

Good beacon host candidates are infrastructure devices that are highly available and unlikely to all fail at once — for example, the default gateway, a core router, or 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.

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

Database writer queue length at which the housekeeper pauses deletions

Housekeeper.Throttle.LowWatermark

50000

Database writer queue length at 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.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.Main.BaseSize

8

Base main pool threads

ThreadPool.Main.MaxSize

256

Maximum main pool 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.