syslog-ng and NXLog are both powerful log collectors providing flexible log processing. However, you might be in a position where you need to switch from syslog-ng to NXLog. Whether it’s because syslog-ng doesn’t support an operating system or you want to upgrade your log collection solution to one that can be centrally managed, converting your syslog-ng configuration to NXLog is a simple task.
How do syslog-ng and NXLog differ?
syslog-ng and NXLog are alike in many ways. They can both parse, process, normalize, and forward logs over the network via secure transport, all at impressive speeds. They also implement caching mechanisms for reliable message delivery and their own protocol for more efficient log forwarding between nodes. However, NXLog’s rich feature set supports more input sources in more formats and ships to more output destinations.
Some of the predominant differences include the following:
-
syslog-ng does not support macOS. On the other hand, NXLog can be installed on macOS and has specialized modules for collecting macOS system and security logs.
-
Unlike syslog-ng, NXLog is made to be centrally managed. The agent includes a remote management module providing RESTful and SOAP APIs, so you can easily integrate it with whatever SCM tool you already use. In addition, we make your life easy with NXLog Manager and NXLog Minder.
-
NXLog supports custom extensions in Go, Perl, Python, Ruby, and Java. In comparison, syslog-ng only supports Python, which is still a preview feature at the time of writing.
-
Whereas syslog-ng requires Java to be installed when using certain destinations, such as Elasticsearch and HDFS, NXLog has no such requirements.
What can NXLog do that syslog-ng can’t?
Here is a non-exhaustive list of input/output sources and log formats NXLog supports out-of-the-box that are not available in syslog-ng.
Input | Output | Log format |
---|---|---|
Generic HTTP(s) input |
Amazon S3 |
GELF |
Google Cloud Logging (formerly Stackdriver) |
Microsoft Azure - tables and blobs (in addition to Log Analytics workspaces, also supported by syslog-ng) |
NetFlow |
macOS - Apple’s unified logging system (ULS) and Endpoint Security auditing system |
Microsoft 365 - Microsoft Graph and Office 365 Reporting web service (in addition to the Office 365 Management API, also supported by syslog-ng) |
Microsoft DNS Server |
Microsoft Azure - tables, blobs, and Log Analytics workspaces |
Google Chronicle |
SAP audit logs |
Network packet capture |
Raijin Database |
W3C |
Redis |
Redis |
|
Salesforce |
ZeroMQ |
|
Okta |
||
File integrity monitoring |
||
Windows Registry monitoring |
||
ZeroMQ |
syslog-ng and NXLog configuration comparison
syslog-ng v.s. NXLog nomenclature
Before going any further, it would be wise to familiarize yourself with how both products refer to configuration elements. We cover the basics in the following matrix.
Configuration element | syslog-ng | NXLog |
---|---|---|
Log ingestion element |
source/source driver |
input module |
Log output element |
destination/destination driver |
output module |
Log routing element |
log path |
route |
Log filtering element |
filter block |
xm_pattern module or via regular expressions |
Log parsing element |
parser block |
extension modules or via regular expressions |
Log transformation element |
rewrite rule |
xm_rewrite module or Exec statements |
Configuration parameters |
options |
directives |
Values parsed from log records |
macros |
fields |
NXLog on Linux
Both syslog-ng and NXLog use a file-based configuration system on Linux platforms. The default configuration file location for the two products is:
- syslog-ng
-
/opt/syslog-ng/etc/syslog-ng.conf
- NXLog
-
/opt/nxlog/etc/nxlog.conf
A key difference is that syslog-ng automatically disables Rsyslog and renames the /etc/init.d/sysklogd
init script to /etc/init.d/sysklogd.backup
upon installation.
NXLog doesn’t make changes to other components on the system.
Therefore, if you’d like to disable Rsyslog, you must do it manually by executing the following commands:
$ sudo systemctl disable --now rsyslog
$ sudo systemctl force-reload systemd-journald
$ sudo systemctl restart nxlog
Ready to start? Let’s dive right into the configuration.
Convert syslog-ng internal and Linux system log sources
The default syslog-ng configuration on Linux collects system and kernel logs and syslog-ng’s own internal logs. So let’s see how easy it is to replicate these sources in NXLog. |
|
|
Start by choosing which Linux logs you want to collect:
In this NXLog configuration, we collect the first three logs corresponding to syslog-ng’s NXLog can also collect its own internal logs with the im_internal module. |
Convert a syslog-ng file source
The use of log files is still widespread in the logging sphere, especially on Linux platforms. So let’s convert a syslog-ng file source collecting Apache access logs to NXLog. |
|
|
Use the im_file input module to collect file-based logs.
You can specify the File directive multiple times and use wildcards.
The PollInterval directive, set to 1 second by default, corresponds to the syslog-ng Since the syslog-ng configuration uses the |
Convert syslog-ng destinations and log paths
Now that we sorted our input sources, we’ll see how to save the logs to a file and/or forward them to a remote host over TCP. |
|
|
Use the om_file output module to save logs to a file. For example, in this NXLog configuration, we’re writing the log records in syslog-BSD format by using the to_syslog_bsd() procedure provided by the xm_syslog extension. To forward logs to a remote destination over TCP, the om_tcp output module will do the job.
By default, this module outputs logs one record per line separated by a newline character.
In this example, we change the output format to use octet-framing by setting the OutpuType directive to Syslog_TLS.
We also convert log records to syslog-IETF messages by calling the to_syslog_ietf() procedure.
Both the Finally, all that’s left will be to convert the syslog-ng log paths to NXLog routes. This configuration forwards all logs to the remote host and saves the Linux system and NXLog internal logs to a file. |
That was easy, right? Read on to see how to convert your syslog-ng configuration on Windows.
NXLog on Windows
The syslog-ng Agent for Windows comes with an MMC-based configuration interface and supports importing and exporting the configuration to and from an XML file. syslog-ng Agent for Windows is also available as an MSI, so you can deploy and configure it via GPO. However, the configuration options are limited on Windows. According to the syslog-ng documentation:
-
It only supports log forwarding using the Snare, IETF syslog, or BSD syslog protocols.
-
Only basic filtering is available. Log parsing and classification are not possible.
-
The syslog-ng Agent for Windows only reads logs from files, including for Eventlog Containers, and does not implement disk buffering.
NXLog on Windows is configured the same as any other platform, using the configuration file. It is fully featured with no limitations and can be installed interactively or deployed via GPO.
Now, onto some concrete configuration examples.
Convert a syslog-ng Event Container source
Let’s start by converting a Windows Eventlog Source that collects Application, Security, System, and DNS logs. |
|
Use the im_msvistalog input module to collect Application, Security, and System logs.
This diverse module can collect logs directly from the Event Log API or event log files ( On the other hand, use the im_etw input module to collect DNS Server audit logs. This dedicated module collects logs directly from ETW channels, including Analytic and Debug logs, and automatically parses log records into fields. In this NXLog configuration, we also enable the ParsePacketData directive to convert the DNS payload into JSON format. |
Convert a syslog-ng File source
Next, let’s look at how to convert this syslog-ng configuration collecting Domain Controller Promoter (DCPromo) logs. |
|
Use the im_file input module to collect file-based logs. You can specify the File directive multiple times and use wildcards. Optionally, you can include further log processing in an Exec block.
For example, in this NXLog configuration, we are adding two new fields, |
Convert a syslog-ng Server destination
Finally, we’ll forward the logs to a remote server over TCP. You simply need to create the output and bind it to the above sources. |
|
Use the om_tcp output module to forward logs to their destination over TCP. The FlowControl directive, enabled by default, corresponds to the Enable flow-control option in syslog-ng. By default, om_tcp outputs logs one record per line separated by a newline character.
In this NXLog configuration, we change the output format to use octet-framing by setting the OutpuType directive to Syslog_TLS.
We also convert log records to syslog-IETF messages by calling the to_syslog_ietf() procedure.
Both the |
What’s next?
If you haven’t already, download a free NXLog Enterprise Edition trial and try it for yourself. Once you’ve mastered the basics, converting more complex syslog-ng configuration to NXLog will become second nature.
We recommend the following additional reading to help you in the process:
We hope you found our guide helpful in your quest to find a syslog-ng alternative. Finally, get in touch with us if you need advice or hit any walls. Our support team is always available to share their expertise!