NXLog is a multi-platform log collection and centralization tool that offers log processing features, including log enrichment (parsing, filtering, and conversion) and log forwarding. In concept NXLog is similar to syslog-ng or Rsyslog but it is not limited to UNIX and syslog only. It supports all major operating systems such as Windows, macOS, IBM AIX, etc., being compatible with virtually any SIEM, log analytics suites and many other platforms. NXLog can handle different log sources and formats, so it can be used to implement a secured, centralized, scalable logging system. "NXLog Community Edition" is proprietary and can be downloaded free of charge with no license costs or limitations.
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 make sure data security in transit.
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 the developer of NXlog was using 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 qualified. Most of these were still single threaded, syslog oriented, without native support for MS Windows, and came with an ambiguous configuration syntax, ugly source-code and so on.
He decided to design and write NXLog 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 will try to use the Common Event Expression standard for the field names once the standard is stable.
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.
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.
License.
NXLog Community Edition is licensed under the NXLOG PUBLIC LICENSE v1.0.
References.
 ;templatestyles src="Reflist/styles.css" / ;