NXLog

NXLog

Developer(s)	Botond Botyanszki
Initial release	October 2011 (2011-10)
Stable release	v3.1.1930
Repository	gitlab.com/nxlog-public/nxlog-ce
Written in	C
Operating system	Linux (CentOS, RHEL, Ubuntu (operating system), Debian), macOS, Windows, Android (operating system)
Type	Logging Tool
License	Proprietary under NXLOG PUBLIC LICENSE v1.0
Website	nxlog.co

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.

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 contains 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. Summary of features:
  • Multi-platform - support for Unix/Linux, MS Windows
  • Modular architecture through dynamically loadable plugins
  • Scalable, high-performance I/O - collect messages above 100k events per second from thousands of sources
  • 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, Windows EventLog, CheckPoint LEA or even custom formats
  • Remote administration and statistics with a WebService API for easier integration to external monitoring tools
  • Offline processing mode for post processing, conversion or transfer
  • Real-time event correlation and classification
  • Log message rewrite, conversion between different formats
  • Secure SSL transport, message integrity and timestamping support
  • Internationalization for supporting different character sets and on the fly auto-detection of encoding.
• 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.

Features

Feature	NXLog Community Edition	NXLog Enterprise Edition
Scalable, multi-threaded and high-performance architecture
Multi platform
Modular architecture
Support for different message formats
Client-server mode
Log message sources and destinations
Secure operation, secured messages
Lightweight
Message buffering and prioritization
No message loss
Simple configuration
Built-in config language
Scheduled tasks and built-in log rotation
Event classification and pattern matching
Offline processing mode for post processing, conversion or transfer
Internationalization support
Real-time event correlation and classification
Remote administration and statistics

License

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

External links

• NXLog official website
• NXLog Community Edition download site