NXLog

NXLog is a multi-platform log management solution that allows to collect logs from various sources, filter log events, transform log data and route (forward) it to different destinations. It's available both as a free-of-charge NXLog Community Edition and as a commercial NXLog Enterprise Edition with enhanced capabilities, including agent management.

NXLog

Developer(s)	NXLog Ltd.
Initial release	October 2011 (2011-10)
Stable release	NXLog EE v6.2 / Dec 4, 2023
Repository	gitlab.com/nxlog-public/nxlog-ce
Written in	C
Operating system	Windows, macOS, Amazon Linux, CentOS, RHEL, Ubuntu, Debian, AIX, FreeBSD, OpenBSD Oracle Solaris
Type	Log management, Cybersecurity, SIEM
License	NPL
Website	nxlog.co

NXLog is used as an integration component of many security products, like SIEM solutions, including Google Chronicle, Microsoft Azure Sentinel, Securonix, LogPoint; XDR/EDR solutions, including Rapid7 InsightIDR/OPS, Vectra Platform, Trellix XDR; and MSSP/MDR solutions (e.g. from Arctic Wolf and AT&T Cybersecurity). It’s also known as integration component for application performance monitoring (APM) and observability platforms like Datadog, Graylog, Coralogix, SolarWinds Loggly, IBM Log Analysis, Mezmo (former LogDNA), as well as a log management component for industrial control systems (SCADA/ICS), including power automation solutions from Siemens.

Being able to run as a local log collection agent and as a network log aggregator, NXLog supports a wide list of operating systems including Microsoft Windows, Apple macOS, Amazon Linux, Ubuntu, RedHat Linux, CentOS, Debian, SLES, IBM AIX, Oracle Solaris, FreeBSD and OpenBSD.

The source code for NXLog Community Edition is public and available as a GitLab project.

Overview

NXLog can be installed on many operating systems and it is enabled to operate in a heterogeneous environment, collecting event logs from thousands of different sources in many formats. NXLog can accept event logs from TCP, UDP, file, database and various other sources in different formats such as syslog, windows event log, etc. It supports SSL/TLS encryption to ensure data security in transit.

In concept NXLog is similar to syslog-ng or Rsyslog but it is not limited to UNIX and syslog only. NXLog can handle different log sources and formats, so it can be used to implement a secured, centralized, scalable logging system.

It can perform log rewrite, correlation, alerting, and pattern matching, it can execute scheduled jobs, and can perform log rotation. It was designed to be able to fully utilize modern multi-core CPU systems. Its multi-threaded architecture enables input, log processing and output tasks to be executed in parallel. Using an I/O layer it is capable of handling thousands of simultaneous client connections and process log volumes above the 100,000 EPS range.

NXLog does not drop any log messages unless instructed to. It can process input sources in a prioritized order, meaning that a higher priority source will be always processed before others. This can further help avoiding UDP message loss for example. In case of network congestion or other log transmission problems, NXLog can buffer messages on the disk or in memory. Using loadable modules it supports different input sources and log formats, not only limited to syslog but windows event log, audit logs, and custom binary application logs.

With NXLog it is possible to use custom loadable modules similarly to the Apache Web server. In addition to the online log processing mode, it can be used to process logs in batch mode in an offline fashion. NXLog's configuration language, with an Apache style configuration file syntax, enables it to rewrite logs, send alerts or execute any external script based on the specified criteria.

History

Back in 2009 Botond Botyanszki, founder and CEO of NXLog Ltd. used a modified version of msyslog to suit his needs, but when he found a requirement to implement a high performance, scalable, centralized log management solution, there was no such modern logging solution available. There were some alternatives to msyslog with some nice features (e.g. Rsyslog, syslog-ng, etc.), but none of them fit requirements. Most of these were still single threaded, syslog oriented, without native support for MS Windows, and came with an ambiguous configuration syntax and so on.

He decided to develop the tool from scratch, instead of hacking something else. Thus, NXLog was born in 2009 and was a closed source product in the beginning, heavily used in several production deployments. The source code of NXLOG Community Edition was released in November 2011, and has been freely available since.

Design

Most log processing solutions are built around the same concept. The input is read from a source, then the log messages are processed. Finally output is written or sent to a sink in other terminology.

When an event occurs in an application or a device, depending on its configuration, a log message is emitted. This is usually referred to as an "event log" or "log message". These log messages can have different formats and can be transmitted over different protocols depending on the actual implementation.

There is one thing common in all event log messages. All contain important data such as user names, IP addresses, application names, etc. This way an event can be represented as a list of key-value pairs which we call a "field". The name of the field is the key and the field data is the value. In another terminology this meta-data is sometimes referred to as event property or message tag.

The following example illustrates a syslog message:

<30>Nov 21 11:40:27 log4ensics sshd[26459]: Accepted publickey for log4ensics from 192.168.1.1 port 41193 ssh2

The fields extracted from this message are as follows:

AuthMethod publickey
SourceIPAddress 192.168.1.1
AccountName log4ensics
SyslogFacility DAEMON
SyslogSeverity INFO
Severity INFO
EventTime 2009-11-21 11:40:27.0
Hostname log4ensics
ProcessID 26459
SourceName sshd
Message Accepted publickey for log4ensics from 192.168.1.1 port 41193 ssh2

NXLog has a special field$, raw_event. This field is handled by the transport (UDP, TCP, File, etc.) modules to read input into and write output from it. This field is also used later to parse the log message into further fields by various functions, procedures and modules.

Architecture

By utilizing loadable modules, the plugin architecture of NXLog allows it to read data from any kind of input, parse and convert the format of the messages, and then send it to any kind of output. Different input, processor and output modules can be used at the same time to cover all the requirements of the logging environment. The following figure illustrates the flow of log messages using this architecture.

NXLog architecture

The core of NXLog is responsible for parsing the configuration file, monitoring files and sockets, and managing internal events. It has an event based architecture, all modules can dispatch events to the core. The NXLog core will take care of the event and will optionally pass it to a module for processing. NXLog is a multi-threaded application, the main thread is responsible for monitoring files and sockets. These are added to the core by the different input and output modules. There is a dedicated thread handling internal events. It sleeps until the next event is to be processed then wakes up and dispatches the event to a worker thread. NXLog implements a worker thread-pool model. Worker threads receive an event which must be processed immediately. This way the NXLog core can centrally control all events and the order of their execution making prioritized processing possible. Modules which handle sockets or files are written to use non-blocking I/O in order to ensure that the worker threads never block. The files and sockets monitored by the main thread also dispatch events which are then delegated to the workers. Each event belonging to the same module is executed in sequential order, not concurrently. This ensures that message order is kept and prevents concurrency issues in modules. Yet the modules (worker threads) run concurrently, thus the global log processing flow is greatly parallelized.

When an input module receives data, it creates an internal representation of the log message which is basically a structure containing the raw event data and any optional fields. This log message is then pushed to the queue of the next module in the route and an internal event is generated to signal the availability of the data. The next module after the input module in a route, can be either a processor module or an output module. Actually an input or output module can also process data through built-in code or using the NXLog language execution framework. The only difference is that processor modules are run in another worker thread, thus parallelizing log processing even more. Considering that processor modules can also be chained, this can efficiently distribute work among multiple CPUs or CPU cores in the system.

Distributions

• NXLog Community Edition is a proprietary log management tool available at no cost. It is available for various platforms including Windows and Linux. The NXLog Community Edition can be used both as a log collector agent and as a log server. Summary of features:
  • Multi-platform - support for Linux, IBM AIX, Solaris, HP-UX, BSD, Android and Microsoft Windows (from XP through 2012)
  • Modular architecture through dynamically loadable plugins
  • Scalable, high-performance I/O - collect messages at blazing speeds (can achieve above 500k EPS)
  • Message buffering and prioritization - no lost or dropped messages
  • Simple configuration format with a powerful language similar to Perl
  • Scheduled tasks and built-in log rotation
  • Support for different formats such as Syslog, CSV, GELF, JSON, XML, Windows EventLog and even custom formats
  • Offline processing mode for post processing, conversion or transfer
  • Event classification and pattern matching
  • Log message rewrite, conversion between different formats
  • Event correlation
  • Secure network transport over SSL
  • Internationalization for supporting different character sets and on the fly auto-detection of encoding
• NXLog Enterprise Edition: In addition to the features of NXLog Community Edition such as the flexibility, low memory footprint and high performance, the NXLog Enterprise Edition provides several enhancements which can be useful in enterprise deployments. These features are enhanced reliability, support for additional log sources such as CheckPoint LEA and SNMP events, agent management and monitoring capabilities, remote Windows EventLog collection, ODBC input and output modules to read/write data into databases (e.g. Microsoft SQL Server) and many more. Also, NXLog Enterprise Edition agents can be centrally managed by NXLog Manager. Managing and monitoring a large number of log collector agents can be tough, especially if you have a lot of servers in different roles with multiple teams in charge. NXLog Manager can remotely manage and monitor NXLog Enterprise Edition instances using a centralized web-based management console.

License

NXLog Community Edition is licensed under the NXLOG PUBLIC LICENSE v1.0.

External links

• NXLog official website
• NXLog Community Edition download site