Syslog Monitoring

NetXMS includes a built-in syslog server that receives, parses, stores, and processes syslog messages from network devices and systems. Unlike file-based log monitoring, syslog monitoring does not require an agent — devices send syslog messages directly to the NetXMS server (or to an agent acting as syslog proxy).

Architecture

Syslog processing in NetXMS:

  1. Network devices and systems send syslog messages to the NetXMS server via UDP, or via TLS (RFC 5425) if the TLS listener is enabled

  2. The server parses each message (RFC 3164 and RFC 5424 formats are supported)

  3. The server matches the source to a managed node; messages from unknown sources are discarded by default

  4. If a syslog parser is configured, matching rules generate events for processing through the EPP

  5. Matched messages are stored in the database for browsing and searching

Enabling Syslog Receiver

Enable the syslog receiver by setting these server configuration variables:

Variable Default Description

Syslog.EnableListener

0

Enable the built-in syslog receiver

Syslog.ListenPort

514

UDP port for receiving syslog messages

Syslog.EnableStorage

1

Store received messages in the database

Syslog.RetentionTime

90

How long to keep syslog messages in the database (days)

Syslog.AllowUnknownSources

0

Accept and store messages from sources that do not match any node

Syslog.ParseUnknownSourceMessages

0

Also run the syslog parser on messages from unknown sources

Syslog.IgnoreMessageTimestamp

0

Use server time instead of the timestamp from the message

Syslog.Codepage

(empty)

Codepage for decoding non-UTF-8 messages

Changes to Syslog.EnableListener, Syslog.ListenPort, Syslog.NodeMatchingPolicy, and the Syslog.TLS.* variables require a server restart; the other variables take effect immediately.

Binding to port 514 requires root/administrator privileges. On an unprivileged setup, set Syslog.ListenPort to a port above 1024 and redirect the traffic (device-side configuration or a firewall port redirect).

Syslog over TLS

A separate listener accepts syslog over TLS (RFC 5425):

Variable Default Description

Syslog.TLS.EnableListener

0

Enable the syslog-over-TLS listener

Syslog.TLS.ListenPort

6514

TCP port for the TLS listener

Syslog.TLS.MinVersion

2

Minimum accepted TLS protocol version: 0 = TLS 1.0, 1 = TLS 1.1, 2 = TLS 1.2, 3 = TLS 1.3 (same encoding as AgentTunnels.TLS.MinVersion)

Syslog.TLS.RequireClientCertificate

0

Require clients to present a certificate

The TLS listener requires a server certificate and refuses to start without one. It presents the certificate configured with ServerCertificate/ServerCertificateKey in netxmsd.conf (or the automatically generated one) and validates client certificates against TrustedCertificate entries and the internal CA. A client that presents a certificate must chain to a trusted CA even when Syslog.TLS.RequireClientCertificate is 0.

Syslog Parser Rules

Syslog messages are processed using the same log parser XML format as file-based log monitoring, but parsing is done by the server, not by the agent. The parser is configured in the management client under Configuration > Syslog parser.

When a rule matches, the configured event is generated on the node matched as the message source. If Syslog.ParseUnknownSourceMessages is enabled and the message does not match any node, the event is generated on the management server node. Regular expression capture groups from the <match> pattern become the first event parameters, followed by named parameters that can be referenced in the event message template as %<name>:

Parameter Description

repeatCount

Number of times the message was repeated

sourceAddress

Source address of the message

severity

Syslog severity as a bitmask: 2N for severity N (e.g. err (3) is passed as 8), the same encoding as the <severity> filter element

facility

Syslog facility (numeric)

tag

Syslog tag (application name)

message

Message text

Example Syslog Parser

<parser>
  <rules>
    <rule>
      <facility>4</facility>
      <match>authentication failure.*user=(\S+)</match>
      <event>100100</event>
    </rule>
    <rule>
      <facility>0</facility>
      <match>Out of memory</match>
      <event>100101</event>
    </rule>
  </rules>
</parser>

Facility, Severity, and Tag Filters

Syslog rules can filter by syslog header fields in addition to pattern matching:

Element Description

<facility>

Match only messages with this syslog facility (0-23). A range is also accepted, e.g. <facility>16-23</facility>.

<severity>

Bitmask of syslog severity levels to match. The bit value for severity N is 2N — for example, 8 matches err (3), 31 matches emergency (0) through warning (4).

<source> (or <tag>)

Match the syslog tag against a pattern

Standard syslog facilities:

Code Facility Code Facility

0

kern

8

UUCP

1

user

9

Cron

2

mail

10

Security

3

daemon

11

FTPD

4

auth

12

ntp

5

syslog

13

Log Audit

6

lpr

14

Log Alert

7

news

15

Clock

16-23

local0-local7

See Log Parser Reference for the complete XML format.

Viewing Syslog Messages

  • The Syslog view in the Monitor perspective shows incoming messages in real time

  • The Syslog log in the Logs perspective provides historical browsing with filtering by time, source, facility, severity, and text content

Node Matching

When a syslog message arrives, NetXMS matches the source to a managed node. The matching order is controlled by the Syslog.NodeMatchingPolicy server configuration variable:

  • 0 (default) — by source IP address first, then by hostname from the syslog header

  • 1 — by hostname first, then by source IP address

Hostname matching first checks object names, then falls back to DNS resolution; resolver results are cached (Syslog.ResolverCacheTTL, default 300 seconds). In zoned setups, matching is scoped to the zone the message arrived from. Messages arriving on the loopback interface are attributed to the management server node.

By default, messages that do not match any node are discarded. Set Syslog.AllowUnknownSources to 1 to store them, and Syslog.ParseUnknownSourceMessages to 1 to also run the parser on them. To troubleshoot unmatched messages, raise the syslog debug tag (see Enabling Debug Logging).

Syslog messages can also drive network discovery: when NetworkDiscovery.UseSyslog is enabled, unknown source addresses are fed into the discovery pipeline as potential new nodes (see Network Discovery).

Syslog Proxy

Devices that cannot reach the server directly can send syslog to a NetXMS agent acting as syslog proxy. Enable the proxy with EnableSyslogProxy = yes in the agent configuration; the agent then relays received syslog messages to the server. In zoned setups, relayed messages are matched to nodes within the zone set by the proxy agent’s ZoneUIN configuration parameter.