Table of Contents

Introduction

1. About This Guide

This Guide is designed to give you all the information and skills you need to successfully deploy and configure NXLog in your organization. The following chapters provide detailed information about NXLog, including features, architecture, configuration, and integration with other software and devices. An NXLog Enterprise Edition Reference Manual is included, as well as documentation for the NXLog Manager.

NXLog is available in two versions, the Community Edition and the Enterprise Edition. Features that are unique to the Enterprise Edition are noted as such, except in the Reference Manual (the Community Edition Reference Manual is published separately). For more details about the functionality provided by the two NXLog editions, see the following chapters (in particular, About NXLog and Available Modules).

Warning
Though most of the content applies to all versions of NXLog Community Edition and NXLog Enterprise Edition, this Guide was written specifically for NXLog Enterprise Edition version 4.1.4181. Some features covered by this book may not be available in earlier versions of NXLog, and earlier versions of NXLog may behave differently than documented here.

2. About NXLog

Modern IT infrastructure produces large volumes of event logging data. In a single organization, hundreds or thousands of different devices, applications, and appliances generate event log messages. These messages require many log processing tasks, including filtration, classification, correlation, forwarding, and storage. In most organizations these requirements are met with a collection of scripts and programs, each with its custom format and configuration. NXLog provides a single, high-performance, multi-platform product for solving all of these tasks and achieving consistent results.

At NXLog’s inception, there were various logging solutions available, but none with the required features. Most were single threaded and Syslog-oriented, without native support for Windows. Work on NXLog began with the goal of building a modern logger with a multi-threaded design, a clear configuration syntax, multi-platform support, and clean source code. NXLog was born in 2009 as a closed source product heavily used in several production deployments. The source code of NXLog Community Edition was released in November 2011.

NXLog can process event logs from thousands of different sources with volumes over 100,000 events per second. It can accept event logs over TCP, TLS/SSL, and UDP; from files and databases; and in Syslog, Windows EventLog, and JSON formats. NXLog can also perform advanced processing on log messages, such as rewriting, correlating, alerting, pattern matching, scheduling, and log file rotation. It supports prioritized processing of certain log messages, and can buffer messages on disk or in memory to work around problems with input latency or network congestion. After processing, NXLog can store or forward event logs in any of many supported formats. Inputs, outputs, log formats, and complex processing are implemented with a modular architecture and a powerful configuration language.

2.1. NXLog Features

This section gives an overview of some of the key advantages of NXLog over alternative systems.

Multi-platform deployment

Installer packages are provided for multiple platforms, including Linux, Windows, and Android. You can use NXLog across your infrastructure, without resorting to different tools for different platforms.

Client or server operation

Depending on the configuration, NXLog will run as a server, a client, or a combination of both. You have the freedom to choose the deployment architecture that best meets your needs. For example, NXLog can collect local log data and forward it, relay data without storing it locally, or save incoming log data to disk.

Many input and output types and formats

NXLog can accept data from many different sources, convert the data internally, and output it to other destinations. You can use NXLog as a single tool to process all of the different types of logs in your organization. For example, logs can be collected from files, databases, Unix domain sockets, network connections, and other sources. BSD Syslog, IETF Syslog, the Snare Agent format, Windows EventLog, JSON, and other formats are supported. NXLog can likely be configured to read or write logs in your custom application format, using the NXLog language and provided extension modules.

High performance, scalable architecture

With an event-based architecture for processing tasks in parallel, non-blocking input and output where possible, and a worker thread pool for incoming log messages, NXLog is designed for high performance on modern multi-core and multi-processor systems. The input/output readiness notifications provided by most operating systems are used to efficiently handle large numbers of open files and network connections.

Security

NXLog provides features throughout the application to maintain the security of your log data and systems. The core can be configured to run as an unprivileged user, and special privileges (such as binding to ports below 1024) are accessed through Linux capabilities rather than requiring the application to run as root. TLS/SSL is supported for encrypted, authenticated communications and to prevent data interception or alteration during transmission.

Modular architecture

NXLog has a lightweight modular architecture, providing a reduced memory footprint and increased flexibility for different uses. The core handles files, events, and sockets, and provides the configuration language; modules provide the input, output, and processing capabilities. Because modules use a common API, you can write new modules to extend the features of NXLog.

Message buffering

Log messages can be buffered in memory or on disk. This increases reliability by holding messages in a temporary cache when a network connectivity issue or dropout occurs. Conditional buffering can be configured by using the NXLog language to define relevant conditions. For example, UDP messages may arrive faster than they can be processed, and NXLog can buffer the messages to disk for processing when the system is under less load. Conditional buffering can be used to explicitly buffer log messages during certain hours of the day or when the system load is high.

Prioritized processing

NXLog can be configured to separate high-priority log processing from low-priority log processing, ensuring that it processes the most important data first. When the system is experiencing high load, NXLog will avoid dropping important incoming messages. For example, incoming UDP messages can be prioritized to prevent dropped logs if a high volume of TCP messages overloads the system.

Message durability

Built-in flow control ensures that a blocked output does not cause dropped log messages when buffers are full. In combination with the previously mentioned parallel processing, buffering, and prioritization, the possibility of message loss is greatly reduced.

Familiar and powerful configuration syntax

NXLog uses an Apache-style configuration syntax that is easy to read and can be parsed or generated with scripts. The NXLog language supports advanced scripting and processing capabilities that are usually only found in full-fledged scripting languages. The syntax is similar to Perl, so users familiar with that language can learn it easily. It supports polymorphic functions and procedures and regular expressions with captured sub-strings. Modules can register additional functions and procedures to further extend the capabilities of the language.

Scheduled tasks and log rotation

NXLog includes a scheduler service. A task can be scheduled from any module without requiring an external tool such as Cron. Log files can be rotated automatically, on a time-based schedule or according to file size. The file reader and writer modules in NXLog can detect when an input or output file moves or changes its name, and re-open the file automatically.

Advanced message processing

NXLog can perform advanced processing actions on log messages, in addition to the core features already mentioned. By using additional modules, NXLog can solve many related tasks such as message classification, event correlation, pattern matching, message filtering, message rewriting, and conditional alerting. You can use a single tool for all log processing functionality.

Offline processing

Sometimes log messages need to be processed in batches for conversion, filtering, or analysis. NXLog provides an offline mode in which it processes all input and then exits. Because NXLog does not assume that the event time and processing time are identical, time-based correlation features can be used even during offline log processing.

International character and encoding support

NXLog supports explicit character set conversion and automatic character set detection. Log messages received in different character sets can be automatically normalized to a common standard, allowing messages to be compared across different sources.

2.2. Enterprise Edition Features

While the NXLog Community Edition provides all the flexibility and performance of the NXLog engine, the NXLog Enterprise Edition provides additional enhancements, including modules and core features, as well as regular hot-fixes and updates. The Enterprise Edition provides the following enhancements.

Additional platform support

In addition to Linux, Windows, and Android, installer packages are provided for the BSDs and the major variants of Unix (AIX, Solaris, and macOS).

Signed installer packages

Installer packages are certificate signed to ensure that the binaries are not corrupted or compromised.

On-the-wire compression

Log data can be transferred in compressed batches with the im_batchcompress and om_batchcompress input/output modules. This can help in limited bandwidth scenarios.

UDP source IP address spoofing

Some SIEM and log collection systems use the IP address of the UDP Syslog packet sent by the client. When used as a server or relay, the om_udpspoof output module can be configured to retain the original IP address of the sender.

Better control over SSL and TLS

Due to vulnerabilities discovered in the SSL protocols, some protocols may need to be disabled. The various SSL/TLS networking modules in NXLog Enterprise Edition can be configured to allow only specific protocols via the SSLProtocol directive. On Windows, NXLog Enterprise Edition can utilize TLSv1.2 while NXLog Community Edition supports TLSv1.0 only.

ODBC input and output

The ODBC input and output modules, im_odbc and om_odbc, allow log data to be read from or inserted into any ODBC compliant database. The primary purpose of the im_odbc module is native Windows MSSQL support to enable log collection from Windows applications that write logs to MSSQL. The om_odbc output module can be used to insert data into an ODBC database. These modules are available on Windows as well as Linux.

Support for trusted timestamping

The Time-Stamp Protocol, defined by RFC 3161, uses a Time-Stamp Authority to cryptographically sign each message. This signature can be used later to prove that the message existed at that time and has not been modified since. The pm_ts processor module provides support for the Time-Stamp Protocol.

Message integrity protection

The pm_hmac and pm_hmac_check processor modules provide chained HMAC-based integrity protection for tamper-proof logs. The pm_hmac module signs outgoing messages while the pm_hmac_check module verifies incoming messages.

Remote management

A dedicated xm_soapadmin extension module allows NXLog agents to be managed remotely over a secure SOAP/SSL connection or integrated with existing monitoring and management tools. The configuration, correlation rules, patterns, and certificates can all be updated remotely from the NXLog Manager web interface or from scripts. In addition, the NXLog agent and the individual modules can be stopped/started and log collection statistics can be queried for real-time statistics.

Crash recovery

Additional functionality is provided to guarantee a clean recovery in the case of a system crash, ensuring that no messages are lost or duplicated.

Event correlation

The pm_evcorr processor module can efficiently solve complex event correlation tasks, with capabilities similar to what the open-source SEC tool provides.

HTTP(S) protocol support

RESTful services are becoming increasingly popular, even for logging. The im_http and om_http input and output modules make it possible to send or receive log message data over HTTP or HTTPS.

File integrity and registry monitoring

Several compliance standards mandate file integrity monitoring. With the im_fim input module, NXLog Enterprise Edition can be used to detect modifications to files or directories. This module is available on Windows as well as Linux. The im_regmon module provides monitoring of the Windows Registry.

Structured data formats

The xm_xml extension module can parse nested XML and data stored in XML attributes. Parsing of nested JSON has also been implemented in xm_json, and UTF-8 validation can be enforced to avoid parser failures caused by invalid UTF-8 from other tools.

Native W3C parser

The W3C format is widely used in various Microsoft products and perhaps IIS is the most well-known producer. Parsing of W3C is possible with the xm_csv extension module, but that requires defining the fields in the configuration and adjustment when the IIS configuration is changed. The xm_w3c extension module can automatically parse the logs using the field information stored in the headers. It also supports automatic parsing of the data format produced by BRO.

More support for SIEM products

The xm_cef and xm_leef modules provide parsing and generation of CEF and LEEF formatted data. CEF (Common Event Format) was introduced by HP ArcSight and LEEF (Log Event Extended Format) is used by IBM Security QRadar.

Simplified data processing configuration

Two extension modules help simplify the configuration. The xm_rewrite module allows fields to be renamed, kept (whitelisted), or deleted (blacklisted). It also supports the Exec directive so log processing logic can be localized and to avoid duplicated statements. The xm_filelist module provides two functions, contains() and matches(), which can be invoked to check whether a string is present in a text file. This can be a username, IP address, or similar. The files are cached in memory and any changes are automatically picked up without the need to reload NXLog.

Custom input and output modules in Perl

Perl has a vast number of libraries that can be used to easily implement integration with various APIs, formats, and protocols. The im_perl and om_perl input and output modules make it possible to utilize Perl to collect and output data without the need to run the code as an external script.

Name resolution

The xm_resolver extension module provides cached DNS lookup functions for translating between IP addresses and host names. User and group names can also be mapped to/from user and group ids.

Elasticsearch integration

The om_elasticsearch output module allows log data to be loaded directly into an Elasticsearch server without requiring Logstash.

Checkpoint LEA input

The im_checkpoint input module enables the remote collection of Checkpoint firewall logs over the OPSEC/LEA protocol. This feature is only available in the Linux version.

Remote Windows EventLog collection

The im_wmi module allows remote collection of Windows EventLog over the WMI protocol on Linux hosts without the need to install an agent on the Windows target. This module is only available in the Linux version. In addition, the im_msvistalog module can query and collect Windows EventLog remotely over MSRPC on Windows Vista and later versions.

Redis Support

Redis is often used as an intermediate queue for log data. Two native modules, im_redis and om_redis, are available to push data to and pull data from Redis servers.

SNMP input

The xm_snmp extension module can be used to parse SNMP traps. The traps can then be handled like regular log messages: converted to Syslog, stored, forwarded, etc.

Multi-platform support for Windows Event Forwarding

The im_wseventing input module can be used to collect forwarded events from Windows hosts. The Windows clients can be configured from Group Policy to send Windows EventLog using Windows Event Forwarding. While NXLog Enterprise Edition can collect Windows EventLog remotely over WMI and MSRPC, this module provides improved security for collecting from Windows machines in agent-less mode, with support for both Kerberos and HTTPS data transfer. The im_wseventing module is platform independent and available on Linux as well as Windows.

HDFS output

The om_webhdfs output module is available to support the Hadoop ecosystem.

Windows Performance Counters

The im_winperfcount input module can collect metrics from Windows Performance Counters such as CPU, disk, and memory statistics.

Reading Windows EventLog files directly

The im_msvistalog module can read .evt, .evtx, and .etl EventLog files directly; this is particularly useful for forensics purposes.

Additional Windows EventLog data

The im_msvistalog module retrieves the EventData and UserData parts which can contain important data in some log sources. In addition, SID values in the EventLog Message can be resolved to account names to produce the same output that EventViewer gives.

Netflow support

The xm_netflow extension module can parse Netflow packets received over UDP. It supports Netflow v1, v5, v7, v9, and IPFIX.

ZeroMQ support

ZeroMQ is a popular high performance messaging library. The im_zmq and om_zmq modules provide input and output support for the ZeroMQ protocol.

Regular hot fixes

Unlike NXLog Community Edition which is a volunteer effort, NXLog Enterprise Edition receives regular hot fixes and enhancements.

2.3. What NXLog is Not

NXLog provides a broad range of features for collecting, processing, forwarding, and storing log data. However, NXLog is not a SIEM product and does not provide:

  • a graphical interface (or "dashboard") for searching logs and displaying reports,

  • vulnerability detection or integration with external threat data,

  • automatic analysis and correlation algorithms, or

  • pre-configured compliance and retention policies.

NXLog does provide processing features that can be used to set up analysis, correlation, retention, and alerting; NXLog can be integrated with many other products to provide a complete solution for aggregation, analysis, and storage of log data.

3. System Architecture

NXLog’s architecture utilizes loadable modules that provide input, output, and parsing functionality. Different modules can be used together to create log data routes that meet the requirements of the logging environment. Each route accepts log messages in a particular format, processes or transforms them, and then outputs them in one of the supported formats. Routes work in parallel, so processing of different types of log data can happen at the same time.

The NXLog core is responsible for parsing the configuration file, monitoring files and sockets, managing internal events, and coordinating log data queues and modules according to the configured routes. Files and sockets are added to the core by the various modules, and the core delegates events when necessary. Modules also dispatch log events to the core, which passes each one to the appropriate module. In this way, the core can centrally control all events and the order of their execution making prioritized processing possible. Each event belonging to the same module instance is executed in sequential order, not concurrently. This ensures that message order is kept and allows modules to be written without concern for concurrency. Yet because the modules run concurrently, the global log processing flow remains parallelized.

3.1. Event Records and Fields

A log message is an event, and the data relating to that event is collectively an event record. When NXLog processes an event record, it stores the various values in fields. The following sections describe event records and fields in the context of NXLog processing.

3.1.1. Event Records

There are many kinds of event records. A few important ones are listed here.

  • The most common event record is a single line. Thus the default is LineBased for the InputType and OutputType directives.

  • It is also common for an event record to use a single UDP datagram. NXLog can send and receive UDP events with the im_udp and om_udp modules.

  • Some event records are generated using multiple lines. These can be joined into a single event record with the xm_multiline module.

  • Event records may be stored in a database. Each row in the database represents an event. In this case the im_odbc and om_odbc modules can be used.

  • It is common for structured event records to be formatted in CSV, JSON, or XML formats. The xm_csv, xm_json, and xm_xml modules provide functions and procedures for parsing these.

  • NXLog provides a Binary InputType and OutputType for use when compatibility with other logging software is not required. This format preserves parsed fields and their types.

In NXLog, each event record consists of the raw event data (in a field named $raw_event) and additional fields generated during processing and parsing.

3.1.2. Fields

All event log messages contain important data such as user names, IP addresses, and application names. Traditionally, these logs have been generated as free form text messages prepended by basic metadata like the time of the event and a severity value.

While this format is easy for humans to read, it is difficult to perform log analysis and filtering on thousands of free-form logs. In contrast, structured logging provides means for matching messages based on key-value pairs. With structured logging, an event is represented as a list of key-value pairs. The name of the field is the key and the field data is the value. NXLog’s core design embraces structured logging. Using various features provided by NXLog, a message can be parsed into a list of key-value pairs for processing or as part of the message sent to the destination.

When a message is received by NXLog, it creates an internal representation of the log message using fields. Each field is typed and represents a particular attribute of the message. These fields passes through the log route, and are available in each successive module in the chain, until the log message has been sent to its destination.

  1. The special $raw_event field contains the raw data received by the input module. Most input and output modules only transfer $raw_event by default.

  2. The core adds a few additional fields by default. This includes, for example, the $EventReceivedTime field which is set to the time when the event is received.

  3. The input module may add other fields. For example, the im_udp module adds a $MessageSourceAddress field.

  4. Some input modules, such as im_msvistalog and im_odbc, map fields from the source directly to fields in the NXLog event record.

  5. Parsers such as the parse_syslog() procedure will add more fields.

  6. Custom fields can be added by using the NXLog language and an Exec directive.

  7. The NXLog language or the pm_pattern module can be used to set fields using regular expressions. See Extracting Data.

When the configured output module receives the log message, in most cases it will use the contents of the $raw_event field only. If the event’s fields have been modified, it is therefore important to update $raw_event from the other fields. This can be done with the NXLog language, perhaps using a procedure like to_syslog_bsd().

A field is denoted and referenced in the configuration by a preceding dollar sign ($). See the Fields section in the Reference Manual for more information.

Example 1. Sample Syslog Event as Processed by NXLog

This example shows a Syslog event and its corresponding fields as processed by NXLog.

Syslog Message
<38>Nov 21 11:40:27 myhost sshd[8459]: Accepted publickey for john from 192.168.1.22 port 41193 ssh2

The below configuration parses the event with the parse_syslog() procedure, which adds a set of fields to the event record.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
<Extension _syslog>
    Module  xm_syslog
</Extension>

<Input udp>
    Module  im_udp
    Host    0.0.0.0
    Port    514
    Exec    parse_syslog();
</Input>

When the above message is parsed by parse_syslog(), the following fields are added to the event record.

Table 1. Syslog Fields as Parsed by parse_syslog()
Field Value

$Message

Accepted publickey for john from 192.168.1.22 port 41193 ssh2

$SyslogSeverityValue

6

$SyslogSeverity

INFO

$SeverityValue

2

$Severity

INFO

$SyslogFacilityValue

4

$SyslogFacility

AUTH

$EventTime

2016-11-21 11:40:27

$Hostname

myhost

$SourceName

sshd

$ProcessID

8459

See Extracting Data for more examples.

3.2. Modules and Routes

NXLog uses loadable modules (plugins) that extend its capabilities to accept, process, and output log messages. The log processing path is made of module instances connected by routes. The following sections explain this in greater detail.

3.2.1. Modules

A module is a foo.so or foo.dll that can be loaded by the NXLog core. The various modules provide different capabilities to NXLog. A module instance is part of the configured data flow. For example, the configuration block for an input module instance begins with <Input instancename>. See the Instance examples below. A single module can be used in multiple instances. With regard to configuration, a module instance is often referred to as simply a module.

There are four types of modules.

Input

Functionality for accepting or retrieving log data is provided by input modules. An input module instance is a source or producer. It accepts log data from a source and produces event records.

An Input Module Instance
1
2
3
4
<Input foo_in>
    Module im_foo
    ...
</Input>
Output

Output modules provide functionality for sending log data to a local or remote destination. An output module instance is a sink, destination, or consumer. It is responsible for consuming event records produced by one or more input module instances.

An Output Module Instance
1
2
3
4
<Output foo_out>
    Module om_foo
    ...
</Output>
Extension

The NXLog language can be extended with extension modules. Extension module instances do not process log data directly. Instead, they provide features (usually functions and procedures) that can be used from other parts of the processing pipeline. Many extension module instances require no directives other than the Module directive.

Example 2. Using an Extension Module

In this example, the xm_syslog module is loaded by the Extension block. This module provides the parse_syslog() procedure, in addition to other functions and procedures. In the following Input instance, the Exec directive calls parse_syslog() to parse the Syslog-formatted event.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
<Extension _syslog>
    Module  xm_syslog
</Extension>

<Input in>
    Module  im_file
    File    '/var/log/messages'
    Exec    parse_syslog();
</Input>
Processor

Processor modules offer features for transforming, filtering, or converting log messages. One or more processor module instances can be used in a route between input and output module instances.

A Processor Module Instance
1
2
3
4
<Processor foo>
    Module pm_foo
    ...
</Processor>
Note
Many processing functions and procedures are available through the NXLog language and can be accessed through the Exec directive in an Input or Output block without using a separate processor module instance. However, a separate processor module (pm_null, perhaps) will use a separate worker thread, providing additional processing parallelization.

For a list of available modules, see Available Modules.

3.2.2. Routes

Most log processing solutions are built around the same concept. The input is read from a source, log messages are processed, and then log data is written to a destination. In NXLog, this path is called a "route" and is configured with a Route block.

Routes are made up of one or more inputs, zero or more processors, and one or more outputs.

Example 3. A Simple Route

This route accepts input with the in module and sends it to the out module. This is the simplest functional route.

route1
nxlog.conf
1
2
3
<Route r1>
    Path    in => out
</Route>
Example 4. A Route With a Processor

This route extends the previous example by adding an intermediate processing module proc.

route2
nxlog.conf
1
2
3
<Route r2>
    Path    in => proc => out
</Route>
Example 5. Advanced Route With Multiple Input/Output Modules

This route uses two input modules and two output modules. Input from in1 and in2 will be combined and sent to both out1 and out2.

route3
nxlog.conf
1
2
3
<Route r3>
    Path    in1, in2 => out1, out2
</Route>
Example 6. Branching: Two Routes Using One Input Module

A module can be used by multiple routes simultaneously, as in this example. The in1 module instance is only declared once, but is used by both routes.

branching
nxlog.conf
1
2
3
4
5
6
7
<Route r1>
    Path    in => out1
</Route>

<Route r2>
    Path    in => proc => out2
</Route>

3.3. Log Processing Modes

NXLog can process logs in three modes. Each mode has different characteristics, and you can use any combination of modes for your overall logging infrastructure.

3.3.1. Agent-Based Collection

With agent-based collection, NXLog runs as an agent on the system that is generating the log data. It collects the log data and sends it to another NXLog instance over the network.

Note
We recommend agent-based log collection for most use cases. In particular, we recommend this mode if you need strong security and reliability or need to transform log data before it leaves the system on which it was generated.

Agent-based log collection offers several important advantages over agent-less collection.

  • Log data can be collected from more sources. For example, you can collect logs directly from files, instead of relying on a logging process to send log data across the network.

  • NXLog’s processing features are available. You can filter, normalize, and rewrite log data before sending it to a destination, whether a NXLog instance or a log aggregation system. This includes the ability to send structured log data, such as JSON and key-value pairs.

  • You have full control over the transfer of the log data. Messages can be sent using a variety of protocols, including over TLS/SSL encrypted connections for security. Log data can be sent in compressed batches and can be buffered if necessary.

  • Log collection in this mode is more reliable. NXLog includes delivery guarantees and flow control systems that make sure your log data gets to its destination. You can monitor the health of the NXLog agent to check that it is operating correctly.

Although agent-based collection has many compelling advantages, it is not well suited to some use cases.

  • Many network and embedded systems, such as routers and firewalls, do not support installing third-party software. In this case it would not be possible to install the NXLog agent.

  • Installing the NXLog agent on each system in a large-scale deployment may not be practical compared to reading from the existing logging daemon on each system.

3.3.2. Agent-Less Collection

With this mode of log collection, a server or device sends log data to an NXLog instance over the network, using its native protocols. NXLog collects and processes the information that it receives.

Note
We recommend agent-less log collection in cases where agent-based log collection is not feasible, for example from legacy or embedded systems that do not support installing the NXLog agent.

Agent-less log collection has the following advantages.

  • It is not necessary to install an NXLog agent application on the target system to collect log data from it.

  • Generally, a device or system requires only minimal configuration to send log data over the network to an NXLog instance in its native format.

Agent-less log collection has some disadvantages that you should consider before deploying it.

  • Agent-less log collection may provide lower performance than agent-based collection. On Windows systems, the Windows Management Instrumentation process can consume more system resources than the NXLog agent.

  • Reliability is also a potential issue. Since most Syslog log forwarders use UDP to transfer log data, some data could be lost if the server restarts or becomes unreachable over the network. Unlike agent-based log collection, you often cannot monitor the health of the logging source.

  • The security of data transferred may be lower when using agent-less collection, since most Syslog sources transfer data over unencrypted UDP.

Agent-less collection is commonly used with the following protocols.

3.3.3. Offline Log Processing

While the other modes process log data in real-time, NXLog can also be used to perform batch log processing. This is provided by the nxlog-processor(8) tool, which is similar to the NXLog daemon and uses the same configuration file. However, it runs in the foreground and exits after all input log data has been processed.

Common input sources are files and databases. This tool is useful for log processing tasks such as:

  • loading a group of files into a database,

  • converting between different formats,

  • testing patterns,

  • doing offline event correlation, or

  • checking HMAC message integrity.

4. Available Modules

The following modules are provided with NXLog. Modules which are only available in NXLog Enterprise Edition are noted.

4.1. Extension Modules

The following extension (xm_*) modules are available.

Table 2. Available Extension Modules
Module Description Platforms

Remote Management (xm_admin)

Adds secure remote administration capabilities to NXLog using SOAP or JSON over HTTP/HTTPS.

All (Enterprise Edition only)

AIX Auditing (xm_aixaudit)

Parses AIX audit events that have been written to file.

AIX (Enterprise Edition only)

Apple System Logs (xm_asl)

Parses events in the Apple System Log (ASL) format.

All (Enterprise Edition only)

Basic Security Module Auditing (xm_bsm)

Supports parsing of events written to file in Sun’s Basic Security Module (BSM) Auditing binary format.

FreeBSD, Solaris, macOS (Enterprise Edition only)

CEF (xm_cef)

Provides functions for generating and parsing data in the Common Event Format (CEF) used by HP ArcSight™ products.

All (Enterprise Edition only)

Character Set Conversion (xm_charconv)

Provides functions and procedures to help you convert strings between different character sets (code pages).

All

CSV (xm_csv)

Provides functions and procedures to help you process data formatted as comma-separated values (CSV), and to convert CSV data into fields.

All

External Program Execution (xm_exec)

Passes log data through a custom external program for processing, either synchronously or asynchronously.

All

Filelist (xm_filelist)

Implements file-based blacklisting or whitelisting.

All (Enterprise Edition only)

File Operations (xm_fileop)

Provides functions and procedures to manipulate files.

All

GELF (xm_gelf)

Provides an output writer function which can be used to generate output in Graylog Extended Log Format (GELF) for Graylog2 or GELF compliant tools.

All

Grok Patterns (xm_grok)

Provides support for parsing events with Grok patterns.

All (Enterprise Edition only)

JSON (xm_json)

Provides functions and procedures to process data that is formatted as JSON (Java Serialized Object Notation).

All

Key-Value Pairs (xm_kvp)

Provides functions and procedures to parse and generate data that is formatted as key-value pairs.

All

LEEF (xm_leef)

Provides functions for parsing and generating data in the Log Event Extended Format (LEEF), which is used by IBM Security QRadar products.

All (Enterprise Edition only)

DNS Server Log Parsing (xm_msdns)

Parses Microsoft Windows DNS Server logs

All (Enterprise Edition only)

Multi-Line Message Parser (xm_multiline)

Parses log entries that span multiple lines.

All

NetFlow (xm_netflow)

Provides a parser for NetFlow payload collected over UDP.

All (Enterprise Edition only)

NPS (xm_nps)

Provides functions and procedures for processing data in NPS Database Format stored in files by Microsoft Radius services.

All (Enterprise Edition only)

Pattern Matcher (xm_pattern)

Applies advanced pattern matching logic to log data, which can give greater performance than normal regular expression statements in Exec directives. Replaces pm_pattern.

All (Enterprise Edition only)

Perl (xm_perl)

Processes log data using Perl.

Linux

Python (xm_python)

Processes log data using Python.

Linux (Enterprise Edition only)

Resolver (xm_resolver)

Resolves key identifiers that appear in log messages into more meaningful equivalents, including IP addresses to host names, and group/user IDs to friendly names.

All (Enterprise Edition only)

Rewrite (xm_rewrite)

Transforms event records by modifying or discarding specific fields.

All (Enterprise Edition only)

Ruby (xm_ruby)

Processes log data using Ruby.

Linux (Enterprise Edition only)

SNMP Traps (xm_snmp)

Parses SNMPv1 and SNMPv2c trap messages.

All (Enterprise Edition only)

Remote Management (xm_soapadmin)

Adds secure remote administration capabilities to NXLog using SOAP (web services) over HTTP/HTTPS.

All (Enterprise Edition only)

Syslog (xm_syslog)

Provides helpers that let you parse and output the BSD Syslog protocol as defined by RFC 3164.

All

W3C (xm_w3c)

Parses data in the W3C Extended Log File Format, the BRO format, and Microsoft Exchange Message Tracking logs.

All (Enterprise Edition only)

WTMP (xm_wtmp)

Provides a parser function to process binary wtmp files.

Linux

XML (xm_xml)

Provides functions and procedures to process data that is formatted as XML.

All

4.2. Input Modules

The following input (im_*) modules are available.

Table 3. Available Input Modules
Module Description Platforms

BSD/Linux Process Accounting (im_acct)

Collects process accounting logs from a Linux or BSD kernel.

Linux, AIX, *BSD, Solaris, macOS

AIX Auditing (im_aixaudit)

Collects AIX audit events directly from the kernel.

AIX (Enterprise Edition only)

Azure (im_azure)

Collects logs from Microsoft Azure applications.

All (Enterprise Edition only)

Batched Compression over TCP or SSL (im_batchcompress)

Provides a compressed network transport for incoming messages with optional TLS/SSL encryption. Pairs with the om_batchcompress output module.

All (Enterprise Edition only)

Basic Security Module Auditing (im_bsm)

Collects audit events directly from the kernel using Sun’s Basic Security Module (BSM) Auditing API.

FreeBSD, Solaris, macOS (Enterprise Edition only)

CheckPoint OPSEC (im_checkpoint)

Provides support for collecting logs remotely from CheckPoint devices over the OPSEC LEA protocol.

Linux (Enterprise Edition only)

DBI (im_dbi)

Collects log data by reading data from an SQL database using the libdbi library.

Linux

Event Tracing for Windows (ETW) (im_etw)

Implements ETW controller and consumer functionality in order to collect events from the ETW system.

Windows (Enterprise Edition only)

Program (im_exec)

Collects log data by executing a custom external program. The standard output of the command forms the log data.

All

File (im_file)

Collects log data from a file on the local file system.

All

File Integrity Monitoring (im_fim)

Scans files and directories and reports detected changes.

All (Enterprise Edition only)

HTTP(S) (im_http)

Accepts incoming HTTP or HTTPS connections and collects log events from client POST requests.

All (Enterprise Edition only)

Internal (im_internal)

Collect log messages from NXLog.

All

Apache Kafka (im_kafka)

Implements a consumer for collecting from a Kafka cluster.

Linux, Windows (Enterprise Edition only)

Kernel (im_kernel)

Collects log data from the kernel log buffer.

Linux, *BSD, macOS (*BSD and macOS support in Enterprise Edition only)

Linux Audit System (im_linuxaudit)

Configures and collects events from the Linux Audit System

Linux (Enterprise Edition only)

Mark (im_mark)

Outputs 'boilerplate' log data periodically to indicate that the logger is still running.

All

MS EventLog for Windows XP/2000/2003 (im_mseventlog)

Collects EventLog messages on the Windows platform.

Windows

MS EventLog for Windows 2008/Vista and later (im_msvistalog)

Collects EventLog messages on the Windows platform.

Windows

Null (im_null)

Acts as a dummy log input module, which generates no log data. You can use this for testing purposes.

All

OCI (im_oci)

Reads log messages from an Oracle database.

Linux (Enterprise Edition only)

ODBC (im_odbc)

Uses the ODBC API to read log messages from database tables.

Linux, Windows (Enterprise Edition only)

Perl (im_perl)

Captures event data directly into NXLog using Perl code.

Linux (Enterprise Edition only)

Python (im_python)

Captures event data directly into NXLog using Python code.

Linux (Enterprise Edition only)

Redis (im_redis)

Retrieves data stored in a Redis server.

All (Enterprise Edition only)

Ruby (im_ruby)

Captures event data directly into NXLog using Ruby code.

Linux (Enterprise Edition only)

Windows Registry Monitoring (im_regmon)

Periodically scans the Windows registry and generates event records if a change in the monitored registry entries is detected.

Windows (Enterprise Edition only)

TLS/SSL (im_ssl)

Collects log data over a TCP connection that is secured with Transport Layer Security (TLS) or Secure Sockets Layer (SSL).

All

TCP (im_tcp)

Collects log data over a TCP network connection.

All

UDP (im_udp)

Collects log data over a UDP network connection.

All

Unix Domain Socket (im_uds)

Collects log data over a Unix domain socket (typically /dev/log).

Linux, AIX, *BSD, Solaris, macOS

Windows Performance Counters (im_winperfcount)

Periodically retrieves the values of the specified Windows Performance Counters to create an event record.

Windows (Enterprise Edition only)

Windows Management Instrumentation (im_wmi)

Collects EventLog messages from Windows platforms supporting WMI mode.

Linux (Enterprise Edition only)

Windows Event Forwarding (im_wseventing)

Collects EventLog from Windows clients that have Windows Event Forwarding configured.

All (Enterprise Edition only)

ZeroMQ (im_zmq)

Provides incoming message transport over ZeroMQ, a scalable high-throughput messaging library.

Linux (Enterprise Edition only)

4.3. Processor Modules

The following processor (pm_*) modules are available.

Table 4. Available Processor Modules
Module Description Platforms

Blocker (pm_blocker)

Blocks log data from progressing through a route. You can use this module for testing purposes, to simulate when a route is blocked.

All

Buffer (pm_buffer)

Caches messages in an in-memory or disk-based buffer before forwarding it. This module is useful in combination with UDP data inputs.

All

Event Correlator (pm_evcorr)

Perform log actions based on relationships between events.

All

Filter (pm_filter)

Forwards the log data only if the condition specified in the Filter module configuration evaluates to true. This module is obsolete. Use the NXLog language drop() procedure instead.

All

HMAC Message Integrity (pm_hmac)

Protect messages with HMAC cryptographic checksumming.

All (Enterprise Edition only)

HMAC Message Integrity Checker (pm_hmac_check)

Check HMAC cryptographic checksums on messages.

All (Enterprise Edition only)

Message De-Duplicator (pm_norepeat)

Drops messages that are identical to previously-received messages.

All

Null (pm_null)

Acts as a dummy log processing module, which does not transform the log data in any way. You can use this module for testing purposes.

All

Pattern Matcher (pm_pattern)

Applies advanced pattern matching logic to log data, which can give greater performance than normal regular expression statements in Exec directives.

All

Message Format Converter (pm_transformer)

Provides parsers for various log formats, and converters between them. This module is obsolete. Use the xm_syslog, xm_csv, xm_json and xm_xml modules instead.

All

Timestamping (pm_ts)

Add cryptographic Time-Stamp signatures to messages.

All (Enterprise Edition only)

4.4. Output Modules

The following output (om_*) modules are available.

Table 5. Available Output Modules
Module Description Platforms

Batched Compression over TCP or SSL (om_batchcompress)

Provides a compressed network transport for outgoing messages with optional TLS/SSL encryption. Pairs with the im_batchcompress input module.

All (Enterprise Edition only)

Blocker (om_blocker)

Blocks log data from being written. You can use this module for testing purposes, to simulate when a route is blocked.

All

DBI (om_dbi)

Stores log data in an SQL database using the libdbi library.

Linux

Elasticsearch (om_elasticsearch)

Stores logs in an Elasticsearch server.

All (Enterprise Edition only)

EventDB (om_eventdb)

Uses libdrizzle to insert log message data into a MySQL database with a special schema.

Linux (Enterprise Edition only)

Program (om_exec)

Writes log data to the standard input of a custom external program.

All

File (om_file)

Writes log data to a file on the file system.

All

HTTP(s) (om_http)

Send events over HTTP or HTTPS using POST requests.

All

Apache Kafka (om_kafka)

Implements a producer for publishing to a Kafka cluster.

Linux, Windows (Enterprise Edition only)

Null (om_null)

Acts as a dummy log output module. The output is not written or sent anywhere. You can use this module for testing purposes.

All

OCI (om_oci)

Writes log messages to an Oracle database.

Linux (Enterprise Edition only)

ODBC (om_odbc)

Uses the ODBC API to write log messages to database tables.

Linux, Windows (Enterprise Edition only)

Perl (om_perl)

Uses Perl code to handle output log messages from NXLog.

Linux (Enterprise Edition only)

Python (om_python)

Uses Python code to handle output log messages from NXLog.

Linux (Enterprise Edition only)

Redis (om_redis)

Stores log messages in a Redis server.

All (Enterprise Edition only)

Ruby (om_ruby)

Uses Ruby code to handle output log messages from NXLog.

Linux (Enterprise Edition only)

TLS/SSL (om_ssl)

Sends log data over a TCP connection that is secured with Transport Layer Security (TLS) or Secure Sockets Layer (SSL).

All

TCP (om_tcp)

Sends log data over a TCP connection to a remote host.

All

UDP (om_udp)

Sends log data over a UDP connection to a remote host.

All

UDP with IP Spoofing (om_udpspoof)

Sends log data over a UDP connection, and spoofs the source IP address to make packets appear as if they were sent from another host.

All (Enterprise Edition only)

UDS (om_uds)

Sends log data to a Unix domain socket.

Linux, AIX, *BSD, Solaris, macOS

WebHDFS (om_webhdfs)

Stores log data in Hadoop HDFS using the WebHDFS protocol.

All (Enterprise Edition only)

ZeroMQ (om_zmq)

Provides outgoing message transport over ZeroMQ, a scalable high-throughput messaging library.

Linux (Enterprise Edition only)

4.5. Modules by Platform

4.5.2. CentOS 6, RHEL 6

Table 7. Available Modules in nxlog-4.1.4046_RHEL6_x86_64.tar.bz2
Package Input Output Processor Extension

nxlog-4.1.4046-1_rhel6.x86_64.rpm

nxlog-checkpoint-4.1.4046-1_rhel6.x86_64.rpm

nxlog-dbi-4.1.4046-1_rhel6.x86_64.rpm

nxlog-odbc-4.1.4046-1_rhel6.x86_64.rpm

nxlog-perl-4.1.4046-1_rhel6.x86_64.rpm

nxlog-wmi-4.1.4046-1_rhel6.x86_64.rpm

nxlog-wseventing-4.1.4046-1_rhel6.x86_64.rpm

4.5.3. CentOS 7, RHEL 7

Table 8. Available Modules in nxlog-4.1.4046_RHEL7_x86_64.tar.bz2
Package Input Output Processor Extension

nxlog-4.1.4046-1_rhel7.x86_64.rpm

nxlog-checkpoint-4.1.4046-1_rhel7.x86_64.rpm

nxlog-dbi-4.1.4046-1_rhel7.x86_64.rpm

nxlog-kafka-4.1.4046-1_rhel7.x86_64.rpm

nxlog-odbc-4.1.4046-1_rhel7.x86_64.rpm

nxlog-perl-4.1.4046-1_rhel7.x86_64.rpm

nxlog-python-4.1.4046-1_rhel7.x86_64.rpm

nxlog-ruby-4.1.4046-1_rhel7.x86_64.rpm

nxlog-wmi-4.1.4046-1_rhel7.x86_64.rpm

nxlog-wseventing-4.1.4046-1_rhel7.x86_64.rpm

nxlog-zmq-4.1.4046-1_rhel7.x86_64.rpm

4.5.5. Debian Jessie

Table 10. Available Modules in nxlog-4.1.4046_debian-jessie_amd64.tar.bz2
Package Input Output Processor Extension

nxlog_4.1.4046_amd64.deb

nxlog-checkpoint_4.1.4046_amd64.deb

nxlog-dbi_4.1.4046_amd64.deb

nxlog-kafka_4.1.4046_amd64.deb

nxlog-odbc_4.1.4046_amd64.deb

nxlog-perl_4.1.4046_amd64.deb

nxlog-python_4.1.4046_amd64.deb

nxlog-ruby_4.1.4046_amd64.deb

nxlog-wmi_4.1.4046_amd64.deb

nxlog-wseventing_4.1.4046_amd64.deb

nxlog-zmq_4.1.4046_amd64.deb

4.5.6. Debian Stretch

Table 11. Available Modules in nxlog-4.1.4046_debian-stretch_amd64.tar.bz2
Package Input Output Processor Extension

nxlog_4.1.4046_amd64.deb

nxlog-checkpoint_4.1.4046_amd64.deb

nxlog-dbi_4.1.4046_amd64.deb

nxlog-kafka_4.1.4046_amd64.deb

nxlog-odbc_4.1.4046_amd64.deb

nxlog-perl_4.1.4046_amd64.deb

nxlog-python_4.1.4046_amd64.deb

nxlog-ruby_4.1.4046_amd64.deb

nxlog-wseventing_4.1.4046_amd64.deb

nxlog-zmq_4.1.4046_amd64.deb

4.5.17. SLES 12

Table 22. Available Modules in nxlog-4.1.4046_SLES12_x86_64.tar.bz2
Package Input Output Processor Extension

nxlog-4.1.4046-1_sles12.x86_64.rpm

nxlog-checkpoint-4.1.4046-1_sles12.x86_64.rpm

nxlog-dbi-4.1.4046-1_sles12.x86_64.rpm

nxlog-odbc-4.1.4046-1_sles12.x86_64.rpm

nxlog-perl-4.1.4046-1_sles12.x86_64.rpm

nxlog-python-4.1.4046-1_sles12.x86_64.rpm

nxlog-wmi-4.1.4046-1_sles12.x86_64.rpm

nxlog-wseventing-4.1.4046-1_sles12.x86_64.rpm

nxlog-zmq-4.1.4046-1_sles12.x86_64.rpm

4.5.18. SLES 15

Table 23. Available Modules in nxlog-4.1.4046_SLES15_x86_64.tar.bz2
Package Input Output Processor Extension

nxlog-4.1.4046-1_sles15.x86_64.rpm

nxlog-checkpoint-4.1.4046-1_sles15.x86_64.rpm

nxlog-dbi-4.1.4046-1_sles15.x86_64.rpm

nxlog-odbc-4.1.4046-1_sles15.x86_64.rpm

nxlog-perl-4.1.4046-1_sles15.x86_64.rpm

nxlog-python-4.1.4046-1_sles15.x86_64.rpm

nxlog-ruby-4.1.4046-1_sles15.x86_64.rpm

nxlog-wseventing-4.1.4046-1_sles15.x86_64.rpm

nxlog-zmq-4.1.4046-1_sles15.x86_64.rpm

4.5.22. Ubuntu 14.04

Table 27. Available Modules in nxlog-4.1.4046_ubuntu-trusty_amd64.tar.bz2
Package Input Output Processor Extension

nxlog_4.1.4046_amd64.deb

nxlog-checkpoint_4.1.4046_amd64.deb

nxlog-dbi_4.1.4046_amd64.deb

nxlog-kafka_4.1.4046_amd64.deb

nxlog-odbc_4.1.4046_amd64.deb

nxlog-perl_4.1.4046_amd64.deb

nxlog-python_4.1.4046_amd64.deb

nxlog-wmi_4.1.4046_amd64.deb

nxlog-wseventing_4.1.4046_amd64.deb

nxlog-zmq_4.1.4046_amd64.deb

4.5.23. Ubuntu 16.04

Table 28. Available Modules in nxlog-4.1.4046_ubuntu-xenial_amd64.tar.bz2
Package Input Output Processor Extension

nxlog_4.1.4046_amd64.deb

nxlog-checkpoint_4.1.4046_amd64.deb

nxlog-dbi_4.1.4046_amd64.deb

nxlog-kafka_4.1.4046_amd64.deb

nxlog-odbc_4.1.4046_amd64.deb

nxlog-perl_4.1.4046_amd64.deb

nxlog-python_4.1.4046_amd64.deb

nxlog-ruby_4.1.4046_amd64.deb

nxlog-wseventing_4.1.4046_amd64.deb

nxlog-zmq_4.1.4046_amd64.deb

4.5.24. Ubuntu 18.04

Table 29. Available Modules in nxlog-4.1.4046_ubuntu-bionic_amd64.tar.bz2
Package Input Output Processor Extension

nxlog_4.1.4046_amd64.deb

nxlog-checkpoint_4.1.4046_amd64.deb

nxlog-dbi_4.1.4046_amd64.deb

nxlog-kafka_4.1.4046_amd64.deb

nxlog-odbc_4.1.4046_amd64.deb

nxlog-perl_4.1.4046_amd64.deb

nxlog-python_4.1.4046_amd64.deb

nxlog-ruby_4.1.4046_amd64.deb

nxlog-wseventing_4.1.4046_amd64.deb

nxlog-zmq_4.1.4046_amd64.deb

4.6. Modules by Package

Table 30. Input Modules

im_acct

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

im_aixaudit

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1)

im_azure

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

im_batchcompress

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

im_bsm

nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc)

im_checkpoint

nxlog-checkpoint-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-checkpoint-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog-checkpoint_4.1.4046_amd64.deb (Debian Jessie) nxlog-checkpoint_4.1.4046_amd64.deb (Debian Stretch) nxlog-checkpoint_4.1.4046_amd64.deb (Debian Wheezy) nxlog-checkpoint-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-checkpoint-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-checkpoint-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-checkpoint_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog-checkpoint_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog-checkpoint_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog-checkpoint_4.1.4046_amd64.deb (Ubuntu 18.04)

im_dbi

nxlog-dbi-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-dbi-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog-dbi_4.1.4046_amd64.deb (Debian Jessie) nxlog-dbi_4.1.4046_amd64.deb (Debian Stretch) nxlog-dbi_4.1.4046_amd64.deb (Debian Wheezy) nxlog-dbi-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-dbi-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-dbi_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog-dbi_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog-dbi_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog-dbi_4.1.4046_amd64.deb (Ubuntu 18.04)

im_etw

nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano)

im_exec

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

im_file

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

im_fim

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

im_http

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

im_internal

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

im_kafka

nxlog-kafka-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog-kafka_4.1.4046_amd64.deb (Debian Jessie) nxlog-kafka_4.1.4046_amd64.deb (Debian Stretch) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-kafka_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog-kafka_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog-kafka_4.1.4046_amd64.deb (Ubuntu 18.04)

im_kernel

nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

im_linuxaudit

nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

im_mark

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

im_mseventlog

nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano)

im_msvistalog

nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano)

im_null

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

im_odbc

nxlog-odbc-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-odbc-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog-odbc_4.1.4046_amd64.deb (Debian Jessie) nxlog-odbc_4.1.4046_amd64.deb (Debian Stretch) nxlog-odbc_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-odbc-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-odbc-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-odbc-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-odbc_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog-odbc_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog-odbc_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog-odbc_4.1.4046_amd64.deb (Ubuntu 18.04)

im_perl

nxlog-perl-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-perl-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog-perl_4.1.4046_amd64.deb (Debian Jessie) nxlog-perl_4.1.4046_amd64.deb (Debian Stretch) nxlog-perl_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-perl-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-perl-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-perl-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-perl_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog-perl_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog-perl_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog-perl_4.1.4046_amd64.deb (Ubuntu 18.04)

im_python

nxlog-python-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog-python_4.1.4046_amd64.deb (Debian Jessie) nxlog-python_4.1.4046_amd64.deb (Debian Stretch) nxlog-python_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-python-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-python-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-python_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog-python_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog-python_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog-python_4.1.4046_amd64.deb (Ubuntu 18.04)

im_redis

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

im_regmon

nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano)

im_ruby

nxlog-ruby-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog-ruby_4.1.4046_amd64.deb (Debian Jessie) nxlog-ruby_4.1.4046_amd64.deb (Debian Stretch) nxlog-ruby-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-ruby_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog-ruby_4.1.4046_amd64.deb (Ubuntu 18.04)

im_ssl

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

im_tcp

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

im_testgen

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

im_udp

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

im_uds

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

im_winperfcount

nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano)

im_wmi

nxlog-wmi-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-wmi-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog-wmi_4.1.4046_amd64.deb (Debian Jessie) nxlog-wmi_4.1.4046_amd64.deb (Debian Wheezy) nxlog-wmi-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-wmi_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog-wmi_4.1.4046_amd64.deb (Ubuntu 14.04)

im_wseventing

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-wseventing-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-wseventing-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog-wseventing_4.1.4046_amd64.deb (Debian Jessie) nxlog-wseventing_4.1.4046_amd64.deb (Debian Stretch) nxlog-wseventing_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-wseventing-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-wseventing-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-wseventing-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog-wseventing_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog-wseventing_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog-wseventing_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog-wseventing_4.1.4046_amd64.deb (Ubuntu 18.04)

im_zmq

nxlog-zmq-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog-zmq_4.1.4046_amd64.deb (Debian Jessie) nxlog-zmq_4.1.4046_amd64.deb (Debian Stretch) nxlog-zmq-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-zmq-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-zmq_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog-zmq_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog-zmq_4.1.4046_amd64.deb (Ubuntu 18.04)
Table 31. Output Modules

om_batchcompress

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

om_blocker

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

om_dbi

nxlog-dbi-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-dbi-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog-dbi_4.1.4046_amd64.deb (Debian Jessie) nxlog-dbi_4.1.4046_amd64.deb (Debian Stretch) nxlog-dbi_4.1.4046_amd64.deb (Debian Wheezy) nxlog-dbi-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-dbi-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-dbi_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog-dbi_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog-dbi_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog-dbi_4.1.4046_amd64.deb (Ubuntu 18.04)

om_elasticsearch

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

om_eventdb

nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

om_exec

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

om_file

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

om_http

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

om_kafka

nxlog-kafka-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog-kafka_4.1.4046_amd64.deb (Debian Jessie) nxlog-kafka_4.1.4046_amd64.deb (Debian Stretch) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-kafka_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog-kafka_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog-kafka_4.1.4046_amd64.deb (Ubuntu 18.04)

om_null

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

om_odbc

nxlog-odbc-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-odbc-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog-odbc_4.1.4046_amd64.deb (Debian Jessie) nxlog-odbc_4.1.4046_amd64.deb (Debian Stretch) nxlog-odbc_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-odbc-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-odbc-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-odbc-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-odbc_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog-odbc_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog-odbc_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog-odbc_4.1.4046_amd64.deb (Ubuntu 18.04)

om_perl

nxlog-perl-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-perl-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog-perl_4.1.4046_amd64.deb (Debian Jessie) nxlog-perl_4.1.4046_amd64.deb (Debian Stretch) nxlog-perl_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-perl-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-perl-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-perl-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-perl_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog-perl_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog-perl_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog-perl_4.1.4046_amd64.deb (Ubuntu 18.04)

om_python

nxlog-python-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog-python_4.1.4046_amd64.deb (Debian Jessie) nxlog-python_4.1.4046_amd64.deb (Debian Stretch) nxlog-python_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-python-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-python-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-python_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog-python_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog-python_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog-python_4.1.4046_amd64.deb (Ubuntu 18.04)

om_redis

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

om_ruby

nxlog-ruby-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog-ruby_4.1.4046_amd64.deb (Debian Jessie) nxlog-ruby_4.1.4046_amd64.deb (Debian Stretch) nxlog-ruby-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-ruby_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog-ruby_4.1.4046_amd64.deb (Ubuntu 18.04)

om_ssl

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

om_tcp

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

om_udp

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

om_udpspoof

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

om_uds

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

om_webhdfs

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

om_zmq

nxlog-zmq-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog-zmq_4.1.4046_amd64.deb (Debian Jessie) nxlog-zmq_4.1.4046_amd64.deb (Debian Stretch) nxlog-zmq-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-zmq-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-zmq_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog-zmq_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog-zmq_4.1.4046_amd64.deb (Ubuntu 18.04)
Table 32. Extension Modules

xm_admin

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

xm_aixaudit

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

xm_asl

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

xm_bsm

nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc)

xm_cef

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

xm_charconv

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

xm_csv

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

xm_exec

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

xm_filelist

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

xm_fileop

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

xm_gelf

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

xm_grok

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

xm_json

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

xm_kvp

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

xm_leef

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

xm_msdns

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

xm_multiline

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

xm_netflow

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

xm_nps

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

xm_pattern

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

xm_perl

nxlog-perl-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-perl-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog-perl_4.1.4046_amd64.deb (Debian Jessie) nxlog-perl_4.1.4046_amd64.deb (Debian Stretch) nxlog-perl_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-perl-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-perl-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-perl-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-perl_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog-perl_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog-perl_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog-perl_4.1.4046_amd64.deb (Ubuntu 18.04)

xm_python

nxlog-python-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog-python_4.1.4046_amd64.deb (Debian Jessie) nxlog-python_4.1.4046_amd64.deb (Debian Stretch) nxlog-python_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-python-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-python-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-python_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog-python_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog-python_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog-python_4.1.4046_amd64.deb (Ubuntu 18.04)

xm_resolver

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

xm_rewrite

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

xm_ruby

nxlog-ruby-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog-ruby_4.1.4046_amd64.deb (Debian Jessie) nxlog-ruby_4.1.4046_amd64.deb (Debian Stretch) nxlog-ruby-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-ruby_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog-ruby_4.1.4046_amd64.deb (Ubuntu 18.04)

xm_snmp

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

xm_soapadmin

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

xm_stdinpw

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

xm_syslog

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

xm_w3c

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

xm_wtmp

nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

xm_xml

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)
Table 33. Processor Modules

pm_blocker

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

pm_buffer

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

pm_evcorr

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

pm_filter

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

pm_hmac

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

pm_hmac_check

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

pm_norepeat

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

pm_null

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

pm_pattern

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

pm_transformer

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

pm_ts

nxlog-4.1.4016-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-4.1.4046-1_rhel6.x86_64.rpm (CentOS 6, RHEL 6) nxlog-4.1.4046-1_rhel7.x86_64.rpm (CentOS 7, RHEL 7) nxlog_4.1.4046_amd64.deb (DEB Generic) nxlog_4.1.4046_amd64.deb (Debian Jessie) nxlog_4.1.4046_amd64.deb (Debian Stretch) nxlog_4.1.4046_amd64.deb (Debian Wheezy) nxlog-4.1.4046-fbsd.tgz (FreeBSD 11) nxlog-4.1.4046-macos-x86.pkg (MacOS) nxlog-4.1.4046-x86.msi (Microsoft Windows 32bit) nxlog-4.1.4046-x64.msi (Microsoft Windows 64bit) nxlog-4.1.4046-nano.zip (Microsoft Windows Nano) nxlog-4.1.4046-obsd6_0.tgz (OpenBSD 6.0) nxlog-4.1.4046-obsd6_2.tgz (OpenBSD 6.2) nxlog-4.1.4046-1_generic.x86_64.rpm (RPM Generic) nxlog-4.1.4046-1_sles11.x86_64.rpm (SLES 11) nxlog-4.1.4046-1_sles12.x86_64.rpm (SLES 12) nxlog-4.1.4046-1_sles15.x86_64.rpm (SLES 15) nxlog-4.1.4046.solaris-x86.pkg.gz (Solaris 10 i386) nxlog-4.1.4016.solaris-sparc.pkg.gz (Solaris 10 sparc) nxlog_4.1.4046_amd64.deb (Ubuntu 12.04) nxlog_4.1.4046_amd64.deb (Ubuntu 14.04) nxlog_4.1.4046_amd64.deb (Ubuntu 16.04) nxlog_4.1.4046_amd64.deb (Ubuntu 18.04)

Deployment

5. Supported Platforms

The following operating systems and architectures are fully supported, except as noted.

Table 34. Supported GNU/Linux Platforms
Operating System Architectures

RedHat Enterprise Linux 6

x86 (see note), x86_64

RedHat Enterprise Linux 7

x86 (see note), x86_64

CentOS Linux 6

x86 (see note), x86_64

CentOS Linux 7

x86 (see note), x86_64

Debian GNU/Linux 8 (Jessie)

x86 (see note), x86_64

Debian GNU/Linux 9 (Stretch)

x86 (see note), x86_64

Ubuntu 14.04 (Trusty Tahr)

x86 (see note), x86_64

Ubuntu 16.04 (Xenial Xerus)

x86 (see note), x86_64

Ubuntu 18.04 (Bionic Beaver)

x86 (see note), x86_64

SUSE Linux Enterprise Server 11

x86 (see note), x86_64

SUSE Linux Enterprise Server 12

x86 (see note), x86_64

Other distributions

(See note)

Table 35. Supported BSD Platforms
Operating System Architectures

FreeBSD 11

x86 (see note), x86_64

OpenBSD 6.0

x86 (see note), x86_64

OpenBSD 6.2

x86 (see note), x86_64

Note

Under the Technical Support Services Agreement, Linux and BSD binary packages may be provided upon request for operating systems that have reached their end-of-life date (like RHEL 5), for legacy 32-bit hardware, or for less common distributions (such as Linux Mint).

Table 36. Supported Windows Platforms
Operating System Architectures

Microsoft Windows Server 2008

x86, x86_64

Microsoft Windows Server 2012

x86_64

Microsoft Windows Server 2016

x86_64

Microsoft Windows Nano Server

x86_64 (see note)

Microsoft Windows Vista

x86, x86_64

Microsoft Windows 7

x86, x86_64

Microsoft Windows 8

x86, x86_64

Microsoft Windows 10

x86, x86_64

Note

While the im_odbc input module is included in the Windows Nano Server package, currently Microsoft does not provide a reverse forwarder to support the ODBC API.

Table 37. Other Supported Platforms
Operating System Architectures

Apple OS X 10.11 (El Capitan)

x86_64

Apple macOS 10.12 (Sierra)

x86_64

Docker

x86_64

IBM AIX 7.1

PowerPC

IBM AIX 7.2

PowerPC

Oracle Solaris 10

x86, SPARC

Oracle Solaris 11

x86, SPARC

The following Microsoft Windows operating systems are unsupported due to having reached end-of-life status, but are known to work with NXLog.

Table 38. End-of-Life Windows Platforms
Operating System Architectures

Microsoft Windows XP

x86, x86_64   

Microsoft Windows Server 2000

x86

Microsoft Windows Server 2003

x86, x86_64

6. System Requirements

In order to function efficiently, each NXLog product requires a certain amount of available system resources on the host system. The tables below provide general guidelines to use when planning an NXLog deployment. Actual system requirements will vary based on the configuration and event rate; therefore, both minimum and recommended requirements are listed. Always thoroughly test a deployment to verify that the desired performance can be achieved with the system resources available.

Note
These requirements are in addition to the operating system’s requirements, and the requirements should be combined cumulatively for systems running both NXLog Enterprise Edition and NXLog Manager.
Table 39. NXLog Enterprise Edition Requirements
Minimum Recommended

Processor cores

1

2

Memory/RAM

60 MB

250 MB

Disk space

50 MB

150 MB

Table 40. NXLog Manager Requirements
Minimum Recommended

Processor cores

2

2

Memory/RAM (see note)

2048 MB

4096 MB

Disk space

300 MB

1024 MB

Note

The NXLog Manager memory/RAM requirement increases by 2 MB for each managed agent. For example, if an NXLog Manager instance monitors 100 agents, the recommended memory/RAM requirement is 4296 MB.

7. Red Hat Enterprise Linux & CentOS

7.1. Installing

  1. Download the appropriate NXLog install archive from the NXLog website.

    1. Log in to your account, then click My account at the top of the page.

    2. Under the Downloads  NXLog Enterprise Edition files tab, choose the correct archive for your system.

      Table 41. Available RHEL/CentOS Files
      Platform Archive

      RHEL 6 or CentOS 6

      nxlog-4.1.4181_rhel6.x86_64.tar.bz2

      RHEL 7 or CentOS 7

      nxlog-4.1.4181_rhel7.x86_64.tar.bz2

      Generic RPM

      nxlog-4.1.4181_generic.x86_64.rpm

      Note

      The RHEL 6 and RHEL 7 archives above each contain several RPMs (see Packages in a RHEL Archive below). These RPMs have dependencies on system-provided RPMs.

      The generic RPM above contains all the libraries (such as libpcre and libexpat) that are needed by NXLog, the only dependency is libc. However, some modules are not available (im_checkpoint, for example). The advantage of the generic RPM is that it can be installed on most RPM-based Linux distributions.

  2. Use SFTP or a similar secure method to transfer the archive to the target server.

  3. Log in to the target server and extract the contents of the archive.

    $ tar -xf nxlog-4.1.4181_rhel7.x86_64.tar.bz2
    Table 42. Packages in a RHEL Archive
    Package Description

    nxlog-4.1.4181_rhel7.x86_64.rpm

    The main NXLog package

    nxlog-checkpoint-4.1.4181_rhel7.x86_64.rpm

    Provides the im_checkpoint module

    nxlog-dbi-4.1.4181_rhel7.x86_64.rpm

    Provides the im_dbi and om_dbi modules

    nxlog-odbc-4.1.4181_rhel7.x86_64.rpm

    Provides the im_odbc and om_odbc modules

    nxlog-perl-4.1.4181_rhel7.x86_64.rpm

    Provides the xm_perl, im_perl, and om_perl modules

    nxlog-wmi-4.1.4181_rhel7.x86_64.rpm

    Provides the im_wmi module

    nxlog-wseventing-4.1.4181_rhel7.x86_64.rpm

    Provides the im_wseventing module

    nxlog-zmq-4.1.4181_rhel7.x86_64.rpm

    Provides the im_zmq and om_zmq modules

  4. Optional: To change the NXLog user and group for the installation, set the NXLOG_USER and NXLOG_GROUP environment variables. The specified user and group will be created, used for the User and Group directives in nxlog.conf, and used for the ownership of some directories under /opt/nxlog. Specifying an already existing user or group is not supported. The created user and group will be deleted on NXLog removal.

    $ export NXLOG_USER=nxlog2
    $ export NXLOG_GROUP=nxlog2
  5. Install the required NXLog packages and their dependencies. The following example installs the main NXLog package only.

    $ sudo yum install nxlog-4.1.4181_rhel7.x86_64.rpm
    Note
    If you are installing the nxlog-zmq package, the EPEL repository must first be enabled with yum install -y epel-release.
  6. Configure NXLog by editing /opt/nxlog/etc/nxlog.conf. General information about configuring NXLog can be found in Configuration. For more details about configuring NXLog to collect logs on Linux, see the GNU/Linux summary.

  7. Verify the configuration file syntax.

    $ sudo /opt/nxlog/bin/nxlog -v
    2017-03-17 08:05:06 INFO configuration OK
  8. Start the service using the service command:

    $ sudo service nxlog start
  9. Check that the NXLog service is running.

    $ sudo service nxlog status
    nxlog (pid  9218) is running...

7.2. Upgrading

To update an NXLog installation to the latest release, use yum as in the installation instructions above.

$ sudo yum install nxlog-4.1.4181_rhel7.x86_64.rpm

To replace a trial installation of NXLog Enterprise Edition with a licensed copy of the same version, follow the installation instructions but use yum reinstall.

$ sudo yum reinstall nxlog-4.1.4181_rhel7.x86_64.rpm
Note
The same user and group will be used for the upgrade as was used for the original installation (see installation step 4 above). Changing to a different user and group during upgrade is not supported.

7.3. Uninstalling

To uninstall NXLog, use yum remove. To remove any packages that were dependencies of NXLog but are not required by any other packages, include the --setopt=clean_requirements_on_remove=1 option. Verify the operation before confirming!

$ sudo yum remove 'nxlog-*'
Note
This procedure may not remove all files that were created in order to configure NXLog, or that were created as a result of NXLog’s logging operations. To find these files, consult the configuration files that were used with NXLog and check the installation directory (/opt/nxlog).

8. Debian & Ubuntu

8.1. Installing

  1. Download the appropriate NXLog install archive from the NXLog website.

    1. Log in to your account, then click My account at the top of the page.

    2. Under the Downloads  NXLog Enterprise Edition files tab, choose the correct archive for your system.

      Table 43. Available Debian/Ubuntu Archives
      Platform Archive

      Debian 8 (Jessie)

      nxlog-4.1.4181_debian-jessie_amd64.tar.bz2

      Debian 9 (Stretch)

      nxlog-4.1.4181_debian-stretch_amd64.tar.bz2

      Ubuntu 14.04 (Trusty Tahr)

      nxlog-4.1.4181_ubuntu-trusty_amd64.tar.bz2

      Ubuntu 16.04 (Xenial Xerus)

      nxlog-4.1.4181_ubuntu-xenial_amd64.tar.bz2

      Ubuntu 18.04 (Bionic Beaver)

      nxlog-4.1.4181_ubuntu-bionic_amd64.tar.bz2

  2. Use SFTP or a similar secure method to transfer the archive to the target server.

  3. Log in to the target server and extract the contents of the archive.

    $ tar -xjf nxlog-4.1.4181_debian-stretch_amd64.tar.bz2
    Table 44. Packages in a Debian/Ubuntu Archive
    Package Description

    nxlog-4.1.4181_amd64.deb

    The main NXLog package

    nxlog-checkpoint-4.1.4181_amd64.deb

    Provides the im_checkpoint module

    nxlog-dbi-4.1.4181_amd64.deb

    Provides the im_dbi and om_dbi modules

    nxlog-odbc-4.1.4181_amd64.deb

    Provides the im_odbc and om_odbc modules

    nxlog-perl-4.1.4181_amd64.deb

    Provides the xm_perl, im_perl, and om_perl modules

    nxlog-wmi-4.1.4181_amd64.deb

    Provides the im_wmi module

    nxlog-wseventing-4.1.4181_amd64.deb

    Provides the im_wseventing module

    nxlog-zmq-4.1.4181_amd64.deb

    Provides the im_zmq and om_zmq modules

  4. Install the required NXLog packages and their dependencies.

    1. Optional: To change the NXLog user and group for the installation, set the NXLOG_USER and NXLOG_GROUP environment variables. The specified user and group will be created, used for the User and Group directives in nxlog.conf, and used for the ownership of some directories under /opt/nxlog. Specifying an already existing user or group is not supported. The created user and group will be deleted on NXLog removal.

      $ export NXLOG_USER=nxlog2
      $ export NXLOG_GROUP=nxlog2
    2. First, use dpkg to install the NXLog packages (this example installs the main NXLog package only).

      $ sudo dpkg -i nxlog-4.1.4181_amd64.deb
    3. Then, if dpkg returned errors about uninstalled dependencies, use apt-get to install them and complete the NXLog installation.

      $ sudo apt-get -f install
  5. Configure NXLog by editing /opt/nxlog/etc/nxlog.conf. General information about configuring NXLog can be found in Configuration. For more details about configuring NXLog to collect logs on Linux, see the GNU/Linux summary.

  6. Verify the configuration file syntax.

    $ sudo /opt/nxlog/bin/nxlog -v
    2017-03-17 08:05:06 INFO configuration OK
  7. Start the service using the service command:

    $ sudo service nxlog start
  8. Check that the NXLog service is running with the service command.

    $ sudo service nxlog status
    ● nxlog.service - LSB: logging daemon
       Loaded: loaded (/etc/init.d/nxlog)
       Active: active (running) since Wed 2016-10-19 22:21:36 BST; 3h 49min ago
      Process: 518 ExecStart=/etc/init.d/nxlog start (code=exited, status=0/SUCCESS)
       CGroup: /system.slice/nxlog.service
               └─6297 /opt/nxlog/bin/nxlog
    [...]

8.2. Upgrading

To update an NXLog installation to the latest release, or to replace a trial installation of NXLog Enterprise Edition with a licensed copy, use dpkg as in the installation instructions above.

$ sudo dpkg -i nxlog-4.1.4181_amd64.deb

If dpkg returns errors about uninstalled dependencies, resolve with apt-get.

$ sudo apt-get -f install
Note
The same user and group will be used for the upgrade as was used for the original installation (see installation step 4a above). Changing to a different user and group during upgrade is not supported.

8.3. Uninstalling

To uninstall NXLog, use apt-get. To remove any unused dependencies (system-wide), include the --auto-remove option. Verify the operation before confirming!

$ sudo apt-get remove '^nxlog*'
Note
Use apt-get purge instead to also remove configuration files. But in either case, this procedure may not remove all files that were created in order to configure NXLog, or that were created as a result of NXLog’s logging operations. To find these files, consult the configuration files that were used with NXLog and check the installation directory (/opt/nxlog).

9. SUSE Linux Enterprise Server

9.1. Installing

  1. Download the appropriate NXLog install archive from the NXLog website.

    1. Log in to your account, then click My account at the top of the page.

    2. Under the Downloads  NXLog Enterprise Edition files tab, choose the correct archive for your system.

      Table 45. Available SLES Files
      Platform Archive

      SUSE Linux Enterprise Server 11

      nxlog-4.1.4181_sles11.x86_64.tar.bz2

      SUSE Linux Enterprise Server 12

      nxlog-4.1.4181_sles12.x86_64.tar.bz2

      Note

      The SLES 11 and SLES 12 archives above each contain several RPMs (see Packages in an SLES Archive below). These RPMs have dependencies on system-provided RPMs.

  2. Use SFTP or a similar secure method to transfer the archive to the target server.

  3. Log in to the target server and extract the contents of the archive.

    $ tar xjf nxlog-4.1.4181_sles12.x86_64.tar.bz2
    Table 46. Packages in an SLES Archive
    Package Description

    nxlog-4.1.4181_sles12.x86_64.rpm

    The main NXLog package

    nxlog-dbi-4.1.4181_sles12.x86_64.rpm

    Provides the im_dbi and om_dbi modules

    nxlog-odbc-4.1.4181_sles12.x86_64.rpm

    Provides the im_odbc and om_odbc modules

    nxlog-perl-4.1.4181_sles12.x86_64.rpm

    Provides the xm_perl, im_perl, and om_perl modules

    nxlog-wmi-4.1.4181_sles12.x86_64.rpm

    Provides the im_wmi module

    nxlog-wseventing-4.1.4181_sles12.x86_64.rpm

    Provides the im_wseventing module

  4. Optional: To change the NXLog user and group for the installation, set the NXLOG_USER and NXLOG_GROUP environment variables. The specified user and group will be created, used for the User and Group directives in nxlog.conf, and used for the ownership of some directories under /opt/nxlog. Specifying an already existing user or group is not supported. The created user and group will be deleted on NXLog removal.

    $ export NXLOG_USER=nxlog2
    $ export NXLOG_GROUP=nxlog2
  5. Install the required NXLog packages and their dependencies (this example installs the main NXLog package only).

    $ sudo zypper install nxlog-4.1.4181_sles12.x86_64.rpm
  6. Configure NXLog by editing /opt/nxlog/etc/nxlog.conf. General information about configuring NXLog can be found in Configuration. For more details about configuring NXLog to collect logs on Linux, see the GNU/Linux summary.

  7. Verify the configuration file syntax.

    $ sudo /opt/nxlog/bin/nxlog -v
    2017-03-17 08:05:06 INFO configuration OK
  8. Start the service using the service command:

    $ systemctl start nxlog.service
  9. Check that the NXLog service is running with the systemctl command.

    $ systemctl | grep nxlog
      nxlog.service                      loaded active running   LSB: logging daemon

9.2. Upgrading

To update an NXLog installation to the latest release, use zypper as in the installation instructions above.

$ sudo zypper install nxlog-4.1.4181_sles12.x86_64.rpm

To replace a trial installation of NXLog Enterprise Edition with a licensed copy of the same version, follow the installation instructions but use zypper install -f.

$ sudo zypper install -f nxlog-4.1.4181_rhel7.x86_64.rpm
Note
The same user and group will be used for the upgrade as was used for the original installation (see installation step 4 above). Changing to a different user and group during upgrade is not supported.

9.3. Uninstalling

To uninstall NXLog, use zypper remove. To remove any packages that were dependencies of NXLog but are not required by any other packages, include the --clean-deps option. Verify the operation before confirming!

$ sudo zypper remove 'nxlog*'
Note
This procedure may not remove all files that were created in order to configure NXLog, or that were created as a result of NXLog’s logging operations. To find these files, consult the configuration files that were used with NXLog and check the installation directory (/opt/nxlog).

10. FreeBSD

10.1. Installing

NXLog is available in a precompiled package for FreeBSD. Follow these steps to install NXLog.

  1. Download the appropriate NXLog install archive from the NXLog website.

    1. Log in to your account, then click My account at the top of the page.

    2. Under the Downloads  NXLog Enterprise Edition files tab, choose the nxlog-4.1.4181-fbsd.tgz package.

  2. Use SFTP or a similar secure method to transfer the archive to the target server.

  3. Log in to the target server as the root user.

  4. Optional: To change the NXLog user and group for the installation, set the NXLOG_USER and NXLOG_GROUP environment variables. The specified user and group will be created, used for the User and Group directives in nxlog.conf, and used for the ownership of some directories under /opt/nxlog. Specifying an already existing user or group is not supported. The created user and group will be deleted on NXLog removal.

    # setenv NXLOG_USER nxlog2
    # setenv NXLOG_GROUP nxlog2
  5. Install NXLog with the pkg(7) utility.

    # pkg add nxlog-4.1.4181-fbsd.tgz
    Installing nxlog-4.1.4181-fbsd...
    Extracting nxlog-4.1.4181-fbsd: 100%

    The installation prefix is /opt/nxlog. Configuration files are located in /opt/nxlog/etc. The rc init script is placed in /etc/rc.d/ on installation. An nxlog user account is created, and NXLog will run under this user by default.

  6. Edit the configuration file.

    # vi /opt/nxlog/etc/nxlog.conf

    General information about configuring NXLog can be found in Configuration. For more details about configuring NXLog to collect logs on BSD, see the FreeBSD and OpenBSD summary.

  7. Verify the configuration file syntax.

    # /opt/nxlog/bin/nxlog -v
    2017-03-17 08:05:06 INFO configuration OK
  8. To enable NXLog, add the line nxlog_enable="YES" to /etc/rc.conf. Then manage the NXLog service with the service(8) utility.

    # service nxlog start
    # service nxlog status
    nxlog is running as pid 83708.
    # service nxlog stop
    process 83708 stopped

10.2. Upgrading

To upgrade NXLog, first remove the old version and then install the new version.

  1. Remove the installed version of NXLog with the pkg(7) utility.

    # pkg delete nxlog
    Checking integrity... done (0 conflicting)
    Deinstallation has been requested for the following 1 packages (of 0 packages
    in the universe):
    
    Installed packages to be REMOVED:
    	nxlog-4.1.4181-fbsd
    
    Number of packages to be removed: 1
    
    The operation will free 39 MiB.
    
    Proceed with deinstalling packages? [y/N]: y
    [1/1] Deinstalling nxlog-4.1.4181-fbsd...
    [1/1] Deleting files for nxlog-4.1.4181-fbsd: 100%
  2. Install the new version as described in the installation instructions above.

    # pkg add nxlog-4.1.4181-fbsd.tgz
    Installing nxlog-4.1.4181-fbsd...
    Extracting nxlog-4.1.4181-fbsd: 100%
  3. Restart the NXLog service.

    # service nxlog restart

10.3. Uninstalling

  1. Use the pkg(7) utility to uninstall the NXLog package.

    # pkg delete nxlog
    Updating database digests format: 100%
    Checking integrity... done (0 conflicting)
    Deinstallation has been requested for the following 1 packages (of 0 packages
    in the universe):
    
    Installed packages to be REMOVED:
    	nxlog-4.1.4181-fbsd
    
    Number of packages to be removed: 1
    
    The operation will free 92 MiB.
    
    Proceed with deinstalling packages? [y/N]: y
    [1/1] Deinstalling nxlog-4.1.4181-fbsd...
    [1/1] Deleting files for nxlog-4.1.4181-fbsd: 100%

    The uninstall script will remove NXLog along with the user, group, and files. The pkg utility will not remove new or modified files.

  2. Manually remove the base directory. This will remove any new or modified files left behind by the previous step.

    # rm -rf /opt/nxlog

11. OpenBSD

11.1. Installing

NXLog comes in precompiled packages for OpenBSD. To install NXLog take the following actions.

  1. Download the appropriate NXLog install archive from the NXLog website.

    1. Log in to your account, then click My account at the top of the page.

    2. Under the Downloads  NXLog Enterprise Edition files tab, choose the correct package for your system.

      Table 47. Available OpenBSD Packages
      Platform Package

      OpenBSD 6.0

      nxlog-4.1.4181-obsd6_0.tgz

      OpenBSD 6.2

      nxlog-4.1.4181-obsd6_2.tgz

  2. Use SFTP or a similar secure method to transfer the archive to the target server.

  3. Log in to the target server as the root user.

  4. Optional: To change the NXLog user and group for the installation, set the NXLOG_USER and NXLOG_GROUP environment variables. The specified user and group will be created, used for the User and Group directives in nxlog.conf, and used for the ownership of some directories under /opt/nxlog. Specifying an already existing user or group is not supported. The created user and group will be deleted on NXLog removal.

    # export NXLOG_USER=nxlog2
    # export NXLOG_GROUP=nxlog2
  5. Install NXLog with the pkg_add(1) utility. The OpenBSD package is currently unsigned, use the -D unsigned flag to install.

    # pkg_add -D unsigned nxlog-4.1.4181-obsd6_2.tgz
    nxlog-4.1.4181-obsd6_2: ok

    The installation prefix is /opt/nxlog. Configuration files are located in /opt/nxlog/etc. The rc init script is located in /opt/nxlog/share/nxlog/init and is placed in /etc/rc.d on installation.

  6. Copy and edit the configuration file.

    # cp /opt/nxlog/etc/nxlog.conf.sample /opt/nxlog/etc/nxlog.conf
    # vi /opt/nxlog/etc/nxlog.conf

    General information about configuring NXLog can be found in Configuration. For more details about configuring NXLog to collect logs on BSD, see the FreeBSD and OpenBSD summary.

  7. Verify the configuration file syntax.

    # /opt/nxlog/bin/nxlog -v
    2017-03-17 08:05:06 INFO configuration OK
  8. Manage the service using the rcctl(8) utility.

    # rcctl enable nxlog
    # rcctl start nxlog
    nxlog(ok)
    # rcctl stop nxlog
    nxlog(ok)
    # rcctl disable nxlog

    You can also use rcctl(8) to check and set the configuration flags.

    # rcctl set nxlog flags -c /tmp/sample-nxlog.conf
    # rcctl get nxlog
    nxlog_class=daemon
    nxlog_flags=-c /tmp/sample-nxlog.conf
    nxlog_rtable=0
    nxlog_timeout=30
    nxlog_user=root
    # rcctl reload nxlog
  9. Check the NXLog service status using rcctl(8).

    # rcctl check nxlog
    nxlog(ok)

11.2. Upgrading

To upgrade from a previous NXLog version (whether a licensed copy or trial), use the pkg_add(1) utility. This example shows an upgrade from version 3.0.1865 to 4.1.4181.

# pkg_add -U nxlog-4.1.4181-obsd6_2.tgz
nxlog-3.0.1865-obsd6_2->4.1.4181-obsd6_2: ok
Read shared items: ok

To replace a trial installation of NXLog Enterprise Edition with a licensed copy of the same version, use pkg_add with the replace flag (-r).

# pkg_add -r nxlog-4.1.4181-obsd6_2.tgz
Note
The same user and group will be used for the upgrade as was used for the original installation (see installation step 4 above). Changing to a different user and group during upgrade is not supported.

11.3. Uninstalling

To uninstall NXLog, follow these steps.

  1. Use the pkg_delete(1) utility to remove the nxlog package.

    # pkg_delete nxlog
    nxlog-4.1.4181-obsd6_2: ok
    Read shared items: ok
    --- -nxlog-4.1.4181-obsd6_2 -------------------
  2. Remove the /opt/nxlog directory.

    # rm -rf /opt/nxlog

12. Microsoft Windows

12.1. Installing

First, download the NXLog MSI file from the NXLog website.

  1. Log in to your account, then click My account at the top of the page.

  2. Under the Downloads  NXLog Enterprise Edition files tab, download nxlog-4.1.4181.msi.

There are several ways that NXLog can be installed on Windows.

Note

The service Startup type of newer versions of NXLog is set to Automatic (Delayed Start) instead of Automatic. To change this option, open the service control manager and alter the Startup type in the General tab.

12.1.1. Installing Interactively

  1. Run the installer by double-clicking the MSI. Accept the license agreement, customize the installation directory if desired, and click Install. Click Finish when the installation completes; by default, the README.txt file will be opened in Notepad.

  2. Find the configuration file (nxlog.conf) by navigating to the chosen installation directory and then the conf subdirectory. By default, the configuration file will be found at C:\Program Files (x86)\nxlog\conf\nxlog.conf on a 64-bit system or C:\Program Files\nxlog\conf\nxlog.conf on a 32-bit system.

  3. Open nxlog.conf with Notepad. Update the ROOT path if you chose a custom installation directory.

    1
    2
    
    # Default on 64-bit Windows
    define ROOT C:\Program Files (x86)\nxlog
  4. Configure NXLog by editing nxlog.conf. General information about configuring NXLog can be found in Configuration. For more details about configuring NXLog to collect logs on Windows, see the Microsoft Windows summary.

  5. Verify the configuration file syntax.

    > "C:\Program Files (x86)\nxlog\nxlog.exe" -v
    2017-03-17 08:05:06 INFO configuration OK
  6. Start NXLog by opening the Service Manager, finding the nxlog service in the list, and starting it. To run the nxlog.exe executable in the foreground, rather than as a service, execute it with the -f command line argument.

  7. Open the NXLog log file (default C:\Program Files (x86)\nxlog\data\nxlog.log on 64-bit Windows) with Notepad and check for errors.

    Note
    Some text editors (such as Wordpad) use exclusive locking and will refuse to open the log file while NXLog is running.

12.1.2. Installing With Msiexec

Msiexec can be used for performing an unattended install of NXLog. This command does not prompt the user at all, but must be run as administrator.

> msiexec /i nxlog-4.1.4181.msi /q

To allow Windows to prompt for administrator privileges, but otherwise install unattended, use /qb instead.

> msiexec /i nxlog-4.1.4181.msi /qb

To specify a custom installation directory, use the INSTALLDIR property. Remember to set the correct ROOT path in nxlog.conf.

> msiexec /i nxlog-4.1.4181.msi /q INSTALLDIR="C:\nxlog"

12.1.3. Deploying via Group Policy

For large deployments, it may be convenient to use Group Policy to manage the NXLog installation.

Note
These steps were tested with a Windows Server 2016 domain controller and a Windows 7 client. There are multiple ways to configure NXLog deployment with Group Policy, and the required steps for your network may vary from those listed below.
  1. Log on to the server as an administrator.

  2. Set up an Active Directory group for computers requiring an NXLog installation. NXLog will be automatically installed and configured on each computer in this group.

    1. Open the Active Directory Users and Groups console (dsa.msc).

    2. Under the domain, right-click on Computers and click New  Group.

    3. Provide a name for the group (for example, nxlog). Use the Security group type and Global context (or the context suitable for your case).

    4. Add computers to the group by selecting one or more, clicking Actions  Add to a group…, and entering the group name (nxlog).

  3. Create a network share for distributing the NXLog files.

    1. Create a folder in the desired location (for example, C:\nxlog-dist).

    2. Set up the folder as a share: right-click, select Properties, open the Sharing tab, and click Share….

    3. Add the group (nxlog) and click Share. Take note of the share name provided by the wizard, it will be needed later (for example, \\WINSERV1\nxlog-dist).

    4. Copy the required files to the shared folder. If using NXLog Manager, this will include at least three files: nxlog-4.1.4181.msi, log4ensics.conf, and CA certificate agent-ca.pem. If not using NXLog Manager, use a custom nxlog.conf instead of log4ensics.conf, omit the CA certificate, and include any other files required by the configuration.

      Note
      To deploy on both 32-bit and 64-bit systems, you will need a second nxlog.conf with ROOT configured as C:\Program Files\nxlog. See Add the required files below.
  4. Create a Group Policy Object (GPO) for the NXLog deployment.

    1. Open the Group Policy Management console (gpmc.msc).

    2. In the console tree, under Domains, right-click on your domain and click Create a GPO in this domain, and Link it here…; this will create a GPO under the Group Policy Objects folder and link it to the domain.

    3. Name the GPO (for example, nxlog) and click OK.

    4. Select the newly created GPO in the tree.

    5. In the Security Filtering list, add the Active Directory group created in step 2 (nxlog). Remove anything else.

    6. Right-click on the GPO and click Edit. The Group Policy Management Editor console will be opened for editing the GPO.

  5. Add the NXLog MSI to the GPO.

    Group Policy Management Editor
    Figure 1. Configured NXLog GPO
    1. Under Computer Configuration  Policies  Software Settings, right-click Software installation. Click New  Package… to create a deployment package for NXLog.

    2. Browse to the network share and open the nxlog-4.1.4181.msi package. It is important to use the Uniform Naming Convention (UNC) path (for example, \\WINSERV1\nxlog-dist) so the file will be accessible by the remote computers.

    3. Select the Assigned deployment method.

  6. Add the required files to the GPO by following these steps for each file.

    Note

    The following steps are for deployment on 64-bit systems only. To deploy NXLog on both 32-bit and 64-bit systems with a single GPO, use two entries for each file. For each entry, enable Item-level targeting (under the Common tab in the file’s Properties dialog) to create the file with the correct path (C:\Program Files (x86)\nxlog or C:\Program Files\nxlog) based on whether the %Processor_Architecture% environment variable matches AMD64 or x86 respectively.

    Also, if deploying nxlog.conf (not using NXLog Manager), there must be separate nxlog32.conf and nxlog64.conf source files, each containing the correct ROOT path.

    1. Under Computer Configuration  Preferences  Windows Settings, right-click on Files. Click New  File.

    2. Select the Replace action in the drop-down.

    3. Choose the source file on the network share (for example, \\WINSERV1\nxlog-dist\log4ensics.conf or \\WINSERV1\nxlog-dist\agent-ca.pem).

    4. Type in the destination path for the file (for example, C:\Program Files (x86)\nxlog\conf\log4ensics.conf or C:\Program Files (x86)\nxlog\cert\agent-ca.pem).

    5. Check Apply once and do not reapply under the Common tab for files that should only be deployed once. This is especially important for log4ensics.conf because NXLog Manager will write configuration changes to that file.

    6. Click OK to create the File in the GPO.

  7. After the Group Policy is updated on the clients and NXLog is installed, one more reboot will be required before the NXLog service starts automatically.

For more information about Group Policy, see the following TechNet and MSDN articles:

12.2. Upgrading

To upgrade the NXLog installation to the latest release, or to replace a trial installation of NXLog Enterprise Edition with a licensed copy, follow the steps below.

  1. Run the new MSI installer as described in the Installing section (interactively, with Msiexec, or via Group Policy). The installer should detect that the previous version is installed and do an upgrade to the same installation directory.

    Note
    If you are upgrading from v3.x, you will need to manually uninstall the previous version first (see Uninstalling). This is necessary to transition from a per-user to a per-machine installation. You can skip this check by passing the SKIP_PERUSER_CHECK property (such as msiexec /i nxlog-4.1.4181.msi /q SKIP_PERUSER_CHECK=1). Note that this may leave behind another installation and its associated Add/Remove Programs entry.
    Note
    If the Services console (services.msc) is running, the installer may request the computer to be rebooted or give a permission denied error. Please ensure that the Services console is not running before attempting an upgrade.
  2. Start the upgraded NXLog service with the Services console (services.msc) or by rebooting the system. Check the log file (default C:\Program Files (x86)\nxlog\data\nxlog.log on 64-bit Windows) and verify that logging is working as expected.

For Group Policy deployments, follow these steps:

  1. Download the new MSI package as described in the Installing introduction.

  2. Place the new MSI in the distribution share (see Create a network share).

  3. Add this MSI as a new package to the NXLog GPO (follow the steps under Add the NXLog MSI).

  4. Right-click on the new package and click Properties. Open the Upgrades tab, click Add…, select the previous version from the list, and click OK.

Note
If you want to downgrade to a previous version of NXLog, you will need to manually uninstall the current version first. See Uninstalling.

12.3. Uninstalling

NXLog can be uninstalled from the Control Panel or with Msiexec and the original NXLog MSI.

Warning
NXLog v3.x installers will remove log4ensics.conf and nxlog.conf on uninstallation, even if they have been modified. If you wish to keep these files, save them elsewhere before uninstalling NXLog v3.x.

Msiexec can be used to uninstall NXLog.

> msiexec /x nxlog-4.1.4181.msi /qb
Note
This procedure will not remove any configuration files, additional files created to set up NXLog, or files that were created as a result of NXLog’s logging operations (except for v3.x installers as noted above). You may wish to remove the installation directory (default C:\Program Files (x86)\nxlog on 64-bit Windows) after completing the installation.

For Group Policy deployments, follow these steps:

  1. Open the Group Policy Object (GPO) originally created for installation (see Create a Group Policy Object).

  2. For each NXLog version that has been deployed, right-click the package and either:

    • click All Tasks  Remove…, and choose the Immediately uninstall removal method; or

    • click Properties, open the Deployment tab, and check Uninstall this application when it falls out of the scope of management.

      Note
      In this case, NXLog will be uninstalled when the GPO is no longer applied to the computer. An additional action will be required, such as removing the selected computer(s) from the nxlog group created in Set up an Active Directory group.

12.4. Configure Using a Custom MSI

NXLog can be configured using a custom built MSI file. The MSI file will install the CA certificate and customized configuration files of your choosing which can be deployed alongside the NXLog MSI. Deployment of the configuration MSI can be done with the same methods as with the NXLog MSI, namely interactively, using msiexec or via group policy.

Note
Deployment via Group Policy already provides a way to deploy the configuration files. For this reason you might prefer to configure NXLog via GPO instead of creating a custom MSI described in this section.

The Windows Installer XML Toolset (Wix) is required to build the custom MSI. Wix is free software available for download from http://wixtoolset.org. A zip file containing all the assets, XML and scripts is also needed, that can be downloaded from NXLog web site.

Download and install Wix. Make a note where the binary folder of Wix is located (containing the candle.exe and light.exe executables, typically C:\Program Files (x86)\WiX Toolset v3.11\bin). Uncompress the provided zip file in a folder of your choosing and make sure the path to the binary folder is correct in the pkgmsi32.bat (or pkgmsi64.bat) script by editing the WIX_BUILD_LOCATION variable. Add the custom agent-ca.pem and log4ensics.conf files in the folder. The files to be deployed can be customized by editing nxlog-conf.wxs.

Finally, execute either the pkgmsi32.bat or the pkgmsi64.bat script, depending on the targeted architecture. While both the resulting MSIs include platform independent files, we strongly advise to build and install the appropriate custom configuration MSI that matches your NXLog installation. The script will proceed to build the MSI. Depending on the architecture selected the result will either be an nxlog-conf_x86.msi or an nxlog-conf_x64.msi. You can now deploy the custom configuration MSI alongside with NXLog.

13. Microsoft Nano Server

13.1. Installing

Follow these steps to deploy NXLog on a Nano Server system.

Note
Microsoft Nano Server does not support the installation of MSI files. In its place, Microsoft introduced the APPX format. The sandboxing and isolation imposed by the APPX format was found to be an unnecessary complication when deploying NXLog; therefore, users are provided with a ZIP file that allows for manual installation instead.
  1. Download the NXLog ZIP archive from the NXLog website.

    1. Log in to your account, then click My account at the top of the page.

    2. Under the Downloads  NXLog Enterprise Edition files tab, download nxlog-4.1.4181-nano.zip.

  2. Transfer the NXLog ZIP file to the Microsoft Nano Server. One way to do so is to use WinRM and the Copy-Item cmdlet. Uncompress the ZIP file at C:\Program Files\nxlog using the Expand-Archive cmdlet as shown below.

    PS C:\tmp> Expand-Archive -Path nxlog-4.1.4181-nano.zip -DestinationPath 'C:\Program Files\nxlog'
  3. To register NXLog as a service, navigate to the installation directory and execute the following.

    PS C:\Program Files\nxlog> .\nxlog.exe -i
  4. Configure NXLog by editing the C:\Program Files\nxlog\nxlog.conf file. General information about configuring NXLog can be found in Configuration. For more details about configuring NXLog to collect logs on Windows, see the Microsoft Windows summary.

    Note
    Because Microsoft Nano Server does not have a native console editor, the configuration file must be edited on a different system and then transferred to the Nano Server. Alternatively, a third party editor could be installed.
  5. Verify the configuration file syntax.

    PS C:\Program Files\nxlog> .\nxlog.exe -v -c nxlog.conf
    2018-09-12 19:15:55 INFO configuration OK

NXLog in now installed, registered, and configured. The NXLog service can be started by running Start-Service nxlog.

13.2. Upgrading

To upgrade the NXLog installation to the latest release, follow the steps below.

  1. Stop the NXLog service by issuing the command Stop-Service nxlog.

  2. Back up any configuration files that have been altered, such as nxlog.conf, log4ensics.conf, and any certificates.

  3. Either delete the nxlog directory and follow the installation procedure again or use the -Force parameter when extracting the NXLog ZIP file. There is no need to register the service again.

    PS C:\tmp> Expand-Archive -Force -Path nxlog-4.1.4181-nano.zip -DestinationPath 'C:\Program Files\nxlog'
  4. Restore any configuration and certificate files.

  5. Start the NXLog service by running Start-Service nxlog.

13.3. Uninstalling

To uninstall NXLog, follow this procedure.

  1. Stop the NXLog service by issuing the command Stop-Service nxlog.

  2. Unregister the NXLog service by navigating to the NXLog directory and running .\nxlog.exe -u.

  3. Now delete the NXLog directory.

13.4. Custom Installation Options

This sections deals with installation options outside the typical scenario.

Note

The following installation options require altering the Windows Registry. Incorrect modifications can potentially damage the system. Always double check the commands and make sure you can revert to a known working state before altering the registry.

13.4.1. Installing to a Custom Directory

NXLog can be installed to a custom location on Nano Server.

  1. Follow the same procedure as with the typical installation, but choose a different DestinationPath when expanding the ZIP file. Also register the NXLog service as shown above.

  2. At this point the registry entry for the NXLog service needs to be altered. View the current setting:

    PS C:\> Get-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\nxlog"
    
    
    Type            : 16
    Start           : 2
    ErrorControl    : 0
    ImagePath       : "c:\Program Files\nxlog\nxlog.exe" -c "c:\Program Files\nxlog\nxlog.conf"
    DisplayName     : nxlog
    DependOnService : {eventlog}
    ObjectName      : LocalSystem
    PSPath          : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\nxlog
    PSParentPath    : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services
    PSChildName     : nxlog
    PSDrive         : HKLM
    PSProvider      : Microsoft.PowerShell.Core\Registry
  3. The value of the ImagePath parameter needs to be modified in order to correct the location of both the NXLog executable and the configuration file. For example, if NXLog is installed at C:\nxlog, run the following command to update the registry key.

    PS C:\> Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\nxlog" -Name "ImagePath" -Value '"C:\nxlog\nxlog.exe" -c "C:\nxlog\nxlog.conf"'
  4. The configuration file (nxlog.conf) also needs to reflect the directory where NXLog is located. Make sure the define ROOT points to the correct location.

13.4.2. Service Startup Type

The service Startup type of newer versions of NXLog is set to Automatic (Delayed Start) instead of Automatic. This is controlled by the DelayedAutostart parameter. To revert back to the old behavior, run the following command.

PS C:\> Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\nxlog" -Name "DelayedAutostart" -Value 0

14. Apple macOS

14.1. Installing

To install NXLog under macOS, follow the steps below. You will need administrator privileges to complete the installation process.

  1. Download the appropriate NXLog install package from the NXLog website.

    1. Log in to your account, then click My account at the top of the page.

    2. Under the Downloads  NXLog Enterprise Edition files tab, choose the nxlog-4.1.4181-macos-x86.pkg package.

  2. Optional: To change the NXLog user and group for the installation, create a /tmp/.nxlog file with the following command. The specified user and group will be created, used for the User and Group directives under nxlog.conf, and used for the ownership of some directories under /opt/nxlog. Specifying an already existing user or group is not supported. The created user and group will be deleted on NXLog removal.

    $ echo 'nxlog2:nxlog2' > /tmp/.nxlog
  3. Install the NXLog package. You can do the installation interactively or with the command line installer.

    • To install interactively, double-click the NXLog package.

      If you see the following message, go to System Preferences  Security & Privacy and click Open Anyway, then follow the instructions shown by the installer.

      "nxlog-4.1.4181-macos-x86.pkg" can’t be opened because it is from an unidentified developer.

      Allow NXLog to launch the installer
    • To install the package using the command line installer, run the following command.

      $ sudo installer -pkg nxlog-4.1.4181-macos-x86.pkg -target /
      Password:
      installer: Package name is nxlog-4.1.4181-macos-x86
      installer: Upgrading at base path /
      installer: The upgrade was successful.

    Upon installation, all NXLog files are placed under /opt/nxlog. The launchd(8) script is installed in /Library/LaunchDaemons/com.nxlog.plist and has the KeepAlive flag set to true (launchd will automatically restart NXLog). NXLog log files are managed by launchd and can be found in /var/log/.

  4. Configure NXLog by editing /opt/nxlog/etc/nxlog.conf. General information about configuring NXLog can be found in Configuration. For more details about configuring NXLog to collect logs on macOS, see the Apple macOS summary.

  5. Verify the configuration file syntax.

    $ sudo /opt/nxlog/bin/nxlog -v
    2017-03-17 08:05:06 INFO configuration OK
  6. To apply your changes, stop NXLog with the following command. The launchd manager will restart the daemon and the new configuration will be loaded.

    $ sudo launchctl stop com.nxlog
  7. To permanently stop NXLog, the service must be unloaded.

    $ sudo launchctl unload /Library/LaunchDaemons/com.nxlog.plist

14.2. Upgrading

To upgrade NXLog, follow the installation instructions.

The installation script will not modify the configuration files, and the script will restart NXLog after the installation is completed.

Note
The same user and group will be used for the upgrade as was used for the original installation (see installation step 2 above). Changing to a different user and group during upgrade is not supported.

14.3. Uninstalling

To properly uninstall NXLog, follow these steps.

  1. Start the uninstaller script as user root.

    Warning
    This will remove any custom configuration files, certificates and other files in the listed directories. Save these files to another location first if you do not wish to discard them.
    $ sudo bash /opt/nxlog/bin/uninstaller -y
    Note
    Use -n switch if you would like to preserve user data.
  2. Delete user data if you are sure it will not be needed anymore.

    $ sudo rm -rf /opt/nxlog

To manually uninstall NXLog, follow these steps below.

  1. Unload the daemon.

    $ sudo launchctl unload /Library/LaunchDaemons/com.nxlog.plist
  2. Delete the nxlog user and group that were created during installation. If a non-default user/group were used during installation (see installation step 2 above), remove those instead.

    $ sudo dscl . -delete "/Groups/nxlog"
    $ sudo dscl . -delete "/Users/nxlog"
  3. Remove NXLog files.

    Warning
    This will remove any custom configuration files, certificates and other files in the listed directories. Save these files to another location first if you do not wish to discard them.
    $ sudo rm -rf /opt/nxlog /Library/LaunchDaemons/com.nxlog.plist \
                  /var/log/nxlog.std* && \
      sudo pkgutil --forget com.nxlog.agent

15. Docker

15.1. Installing

  1. Download the appropriate NXLog install archive from the NXLog website.

    1. Log in to your account, then click My account at the top of the page.

    2. Under the Downloads  NXLog Enterprise Edition files tab, choose the nxlog-4.1.4181-docker.tar.gz archive (which is based on CentOS 7).

  2. Use SFTP or a similar secure method to transfer the archive to the target server.

  3. Log in to the target server and extract the contents of the archive.

    $ tar -xzf nxlog-4.1.4181-docker.tar.gz
    Table 48. Files in the Docker Archive
    Package Description

    Dockerfile

    The main NXLog Docker definition file

    README.md

    Readme for building NXLog Docker image

    nxlog-4.1.4181_rhel7.x86_64.tar.bz2

    The NXLog RHEL7 package

  4. Configure NXLog. Custom configuration files can be placed in the build directory of the NXLog Docker version, before the build. Every file ending with .conf will be copied into the Docker image and placed in the /opt/nxlog/etc directory.

    Note
    If there is already a configuration file inside the /opt/nxlog/etc directory, it will be overwritten with the custom one.
  5. Build the NXLog Docker image.

    • The standalone version of NXLog Docker image can be built with this command.

      $ docker build -t nxlog .
    • It is also possible to specify the IP address of an NXLog Manager instance at build time. In this case, NXLog will connect automatically at startup. Before build, the CA certificate file, exported from NXLog Manager in PEM format and named agent-ca.pem, must be placed in the Docker build directory.

      $ docker build -t nxlog --build-arg NXLOG_MANAGER=<NXLOG-MANAGER-IP> .
  6. Run the container using the docker command.

    $ docker run -p <HostPort>:<ContainerPort> -d nxlog
  7. Check that the NXLog container is running with the docker command.

    $ docker ps | grep nxlog
    a3b4d6240e9d nxlog "/opt/nxlog/bin/nx..." 7 seconds ago Up 6 seconds 0.0.0.0:1514->1514/tcp cranky_perlman
    [...]

15.2. Upgrading

The upgrade process consists of creating a new NXLog Docker image build and running a new container instance with the newly built image.

  1. Follow steps 1-5 above to build a new Docker image.

  2. Get the container ID of the running NXLog instance and stop the running container.

    $ docker ps | grep nxlog
    $ docker stop <containerID>
  3. Run the new container using the docker command.

    $ docker run -p <HostPort>:<ContainerPort> -d nxlog
  4. Check that the new NXLog container is running.

    $ docker ps | grep nxlog
    a3b4d6240e9d nxlog "/opt/nxlog/bin/nx..." 7 seconds ago Up 6 seconds 0.0.0.0:1514->1514/tcp cranky_perlman
    [...]
  5. Any old containers and images that are no longer needed can be removed with docker rm -v <containerID> and docker rmi <imageID>, respectively. See Uninstalling below for more information.

15.3. Uninstalling

The uninstallation process of the NXLog Docker version is simply removing the running container and the image.

  1. Get the container ID of the running NXLog instance and stop the running container.

    $ docker ps | grep nxlog
    $ docker stop <containerID>
  2. Remove the stopped container.

    $ docker rm -v <containerID>
  3. Any other remaining containers that are not running can be listed with docker ps -a, and removed.

    $ docker ps -a | grep nxlog
    $ docker rm -v <containerID>
  4. Finally, list and remove NXLog Docker images.

    $ docker images
    $ docker rmi <containerID>

16. IBM AIX

16.1. Installing

  1. Download the appropriate NXLog installer package from the NXLog website.

    1. Log in to your account, then click My account at the top of the page.

    2. Under the Downloads  NXLog Enterprise Edition files tab, choose the nxlog-4.1.4181-1.aix6.1.ppc.rpm package.

  2. Use SFTP or a similar secure method to transfer the archive to the target server.

  3. Install the required NXLog package.

    1. Optional: To change the NXLog user and group for the installation, set the NXLOG_USER and NXLOG_GROUP environment variables. The specified user and group will be created, used for the User and Group directives in nxlog.conf, and used for the ownership of some directories under /opt/nxlog. Specifying an already existing user or group is not supported. The created user and group will be deleted on NXLog removal.

      # export NXLOG_USER=nxlog2
      # export NXLOG_GROUP=nxlog2
    2. Use rpm to install the package.

      # rpm -ivh nxlog-4.1.4181-1.aix6.1.ppc.rpm
  4. Configure NXLog by editing /opt/nxlog/etc/nxlog.conf. See the IBM AIX section for AIX specific configuration. General information about configuring NXLog can be found in Configuration.

  5. Verify the configuration file syntax.

    # /opt/nxlog/bin/nxlog -v
    2017-03-17 08:05:06 INFO configuration OK
  6. Start the service using the init script in /opt/nxlog/etc:

    # ./init start

16.2. Upgrading

To update an NXLog installation to the latest release, use rpm as in the installation instructions above.

# rpm -Uvh nxlog-4.1.4181-1.aix6.1.ppc.rpm
Note
The rpm package manager creates a backup of an existing nxlog.conf file as nxlog.conf.rpmsave under the /opt/nxlog/etc/ directory.
Note
The same user and group will be used for the upgrade as was used for the original installation (see installation step 3a above). Changing to a different user and group during upgrade is not supported.

16.3. Uninstalling

To uninstall NXLog use rpm with the -e option.

# rpm -e nxlog
Note
This procedure may not remove all files that were created in order to configure NXLog, or that were created as a result of NXLog’s logging operations. To find these files, consult the configuration files that were used with NXLog and check the installation directory (/opt/nxlog).

17. Oracle Solaris

17.1. Installing

  1. Download the appropriate NXLog install archive from the NXLog website.

    1. Log in to your account, then click My account at the top of the page.

    2. Under the Downloads  My downloads tab, choose the correct archive for your system.

      Table 49. Available Solaris Files
      Platform Archive

      Solaris 10/11 x86 archive

      nxlog-4.1.4181_solaris-x86.pkg.gz

      Solaris 10/11 SPARC archive

      nxlog-4.1.4181_solaris-sparc.pkg.gz

  2. Use SFTP or a similar secure method to transfer the archive to the target server.

  3. Log in to the target server and extract the contents of the archive.

    $ gunzip nxlog-4.1.4181_solaris-sparc.pkg.gz
  4. Optional: To change the NXLog user and group for the installation, create a /var/sadm/install/admin/nxlog-user_group file with the following command. The specified user and group will be created, used for the User and Group directives in nxlog.conf, and used for the ownership of some directories under /opt/nxlog. Specifying an already existing user or group is not supported. The created user and group will be deleted on NXLog removal.

    $ echo 'nxlog2:nxlog2' > /var/sadm/install/admin/nxlog-user_group
  5. Install the NXLog package.

    • For interactive installation, issue the following command and answer y (yes) to the questions.

      $ sudo pkgadd -d nxlog-4.1.4181.pkg NXnxlog
    • For a quiet install, use an administration file. Place the file (nxlog-adm in this example) in the /var/sadm/install/admin/ directory.

      $ sudo pkgadd -n -a nxlog-adm -d nxlog-4.1.4181.pkg NXnxlog
      nxlog-adm
      mail=
      instance=overwrite
      partial=nocheck
      runlevel=nocheck
      idepend=nocheck
      rdepend=nocheck
      space=quit
      setuid=nocheck
      conflict=nocheck
      install
      action=nocheck
      basedir=/opt/nxlog
      networktimeout=60
      networkretries=3
      authentication=quit
      keystore=/var/sadm/security
      proxy=
  6. Configure NXLog by editing /opt/nxlog/etc/nxlog.conf. General information about configuring NXLog can be found in Configuration. For more details about configuring NXLog to collect logs on Solaris, see the Oracle Solaris summary.

  7. Verify the configuration file syntax.

    $ sudo /opt/nxlog/bin/nxlog -v
    2017-03-17 08:05:06 INFO configuration OK
  8. Check that the NXLog service is running with the svcs command.

    $ svcs nxlog
     online     12:40:37 svc:system/nxlog:default
  9. Manage the NXLog service with svcadm (restart the service to load the edited configuration file).

    $ sudo svcadm restart nxlog
    $ sudo svcadm enable nxlog
    $ sudo svcadm disable nxlog

17.2. Upgrading

To update an NXLog installation to the latest release, remove the old version and then install the new version.

  1. Before removing the old version, run the backup script from /opt/nxlog/bin/backup. The backup script will create a backup directory in /opt (the directory will be named according to this format: /opt/nxlog-backup-YYYYMMDD_hhmmss).

    $ sudo bash /opt/nxlog/bin/backup
  2. To uninstall NXLog, use pkgrm as shown in the uninstallation instructions below.

    $ sudo pkgrm NXnxlog
  3. To install the new NXLog release, use pkgadd as in the installation instructions above.

    $ sudo pkgadd -d nxlog-4.1.4181.pkg NXnxlog
  4. After reinstalling NXLog, use the restore script from the latest backup directory to restore data to the new NXLog installation.

    $ sudo bash /opt/nxlog-backup-20180101_000001/restore
  5. Optional: To discard the backup files, remove the backup directory.

    $ sudo rm -rf /opt/nxlog-backup-20180101_000001

To replace a trial installation of NXLog Enterprise Edition with a licensed copy of the same version, follow the same installation instructions (use instance=overwrite as shown).

17.3. Uninstalling

To uninstall NXLog, use pkgrm. To remove the package files from the client’s file system, include the -A option.

$ sudo pkgrm NXnxlog
Note
This procedure may not remove all files that were created in order to configure NXLog, or that were created as a result of NXLog’s logging operations. To find these files, consult the configuration files that were used with NXLog and check the installation directory (/opt/nxlog).

18. Hardening NXLog

18.1. Running Under a Non-Root User on Linux

NXLog can be configured to improve security by running under a specified user and group rather than retaining root privileges. The User and Group global directives specify the user and group for the NXLog process to run under. By default on Linux installations, NXLog is configured to run under the nxlog user and nxlog group as shown below.

Running as nxlog:nxlog
1
2
User nxlog
Group nxlog

Some operations require privileges that are normally not available to the nxlog user. In this case, the simplest solution is to configure NXLog to retain full root privileges by removing the User and Group directives from the configuration. This is not recommended, however; it is more secure to provide only the required privileges and to avoid running NXLog as root. See the following sections for more information.

18.1.1. Reading From /var/log

By default, the nxlog user will not have access to files in /var/log. If your Linux distribution uses a group other than root for the log files, you can use that group with the Group directive. Otherwise, reconfigure your system logger (Rsyslog for example) to create files with the necessary ownership. See Reading Rsyslog Log Files for more information.

18.1.2. UDP Spoofing and Binding to Ports Below 1024

NXLog requires special privileges if configured to perform UDP source address spoofing (with om_udpspoof) or to bind to a port below 1024 (for example to accept incoming Syslog messages on port 514). Consider the following solutions.

Use built-in capability support

NXLog will automatically set the corresponding Linux capability before dropping root privileges.

Set the capability manually

For binding to ports below 1024, use the CAP_NET_BIND_SERVICE capability. For the UDP source address spoofing, use the CAP_NET_RAW capability.

Example 7. Setting Linux Capabilities

This command sets the CAP_NET_BIND_SERVICE capability for the NXLog executable.

# setcap cap_net_bind_service+ep /opt/nxlog/bin/nxlog

This command sets both the CAP_NET_BIND_SERVICE and the CAP_NET_RAW capabilities.

# setcap cap_net_bind_service,cap_net_raw=+ep /opt/nxlog/bin/nxlog

Verify with this command, or by adding the -v (verify) flag to the setcap command.

# getcap /opt/nxlog/bin/nxlog

18.1.3. Reading the Kernel Log

NXLog requires special privileges to read from the Linux kernel log with the im_kernel module. Consider the following solutions.

Use built-in capability support

NXLog will automatically set the Linux CAP_SYS_ADMIN capability before dropping root privileges.

Set the capability manually

Use the CAP_SYS_ADMIN capability or the CAP_SYSLOG capability (since Linux 2.6.37). See Setting Linux Capabilities.

18.2. Configuring SELinux

To further harden NXLog, SELinux can optionally be used. SELinux improves security by providing mandatory access controls on Linux. This section provides an overview for creating an SELinux policy for NXLog. The resulting policy will provide the permissions necessary for the NXLog deployment to operate as configured, with SELinux enabled on the host.

The process is divided into two parts. First, a base policy is created. Then the policy is deployed and tailored to the specific requirements of the current NXLog configuration.

18.2.1. Base Policy

The base policy file can be generated with the SELinux Policy Generation Tool (which requires a graphical environment) or with the SELinux CLI development utilities.

In either case, the following policy files are generated:

nxlog.te

Base policy information; this file defines all the types and rules for a particular domain.

nxlog.fc

File system information; this file defines he security contexts that are applied to files when the policy is installed.

nxlog.if

Interface information; this file defines the default file context for the system.

nxlog.sh

A helper shell script for compiling and deploying the policy module and fixing the labeling on the system; for use only on the target system.

nxlog_selinux.spec

A specification file that can be used to generate an RPM package from the policy, useful for deploying the policy on another system later. This spec file is generated on RPM-based systems only.

18.2.1.1. Base Policy Using Policy Generation Tool (GUI)
  1. Install the SELinux Policy Generation Tool package.

    On Red Hat based systems run the following command:

    $ sudo yum install rpm-build policycoreutils-gui

    On Debian based systems run the following command:

    $ sudo apt-get install policycoreutils-gui
  2. Start the SELinux Policy Generation Tool from the system launcher.

  3. In the first screen, select Standard Init Daemon for the policy type, then click Forward.

    SELinux Policy Generation Tool, screen 1
  4. On the second screen, enter the following details for the application and user role, then click Forward.

    Name

    A custom name for the role (for example, nxlog)

    Executable

    The path to the NXLog executable (for example, /opt/nxlog/bin/nxlog)

    Init script

    The path of the NXLog system init script (for example, /etc/rc.d/init.d/nxlog)

    SELinux Policy Generation Tool, screen 2
  5. On the third screen, enter the TCP and UDP used by the NXLog deployment, then click Forward. If the ports are unknown or not yet determined, then leave these fields blank; they can be customized later.

    SELinux Policy Generation Tool, screen 3
  6. On the fourth screen, select the appropriate application traits for NXLog, then click Forward. The default configuration requires only the Interacts with the terminal trait. For collecting Syslog messages or creating files in /tmp, include the appropriate traits.

    SELinux Policy Generation Tool, screen 4
  7. On the fifth screen, specify all the arbitrary files and directories that the NXLog installation should have access to, then click Forward. The default configuration requires only the NXLog system directory, /opt/nxlog. Include the paths of any custom log files that NXLog needs to access.

    SELinux Policy Generation Tool, screen 5
  8. Additional SELinux configuration values can be set on the sixth screen. None of these are required for NXLog. Click Forward to continue.

  9. The policy files are generated on the final screen. Click Save to write the policy to disk.

18.2.1.2. Base Policy Using sepolicy (CLI)
  1. Install the SELinux Policy Core Policy Devel Utilities package.

    On Red Hat based systems run the following command:

    $ sudo yum install rpm-build policycoreutils-devel

    On Debian based systems run the following command:

    $ sudo apt-get install policycoreutils-dev selinux-policy-default
  2. The base policy can be generated with the following command.

    $ sepolicy generate -n nxlog --init /opt/nxlog/bin/nxlog -w /opt/nxlog
    Note
    Additional managed directories can be added to the policy by passing to the -w parameter the full directory paths separated by spaces (for example, -w /opt/nxlog /var/log).
  3. The policy files are generated when the command exits successfully; the policy is written to the current working directory.

18.2.2. Deploying and Customizing the Policy

In this section, the base policy generated in the previous section will be applied and then customized with appropriate rules for NXLog operation as configured. To accomplish this, SELinux will be set to permissive mode and then the audit2allow tool will be used to generate additional SELinux rules based on the resulting audit logs.

Warning
When set to permissive mode, SELinux generates alerts rather than actively blocking actions as it does in enforcing mode. Because this reduces system security, it is recommended that this be done in a test environment.
  1. Make sure that NXLog is correctly configured with all required functionality.

  2. Stop the NXLog service.

  3. Transfer the files containing your SELinux base policy to the target system. All the files should be in the same directory.

  4. Apply the SELinux base policy by executing the policy script. This script will compile the policy module, set the appropriate security flags on the directories specified, and install the policy.

    $ sudo ./nxlog.sh
    Note

    You may see the error message libsemanage.add_user: user system_u not in password file. This is caused by a bug in the selinux-policy RPM or selinux-policy-default DEB package and does not affect the policy at all. It has been fixed in later releases.

    You may see the error message InvalidRBACRuleType: a is not a valid RBAC rule type. This is from a bug in the policycoreutils package. It only affects man page generation, which is not generated in this case. This has been fixed in later releases.

  5. Verify that the new policy is installed.

    $ sudo semodule -l | grep nxlog
  6. Set SELinux to permissive mode. All events which would have been prevented by SELinux will now be permitted and logged to /var/log/audit/audit.log (including events not related to NXLog).

    $ sudo setenforce 0
  7. Start and then stop the NXLog service. Any actions taken by NXLog that are not permitted by the policy will result in events logged by the Audit system. Run audit2allow -a -l -w to view all policy violations (with descriptions) since the last policy reload.

    $ sudo systemctl start nxlog
    $ sudo systemctl stop nxlog
    Example 8. Audit Logs

    If NXLog has been configured to listen on TCP port 1514, but the appropriate rules are not specified in the current SELinux policy, then various audit events will be generated when the NXLog process initializes and binds to that port. These events can be viewed from the Audit log file directly, with ausearch, or with audit2allow (as shown below).

    $ sudo audit2allow -a -l -w
    type=AVC msg=audit(1524239322.612:473): avc:  denied  { listen } for  pid=5697 comm="nxlog" lport=1514 scontext=system_u:system_r:nxlog_t:s0 tcontext=system_u:system_r:nxlog_t:s0 tclass=tcp_socket
        Was caused by:
            Missing type enforcement (TE) allow rule.
    
            You can use audit2allow to generate a loadable module to allow this access.

    Additional log messages will be generated for any other file or network action not permitted by the SELinux policy. These actions would all be denied by SELinux when set to enforcing mode.

  8. Use the helper script --update option to add additional rules to the policy based on logged policy violations with the nxlog context. Review the suggested changes and press y to update the policy. If no changes are required, the script will exit zero.

    $ sudo ./nxlog.sh --update
    Example 9. Updating the Policy

    The script will offer to add any required rules. The following output corresponds to the example in the previous step.

    $ sudo ./nxlog.sh --update
    Found avc's to update policy with
    
    require {
        type nxlog_rw_t;
        type nxlog_t;
        class capability dac_override;
        class tcp_socket { bind create listen setopt };
        class file execute;
        class capability2 block_suspend;
    }
    
    #============= nxlog_t ==============
    allow nxlog_t nxlog_rw_t:file execute;
    allow nxlog_t self:capability dac_override;
    allow nxlog_t self:capability2 block_suspend;
    allow nxlog_t self:tcp_socket { bind create listen setopt };
    corenet_tcp_bind_generic_node(nxlog_t)
    corenet_tcp_bind_unreserved_ports(nxlog_t)
    Do you want these changes added to policy [y/n]?
  9. Set the SELinux policy to enforcing mode. This can be set permanently in /etc/selinux/config.

    $ sudo setenforce 1
  10. Reboot the system.

18.3. Running Under a Custom Account on Windows

On Windows, the NXLog installer sets up the NXLog service to run under the local system account. This procedure describes how to configure a system service for NXLog that runs under a dedicated svc-nxlog user account. This approach can improve security by limiting the privileges that NXLog requires to run.

Note
In enterprise environments managed by Group Policy, the dedicated user account and its permissions must be managed by the domain administrator.
  1. Create a new user account. Open the Computer Management console (compmgmt.msc), right-click on Local Users and Groups  Users, and select New User…​ from the context menu.

    Users context menu
  2. Enter the svc-nxlog user name, description, and password; enable the Password never expires check box; and click Create.

    New User dialog
  3. Open the Services console (services.msc), right-click the nxlog service, and select Properties.

    Service properties context menu
  4. Under the Log On tab, select the This Account radio button, click Browse…​, select the svc-nxlog user account, and enter the password. Then click OK. Windows will warn you that the service must be restarted.

    nxlog service Select User window
  5. Open the Local Security Settings console (secpol.msc) and select Local Policies  User Rights Assignment in the left pane.

    Local Security Settings console
  6. Right-click the Log on as a service policy and click Properties.

    Security policy: Log on as a service
  7. Click Add User or Group…​ and select the new user. The new user should appear in the list. Click OK.

    Log on as a service Properties
  8. Add the new user to the the Manage auditing and security log policy also.

  9. In Windows Explorer, browse to the NXLog installation directory (by default, C:\Program Files (x86)\nxlog on 64-bit systems), right-click, and select Properties. Under the Security tab, select the new user from the Group or user names list. Check Allow for the following permissions, and then click OK.

    • Modify

    • Read & Execute

    • List Folder Contents

    • Read

    • Write

    nxlog Folder Security Properties
  10. In the Services console (services.msc), right-click the nxlog service and select Restart.

    Restarting the nxlog service
  11. Check the NXLog log files for start-up errors. Successful startup should look like this:

    nxlog.log
    2016-11-16 16:53:10 INFO nxlog-4.1.4181 started
    2016-11-16 16:53:10 INFO connecting to 192.168.40.43
    2016-11-16 16:53:12 INFO successfully connected to 192.168.40.43:1514
    2016-11-16 16:53:12 INFO successfully connected to agent manager at 192.168.40.43:4041 in SSL mode
Note

On some Windows systems, this procedure may result in the following access denied error when attempting to access the Windows EventLog:

WARNING ignoring source as it cannot be subscribed to (error code: 5)

In this case, wevtutil can be used to set ACLs on the Windows EventLog. For more details, see the Giving Non Administrators permission to read Event Logs Windows 2003 and Windows 2008 TechNet article.

19. Relocating NXLog

While not officially supported, it is possible to relocate NXLog to a different directory than where it was installed originally. The procedure shown below assumes that NXLog was installed normally, using the system’s package manager. While it is also possible to manually extract the files from the package and perform a manual installation in a custom directory, this is not covered here but the basic principals are the same. This procedure has been tested in GNU/Linux systems and should work in any system that supports run-time search paths.

Warning
Both relocation and manual installation can result in a non-functional NXLog agent. Furthermore, subsequent update and removal using the system’s package manager may not work correctly. Follow this procedure at your own risk. This is not recommended for inexperienced users.

Move the NXLog directory structure to the new location. Though not required, it is best to keep the original directory structure. Then proceed to the following sections.

Note
In the examples that follow, NXLog is being relocated from /opt/nxlog to /opt/nxlog_new.

19.1. System V Init File

For systems that manage services with System V, edit the NXLog init file. This file can normally be found at /etc/init.d/nxlog. Modify the init file so that the $BASE variable reflects the new directory. Update the $pidfile, $nxlog, and $conf variables to reference $BASE. Finally, reassign the $nxlog variable to include the configuration file. This must be done after any tests to the binary executable. The init file should look similar to the following.

/etc/init.d/nxlog
BASE=/opt/nxlog_new

pidfile=$BASE/var/run/nxlog/nxlog.pid
nxlog=$BASE/bin/nxlog
conf=$BASE/etc/nxlog.conf

test -f $nxlog || exit 0

nxlog="$nxlog -c $conf"

On systems that use a hybrid System V and Systemd, reload the init files by executing the following command.

# systemctl daemon-reload

19.2. Systemd Unit File

For systems using Systemd, the /lib/systemd/system/nxlog.service unit file must be edited and the paths updated.

nxlog.service
[Service]
Type=simple
User=root
Group=root
PIDFile=/opt/nxlog_new/var/run/nxlog/nxlog.pid
ExecStartPre=/opt/nxlog_new/bin/nxlog -v -c /opt/nxlog_new/etc/nxlog.conf
ExecStart=/opt/nxlog_new/bin/nxlog -f -c /opt/nxlog_new/etc/nxlog.conf
ExecStop=/opt/nxlog_new/bin/nxlog -s -c /opt/nxlog_new/etc/nxlog.conf
ExecReload=/opt/nxlog_new/bin/nxlog -r -c /opt/nxlog_new/etc/nxlog.conf
KillMode=process

Reload the modified unit files by executing the following command.

# systemctl daemon-reload

19.3. Edit Configuration File

The configuration file of NXLog itself must be modified to reflect the directory relocation, as well as any changes in the directory structure. For most cases, running sed -i s,/opt/nxlog,/opt/nxlog_new,g /opt/nxlog_new/etc/nxlog.conf will update the configuration file. Alternatively, edit the file manually as shown below.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
define BASE /opt/nxlog_new
define CERTDIR %BASE%/var/lib/nxlog/cert
define CONFDIR %BASE%/var/lib/nxlog
define LOGDIR %BASE%/var/log/nxlog
define LOGFILE "%LOGDIR%/nxlog.log"

SpoolDir %BASE%/var/spool/nxlog

# default values:
PidFile %BASE%/var/run/nxlog/nxlog.pid
CacheDir %BASE%/var/spool/nxlog
ModuleDir %BASE%/lib/nxlog/modules
Note
Depending on the architecture and whether system supplied libraries are used, NXLog will store the modules under a different directory such as %BASE%/libexec/nxlog/modules.

19.4. Modify rpath

Depending on the NXLog package used, the run-time search path of the binaries must be changed. This is relevant for the generic versions of NXLog where the libraries are statically linked against the binaries. To check the shared libraries used by the binaries, issue the following command.

# ldd nxlog
        linux-vdso.so.1 =>  (0x00007ffc15d36000)
        libpcre.so.1 => /opt/nxlog/lib/libpcre.so.1 (0x00007ff7f311e000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007ff7f2f14000)
        libcap.so.2 => /lib64/libcap.so.2 (0x00007ff7f2d0f000)
        libapr-1.so.0 => /opt/nxlog/lib/libapr-1.so.0 (0x00007ff7f2ad9000)
        librt.so.1 => /lib64/librt.so.1 (0x00007ff7f28d0000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007ff7f2699000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ff7f247d000)
        libc.so.6 => /lib64/libc.so.6 (0x00007ff7f20bb000)
        /lib64/ld-linux-x86-64.so.2 (0x00007ff7f336d000)
        libattr.so.1 => /lib64/libattr.so.1 (0x00007ff7f1eb6000)
        libfreebl3.so => /lib64/libfreebl3.so (0x00007ff7f1cb3000)

Notice that libpcre and libapr are pointing to the included libraries in /opt/nxlog/lib/. To change the run-time search path of the binaries, a tool such as chrpath or patchelf can be used.

# chrpath -r /opt/nxlog_new/lib nxlog
        nxlog: RPATH=/opt/nxlog/lib:/home/builder/workspace/nxlog3-rpm-generic-amd64/rpmbuild/BUILD/nxlog-deps/opt/nxlog/lib
        nxlog: new RPATH: /opt/nxlog_new/lib

NXLog modules are also linked against statically included libraries. Therefore, if the run-time search path of the binaries required a change, then the rpath of the modules needs updated as well. To change the run-time search path of all the modules (or binaries) in a directory, use a command like this.

# chrpath -r /opt/nxlog_new/lib *

NXLog is now successfully relocated to a new directory.

20. Monitoring and Recovery

While considerable effort is put into eliminating software bugs from NXLog, no complex piece of software is perfect. This section describes potential ways to automatically recover from an error that results in a crash of NXLog. Note that there are other monitoring solutions than those shown here which may also be of interest.

20.1. Recovery on Unix Platforms

Monit can be used on several flavors of Unix and macOS to both monitor and recover NXLog after a crash. Monit can be installed directly from your distribution’s package manager—see Installation on the Monit wiki for more information about installing Monit. Precompiled binaries can also be found here.

While Monit can monitor and react to several conditions, the requirement presented here is to restart NXLog after a crash. To do so, include the following in the Monit configuration. It may be necessary to adjust the paths for the particular installation. Then restart Monit.

/etc/monit/monitrc
check process nxlog with pidfile /opt/nxlog/var/run/nxlog/nxlog.pid
   start program = "/etc/init.d/nxlog start"
   stop program  = "/etc/init.d/nxlog stop"
Note
On recent Linux distributions employing systemd, the start and stop directives should use systemd calls instead (for example, /bin/systemctl start nxlog).

To simulate an NXLog crash, execute the following in a shell (<PID> is the process ID of NXLog).

# kill -9 <PID>

20.2. Recovery on Windows

The service control manager (SCM) in Microsoft Windows includes recovery options, as shown below; these can be adjusted as required.

SCM Recovery
Figure 2. Recovery settings in SCM
Note
Newer versions of NXLog will enable automatic recovery during the installation. For older versions, automatic recovery can be enabled by manually editing the values in the recovery tab of the SCM.

To simulate an NXLog crash, execute the following in PowerShell (<PID> is the process ID of NXLog).

PS> Taskkill /PID <PID> /F

Configuration

21. Configuration Overview

NXLog uses Apache style configuration files. The configuration file is loaded from its default location, or it can be explicitly specified with the -c command line argument.

The configuration file is made up of blocks and directives. Blocks are similar to XML tags containing multiple directives. Directive names are case insensitive but arguments are case sensitive in some cases. A directive and its argument must be specified on the same line. Values spanning multiple lines must have the newline escaped with the backslash (\). A typical case for this is the Exec directive. Blank lines and lines starting with the hash mark (#) are ignored. Configuration directives referring to a file or a path can be quoted with double quotes (") or single quotes ('). This applies to both global and module directives.

The configuration file can be logically divided into three parts: global parameters, module instances, and route instances.

Example 10. Configuration File Structure

Here are the three sections of a configuration file. This example contains two global directives, Input and Output blocks, and a Route block.

nxlog.conf
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# Global section
User        nxlog
Group       nxlog

# Modules section
<Input in>
    Module  im_null
</Input>

<Output out>
    Module  om_null
</Output>

# Route section
<Route r>
    Path    in => out
</Route>

21.1. Global Directives

The global section contains directives that control the overall behavior of NXLog.

The LogFile directive sets a destination file for NXLog internal logs. If this directive is unset, the log file is disabled and internal NXLog logs are not written to file (unless configured via the im_internal module). See also Rotating the Internal Log File.

With the User and Group directives set, NXLog will drop root privileges after starting and run under the specified user and group. These directives are ignored if running on the Windows platform.

After starting, NXLog will change its working directory to the directory specified by the SpoolDir directive. Non-absolute paths in the configuration will be relative to this directory.

See the Reference Manual for a complete list of available global directives.

21.2. Modules

NXLog will only load modules which are specified in the configuration file and used in an active route. A module instance is specified according to its corresponding module type (Extension, Input, Processor, or Output). Each module instance must have a unique name and a Module directive. The following is a skeleton configuration block for an input module.

nxlog.conf
1
2
3
4
<Input instancename>
    Module  im_module
    ...
</Input>

For more details about module instance names, see Configuration in the Reference Manual.

21.3. Routes

Routes define the flow and processing order of the log messages. Each route instance must have a unique name and a Path.

Example 11. Route Block

This Route instance, named example, takes logs from Input module instances named in1 and in2, processes the logs with the proc Processor module instance, and sends the resulting logs to both Output module instances out1 and out2. These named module instances must be defined elsewhere in the configuration file.

nxlog.conf
1
2
3
<Route example>
    Path    in1, in2 => proc => out1, out2
</Route>

For more details about route instance names, see Configuration in the Reference Manual.

If no Route block is specified in the configuration, NXLog will automatically generate a route, with all the Input and Output instances specified in a single path.

Example 12. An Automatic Route Block

NXLog can use a configuration with no Route block, such as the following.

nxlog.conf
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<Input in1>
    Module  im_null
</Input>

<Input in2>
    Module  im_null
</Input>

<Output out1>
    Module  om_null
</Output>

<Output out2>
    Module  om_null
</Output>

The following Route block will be generated automatically.

nxlog.conf (Generated Route)
1
2
3
<Route r>
    Path    in1, in2 => out1, out2
</Route>

21.4. Constant and Macro Definitions

A define is useful if there are many instances in the configuration where the same value must be used. Typically, defines are used for directories and hostnames. In such cases the value can be configured with a single definition. In addition to constants, other strings like code snippets or parser rules can be defined in this way.

An NXLog define works in a similar way to the C language, where the pre-processor substitutes the value in places where the macro is used. The NXLog configuration parser replaces all occurrences of the defined name with its value, and then after this substitution the configuration check occurs.

Example 13. Using Defines

This example shows the use of two defines: BASEDIR and IGNORE_DEBUG. The first is a simple constant, and its value is used in two File directives. The second is an NXLog language statement, it is used in an Exec directive.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
define BASEDIR /var/log
define IGNORE_DEBUG if $raw_event =~ /debug/ drop();

<Input messages>
    Module  im_file
    File    '%BASEDIR%/messages'
</Input>

<Input proftpd>
    Module  im_file
    File    '%BASEDIR%/proftpd.log'
    Exec    %IGNORE_DEBUG%
</Input>

The define directive can be used for statements as shown above, but multiple statements should be specified using a code block, with curly braces ({}), to result in the expected behavior.

Example 14. Incorrect Use of a Define

The following example shows an incorrect use of the define directive. After substitution, the drop() procedure will always be executed; only the warning message will be logged conditionally.

nxlog.conf (incorrect)
1
2
3
4
5
6
7
define ACTION log_warning("dropping message"); drop();

<Input in>
    Module  im_file
    File    '/var/log/messages'
    Exec    if $raw_event =~ /dropme/ %ACTION%
</Input>

To avoid this problem, the action should be defined using a code block.

1
define ACTION { log_warning("dropping message"); drop(); }

21.5. Environment Variables

The envvar directive works like define except that the value is retrieved from the environment. This makes it possible to reference the environment variable as if it was a define. This directive is only available in NXLog Enterprise Edition.

Example 15. Using Environment Variables

This is similar to the previous example using a define, but here the value is fetched from the environment.

nxlog.conf [Download file]
1
2
3
4
5
6
envvar BASEDIR

<Input in>
    Module  im_file
    File    '%BASEDIR%/messages'
</Input>

21.6. File Inclusion

NXLog provides several features for including configuration directives and blocks from separate files or from executables.

Note
The SpoolDir directive does not take effect until after the configuration has been parsed, so relative paths specified with these directives are relative to the working directory where NXLog was started from. Generally, it is recommended to use absolute paths. If desired, define directives can be used to simulate relative paths (see Using Defines to Include a Configuration File).

With the include directive it is possible to specify a file or set of files to be included in the current configuration file.

Example 16. Including a Configuration File

This example includes the contents of the /opt/nxlog/etc/syslog.conf file in the current configuration.

nxlog.conf
1
include /opt/nxlog/etc/syslog.conf
Example 17. Using Defines to Include a Configuration File

In this example for Windows, two define directives are used to include an eventlog.conf configuration file.

nxlog.conf [Download file]
1
2
3
define ROOT C:\Program Files (x86)\nxlog
define CONFDIR %ROOT%\conf
include %CONFDIR%\eventlog.conf

The include directive also supports wildcarded filenames. A set of files in a directory can be included without the need to explicitly list each one. This could be used to specify a drop-in directory for OS-specific configuration snippets (like windows2003.conf) or application-specific snippets (such as syslog.conf).

Example 18. Including a Configuration Directory

This example includes all .conf files in /opt/nxlog/etc/nxlog.d.

nxlog.conf
1
include /opt/nxlog/etc/nxlog.d/*.conf

Because the backslash (\) is used as a path separator on Windows, an additional backslash (\) must be used to prevent the \* from being treated as a literal asterisk (*). The same wildcard rules apply as for the im_file File directive.

nxlog.conf (Windows)
1
include C:\Program Files\nxlog\conf\nxlog.d\\*.conf

With the include_stdout directive, an external command can be used to provide configuration content. There are many ways this could be used, including fetching, decrypting, and validating a signed configuration from a remote host, or generating configuration content dynamically.

Example 19. Using an Executable to Generate Configuration

Here, a separate script is responsible for fetching the NXLog configuration.

nxlog.conf
1
include_stdout /opt/nxlog/etc/fetch_conf.sh

22. NXLog Language

The NXLog core has a built-in interpreted language. This language can be used to make complex decisions or build expressions in the NXLog configuration file. Code written in the NXLog language is similar to Perl, which is commonly used by developers and administrators for log processing tasks. When NXLog starts and reads its configuration file, directives containing NXLog language code are parsed and compiled into a pseudo-code. If a syntax error is found, NXLog will print the error. The pseudo-code is then evaluated at run-time, as with other interpreted languages.

The features of the NXLog language are not limited to those in the NXLog core: modules can register functions and procedures to supplement the built-in functions and procedures (see the xm_syslog functions, for example).

Note
Due to the simplicity of the language there is no error handling (except for function return values) available to the user. If an error occurs during the execution of the NXLog pseudo-code, usually the error is printed in the NXLog logs. If an error occurs during log message processing it is also possible for the message to be dropped. If sophisticated error handling or more complex processing is required, the message processing can be implemented in an external script or program via the xm_exec module, in a dedicated NXLog module, or in Perl via the xm_perl module.

The NXLog language is described in five sections.

Types

All fields and other expressions in the NXLog language are typed.

Expressions

An expression is evaluated to a value at run-time and the value is used in place of the expression. All expressions have types. Expressions can be used as arguments for some module directives.

Statements

The evaluation of a statement will cause a change in the state of the NXLog engine, the state of a module instance, or the current event. Statements often contain expressions. Statements are used as arguments for the Exec module directive, where they are then executed for each event (unless scheduled).

Variables

Variables store data persistently in a module instance, across multiple event records.

Statistical Counters

NXLog provides statistical counters with various algorithms that can be used for realtime analysis.

Example 20. Statements vs. Configurations

While this Guide provides many configuration examples, in some cases only statement examples are given. Statements must be used with the Exec directive (or Exec block). The following statement example shows a way to use the parsedate() function.

1
2
if $raw_event =~ /^(\w{3} \d{2} \d{2}:\d{2}:\d{2})/
    $EventTime = parsedate($1);

The following configuration example uses the above statement in an Exec block.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
<Input in>
    Module  im_file
    File    '/var/log/app.log'
    <Exec>
        if $raw_event =~ /^(\w{3} \d{2} \d{2}:\d{2}:\d{2})/
            $EventTime = parsedate($1);
    </Exec>
</Input>

22.1. Types

The NXLog language is a typed language. Fields, literals, and other expressions evaluate to values with specific types. This allows for stricter type-safety syntax checking when parsing the configuration. Note that fields and some functions can return values with types that can only be determined at run-time.

Note
The language provides only simple types, complex types such as arrays and hashes (associative arrays) are not supported. The language does support the undefined value similar to that in Perl. See the xm_perl module if you require more complex types.

A log format must be parsed before its individual parts can be used for processing (see Fields). But even after the message has been parsed into its parts, additional processing may still be required to, for example, prepare a timestamp for comparison with another timestamp. This is where typing is helpful: by converting all timestamps to datetime types, they can be easily compared and later converted to strings if required using provided functions and procedures. The same applies to other types.

Example 21. Typed Fields in a Syslog Event Record

The following input configuration, and list below, show the processing of typed fields in a Syslog event record.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<Input in>
    # 1. New event record created
    Module  im_udp
    Host    0.0.0.0
    Port    514
    <Exec>
        # 2. Timestamp parsed from Syslog header
        if $raw_event =~ /^(\w{3} \d{2} \d{2}:\d{2}:\d{2})/
        {
            # 3. parsedate() function converts from string to datetime
            $EventTime = parsedate($1);
            # 4. Datetime fields compared
            if ( $EventReceivedTime - $EventTime ) > 60000000
                log_warning('Message delayed more than 1 minute');
        }
    </Exec>
</Input>
  1. NXLog creates a new event record for the incoming log message. The new event record contains the $raw_event string type field, with the contents of the entire Syslog string.

  2. A regular expression is used to parse the timestamp from the event. The captured sub-string is a string type, not a datetime type.

  3. The parsedate() function converts the captured string to a datetime type.

  4. Two datetime fields are compared to determine if the message was delayed during delivery. The datetime type $EventReceivedTime field is added by NXLog to each event when it is received.

Note
Normally the parse_syslog() procedure (provided by the xm_syslog extension module) would be used to parse a Syslog event. It will create fields with the appropriate types during parsing, eliminating the need to directly call the parsedate() function. See Collecting and Parsing Syslog.

For a full list of types, see the Reference Manual Types section. For NXLog language core functions that can be used to work with types, see Functions. For functions and procedures that can work with types related to a particular format, see the module corresponding to the required format.

22.2. Expressions

An expression is a language element that is dynamically evaluated to a value at run-time. The value is then used in place of the expression. Each expression evaluates to a type, but not always to the same type.

The following language elements are expressions: literals, regular expressions, fields, operations, and functions.

Expressions can be bracketed by parentheses (()) to help improve code readability.

Example 22. Using Brackets Around Expressions

There are three statements below, one per line. Each statement contains multiple expressions, with parentheses added in various ways.

1
2
3
if 1 + 1 == (1 + 1) log_info("2");
if (1 + 1) == (1 + 1) log_info("2");
if ((1 + 1) == (1 + 1)) log_info("2");

Expressions are often used in statements.

Example 23. Using an Expression in a Statement

This simple statement uses the log_info() procedure with an expression as its argument. The expression, in this case, is a literal.

1
log_info('This message will be logged.');

Here is a function (also an expression) that is used in the same procedure. It generates an internal event with the current time when each event is processed.

1
log_info(now());

Expressions can be used with module directives that support them.

Example 24. Expressions for Directives

The File directive of the om_file module supports expressions. This allows the output filename to be set dynamically for each individual event.

nxlog.conf [Download file]
1
2
3
4
<Output out>
    Module  om_file
    File    "/var/log/nxlog/out_" + strftime($EventTime, "%Y%m%d")
</Output>

See Using Dynamic Filenames for more information.

22.2.1. Literals

A literal is a simple expression that represents a fixed value. Common literals include booleans, integers, and strings. The type of literal is detected by the syntax used to declare it.

Note
This section demonstrates the use of literals by using examples with assignment statements.

Boolean literals are either TRUE or FALSE, and are case-insensitively declared using one of those keywords.

Setting Boolean Literals
1
2
$Important = FALSE;
$Local = true;

Integer literals are declared with an unquoted integer. Negative integers, hexademical notation, and base-2 modifiers (Kilo, Mega, and Giga) are supported.

Setting Integer Literals
1
2
3
4
$Count = 42;
$NegativeCount = -42;
$BigCount = 42M;
$HexCount = 0x2A;

String literals are declared by quoting characters with single or double quotes. Escape sequences are available when using double quotes.

Setting String Literals
1
2
3
4
$Server = 'Alpha';
$Message = 'This is a test message.';
$NumberAsString = '12';
$StringWithNewline = "This is line 1.\nThis is line 2.";

For a list of all available literals, see the Reference Manual Literals section.

22.2.2. Regular Expressions

NXLog supports regular expressions for matching, parsing, and modifying event records. In the context of the NXLog language, a regular expression is an expression that is evaluated to a boolean value at run-time. Regular expressions can be used to define complex search and replacement patterns for text matching and substitution.

Note
Examples in this section use only simple patterns. See Extracting Data and other topic-specific sections for more extensive examples.

Matching can be used with an if statement to conditionally execute a statement.

Example 25. Matching a Field With a Regular Expression

The event record will be discarded if the $raw_event field matches the regular expression.

1
if $raw_event =~ /TEST: / drop();

Regular expression matching can also be used for extensive parsing, by capturing sub-strings for field assignment.

Example 26. Parsing Fields With a Regular Expression

If the $raw_event field contains the regular expression, the two fields will be set to the corresponding captured sub-strings.

1
2
3
4
5
if $raw_event =~ /TEST(\d): (.+)/
{
    $TestNumber = $1;
    $TestName = $2;
}

Regular expression substitution can be used to modify a string. In this case, the regular expression follows the form s/pattern/replace/. The result of the expression will be assigned to the field to the left of the operator.

Example 27. Performing Substitution Using a Regular Expression

The first regular expression match will be removed from the $raw_event field.

1
$raw_event =~ s/TEST: //;

Global substitution is supported with the /g modifier. Without the /g modifier, only the first match in the string will be replaced.

Example 28. Global Regular Expression Substitution

Every whitespace character in the $AlertType field will be replaced with an underscore (_).

1
$AlertType =~ s/\s/_/g;

A statement can be conditionally executed according to the success of a regular expression substitution.

Example 29. Regular Expression Substitution With Conditional Execution

If the substitution succeeds, an internal log message will also be generated.

1
if $Hostname =~ s/myhost/yourhost/ log_info('Updated hostname');

For more information, see the following sections in the Reference Manual: Regular Expressions, =~, and !~.

22.2.3. Fields

When NXLog receives a log message, it creates an event record for it. An event record is a set of fields (see Fields for more information). A field is an expression which evaluates to a value with a specific type. Each field has a name, and in the NXLog language it is represented with the dollar sign ($) prepended to the name of the field, like Perl’s scalar variables.

Fields are only available in an evaluation context which is triggered by a log message. For example, using a value of a field in the Exec directive of a Schedule block will result in a run-time error because the scheduled execution is not triggered by a log message.

Because it is through fields that the NXLog language accesses the contents of an event record, they are frequently referenced. The following examples show some common ways that fields are used in NXLog configurations.

Example 30. Assigning a Value to a Field

This statement uses assignment to set the $Department field on log messages.

1
$Department = 'customer-service';
Example 31. Testing a Field Value

If the $Hostname field does not match, the message will be discarded with the drop() procedure.

1
if $Hostname != 'webserver' drop();
Example 32. Using a Field in a Procedure

This statement will generate an internal event if $SeverityValue integer field is greater than 2 (NXLog INFO severity). The generated event will include the contents of the $Message field.

1
if $SeverityValue > 2 log_warning("ALERT: " + $Message);

22.2.4. Operations

Like other programming languages and especially Perl, the NXLog language has unary operations, binary operations, and the conditional ternary operation. These operations are expressions and evaluate to values.

Unary Operations

Unary operations work with a single operand and evaluate to a boolean value.

Example 33. Using a Unary Operation

This statement uses the defined operator to log a message only if the $Hostname field is defined in the event record.

1
if defined $Hostname log_info('Event received');
Binary Operations

Binary operations work with two operands and evaluate to a value. The type of the evaluated value depends on the type of the operands. Execution might result in a run-time error if the type of the operands are unknown at compile time and then evaluate to types which are incompatible with the binary operation when executed.

Example 34. Using Binary Operations

This statement uses the == operator to drop the event if the $Hostname field matches.

1
if $Hostname == 'testbox' drop();

Here, the + operator is used to concatenate two strings.

1
log_info('Event received from ' + $Hostname);
Ternary Operation

The conditional or ternary operation requires three operands. The first is an expression that evaluates to a boolean. The second is an expression that is evaluated if the first expression is TRUE. The third is an expression that is evaluated if the first expression is FALSE.

Example 35. Using the Ternary Operation

This statement sets the $Important field to TRUE if $SeverityValue is greater than 2, or FALSE otherwise. The parentheses are optional and have been added here for clarity.

1
$Important = ( $SeverityValue > 2 ? TRUE : FALSE );

For a full list of supported operations, see the Reference Manual Operations section.

22.2.5. Functions

A function is an expression which always returns a value. A function cannot be used without using its return value. Functions can be polymorphic: the same function can take different argument types.

Many NXLog language features are provided through functions. As with other types of expressions, and unlike procedures, a function never modifies the state of the NXLog engine, the state of the module, or the current event.

See the list of core functions. Modules can provide additional functions for use with the NXLog language.

Example 36. Function Calls

These statements use the now() function (returning the current time) and the hostname() function (returning the hostname of the system running NXLog) to set fields.

1
2
$EventTime = now();
$Relay = hostname();

Here, any event with a $Message field over 4096 bytes causes an internal log to be generated.

1
if size($Message) > 4096 log_info('Large message received.');

22.3. Statements

The evaluation of a statement will usually result in a change in the state of the NXLog engine, the state of a module, or the log message.

Statements are used with the Exec module directive. A statement is terminated by a semicolon (;).

Example 37. Using a Statement with Exec

With this input configuration, an internal NXLog log message will be generated for each message received.

nxlog.conf [Download file]
1
2
3
4
5
6
<Input in>
    Module  im_udp
    Host    0.0.0.0
    Port    514
    Exec    log_info("Message received on UDP port 514");
</Input>

Multiple statements can be specified, these will be evaluated and executed in order. Statements can also be given on multiple lines by using line continuation or by enclosing the statements in an Exec block.

Example 38. Using Multiple Statements with Exec

This configuration generates an internal log message and sets the $File field.

nxlog.conf [Download file]
1
2
3
4
5
<Input in1>
    Module  im_file
    File    '/var/log/app.log'
    Exec    log_info("App message read from log"); $File = file_name();
</Input>

This is the same, but the backslash (\) is used to continue the Exec directive to the next line.

nxlog.conf [Download file]
1
2
3
4
5
6
<Input in2>
    Module  im_file
    File    '/var/log/app.log'
    Exec    log_info("App message read from log"); \
            $File = file_name();
</Input>

This also is the same, but uses an Exec block instead. The backslash is not necessary here.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
<Input in3>
    Module  im_file
    File    '/var/log/app.log'
    <Exec>
        log_info("App message read from log");
        $File = file_name();
    </Exec>
</Input>

Statements can also be executed based on a schedule, by using the Exec directive of a Schedule block. The Exec directive is slightly different in this case: because its execution is based on a schedule rather than a log event, there is no associated event record. The $File field assignment in the example above would be impossible.

Example 39. Using a Statement in a Schedule

This input instance will generate an hourly internal log event.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
<Input syslog_udp>
    Module  im_udp
    Host    0.0.0.0
    Port    514
    <Schedule>
        When    @hourly
        Exec    log_info("The syslog_udp input module instance is active.");
    </Schedule>
</Input>
Note
Similar functionality is implemented by the im_mark module.

22.3.1. Assignment

Each event record is made up of fields, and assignment is the primary way that a value is written to a field in the NXLog language. The assignment operation is declared with an equal sign (=). This operation loads the value from the expression evaluated on the right into an event record field on the left.

Example 40. Using Field Assignment

This input instance uses assignment operations to add two fields to each event record.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
<Input in>
    Module  im_file
    File    '/var/log/messages'
    <Exec>
        $Department = 'processing';
        $Tier = 1;
    </Exec>
</Input>

22.3.2. Block

Statements can be declared inside a block by surrounding them with curly braces ({}). A statement block in the configuration is parsed as if it were a single statement. Blocks are typically used with conditional statements.

Example 41. Using Statement Blocks

This statement uses a block to execute two statements if the $Message field matches.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
<Input in>
    Module  im_file
    File    '/var/log/messages'
    <Exec>
        if $Message =~ /^br0:/
        {
            log_warning('br0 interface state changed');
            $Tag = 'network';
        }
    </Exec>
</Input>

22.3.3. Procedures

While functions are expressions that evaluate to values, procedures are statements that perform actions. Both functions and procedures can take arguments. Unlike functions, procedures never return values. Instead, a procedure modifies its argument, the state of the NXLog engine, the state of a module, or the current event. Procedures can be polymorphic: the same procedure can take different argument types.

Many NXLog language features are provided through procedures. See the list of available procedures. Modules can provide additional procedures for use with the NXLog language.

Example 42. Using a Procedure

This example uses the parse_syslog() procedure, provided by the xm_syslog module, to parse each Syslog-formatted event record received via UDP.

nxlog.conf [Download file]
1
2
3
4
5
6
<Input in>
    Module  im_udp
    Host    0.0.0.0
    Port    514
    Exec    parse_syslog();
</Input>

22.3.4. If-Else

The if or conditional statement allows a statement to be executed based on the boolean value of an expression. When the boolean is TRUE, the statement is executed. An optional else keyword can be followed by another statement to be executed if the boolean is FALSE.

Example 43. Using If Statements

This example uses an if statement and the drop() procedure to discard any event that matches the regular expression.

nxlog.conf [Download file]
1
2
3
4
5
<Input in1>
    Module  im_file
    File    '/var/log/messages'
    Exec    if $raw_event =~ /junk/ drop();
</Input>

Here, any event not matching the regular expression will be dropped.

nxlog.conf [Download file]
1
2
3
4
5
<Input in2>
    Module  im_file
    File    '/var/log/messages'
    Exec    if not ($raw_event =~ /important/) drop();
</Input>

Finally, this statement shows more extensive use of the if statement, with an else clause and blocks defined by curly braces ({}).

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<Input in3>
    Module  im_file
    File    '/var/log/messages'
    <Exec>
        if $raw_event =~ /alert/
        {
            log_warning('Detected alert message');
        }
        else
        {
            log_info('Discarding non-alert message');
            drop();
        }
    </Exec>
</Input>

22.4. Variables

While NXLog provides fields for storing data during the processing of an event, they are only available for the duration of that event record and can not be used to store a value across multiple events. For this purpose, module variables can be used. A variable stores a value for the module instance where it is set. It can only be accessed from the same module where it was created: a variable with the same name is a different variable when referenced from another module.

Each module variable can be created with an expiry value or an infinite lifetime. If an expiry is used, the variable will be destroyed automatically when the lifetime expires. This can be used as a garbage collection method or to reset variable values automatically.

A module variable is referenced by a string value and can store a value of any type. Module variables are supported by all modules. See the create_var(), delete_var(), set_var(), and get_var() procedures.

Example 44. Using Module Variables

If the number of login failures exceeds 3 within 45 seconds, then an internal log message is generated.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<Input in>
    Module  im_file
    File    '/var/log/messages'
    <Exec>
    if $Message =~ /login failure/
    {
       if not defined get_var('login_failures')
       { # create the variable if it doesn't exist
           create_var('login_failures', 45);
           set_var('login_failures', 1);
       }
       else
       { # increase the variable and check if it is over the limit
           set_var('login_failures', get_var('login_failures') + 1);
           if get_var('login_failures') >= 3
              log_warning(">= 3 login failures within 45 seconds");
       }
    }
    </Exec>
</Input>
Note
The pm_evcorr module is recommended instead for this case. This algorithm does not reliably detect failures because the lifetime of the variable is not affected by set_var(). For example, consider login failures at 0, 44, 46, and 47 seconds. The lifetime of the variable will be set when the first failure occurs, causing the variable to be cleared at 45 seconds. The variable is created with a new expiry at 46 seconds, but then only two failures are noticed. Also, this method can only work in real-time because the timing is not based on values available in the log message (though the event time could be stored in another variable).

22.5. Statistical Counters

Like variables, statistical counters provide data storage for a module instance. Counters only support integers, but a counter can use an algorithm to recalculate its value every time it is updated or read. A statistical counter will only return a value if the time specified in the interval argument has elapsed since it was created. Statistical counters can also be created with a lifetime. When a counter expires, it is destroyed, like module variables.

A statistical counter can be created with the create_stat() procedure call. After it is created, it can be updated with the add_stat() procedure call. The value of the counter can be read with the get_stat() function call. Note that the value of the statistical counter is only recalculated during these calls, rather than happening automatically. This can result in some slight distortion of the calculated value if the add and read operations are infrequent.

A time value can also be specified during creation, updating, and reading. This makes it possible for statistical counters to be used with offline log processing.

Example 45. Using Statistical Counters

This input configuration uses a Schedule block and a statistical counter with the RATEMAX algorithm to calculate the maximum rate of events over a 1 hour period. An internal log message is generated if the rate exceeds 500 events/second at any point during the 1 hour period.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<Input in>
    Module  im_tcp
    Host    0.0.0.0
    Port    1514
    <Exec>
        parse_syslog();
        if defined get_stat('eps') add_stat('eps', 1, $EventReceivedTime);
    </Exec>
    <Schedule>
        Every   1 hour
        <Exec>
            create_stat('eps', 'RATEMAX', 1, now(), 3600);
            if get_stat('eps') > 500
                log_info('Inbound TCP rate peaked at ' + get_stat('eps')
                         + ' events/second during the last hour');
        </Exec>
    </Schedule>
</Input>

23. Reading and Receiving Logs

This chapter discusses log sources that you may need to use with NXLog, including:

23.1. Receiving over the Network

This section provides information and examples about receiving log messages from the network over various protocols.

UDP

The im_udp module handles incoming messages over UDP.

Example 46. Using the im_udp Module

This input module instance shows the im_udp module configured with the default options: localhost only and port 514.

nxlog.conf [Download file]
1
2
3
4
5
<Input udp>
    Module  im_udp
    Host    localhost
    Port    514
</Input>
Note

The UDP protocol does not guarantee reliable message delivery. It is recommended to use the TCP or SSL transport modules instead if message loss is a concern.

Though NXLog was designed to minimize message loss even in the case of UDP, adjusting the kernel buffers may reduce the likelihood of UDP message loss on a loaded system. The Priority directive in the Route block can also help.

TCP

The im_tcp module handles incoming messages over TCP. For TLS/SSL, use the im_ssl module.

Example 47. Using the im_tcp Module

This input module instance accepts TCP connections from anywhere on port 1514.

nxlog.conf [Download file]
1
2
3
4
5
<Input tcp>
    Module  im_tcp
    Host    0.0.0.0
    Port    1514
</Input>
SSL/TLS

The im_ssl module handles incoming messages over TCP with SSL/TLS security.

Example 48. Using the im_ssl Module

The following input module instance listens for SSL/TLS encrypted incoming logs on port 6514. The certificate file paths are specified relative to a previously defined CERTDIR.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
<Input in>
    Module      im_ssl
    Host        0.0.0.0
    Port        6514
    CAFile      %CERTDIR%/ca.pem
    CertFile    %CERTDIR%/client-cert.pem
    CertKeyFile %CERTDIR%/client-key.pem
</Input>
Syslog

To receive Syslog over the network, use one of the network modules above, coupled with xm_syslog. Syslog parsing is not required if you only need to forward or store the messages as they are. See also Accepting Syslog via UDP, TCP, or TLS.

Example 49. Receiving Syslog over TCP with Octet-Framing

With this example configuration, NXLog listens for messages on TCP port 1514. The xm_syslog extension module provides the Syslog_TLS InputType (for octet-framing) and the parse_syslog() procedure for parsing Syslog messages.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
<Extension _syslog>
    Module      xm_syslog
</Extension>

<Input in>
    Module      im_tcp
    Host        0.0.0.0
    Port        1514
    # "Syslog_TLS" is for octet framing and may be used with TLS/SSL
    InputType   Syslog_TLS
    Exec        parse_syslog();
</Input>

23.2. Reading from a Database

With the im_dbi and im_odbc modules it is possible to read logs directly from database servers. The im_dbi module can be used on POSIX systems where libdbi is available. The im_odbc module, available in NXLog Enterprise Edition, can be used with ODBC compatible databases on Windows, Linux, and Unix.

Example 50. Using the im_dbi Module

This example uses libdbi and the MySQL driver to read records from the logdb database.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
<Input in>
    Module  im_dbi
    Driver  mysql
    Option  host 127.0.0.1
    Option  username mysql
    Option  password mysql
    Option  dbname logdb
    SQL     SELECT id, facility, severity, hostname, timestamp, application, \
                   message FROM log
</Input>
Example 51. Using the im_odbc Module

Here, the mydb database is accessed via ODBC.

nxlog.conf [Download file]
1
2
3
4
5
6
<Input in>
    Module              im_odbc
    ConnectionString    DSN=mssql;database=mydb;
    SQL                 SELECT RecordNumber as d, DateOccured as EventTime, \
                               data as Message from logtable WHERE RecordNumber > ?
</Input>

23.3. Reading from Files and Sockets

Files

The im_file module can be used to read logs from files. See also Reading Syslog Log Files.

Example 52. Using the im_file Module

This example reads from the specified file without performing any additional processing.

nxlog.conf [Download file]
1
2
3
4
<Input in>
    Module  im_file
    File    "/var/log/messages"
</Input>
Unix Domain Socket

Use the im_uds module to read from a Unix domain socket. See also Accepting Syslog via /dev/log.

Example 53. Using the im_uds Module

With this configuration, NXLog will read messages from the /dev/log socket. NXLog’s flow control feature must be disabled in this case (see the FlowControl directive in the Reference Manual).

nxlog.conf [Download file]
1
2
3
4
5
<Input in>
    Module      im_uds
    UDS         /dev/log
    FlowControl FALSE
</Input>

23.4. Receiving from an Executable

The im_exec module can be used to read logs from external programs and scripts over a pipe.

Example 54. Using the im_exec Module

This example uses the tail command to read messages from a file.

Note
The im_file module should be used to read log messages from files. This example only demonstrates the use of the im_exec module.
nxlog.conf [Download file]
1
2
3
4
5
6
<Input in>
    Module  im_exec
    Command /usr/bin/tail
    Arg     -f
    Arg     /var/log/messages
</Input>

24. Processing Logs

This chapter deals with various tasks that might be required after a log message is received by NXLog.

24.1. Parsing Various Formats

After an input module has received a log message and generated an event record for it, there may be additional parsing required. This parsing can be implemented by a dedicated module, or in the NXLog language with regular expression and other string manipulation functionality.

The following sections provide configuration examples for parsing log formats commonly used by applications.

24.1.1. Common & Combined Log Formats

The Common Log Format (or NCSA Common Log Format) and Combined Log Format are access log formats used by web servers. These are the same, except that the Combined Log Format uses two additional fields.

Common Log Format Syntax
host ident authuser [date] "request" status size
Combined Log Format Syntax
host ident authuser [date] "request" status size "referer" "user-agent"

If a field is not available, a hyphen (-) is used as a placeholder.

Table 50. Fields
Field Description

host

IP address of the client

ident

RFC 1413 identity of the client

authuser

Username of the user accessing the document (not applicable for public documents)

date

Timestamp of the request

request

Request line received from the client

status

HTTP status code returned to the client

size

Size of the object returned to the client (measured in bytes)

referer

URL from which the user was referred

user-agent

User agent string sent by the client

Example 55. Parsing the Common Log Format

This configuration uses a regular expression to parse the fields in each record. The parsedate() function is used to convert the timestamp string into a datetime type for later processing or conversion as required.

nxlog.conf
<Input access_log>
    Module  im_file
    File    "/var/log/apache2/access.log"
    <Exec>
        if $raw_event =~ /(?x)^(\S+)\ \S+\ (\S+)\ \[([^\]]+)\]\ \"(\S+)\ (.+)
                          \ HTTP\/\d\.\d\"\ (\S+)\ (\S+)/
        {
            $Hostname = $1;
            if $2 != '-' $AccountName = $2;
            $EventTime = parsedate($3);
            $HTTPMethod = $4;
            $HTTPURL = $5;
            $HTTPResponseStatus = $6;
            if $7 != '-' $FileSize = $7;
        }
    </Exec>
</Input>
Example 56. Parsing the Combined Log Format

This example is like the previous, but parses the additional two fields in the Combined Log Format. An om_file instance is also shown here: it discards all events not related to the user john and writes the remaining events to a file in JSON format.

nxlog.conf
<Extension _json>
    Module  xm_json
</Extension>

<Input access_log>
    Module  im_file
    File    "/var/log/apache2/access.log"
    <Exec>
        if $raw_event =~ /(?x)^(\S+)\ \S+\ (\S+)\ \[([^\]]+)\]\ \"(\S+)\ (.+)
                          \ HTTP\/\d\.\d\"\ (\S+)\ (\S+)\ \"([^\"]+)\"
                          \ \"([^\"]+)\"/
        {
            $Hostname = $1;
            if $2 != '-' $AccountName = $2;
            $EventTime = parsedate($3);
            $HTTPMethod = $4;
            $HTTPURL = $5;
            $HTTPResponseStatus = $6;
            if $7 != '-' $FileSize = $7;
            if $8 != '-' $HTTPReferer = $8;
            if $9 != '-' $HTTPUserAgent = $9;
        }
    </Exec>
</Input>

<Output out>
    Module  om_file
    File    '/var/log/john_access.log'
    <Exec>
        if not (defined($AccountName) and ($AccountName == 'john')) drop();
        to_json();
    </Exec>
</Output>

For information about using the Common and Combined Log Formats with the Apache HTTP Server, see Apache HTTP Server.

24.1.2. Field Delimited Formats (CSV)

Comma-, space-, or semicolon-separated field list formats are frequently used. The xm_csv module can both generate and parse these formats. Multiple xm_csv instances can be used to reorder, add, remove, or modify fields before outputting to a different CSV format.

Example 57. Complex CSV Format Conversion

This example reads from the input file and parses it with the csv1 instance. The $date field is then set to the current time and the $number field is set to 0 if it is not already defined. Finally, the csv2 instance is used to generate output with the additional date field, a different delimiter, and a different field order.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
<Extension csv1>
    Module      xm_csv
    Fields      $id, $name, $number
    FieldTypes  integer, string, integer
    Delimiter   ,
</Extension>

<Extension csv2>
    Module      xm_csv
    Fields      $id, $number, $name, $date
    Delimiter   ;
</Extension>

<Input filein>
    Module      im_file
    File        "/tmp/input"
    <Exec>
        csv1->parse_csv();
        $date = now();
        if not defined $number $number = 0;
        csv2->to_csv();
    </Exec>
</Input>

<Output fileout>
    Module      om_file
    File        "/tmp/output"
</Output>
Input Sample
1, "John K.", 42
2, "Joe F.", 43
Output Sample
1;42;"John K.";2011-01-15 23:45:20
2;43;"Joe F.";2011-01-15 23:45:20

24.1.3. JSON

The xm_json module provides procedures for generating and parsing log data in JSON format.

Example 58. Using the xm_json Module for Parsing JSON

This example reads JSON-formatted messages from file with the im_file module. Then the parse_json() procedure is used to parse the data, setting each JSON field to a field in the event record.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
<Extension _json>
    Module  xm_json
</Extension>

<Input in>
    Module  im_file
    File    "/var/log/app.json"
    Exec    parse_json();
</Input>
Example 59. Using the xm_json Module for Generating JSON

Here, the to_json() procedure is used to write all the event record fields to $raw_event in JSON format. This is then written to file using the om_file module.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
<Extension _json>
    Module  xm_json
</Extension>

<Output out>
    Module  om_file
    File    "/var/log/json.log"
    Exec    to_json();
</Output>

24.1.4. W3C Extended Log File Format

See the specification draft of the W3C format. The dedicated xm_w3c parser module can be used to process W3C formatted logs. See also the W3C section in the Microsoft IIS chapter.

Log Sample
#Version: 1.0
#Date: 2011-07-01 00:00:00
#Fields: date time cs-method cs-uri
2011-07-01 00:34:23 GET /foo/bar1.html
2011-07-01 12:21:16 GET /foo/bar2.html
2011-07-01 12:45:52 GET /foo/bar3.html
2011-07-01 12:57:34 GET /foo/bar4.html
Example 60. Parsing W3C Format With xm_w3c

This configuration reads the W3C format log file and parses it with the xm_w3c module. The fields in the event record are converted to JSON and the logs are forwarded via TCP.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<Extension _json>
    Module      xm_json
</Extension>

<Extension w3c_parser>
    Module      xm_w3c
</Extension>

<Input w3c>
    Module      im_file
    File        '/var/log/httpd-log'
    InputType   w3c_parser
</Input>

<Output tcp>
    Module      om_tcp
    Host        192.168.12.1
    Port        1514
    Exec        to_json();
</Output>

The W3C format can also be parsed with the xm_csv module if using NXLog Community Edition.

Example 61. Parsing W3C Format With xm_csv

The following configuration reads a W3C file and tokenizes it with the CSV parser. Header lines starting with a leading hash mark (#) are ignored. The $EventTime field is set from the parsed date and time fields.

Note
The fields in the xm_csv module instance below must be updated to correspond with the fields in the W3C file to be parsed.
nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
<Extension w3c_parser>
    Module          xm_csv
    Fields          $date, $time, $HTTPMethod, $HTTPURL
    FieldTypes      string, string, string, string
    Delimiter       ' '
    EscapeChar      '"'
    QuoteChar       '"'
    EscapeControl   FALSE
    UndefValue      -
</Extension>

<Extension _json>
    Module          xm_json
</Extension>

<Input w3c>
    Module          im_file
    File            '/var/log/httpd-log'
    <Exec>
        if $raw_event =~ /^#/ drop();
        else
        {
            w3c_parser->parse_csv();
            $EventTime = parsedate($date + " " + $time);
        }
    </Exec>
</Input>

24.1.5. XML

The xm_xml module can be used for generating and parsing structured data in XML format.

Example 62. Using the xm_xml Module for Parsing XML

This configuration uses the im_file module to read from file. Then the parse_xml() procedure parses the XML into fields in the event record.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
<Extension _xml>
    Module  xm_xml
</Extension>

<Input in>
    Module  im_file
    File    "/var/log/app.xml"
    Exec    parse_xml();
</Input>
Example 63. Using the xm_xml Module for Generating XML

Here, the fields in the event record are used by the to_xml() procedure to generate XML, which is then written to file by the om_file module.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
<Extension _xml>
    Module  xm_xml
</Extension>

<Output out>
    Module  om_file
    File    "/var/log/logs.xml"
    Exec    to_xml();
</Output>

24.2. Alerting

NXLog can be configured to generate alerts when specific conditions are met. Here are several ways alerting could be implemented.

24.2.1. Sending Messages to an External Program

The om_exec module can pipe messages to an external program or script, which will be started when the om_exec module is started. The script is expected to continue running until the om_exec module is stopped and the pipe is closed. This functionality can be used for alerting.

Example 64. Using om_exec,om_exec with an External Alerter

In this example Output, all messages not matching the regular expression are dropped, and remaining messages are piped to a custom alerter.

nxlog.conf [Download file]
1
2
3
4
5
6
<Output out>
    Module  om_exec
    Command /usr/local/sbin/alerter
    Arg     -
    Exec    if not ($raw_event =~ /alertcondition/) drop();
</Output>

Without the Exec directive above, all messages received by the module would be passed to the alerter.

24.2.2. Invoking a Program for Each Message

The xm_exec module provides two procedures, exec() and exec_async(), for spawning an external program or script. The script is executed once for each call, and is expected to terminate when it has finished processing the message.

Example 65. Using xm_exec with an External Alerter

In this example Input, each message matching the regular expression is piped to a new instance of alerter, which is executed asynchronously (does not block additional processing by the calling module).

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
<Extension _exec>
    Module  xm_exec
</Extension>

<Input in>
    Module  im_tcp
    Host    0.0.0.0
    Port    1514
    <Exec>
        if $raw_event =~ /alertcondition/
            exec_async("/usr/local/sbin/alerter");
    </Exec>
</Input>
Example 66. Using xm_exec to Send an Email

In this example, an email is sent using exec_async() when the regular expression condition is met.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<Extension _exec>
    Module  xm_exec
</Extension>

<Input in>
    Module  im_tcp
    Host    0.0.0.0
    Port    1514
    <Exec>
        if $raw_event =~ /alertcondition/
        {
            exec_async("/bin/sh", "-c", 'echo "' + $Hostname + '\n\nRawEvent:\n' +
                       $raw_event + '"|/usr/bin/mail ' +
                       '-a "Content-Type: text/plain; charset=UTF-8" ' +
                       '-s "ALERT" user@domain.com');
        }
    </Exec>
</Input>

24.2.3. Generate an Internal NXLog Log Message

NXLog can be configured to generate an internal log event when a specific condition is met. Internal log events can be generated with various severity levels using the log_error(), log_warning(), log_info(), and log_debug() procedures. Internal log messages will be written to the file specified by the global LogFile directive (according to the configured LogLevel) and will be generated by the im_internal module.

Note
DEBUG level events are not generated by the im_internal module.
Example 67. Using log_warning() for Alerting

If a message matches the regular expression, an internal log event is generated with level WARNING.

nxlog.conf [Download file]
1
2
3
4
5
<Input in>
    Module  im_file
    File    "/var/log/app.log"
    Exec    if $raw_event =~ /alertcondition/ log_warning("ALERT");
</Input>

24.3. Buffering

Each input module has its own read buffer which is filled with data when the source is read. Each processor and output has a limited queue where the route’s preceding module places log messages. The default limit for these internal queues is 100 events. For buffering a larger amount of data, the pm_buffer module provides disk- and memory-based buffering.

Example 68. Using a Memory Buffer to Protect Against UDP Message Loss

In this configuration, a buffer is used for incoming UDP logs to avoid message loss in the case of the TCP output blocking.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
<Input udp>
    Module      im_udp
    Host        0.0.0.0
    Port        514
</Input>

<Processor buffer>
    Module      pm_buffer
    # 1 MB buffer
    MaxSize     1024
    Type        Mem
    # warn at 512k
    WarnLimit   512
</Processor>

<Output tcp>
    Module      om_tcp
    Host        192.168.1.1
    Port        1514
</Output>

<Route udp_to_tcp>
    Path        udp => buffer => tcp
</Route>

24.4. Character Set Conversion

It is recommended to normalize logs to UTF-8. The xm_charconv module provides character set conversion: the convert_fields() procedure for converting an entire message (all event fields) and a convert() function for converting a string.

Example 69. Character Set Auto-Detection of Various Input Encodings

This configuration shows an example of character set auto-detection. The input file can contain differently encoded lines, and the module normalizes output to UTF-8.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<Extension _charconv>
    Module              xm_charconv
    AutodetectCharsets  utf-8, euc-jp, utf-16, utf-32, iso8859-2
</Extension>

<Input filein>
    Module              im_file
    File                "tmp/input"
    Exec                convert_fields("auto", "utf-8");
</Input>

<Output fileout>
    Module              om_file
    File                "tmp/output"
</Output>

<Route r>
    Path                filein => fileout
</Route>

24.5. Detecting a Dead Agent or Log Source

It is a common requirement to detect conditions when there are no log messages coming from a source. This usually indicates a problem such as a broken network connection, a server down, or a stuck application or system service. Usually this problem should be detected by monitoring tools (such as Nagios or OpenView), but the absence of logs can also be a good reason to investigate.

Note
The im_mark module is related: it can generate messages periodically in order to show that the agent is still functioning.

The solution to this problem is the combined use of statistical counters and Scheduled checks. The input module can update a statistical counter configured to calculate events per hour. In the same input module a Schedule block checks the value of the statistical counter periodically. When the event rate is zero or drops below a certain limit, an appropriate action can be executed such as sending out an alert email or generating an internal warning message. Note that there are other ways to solve this issue and this method may not be optimal for all situations.

Example 70. Alerting on Absence of Log Messages

The following configuration example creates a statistical counter in the context of the im_tcp module to calculate the number of events received per hour. The Schedule block within the context of the same module checks the value of the msgrate statistical counter and generates an internal error message when there were no logs received in the past hour.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<Input in>
    Module  im_tcp
    Port    2345
    <Exec>
        create_stat("msgrate", "RATE", 3600);
        add_stat("msgrate", 1);
    </Exec>
    <Schedule>
        Every   3600 sec
        <Exec>
            create_stat("msgrate", "RATE", 10);
            add_stat("msgrate", 0);
            if defined get_stat("msgrate") and get_stat("msgrate") <= 1
                log_error("No messages received from the source!");
        </Exec>
    </Schedule>
</Input>

24.6. Event Correlation

It is possible to write correlation rules in the NXLog language using the built-in features such as the variables and statistical counters. While these are quite powerful, some cases cannot be detected with these, especially those conditions which require a sliding window.

A dedicated NXLog module, pm_evcorr, is available for advanced correlation requirements. It provides features similar to those of SEC and greatly enhances the correlation capabilities of NXLog.

Example 71. Correlation Rules

This following configuration sample contains a rule for each type.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
<Processor evcorr>
    Module                  pm_evcorr
    TimeField               EventTime

    <Simple>
        Exec                if $Message =~ /^simple/ $raw_event = "got simple";
    </Simple>

    <Suppressed>
        # Match input event and execute an action list, but ignore the following
        # matching events for the next t seconds.
        Condition           $Message =~ /^suppressed/
        Interval            30
        Exec                $raw_event = "suppressing..";
    </Suppressed>

    <Pair>
        # If TriggerCondition is true, wait Interval seconds for RequiredCondition
        # to be true and then do the Exec. If Interval is 0, there is no window on
        # matching.
        TriggerCondition    $Message =~ /^pair-first/
        RequiredCondition   $Message =~ /^pair-second/
        Interval            30
        Exec                $raw_event = "got pair";
    </Pair>

    <Absence>
        # If TriggerCondition is true, wait Interval seconds for RequiredCondition
        # to be true. If RequiredCondition does not become true within the specified
        # interval then do the Exec.
        TriggerCondition    $Message =~ /^absence-trigger/
        RequiredCondition   $Message =~ /^absence-required/
        Interval            10
        Exec                log_info("'absence-required' not received within 10s");
    </Absence>

    <Thresholded>
        # If the number of events exceeds the given threshold within the interval do
        # the Exec. Same as SingleWithThreshold in SEC.
        Condition           $Message =~ /^thresholded/
        Threshold           3
        Interval            60
        Exec                $raw_event = "got thresholded";
    </Thresholded>

    <Stop>
        Condition           $EventTime < 2010-01-02 00:00:00
        Exec                log_debug("got stop");
    </Stop>

    <Simple>
        # This will be rewritten only if the previous Stop condition is FALSE.
        Exec                $raw_event = "rewritten";
    </Simple>

</Processor>

24.7. Explicit Drop

NXLog does not drop messages voluntarily. The built-in flow control mechanism ensures that the input modules will pause until the output modules can write. This can be problematic in some situations when dropping messages is preferable to blocking. For this case, the drop() procedure can be used in conjunction with the pm_buffer module.

Example 72. Using drop() with pm_buffer

This example sends the UDP input to two outputs, a file and a TCP destination. This could be done with a basic single-route configuration such as Path udp => tcp, file. However, if the TCP transmission is slower than the rate of incoming UDP packets or the TCP connection is down, the whole chain would be blocked. This would result in dropped UDP packets in the Input udp instance. In this situation it is better to selectively drop log messages in the TCP route than to lose them entirely.

The following configuration uses two routes, one for each output. In the TCP route, a pm_buffer module is used and the size of the buffer is checked. If the buffer size goes over a certain limit, it is assumed that the TCP output is blocked (or too slow), and messages are explicitly dropped with the drop() procedure. In this way the UDP input will not get paused and all messages will be written to the output file regardless of the state of the TCP connection.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
<Processor buffer>
    Module      pm_buffer
    WarnLimit   800
    MaxSize     1000
    Type        Mem
    Exec        if buffer_size() >= 80k drop();
</Processor>

<Input udp>
    Module      im_udp
    Host        0.0.0.0
    Port        1514
</Input>

<Output tcp>
    Module      om_tcp
    Host        192.168.1.1
    Port        1515
</Output>

<Output file>
    Module      om_file
    File        'out.txt'
</Output>

<Route udp_to_tcp>
    Path        udp => buffer => tcp
</Route>

<Route udp_to_file>
    Path        udp => file
</Route>

24.8. Extracting Data

When NXLog receives an event, it creates an event record with a $raw_event field, other core fields like $EventReceivedTime, and any fields provided by the particular module (see Fields for more information). This section explores the various ways that NXLog can be configured to extract values from the raw event.

Some log sources (like Windows EventLog collected via im_msvistalog) already contain structured data. In this case, there is often no additional extraction required; see Message Classification.

24.8.1. Parser Procedures

NXLog includes many parser procedures that will automatically extract values from a raw log event and create corresponding fields in the event record. These procedures are provided by extension modules. For example, the xm_syslog module provides the parse_syslog() procedure, which will parse a BSD or IETF Syslog formatted raw event and create fields in the event record. Other procedures will parse JSON, key-value pairs, XML, and more; many of the available extension modules provide parser procedures.

Example 73. Parsing a Syslog Event With parse_syslog()

This example shows a Syslog event as it is received via UDP and processed by the parse_syslog() procedure.

Syslog Message
<38>Nov 22 10:30:12 myhost sshd[8459]: Failed password for invalid user linda from 192.168.1.60 port 38176 ssh2

The following configuration loads the xm_syslog extension module and then uses the Exec directive to executed the parse_syslog() procedure for each event.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
<Extension _syslog>
    Module  xm_syslog
</Extension>

<Input udp>
    Module  im_udp
    Host    0.0.0.0
    Port    514
    Exec    parse_syslog();
</Input>

This results in the following fields being added to the event record by parse_syslog().

Table 51. Syslog Fields Added by parse_syslog()
Field Value

$Message

Failed password for invalid user linda from 192.168.1.60 port 38176 ssh2

$SyslogSeverityValue

6

$SyslogSeverity

INFO

$SeverityValue

2

$Severity

INFO

$SyslogFacilityValue

4

$SyslogFacility

AUTH

$EventTime

2016-11-22 10:30:12

$Hostname

myhost

$SourceName

sshd

$ProcessID

8459

24.8.2. Regular Expressions via the Exec Directive

NXLog supports the use of regular expressions for parsing fields. For detailed information about regular expressions in NXLog, see the Reference Manual Regular Expressions section.

Example 74. Parsing With Regular Expressions
Syslog Message
<38>Nov 22 10:30:12 myhost sshd[8459]: Failed password for invalid user linda from 192.168.1.60 port 38176 ssh2

With this configuration, the above Syslog message is first parsed with parse_syslog(). This results in a $Message field created in the event record. Then, a regular expression is used to further parse the $Message field and create additional fields if it matches.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<Extension _syslog>
    Module  xm_syslog
</Extension>

<Input udp>
    Module  im_udp
    Host    0.0.0.0
    Port    514
    <Exec>
        parse_syslog();
        if $Message =~ /(?x)^Failed\ (\S+)\ for(?:\ invalid user)?\ (\S+)\ from
                        \ (\S+)\ port\ \d+\ ssh2$/
        {
            $AuthMethod = $1;
            $AccountName = $2;
            $SourceIPAddress = $3;
        }
    </Exec>
</Input>

Named capturing is supported also.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
<Input in>
    Module  im_udp
    Host    0.0.0.0
    Port    514
    <Exec>
        parse_syslog();
        $Message =~ /(?x)^Failed\ (?<AuthMethod>\S+)\ for(?:\ invalid\ user)?
                     \ (?<AccountName>\S+)\ from\ (?<SourceIPAddress>\S+)\ port
                     \ \d+\ ssh2$/;
    </Exec>
</Input>
Table 52. Additional Fields Parsed by Regular Expression
Field Value

$AuthMethod

password

$AccountName

linda

$SourceIPAddress

192.168.1.60

24.8.3. Pattern Matching With pm_pattern

Regular expressions are widely used in pattern matching. Unfortunately, using a large number of regular expression based patterns does not scale well, because these need to be evaluated linearly. The pm_pattern module implements a more efficient pattern matching than regular expressions used in Exec directives.

Example 75. Using Regular Expressions With pm_pattern
Syslog Message
<38>Nov 22 10:30:12 myhost sshd[8459]: Failed password for invalid user linda from 192.168.1.60 port 38176 ssh2

With this configuration, the above Syslog message is first parsed with parse_syslog(). This results in a $Message field created in the event record. Then, the pm_pattern module is used with a pattern XML file to further parse the record.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
<Extension _syslog>
    Module      xm_syslog
</Extension>

<Input in>
    Module      im_udp
    Host        0.0.0.0
    Port        514
    Exec        parse_syslog();
</Input>

<Processor pattern>
    Module      pm_pattern
    PatternFile /var/lib/nxlog/patterndb.xml
</Processor>

<Output out>
    Module      om_null
</Output>

<Route r>
    Path        in => pattern => out
</Route>

The patterns for the pm_pattern module instance above are declared in the following patterndb.xml file.

Pattern Database (patterndb.xml)
<?xml version='1.0' encoding='UTF-8'?>
<patterndb>
  <created>2010-01-01 01:02:03</created>
  <version>42</version>
  <!-- First and only pattern group in this file -->
  <group>
    <name>ssh</name>
    <id>42</id>
    <!-- Only try to match this group if $SourceName == "sshd" -->
    <matchfield>
      <name>SourceName</name>
      <type>exact</type>
      <value>sshd</value>
    </matchfield>
    <!-- First and only pattern in this pattern group -->
    <pattern>
      <id>1</id>
      <name>ssh auth failure</name>
      <!-- Do regular expression match on $Message field -->
      <matchfield>
        <name>Message</name>
        <type>regexp</type>
        <value>^Failed (\S+) for(?: invalid user)? (\S+) from (\S+) port \d+ ssh2</value>
        <!-- Set 3 event record fields from captured strings -->
        <capturedfield>
          <name>AuthMethod</name>
          <type>string</type>
        </capturedfield>
        <capturedfield>
          <name>AccountName</name>
          <type>string</type>
        </capturedfield>
        <capturedfield>
          <name>SourceIPAddress</name>
          <type>string</type>
        </capturedfield>
      </matchfield>
      <!-- Set additional fields if pattern matches -->
      <set>
        <field>
          <name>TaxonomyAction</name>
          <value>Authenticate</value>
          <type>string</type>
        </field>
        <field>
          <name>TaxonomyStatus</name>
          <value>Failure</value>
          <type>string</type>
        </field>
      </set>
    </pattern>
  </group>
</patterndb>
Table 53. Fields Added by pm_pattern
Field Value

$AuthMethod

password

$AccountName

linda

$SourceIPAddress

192.168.1.60

$TaxonomyAction

Authenticate

$TaxonomyStatus

Failure

NXLog Manager provides an interface for writing pattern files, and will also test sample events to aid in establishing the correct match patterns. The pattern functions can be accessed from the PATTERNS menu in the page header.

Example 76. Creating Patterns With NXLog Manager

The following instructions explain the steps required for creating the above pattern database with NXLog Manager.

  1. Open PATTERNS  CREATE GROUP. Enter a Name for the new pattern group, and optionally a Description, in the Properties section. The name is used to refer to the pattern group later. The name of the above pattern group is ssh.

  2. Add a match field by clicking Add Field in the Match section. Only messages that match will be further processed by this pattern group. In the above example, there is no reason to attempt any matches if the $SourceName field does not equal sshd. The above pattern group uses Field name=SourceName, Match=EXACT, and Value=sshd.

    NXLog Manager Pattern Group Match Section
  3. Save the new pattern group.

  4. Open PATTERNS  CREATE FIELD to create a new field to be used when creating new patterns. For the above example, the $AuthMethod field must be added because it is not in the default set provided by NXLog Manager. Set Name=AuthMethod and Field Type=STRING, then click Save.

  5. Open PATTERNS  CREATE PATTERN. In the Pattern Info section, enter a Pattern Name and optionally a Pattern Description. Select the correct Pattern Group from the list. In the above example, the ssh pattern group is used.

  6. In the Match section, set match values for the fields to be matched. If a regular expression match with captured subgroups is detected, the interface will provide a Captured fields list where target fields can be selected. The above example uses Field name=Message, Match=REGEXP, and Value=^Failed (\S+) for(?: invalid user)? (\S+) from (\S+) port \d+ ssh2$. The three captured fields are AuthMethod, AccountName, and SourceIPAddress.

    NXLog Manager Pattern Match Section
  7. The Set section allows fields to be set if the match is successful. Click Add Field for each field. The above example sets $TaxonomyStatus to Failure and $TaxonomyAction to Authenticate.

    NXLog Manager Pattern Set Section
  8. The Action section accepts NXLog language statements like would be specified in an Exec directive. Click Add action, type in the statement, and click Verify to make sure the statement is valid. The above example does not include any NXLog language statements.

  9. The final tabbed section allows test messages to be entered to verify that the match works as expected. Click the + to add a test case. To test the above example, add a Value for the Message field: Failed password for invalid user linda from 192.168.1.60 port 38176 ssh2. Click Update Test Cases in the Match section to automatically fill the captured fields. Verify that the fields are set as expected. Additional test cases can be added to test other events.

    NXLog Manager Pattern Test Case Section
  10. Save the new pattern. Then click Export to download the pattern.xml file or use the pattern to configure a managed agent.

See the NXLog Manager User Guide for more information.

24.8.4. Using the Extracted Fields

The previous sections explore ways that the log message can be parsed and new fields added to the event record. Once the required data has been extracted and corresponding fields created, there are various ways to use this new data.

  • A field or set of fields can be matched by string or regular expression to trigger alerts, perform filtering, or further classify the event.

  • Fields in the event record can be renamed, modified, or deleted.

  • Event correlation can be used to execute statements or suppress messages based on matching events inside a specified window.

  • Some output formats can be used to preserve the full set of fields in the event record (such as JSON and the NXLog Binary format).

24.9. Filtering Messages

Message filtering is a process where only some of the received messages are kept. Filtering is possible using regular expressions or other operators using any of the fields.

Use the drop() procedure in an Exec directive to conditionally discard messages.

Example 77. Using drop() to Discard Unmatching Messages

In this example, any line that matches neither of the two regular expressions will be discarded with the drop() procedure. Only lines that match at least one of the regular expressions will be kept.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
<Input file>
    Module  im_file
    File    "/var/log/myapp/*.log"
    Exec    if not ($raw_event =~ /failed/ or $raw_event =~ /error/) drop();
</Input>

<Output out>
    Module  om_file
    File    "/var/log/myapp/errors.txt"
</Output>

<Route r>
    Path    file => out
</Route>

24.10. Format Conversion

The requirements and possibilities for format conversion are endless. NXLog provides a broad range of functionality for conversion, including the NXLog language and dedicated modules. For special cases a processor or extension module can be crafted.

For converting between CSV formats, see Complex CSV Format Conversion.

Example 78. Converting from BSD to IETF Syslog

This configuration receives log messages in the BSD Syslog format over UDP and forwards the logs in the IETF Syslog format over TCP.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<Extension _syslog>
    Module  xm_syslog
</Extension>

<Input bsd>
    Module  im_udp
    Port    514
    Host    0.0.0.0
    Exec    parse_syslog_bsd(); to_syslog_ietf();
</Input>

<Output ietf>
    Module  om_tcp
    Host    1.2.3.4
    Port    1514
</Output>

<Route bsd_to_ietf>
    Path    bsd => ietf
</Route>

24.11. Log Rotation and Retention

NXLog can implement many kinds of log rotation and retention policies in order to prevent over-use of disk space and to organize past logs. These policies can be applied based on file size, time intervals, or even event attributes (such as severity). Log files can be rotated out to custom filenames and then compressed and/or deleted after a specified time period. The configuration is very flexible and custom policies can be easily implemented.

NXLog supports three main approaches to file rotation. In each case, policies should usually be implemented using a Schedule block.

  • Most policies are implemented under the scope of an om_file module instance, where output files are being written.

  • The im_file module can be configured to rotate log files after they have been fully read.

  • Any log file on the system can be rotated under the scope of an xm_fileop module or any other module. This includes the internal log file (specified by the LogFile directive).

Example 79. Rotating om_file Log Files

Log files written by an om_file module often need to be rotated regularly. This example uses the om_file file_name() function and xm_fileop file_cycle() procedure to rotate the output file daily, keeping a total of 7 old log files.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<Extension _fileop>
    Module  xm_fileop
</Extension>

<Output out>
    Module  om_file
    File    '/var/log/out.log'
    <Schedule>
        When    @daily
        <Exec>
            file_cycle(file_name(), 7);
            reopen();
        </Exec>
    </Schedule>
</Output>
Example 80. Rotating the Internal Log File

NXLog will write its own logs to a file specified by the LogFile directive. It is good practice to set up rotation of this file. This configuration uses the xm_fileop file_size() function. The file_cycle() procedure rotates the file if it is larger than 5 MB. The file is also rotated weekly. No more than 8 past log files are retained.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
define LOGFILE /opt/nxlog/var/log/nxlog/nxlog.log
LogFile %LOGFILE%

<Extension _fileop>
    Module xm_fileop

    # Check the log file size every hour and rotate if larger than 5 MB
    <Schedule>
        Every 1 hour
        <Exec>
            if (file_exists('%LOGFILE') and file_size('%LOGFILE%') >= 5M)
                file_cycle('%LOGFILE%', 8);
        </Exec>
    </Schedule>

    # Rotate log file every week on Sunday at midnight
    <Schedule>
        When    @weekly
        Exec    if file_exists('%LOGFILE') file_cycle('%LOGFILE%', 8);
    </Schedule>
</Extension>

There are many other ways that rotation and retention can be implemented. See the following sections for more details and examples.

24.11.1. Rotation Policies and Intervals

  • The om_file reopen() procedure will cause NXLog to reopen the output file specified by the File directive.

  • The rotate_to() procedure can be used to choose a name to rotate the current file to. This procedure will reopen the output file automatically, so there is no need to use the the reopen() procedure.

  • The file_cycle() procedure will move the selected file to "file.1". If "file.1" already exists, it will be moved to "file.2", and so on. If an integer is used as a second argument, it specifies the maximum number of previous files to keep.

    Warning
    If file_cycle() is used on a file that NXLog currently has open under the scope of an om_file module instance, the reopen() procedure must be used to continue logging to the file specified by the File directive. Otherwise, events will continue to be logged to the rotated file ("file.1", for example). (This is not necessary if the rotated file is the LogFile.)
24.11.1.1. Rotating by File Size

A log file can be rotated according to a pre-defined file size. This policy can be configured with the om_file file_size() function or the xm_fileop file_size() function.

Example 81. Using the file_size() Function

This example uses the file_size() function to detect if a file has grown beyond a specified size. If it has, the file_cycle() procedure is used to rotate it. The file size is checked hourly with the When directive.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<Extension _fileop>
    Module  xm_fileop
</Extension>

<Output out>
    Module  om_file
    File    '/var/log/out.log'
    <Schedule>
        When @hourly
        <Exec>
            if file_size(file_name()) >= 1M
            {
                file_cycle(file_name());
                reopen();
            }
        </Exec>
    </Schedule>
</Output>
24.11.1.2. Using Time-Based Intervals

For time interval based rotation policies NXLog provides two directives for use in Schedule blocks.

  • The Every directive rotates log files according to a specific interval specified in seconds, minutes, days, or weeks.

  • The When directive provides crontab-style scheduling, including extensions like @hourly, @daily, and @weekly.

Example 82. Using Every and When for Time-Based Rotation

This example shows the use of the Every and When directives. The output file is rotated daily using the rotate_to() function. The name is generated in the YYYY-MM-DD format according to the current server time.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<Output out>
    Module  om_file
    File    '/var/log/out.log'
    <Schedule>
        # This can likewise be used for `@weekly` or `@monthly` time periods.
        When @daily

        # The following crontab-style is the same as `@daily` above.
        # When "0 0 * * *"

        # The `Every` directive could also be used in this case.
        # Every 24 hour

        Exec    rotate_to(file_name() + strftime(now(), '_%Y-%m-%d'));
    </Schedule>
</Output>
Example 83. Rotating Into a Nested Directory Structure

In this example, logs for each year and month are stored in separated sub-directories as shown below. The log file is rotated daily.

.../logs/YEAR/MONTH/YYYY-MM-DD.log

This is accomplished with the xm_fileop dir_make() procedure, the core strftime() function, and the om_file rotate_to() procedure.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<Extension _fileop>
    Module  xm_fileop
</Extension>

<Output out>
    define OUT_DIR /srv/logs

    Module  om_file
    File    '%OUT_DIR%/out.log'
    <Schedule>
        When @daily
        <Exec>
            # Create year/month directories if necessary
            dir_make('%OUT_DIR%/' + strftime(now(), '%Y/%m'));

            # Rotate current file into the correct directory
            rotate_to('%OUT_DIR%/' + strftime(now(), '%Y/%m/%Y-%m-%d.log'));
        </Exec>
    </Schedule>
</Output>
24.11.1.3. Using Dynamic Filenames

As an alternative to traditional file rotation, output filenames can be set dynamically, based on each log event individually. This is possible because the om_file File directive supports expressions.

Note
Because dynamic filenames result in events being written to multiple files with semi-arbitrary names, they are not suitable for scenarios where a server or application expects events to be written to a particular foo.log. In this case normal rotation should be used instead.

Often one of now(), $EventReceivedTime, and $EventTime are used for dynamic filenames. Consider the following points.

  • The now() function uses the current server time, not when the event was created or when it was received by NXLog. If logs are delayed, they will be stored according to the time at which the NXLog output module instance processes them. This will not work with nxlog-processor(8) (see Offline Log Processing).

  • The $EventReceivedTime field timestamp is set by the input module instance when an event is received by NXLog. This will usually be practically the same as using now(), except in cases where there are processing delays in the NXLog route (such as when using Buffering). This can be used with nxlog-processor(8) if the $EventReceivedTime field was previously set in the logs.

  • The $EventTime field is set from a timestamp in the event, so will result in correct value even if the event was delayed before reaching NXLog. Note that some parsing may be required before this field is available (for example, the parse_syslog() procedure sets the xm_syslog EventTime field). Note also that an incorrect timestamp in an event record can cause the field to be unset or filled incorrectly resulting in data written into the wrong file.

Example 84. Timestamp-Based Dynamic Filenames With om_file

This example accepts Syslog formatted messages via UDP. Each message is parsed by the parse_syslog() procedure. The EventTime field is set from the timestamp in the syslog header. This field is then used by the expression in the File directive to generate an output filename for the event.

Even if messages received from clients over the network are out of order or delayed, they will still be placed in the appropriate output files according to the timestamps.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<Extension _syslog>
    Module  xm_syslog
</Extension>

<Input in>
    Module  im_udp
    Port    514
    Host    0.0.0.0
    Exec    parse_syslog();
</Input>

<Output out>
    Module  om_file
    File    '/var/log/nxlog/out_' + strftime($EventTime, '%Y-%m-%d')
    Exec    to_syslog_ietf();
</Output>

Dynamic filenames can be based on other fields also.

Example 85. Attribute-Based Dynamic Filenames With om_file

In this example, events are grouped by their source hostname.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<Extension _syslog>
    Module  xm_syslog
</Extension>

<Input in>
    Module  im_udp
    Host    0.0.0.0
    Port    514
    Exec    parse_syslog();
</Input>

<Output out>
    Module  om_file
    File    '/tmp/logs_by_host/' + $Hostname
</Output>
24.11.1.4. Rotating Input Files

An im_file module instance can be configured to manipulate files after they are fully processed. The im_file OnEOF block can be used for this purpose.

Warning
When using OnEOF for rotation, the rotated files must be named (or placed in a directory) such that they will not be detected as new files and re-read by the module instance.
Note
If a logging service keeps a log file open for writing, the xm_exec exec() procedure should be used to restart the service or otherwise instruct it to re-open the log file.
Example 86. Using im_file OnEOF for Input Files

In this example, files matching /var/log/app/*.log are read with an im_file module instance. When each file has been fully read, it is rotated. The GraceTimeout directive will prevent NXLog from rotating the file until after there have been no events for 10 seconds.

The input files are rotated by adding a timestamp suffix to the filename. For example, an input file named /var/log/app/errors.log would be rotated to /var/log/app/errors.log_20180101T130100. The new name does not match the wildcard specified by the File directive, so the file is not re-read.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<Extension _fileop>
    Module  xm_fileop
</Extension>

<Input app_logs_rotated>
    Module  im_file
    File    '/var/log/app/*.log'
    <OnEOF>
        <Exec>
            file_rename(file_name(),
                        file_name() + strftime(now(), '_%Y%m%dT%H%M%S'));
        </Exec>
        GraceTimeout  10
    </OnEOF>
</Input>

24.11.2. Retention Policies

NXLog can be configured to keep old log files according to a particular retention policy. Functions and procedures for retention are provided by the xm_fileop module. Additional actions, such as compressing old log files, can be implemented with the xm_exec extension module.

24.11.2.1. Using Simple File Cycling

The file_cycle() procedure provides simple numbered rotation and, optionally, retention.

Example 87. Cycling One Year of Logs With file_cycle()

This example demonstrates the use of the xm_fileop file_cycle() procedure for keeping a total of 12 log files, one for each month. Log files older than 1 year will be automatically deleted.

This policy creates following log file structure: /var/log/foo.log for the current month,/var/log/foo.log.1 for the previous month, and so on up to the maximum of 12 files.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<Extension _fileop>
    Module  xm_fileop
</Extension>

<Output out>
    Module  om_file
    File    '/var/logs/foo.log'
    <Schedule>
        When @monthly
        <Exec>
            file_cycle(file_name(), 12);
            reopen();
        </Exec>
    </Schedule>
</Output>

Different policies for different events can be implemented in combination with dynamic filenames.

Example 88. Retaining Files According to Severity

This example uses the $Severity field (such as $Severity set by parse_syslog()) to filter events to separate files. Then different retention policies are applied according to severity. Here, one week of debug logs, 2 weeks of informational logs, and 4 weeks of higher severity logs are retained.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
<Extension _syslog>
    Module  xm_syslog
</Extension>

<Extension _fileop>
    Module  xm_fileop
</Extension>

<Input logs_in>
   Module   im_file
   File     "/var/log/messages"
   Exec     parse_syslog();
</Input>

<Output logs_out>
    define OUT_DIR /opt/nxlog/var/log

    Module  om_file
    File    '%OUT_DIR%/' + $Severity + '.log'
    <Schedule>
        When @daily
        <Exec>
            file_cycle('%OUT_DIR%/DEBUG.log', 7);
            file_cycle('%OUT_DIR%/INFO.log', 14);
            file_cycle('%OUT_DIR%/WARNING.log', 28);
            file_cycle('%OUT_DIR%/ERROR.log', 28);
            file_cycle('%OUT_DIR%/CRITICAL.log', 28);
            reopen();
        </Exec>
    </Schedule>
</Output>
24.11.2.2. Compressing Old Log Files

The xm_exec module can be used to compress old log files to reduce disk usage.

Example 89. Using bzip2 With exec_async()

In this example, the file size of the output file is checked hourly with the om_file file_size() function. If the size is over the limit, then:

  1. a newfile module variable is set to the name the current file will be rotated to,

  2. the om_file rotate_to() procedure renames the current output file to the name set in newfile,

  3. the module re-opens the original file specified by the File directive and continue logging, and

  4. the xm_exec exec_async() procedure call bzip2 on the rotated-out file (without waiting for the command to complete).

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
<Extension _exec>
    Module  xm_exec
</Extension>

<Extension _fileop>
    Module  xm_fileop
</Extension>

<Output out>
    Module  om_file
    File    '/opt/nxlog/var/log/app.log'
    <Schedule>
        When @hourly
        <Exec>
            if out->file_size() > 15M
            {
                set_var('newfile', file_name() + strftime(now(), '_%Y%m%d%H%M%S'));
                rotate_to(get_var('newfile'));
                exec_async('/bin/bzip2', get_var('newfile'));
            }
        </Exec>
    </Schedule>
</Output>
24.11.2.3. Deleting Old Log Files

For retention policies where file deletion is not handled automatically by the xm_fileop file_cycle() procedure, the xm_fileop file_remove() can be used to delete old files. This procedure can also delete files based on their creation time.

Example 90. Using file_remove() to Delete Old Files

This example uses file_remove() to remove any files that were created more than 30 days ago.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
<Input in>
   Module   im_null
</Input>

<Output logs_out>
    Module  om_file
    File    '/var/log/'+ strftime(now(),'%Y%m%d') + '.log'
    <Schedule>
        When @daily

        # Delete logs older than 30 days (24x60x60x30)
        Exec    file_remove('/var/log/*.log', now() - 2592000);
    </Schedule>
</Output>

24.12. Message Classification

Pattern matching is commonly used for message classification. When certain strings are detected in a log message, the message gets tagged with classifiers. Thus it is possible to query or take action based on the classifiers only. There are several ways to classify messages based on patterns.

See also Extracting Data, a closely related topic, for more examples of classification.

24.12.1. Simple Matching on Fields

Often, message classification can be performed during parsing. However, if the required fields have already been parsed or the input module provides structured data, then it is only necessary to match the relevant fields and set classifiers.

Example 91. Classifying a Windows Security EventLog Message

This example classifies Windows Security login failure events with Event ID 4625 (controlled by the "Audit logon events" audit policy setting). If a received event has that ID, it is classified as a failed authentication attempt and the $AccountName field is set to the value of $TargetUserName.

Table 54. Sample Event via im_msvistalog (Excerpt)
Field Value

$EventType

AUDIT_FAILURE

$EventID

4625

$SourceName

Microsoft-Windows-Security-Auditing

$Channel

Security

$Category

Logon

$TargetUserSid

S-1-0-0

$TargetUserName

linda

$TargetDomainName

WINHOST

$Status

0xc000006d

$FailureReason

%%2313

$SubStatus

0xc000006a

$LogonType

2

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
<Input in>
    Module  im_msvistalog
    <Exec>
        if ($EventID == 4625) and
           ($SourceName == 'Microsoft-Windows-Security-Auditing')
        {
            $TaxonomyAction = 'Authenticate';
            $TaxonomyStatus = 'Failure';
            $AccountName = $TargetUserName;
        }
    </Exec>
</Input>
Table 55. Fields Added to the Event Record
Field Value

$TaxonomyAction

Authenticate

$TaxonomyStatus

Failure

$AccountName

linda

24.12.2. Regular Expressions via the Exec Directive

The =~ operator can be used for regular expression matching in an Exec directive.

Example 92. Regular Expression Message Classification

When the contents of the $Message field match against the regular expression, the $AccountName and $AccountID fields are filled with the appropriate values from the referenced captured sub-strings. Additionally the value LoginEvent is stored in the $Action field.

1
2
3
4
5
6
7
if $Message =~ /(?x)^pam_unix\(sshd:session\):\ session\ opened\ for\ user\ (\S+)
                \ by\ \(uid=(\d+)\)/
{
    $AccountName = $1;
    $AccountID = integer($2);
    $Action = 'LoginEvent';
}

24.12.3. Using pm_pattern

When there are a lot of patterns, writing them all in the configuration file is inefficient. Instead, the pm_pattern module can be used.

Example 93. Classifying With pm_pattern

The above pattern matching rule can be defined in the pm_pattern modules’s XML format in the following way, which will accomplish the same result.

Pattern Database (patterndb.xml)
<pattern>
   <id>42</id>
   <name>ssh_pam_session_opened</name>
   <description>ssh pam session opened</description>
   <matchfield>
      <name>Message</name>
      <type>REGEXP</type>
      <value>
      ^pam_unix\(sshd:session\): session opened for user (\S+) by \(uid=(\d+)\)
      </value>
      <capturedfield>
         <name>AccountName</name>
         <type>STRING</type>
      </capturedfield>
      <capturedfield>
         <name>AccountID</name>
         <type>INTEGER</type>
      </capturedfield>
   </matchfield>
   <set>
      <field>
          <name>Action</name>
          <type>STRING</type>
          <value>LoginEvent</value>
      </field>
   </set>
</pattern>
nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
<Extension _syslog>
    Module      xm_syslog
</Extension>

<Input uds>
    Module      im_uds
    UDS         /dev/log
    Exec        parse_syslog_bsd();
</Input>

<Processor pattern>
    Module      pm_pattern
    PatternFile /var/lib/nxlog/patterndb.xml
</Processor>

<Output file>
    Module      om_file
    File        "/var/log/messages"
    Exec        to_syslog_bsd();
</Output>

<Route uds_to_file>
    Path        uds => pattern => file
</Route>

24.13. Parsing Multi-Line Messages

Multi-line messages such as exception logs and stack traces are quite common in logs. Unfortunately these log messages are often stored in files or forwarded over the network without any encapsulation. In this case, the newline characters in the messages cannot be correctly parsed by simple line-based parsers, which treat every line as a separate event.

Multi-line events may have one or more of:

  • a header in the first line (with timestamp and severity field, for example),

  • a closing character sequence marking the end, and

  • a fixed line count.

Based on this information, NXLog can be configured to reconstruct the original messages, creating a single event for each multi-line message.

24.13.1. xm_multiline

NXLog provides xm_multiline for multi-line parsing; this dedicated extension module is the recommended way to parse multi-line messages. It supports header lines, footer lines, and fixed line counts. Once configured, the xm_multiline module instance can be used as a parser via the input module’s InputType directive.

Example 94. Using the xm_multiline Module

This configuration creates a single event record with the matching HeaderLine and all successive lines until an EndLine is received.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
<Extension multiline_parser>
    Module      xm_multiline
    HeaderLine  "---------------"
    EndLine     "END------------"
</Extension>

<Input in>
    Module      im_file
    File        "/var/log/app-multiline.log"
    InputType   multiline_parser
</Input>

It is also possible to use regular expressions with the HeaderLine and EndLine directives.

Example 95. Using Regular Expressions With xm_multiline

Here, a new event record is created beginning with each line that matches the regular expression.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
<Extension tomcat_parser>
    Module      xm_multiline
    HeaderLine  /^\d{4}\-\d{2}\-\d{2} \d{2}\:\d{2}\:\d{2},\d{3} \S+ \[\S+\] \- .*/
</Extension>

<Input log4j>
    Module      im_file
    File        "/var/log/tomcat6/catalina.out"
    InputType   tomcat_parser
</Input>
Note
Because the EndLine directive is not specified in this configuration, the xm_multiline parser cannot know that a log message is finished until it receives the HeaderLine of the following message. The log message is kept in the buffers, and not forwarded, until either a new log message is read or the im_file module instance’s PollInterval has expired. See the xm_multiline AutoFlush directive.

24.13.2. Module Variables

It is also possible to parse multi-line messages by using module variables, as shown below. However, it is generally recommended to use the xm_multiline module instead, because it offers:

  • more efficient message processing,

  • a more readable configuration,

  • correctly incremented module event counters (one increment per multi-line message versus one per line), and

  • operation on the message source level rather than the module instance level (each file for a wildcarded im_file module instance or each TCP connection for an im_tcp/im_ssl instance).

Example 96. Parsing Multi-Line Messages with Module Variables

This example saves the matching line and successive lines in the saved variable. When another matching line is read, an internal log message is generated with the contents of the saved variable.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
<Input log4j>
    Module  im_file
    File    "/var/log/tomcat6/catalina.out"
    <Exec>
        if $raw_event =~ /(?x)^\d{4}\-\d{2}\-\d{2}\ \d{2}\:\d{2}\:\d{2},\d{3}\ \S+
                          \ \[\S+\]\ \-\ .*/
        {
            if defined(get_var('saved'))
            {
                $tmp = $raw_event;
                $raw_event = get_var('saved');
                set_var('saved', $tmp);
                delete($tmp);
                log_info($raw_event);
            }
            else
            {
                set_var('saved', $raw_event);
                drop();
            }
        }
        else
        {
            set_var('saved', get_var('saved') + "\n" + $raw_event);
            drop();
        }
    </Exec>
</Input>
Note
As with the previous example, a log message is kept in the saved variable, and not forwarded, until a new log message is read.

24.14. Rate Limiting

The poor man’s tool for rate limiting is the sleep() procedure.

Example 97. Rate Limiting with sleep()

In the following example sleep() is invoked with 500 microseconds. This means that the input module will be able to read at most 2000 messages per second.

nxlog.conf [Download file]
1
2
3
4
5
6
<Input in>
    Module  im_tcp
    Host    0.0.0.0
    Port    1514
    Exec    sleep(500);
</Input>

This is not very precise because the module can do additional processing which can add some to the total execution time, but it gets fairly close.

Warning
It is not recommended to use rate limiting on a route that reads logs over UDP.

24.15. Rewriting and Modifying Messages

There are many ways to modify log messages.

24.15.1. Simple Rewrite

A simple rewrite can be done by modifying the $raw_event field without parsing the message (with Syslog, for example). Regular expression capturing can be used for this.

Example 98. Simple Rewrite Statement

This statement, when used in an Exec directive, will apply the replacement directly to the $raw_event field. In this case, a parsing procedure like parse_syslog() would not be used.

1
2
if $raw_event =~ /^(aaaa)(replaceME)(.+)/
    $raw_event = $1 + 'replaceMENT' + $3;
Example 99. Converting a Timestamp Format

This example will convert a timestamp field to a different format. Like the previous example, the goal is to modify the $raw_event field directly, rather than use other fields and then a procedure like to_json() to update $raw_event.

The input log format is line-based, with whitespace-separated fields. The first field is a timestamp expressed as seconds since the epoch.

Input Sample
1301471167.225121 AChBVvgs1dfHjwhG8 141.143.210.102 5353 224.0.0.251 5353 udp dns - - - S0 - - 0 D 1 73 0 0 (empty)

In the output module instance Exec directive, the regular expression will match and capture the first field from the line, and remove it. This captured portion is parsed with the parsedate() function and used to set the $EventTime field. This field is then prepended to the $raw_event field to replace the previously removed field.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<Input in>
    Module  im_file
    File    "conn.log"
</Input>

<Output out>
    Module  om_tcp
    Host    192.168.0.1
    Port    1514
    <Exec>
        if $raw_event =~ s/^(\S+)//
        {
            $EventTime = parsedate($1);
            $raw_event = strftime($EventTime, 'YYYY-MM-DDThh:mm:ss.sTZ') +
                         $raw_event;
        }
    </Exec>
</Output>
Output Sample
2011-03-30T00:46:07.225121-07:00 AChBVvgs1dfHjwhG8 141.143.210.102 5353 224.0.0.251 5353 udp dns - - - S0 - - 0 D 1 73 0 0 (empty)

24.15.2. Modifying Fields

A more complex method is to parse the message into fields, modify some fields, and finally reconstruct the message from the fields. This method is much more versatile: it allows rewriting to be done regardless of input and output formats.

Example 100. Rewrite Using Fields

In this example, each Syslog message is received via UDP and parsed with parse_syslog_bsd(). Then, if the $Message field matches the regular expression, the $SeverityValue field is modified. Finally, the to_syslog_bsd() procedure generates $raw_event from the fields.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
<Extension _syslog>
    Module  xm_syslog
</Extension>

<Input udp>
    Module  im_udp
    Port    514
    Host    0.0.0.0
    Exec    parse_syslog_bsd();
</Input>

<Output file>
    Module  om_file
    File    "/var/log/logmsg.txt"
    <Exec>
        if $Message =~ /error/ $SeverityValue = syslog_severity_value("error");
        to_syslog_bsd();
    </Exec>
</Output>

<Route syslog_to_file>
    Path    udp => file
</Route>

24.15.3. Renaming and Deleting Fields

In some cases it may be necessary to rename or delete fields.

The simplest way is to use the NXLog language and the Exec directive.

Example 101. Simple Field Rename

This statement uses rename_field() to rename the $user field to $AccountName.

1
rename_field($user, $AccountName);
Example 102. Simple Field Deletion

This statement uses the delete() procedure to delete the $Serial field.

1
delete($Serial);

Alternatively, the xm_rewrite extension module (available in NXLog Enterprise Edition) can be used to rename or delete fields.

Example 103. Using xm_rewrite to Whitelist and Rename Fields

This example uses the parse_syslog() procedure to create a set of Syslog fields in the event record. It then uses the Keep directive to whitelist a set of fields, deleting any field that is not in the list. Finally the Rename directive is used to rename the $EventTime field to $Timestamp. The resulting event record is converted to JSON and sent out via TCP.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
<Extension json>
    Module  xm_json
</Extension>

<Extension rewrite>
    Module  xm_rewrite
    Keep    EventTime, Severity, Hostname, SourceName, Message
    Rename  EventTime, Timestamp
</Extension>

<Input in>
    Module  im_file
    File    '/var/log/messages'
    Exec    parse_syslog(); rewrite->process();
</Input>

<Output out>
    Module  om_tcp
    Host    10.0.0.1
    Port    1514
    Exec    to_json();
</Output>

<Route r>
    Path    in => out
</Route>
Example 104. Using xm_rewrite to Remove Fields

Here is an example Extension block that uses the Delete directive to delete all the severity fields. This could be used to prevent severity-based matching (during later processing) on an event source that does not set severity values correctly.

nxlog.conf [Download file]
1
2
3
4
<Extension rewrite>
    Module  xm_rewrite
    Delete  SyslogSeverityValue, SyslogSeverity, SeverityValue, Severity
</Extension>

24.16. Timestamps

The NXLog core provides functions for parsing timestamps and returning datetime values, and functions for generating formatted timestamps from datetime values.

24.16.1. Parsing Timestamps

Most timestamps can be parsed with the parsedate() function, which will automatically parse any of the supported formats.

Example 105. Parsing a Timestamp With parsedate()

Consider the following line-based input sample. Each record begins with a timestamp followed by a tab.

Input Sample
2016-10-11T22:14:15.003Zmachine.example.comAn account failed to log on.

This example configuration uses a regular expression to capture the string up to the first tab. Then the parsedate() function is used to parse the resulting string and set the $EventTime field to the corresponding datetime value. This value can be converted to a timestamp string as required in later processing, either explicitly or as defined by the global DateFormat directive (see Formatting Timestamps).

nxlog.conf [Download file]
1
2
3
4
5
<Input in>
    Module  im_file
    File    'in.log'
    Exec    if $raw_event =~ /^([^\t])\t/ $EventTime = parsedate($1);
</Input>
Tip
The parsedate() function is especially useful if the timestamp format varies within the events being processed. A timestamp of any supported format will be parsed. In this example, the timestamp must be at the beginning of the event and followed by a tab character to be matched by the regular expression.

Sometimes a log source will contain a few events with invalid or unexpected formatting. If parsedate() fails to parse the input string, it will return an undefined datetime value. This allows the user to configure a fallback timestamp.

Example 106. Using a Fallback Timestamp With parsedate()

This example statement uses a vague regular expression that may in some cases match an invalid string. If parsedate() fails to parse the timestamp, it will return an undefined datetime value. In this case, the final line below will set $EventTime to the current time.

1
2
3
4
5
if $raw_event =~ /^(\S+)\s+(\S+)/
    $EventTime = parsedate($1 + " " + $2);

# Make sure $EventTime is set
if not defined($EventTime) $EventTime = now();
Tip
$EventTime = $EventReceivedTime could be used instead to set a timestamp according to when the event was received by NXLog.

For parsing more exotic formats, the strptime() function can be used.

Example 107. Using strptime() to Parse Timestamps

In this input sample, the date and time are two distinct fields delimited by a tab. It also uses a non-standard single digit format instead of fixed width with double digits.

Input Sample
2011-5-290:3:2 GMTWINDOWSDCAn account failed to log on.

To parse this, a regular expression can be used to capture the timestamp string. This string is then parsed with the strptime() function.

1
2
if $raw_event =~ /^(\d+-\d+-\d+\t\d+:\d+:\d+ \w+)/
    $EventTime = strptime($1, '%Y-%m-%d%t%H:%M:%S %Z');

24.16.2. Adjusting Timestamps

Sometimes a log source sends events with incorrect or incomplete timestamps. For example, some network devices may not have the correct time (especially immediately after rebooting); also, the BSD Syslog header provides neither the year nor the timezone. NXLog can be configured to apply timestamp corrections in various ways.

Warning
Reliably applying timezone offsets is difficult due to complications like daylight savings time (DST) and networking and processing delays. For this reason, it is best to use clock synchronization (such as NTP) and timezone-aware timestamps at the log source when possible.

The simplest solution for incorrect timestamps is to replace them with the time when the event was received by NXLog. This is a good option for devices with untrusted clocks on the local network that send logs to NXLog in real-time. The $EventReceivedTime field is automatically added to each event record by NXLog; this field can be stored alongside the event’s own timestamp (normally $EventTime) if all fields are preserved when the event is stored/forwarded. Alternatively, this field can be used as the event timestamp as shown below. This would have the effect of influencing the timestamp used on most outputs, such as with the to_syslog_ietf() procedure.

Example 108. Using $EventReceivedTime as the Event Timestamp

This configuration accepts Syslog messages via UDP with the im_udp module. Events are parsed with the parse_syslog() procedure, which adds an EventTime field from the Syslog header timestamp. The $EventTime value, however, is replaced by the timestamp set by NXLog in the $EventReceivedTime field. Any later processing that uses the $EventTime field will operate on the updated timestamp. For example, if the to_syslog_ietf() procedure is used, the resulting IETF Syslog header will contain the $EventReceivedTime timestamp.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
<Extension _syslog>
    Module  xm_syslog
</Extension>

<Input syslog>
    Module  im_udp
    <Exec>
        parse_syslog();
        $EventTime = $EventReceivedTime;
    </Exec>
</Input>

In some edge cases, a UTC timestamp that does not have the timezone specified is parsed as local time. This can happen if BSD Syslog timestamps are in UTC, or when reading a non-timezone-aware ID timestamp with im_odbc. In this case, it is necessary to either manuall re-parse (see Parsing Timestamps) or apply a corresponding reverse offset.

Example 109. Reversing an Incorrect Local-to-UTC Timezone Offset

This statement uses the parsedate() and strftime() functions to apply a reverse offset after an incorrect local-to-UTC timezone conversion. To reduce the likelihood of an incorrect offset during the daylight saving time (DST) transition, this should be done in the Input module instance which is collecting the events (see the warning above).

1
$EventTime = parsedate(strftime($EventTime, '%Y-%m-%d %H:%M:%SZ'));

For the general case of adjusting timestamps, the plus (+) and minus (-) operators can be used to adjust a timestamp by a specified number of seconds.

Example 110. Adjusting a Datetime Value by Seconds

This statement adds two hours to the $EventTime field.

Warning
This simple method may not be suitable for correction of a timezone that uses daylight saving time (DST). In that case the required offset may change based on whether DST is in effect.
1
$EventTime = $EventTime + (2 * 3600);

24.16.3. Formatting Timestamps

After a timestamp has been parsed to a datetime value, it will usually need to be converted back to a string at some point before being sent to the output. This can be done automatically by the output configuration.

Example 111. Using the Default Timestamp Formatting

Consider an event record with an $EventTime field (as a datetime value) and a $Message field. Note that the table below shows the $EventTime value as it is stored internally: as microseconds since the epoch.

Table 56. Sample Event Record
Field Value

$EventTime

1493425133541851

$Message

EXT4-fs (dm-0): mounted filesystem with ordered data mode.

The following output module instance uses the to_json() procedure without specifying the timestamp format.

nxlog.conf [Download file]
1
2
3
4
5
<Output out>
    Module  om_file
    File    'out.log'
    Exec    to_json();
</Output>

The output of the $EventTime field in this case will depend on the DateFormat directive. The default DateFormat is YYYY-MM-DD hh:mm:ss (local time).

Output Sample
{
  "EventTime": "2017-01-02 15:19:22",
  "Message": "EXT4-fs (dm-0): mounted filesystem with ordered data mode."
}
Note
A different timestamp may be used in some cases, depending on the procedure used to convert the field and the output module. The to_syslog_bsd() procedure, for example, will use the $EventTime value to generate a RFC 3164 format timestamp regardless of how the DateFormat directive is set.

Alternatively, the strftime() function can be used to explicitly convert a datetime value to a string with the required format.

Example 112. Using strftime() to Format Timestamps

Again, consider an event record with an $EventTime field (as a datetime value) and a $Message field. In this example, the strftime() function is used with a format string (see the strftime(3) manual) to convert $EventTime to a string in the local time zone. Then the to_json() procedure is used to set the $raw_event field.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
<Output out>
    Module  om_file
    File    'out.log'
    <Exec>
        $EventTime = strftime($EventTime, '%Y-%m-%dT%H:%M:%S%z');
        to_json();
    </Exec>
</Output>
Output Sample
{
  "EventTime": "2017-04-29T02:18:53+0200",
  "Message": "EXT4-fs (dm-0): mounted filesystem with ordered data mode."
}

NXLog Enterprise Edition supports a few additional format strings for formats that the stock C strftime() does not offer, including formats with fractional seconds and in UTC time. See the Reference Manual strftime() documentation for the list.

Example 113. Using strftime() Special Formats in NXLog Enterprise Edition

The following statement will convert $EventTime to a timestamp format with fractional seconds and in UTC (regardless of the current time zone).

1
$EventTime = strftime($EventTime, 'YYYY-MM-DDThh:mm:ss.sUTC');

The resulting timestamp string in this case would be 2017-04-29T00:18:53.541851Z.

25. Forwarding and Storing Logs

This chapter discusses the configuration of NXLog outputs, including:

25.1. Generating Various Formats

The data format used in an outgoing log message must be considered in addition to the transport protocol. If the message cannot be parsed by the receiver, it may be discarded or improperly processed. See also Parsing Various Formats.

Syslog

There are two Syslog formats, the older BSD Syslog (RFC 3164) and the newer IETF Syslog (RFC 5424). The transport protocol in Syslog can be UDP, TCP, or SSL. The xm_syslog module provides procedures for generating Syslog messages. For more information, see Generating Syslog.

Example 114. Generating Syslog and Sending via TCP

This configuration uses the to_syslog_ietf() procedure to convert the corresponding fields in the event record to a Syslog message in IETF format. The result is forwarded via TCP by the om_tcp module.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
<Extension _syslog>
    Module  xm_syslog
</Extension>

<Output out>
    Module  om_tcp
    Host    192.168.1.1
    Port    1514
    Exec    to_syslog_ietf();
</Output>
Syslog Snare

The Snare agent format is a special format on top of BSD Syslog which is used and understood by several tools and log analyzer frontends. This format is most useful when forwarding Windows EventLog data in conjunction with im_mseventlog and/or im_msvistalog. The to_syslog_snare() procedure can construct Syslog Snare formatted messages. For more information, see Generating Snare.

Example 115. Generating Syslog Snare and Sending via UDP

In this example, the to_syslog_snare() procedure converts the corresponding fields in the event record to Snare format. The messages are then forwarded via UDP by the om_udp module.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
<Extension _syslog>
    Module  xm_syslog
</Extension>

<Output out>
    Module  om_udp
    Host    192.168.1.1
    Port    514
    Exec    to_syslog_snare();
</Output>
NXLog Binary format

The Binary format is only understood by NXLog. All the fields are preserved when the data is sent in this format, so there is no need to parse it again. The output module instance must contain OutputType Binary. The receiver NXLog module instance can be set to InputType Binary.

Graylog Extended Log Format (GELF)

The xm_gelf module can be used to generate GELF output.

Example 116. Generating GELF Output

With this configuration, NXLog will send the fields in the event record via UDP in GELF format.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
<Extension _gelf>
    Module      xm_gelf
</Extension>

<Output out>
    Module      om_udp
    Host        127.0.0.1
    Port        12201
    OutputType  GELF_UDP
</Output>

25.2. Forwarding over the Network

The following network protocols can be used. There is a trade-off between speed, reliability, compatibility, and security.

UDP

To send logs in UDP datagrams, use the om_udp module.

Warning
UDP packets can be dropped by the operating system because the protocol does not guarantee reliable message delivery. It is recommended to use TCP or TLS/SSL instead if message loss is a concern.
Example 117. Using the om_udp Module

This example sends the contents of the $raw_event field to the specified host via UDP.

nxlog.conf [Download file]
1
2
3
4
5
<Output out>
    Module  om_udp
    Host    192.168.1.1
    Port    514
</Output>
TCP

To send logs over TCP, use the om_tcp module.

Example 118. Using the om_tcp Module

In this example, the contents of the $raw_event field are sent to the specified host via TCP.

nxlog.conf [Download file]
1
2
3
4
5
<Output out>
    Module  om_tcp
    Host    192.168.1.1
    Port    1514
</Output>
SSL/TLS

To send logs over a trusted secure SSL connection, use the om_ssl module.

Example 119. Using the om_ssl Module

This example provides nearly identical behavior to the TCP example above, but in this case SSL is used to securely transmit the data.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
<Output out>
    Module      om_ssl
    Host        192.168.1.1
    Port        6514
    CAFile      %CERTDIR%/ca.pem
    CertFile    %CERTDIR%/client-cert.pem
    CertKeyFile %CERTDIR%/client-key.pem
</Output>
HTTP(S)

To send logs over a HTTP or HTTPS connection, use the om_http and im_http modules (available only in NXLog Enterprise Edition).

Example 120. Using the om_http Module

With this configuration, NXLog will send log messages via HTTP, using a POST request for each log message.

nxlog.conf [Download file]
1
2
3
4
<Output out>
    Module  om_http
    URL     http://server:8080/
</Output>

25.3. Sending to Files and Sockets

Files

To store logs in local files, use the om_file module. See also Writing Syslog to File.

Example 121. Using the om_file Module

This configuration writes log messages to the specified file. No additional processing is performed by the output module instance.

nxlog.conf [Download file]
1
2
3
4
<Output out>
    Module  om_file
    File    "/var/log/out.log"
</Output>
Unix Domain Socket

To send logs to a Unix domain socket, use the om_uds module. See also Sending Syslog to the Local Syslog Daemon via /dev/log.

Example 122. Using the om_uds Module

With this configuration, log messages are written to the specified socket without any additional processing.

nxlog.conf [Download file]
1
2
3
4
<Output out>
    Module  om_uds
    UDS     /dev/log
</Output>

25.4. Storing in Databases

The om_dbi and om_odbc modules can be used to store logs in databases. The om_dbi module can be used on POSIX systems where libdbi is available. The om_odbc module, available in NXLog Enterprise Edition, can be used with ODBC compatible databases on Windows, Linux, and Unix.

Example 123. Using the om_dbi Module

This configuration uses libdbi and the pgsql driver to insert events into the specified database. The SQL statement references fields in the event record to be added to the database.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
<Output out>
    Module  om_dbi
    SQL     INSERT INTO log (facility, severity, hostname, timestamp, application, \
                             message) \
            VALUES ($SyslogFacility, $SyslogSeverity, $Hostname, '$EventTime', \
                    $SourceName, $Message)
    Driver  pgsql
    Option  host 127.0.0.1
    Option  username dbuser
    Option  password secret
    Option  dbname logdb
</Output>
Example 124. Using the om_odbc Module

This example inserts events into the database specified by the ODBC connection string. In this case, the sql_exec() and sql_fetch() functions are used to interact with the database.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<Output out>
    Module              om_odbc
    ConnectionString    DSN=mysql_ds;username=mysql;password=mysql;database=logdb;
    <Exec>
        if ( sql_exec("INSERT INTO log (facility, severity, hostname, timestamp,
                       application, message) VALUES (?, ?, ?, ?, ?, ?)",
                      1, 2, "host", now(), "app", $raw_event) == TRUE )
        {
            if ( sql_fetch("SELECT max(id) as id from log") == TRUE )
            {
                log_info("ID: " + $id);
                if ( sql_fetch("SELECT message from log WHERE id=?", $id) == TRUE )
                    log_info($message);
            }
        }
    </Exec>
</Output>

25.5. Sending to Executables

Using the om_exec module, all messages can be piped to an external program or script which will run until the module (or NXLog) is stopped.

Example 125. Using the om_exec Module

This configuration executes the specified command and writes log messages to its standard input.

nxlog.conf [Download file]
1
2
3
4
5
<Output out>
    Module  om_exec
    Command /usr/bin/someprog
    Arg     -
</Output>

26. Centralized Log Collection

Centralized log collection, log aggregation, or log centralization is the process of sending event log data to a dedicated server or service for storage and optionally search and analytics. Storing logs on a centralized system provides several benefits versus storing the data locally.

  • Event data can be accessed even if the originating server is offline, compromised, or decommissioned.

  • Data can be analyzed and correlated across more than one system.

  • It is more difficult for malicious actors to remove evidence from logs that have already been forwarded.

  • Incident investigation and auditing is easier, as all event data is collected in one location.

  • Scalable, high-availability, and redundancy solutions are easier to implement and maintain because they can be implemented at the point of the collection server.

  • Compliance with internal and external standards for log data retention can be managed at a single point.

26.1. Architecture

The following diagram shows a simple centralized log architecture. The single central server collects logs from servers, applications, and network devices. After collection, the logs can be forwarded as required for further analysis or storage.

This chapter is concerned with the left half of the diagram: collecting logs from clients.

Centralized Log Architecture

In practice, network topology and other requirements may dictate that additional servers such as relays be added for log handling. For those cases, other functionality may be necessary than what is covered here (such as buffering).

26.2. Collection Modes

In the context of clients generating logs, NXLog supports both "agent-based" and "agent-less" log collection, and it is possible to set up a system to work in mixed mode. In brief, these modes differ as follows (see the Log Processing Modes section for more details).

Agent-based log collection requires that an NXLog agent be installed on the client. With a local agent, collection is much more flexible, providing features such as filtering on the source system to send only the required data, format conversion, compression, encryption, and delivery reliability, among others. It is generally recommended that NXLog be deployed as an agent wherever possible.

Example 126. Transporting Batch-Compressed Logs in Agent-Based Mode

With agent-based log collection, NXLog agents are installed on both the client and the central server. Here, the im_batchcompress and om_batchcompress modules are used to transport logs both compressed and encrypted. These modules preserve all the fields in the event record.

nxlog.conf (Client) [Download file]
1
2
3
4
5
6
7
8
9
<Output batch>
    Module      om_batchcompress
    Host        192.168.56.101
    Port        2514
    UseSSL      TRUE
    CAFile      /opt/openssl_rootca/rootCA.pem
    CertFile    /opt/openssl_server/server.crt
    CertKeyFile /opt/openssl_server/server.key
</Output>
nxlog.conf (Log Server) [Download file]
1
2
3
4
5
6
7
8
<Input batch>
    Module      im_batchcompress
    ListenAddr  0.0.0.0
    Port        2514
    CAFile      /opt/openssl_rootca/rootCA.pem
    CertFile    /opt/openssl_server/central.crt
    CertKeyFile /opt/openssl_server/central.key
</Input>

In agent-less mode, there is no NXLog agent installed on the client. Instead, the client forwards events to the central server in a native format. On the central server, NXLog accepts and parses the logs received. Often there is limited control over the log format used, and it may not be possible to implement encryption, compression, delivery reliability, or other features.

Example 127. Collecting UDP Syslog Logs in Agent-Less Mode

With agent-less collection, NXLog is installed on the central server but not on the client. Clients can be configured to send UDP Syslog messages to the central server using their native logging functionality. The im_udp module below could be replaced im_tcp or im_ssl according to what protocol is supported by the clients.

Warning
UDP transport does not provide any guarantee of delivery. Network congestion or other issues may result in lost log data.
nxlog.conf (Log Server) [Download file]
1
2
3
4
5
6
7
8
9
10
<Extension _syslog>
    Module  xm_syslog
</Extension>

<Input input_udp>
    Module  im_udp
    Host    0.0.0.0
    Port    514
    Exec    parse_syslog();
</Input>

It is common for logs to be collected using a mix of different modes among the various clients, network devices, relays, and log servers in a network. For example, an NXLog relay may be configured to collect logs from both agents and agent-less sources and do filtering and processing before forwarding the data to a central server.

26.3. Requirements

Various logging requirements may dictate particular details about the chosen logging architecture. The following are important things to consider when deciding how to set up centralized log collection. In some cases, these requirements can only be met when using agent-based collection.

Reliability

UDP does not guarantee message delivery, and should be avoided if log data loss is not acceptable. Instead, TCP (and therefore, TLS) offers guaranteed packet delivery. In addition, with agent-based collection, NXLog can provide application-level guaranteed delivery. See Reliable Network Delivery for more information.

Structured data

Correlating data across multiple log sources requires parsing event data into a common set of fields. Event fields are a core part of NXLog processing, and an NXLog agent can be configured to parse events at any point along the log path. Often, parsing is done as early as possible (at the source, for agent-based collection) to simplify later classifying as reduce processing load on log servers as logs are transported. See Parsing Various Formats and Message Classification.

Encryption

To maintain confidentiality of log data, TLS can be used during transport.

Compression

If bandwidth is a concern, log data compression may be desirable. Event data is normally quite compressible, allowing bandwidth requirements to be reduced significantly. The im_batchcompress and om_batchcompress modules provide a batched, compressed transport for log data between NXLog agents.

Storage format

Normally, data should be converted to and stored in a unified format in case of heterogeneous logs sources.

26.4. Data Formats

When using agent-based collection, it is often desirable to convert the data prior to transfer. In this case, structured data is often sent using one of these formats.

Batch compression modules

The im_batchcompress and om_batchcompress modules can be used to send logs in compressed and optionally encrypted batches. All fields in the event record are preserved.

NXLog binary format

NXLog has its own binary format (see Binary InputType and Binary OutputType) that retains all the fields of an event and can be used to send logs via TCP, UDP, or TLS (or with other stream-oriented modules).

JSON

JSON is easy to generate and parse and has become a de-facto standard for logging as well. It has some limitations such as the missing datetime format. See the JSON section.

Agent-less collection is restricted to formats supported by the clients. The following are a few common formats, but many more are supported. See also the OS Support chapters.

Syslog

Using Syslog has become a common practice and many SIEM vendors and products support (and may even require) Syslog. See the Syslog chapter for more details. Syslog contains free form message data that typically needs to be parsed to extract more information for further analysis. Syslog often uses UDP, TCP, or TLS as transport.

Snare

The Snare format is commonly used to transport Windows EventLog, with or without Syslog headers.

Windows Event Forwarding (WEF)

Windows EventLog can be forwarded over HTTPS with Windows Event Forwarding. See the Windows EventLog chapter.

27. Encrypted Transfer

In order to protect log data from being modified or viewed by an attacker during transit, NXLog provides SSL/TLS data encryption support in many input and output modules. Benefits of using SSL/TLS encrypted log transfer include:

  • strong authentication,

  • message integrity (assures that the logs are not changed), and

  • message confidentiality (assures that the logs cannot be viewed by an unauthorized party).

Warning
It is important that certificates be renewed before expiration. The NXLog Manager dashboard can be configured with a "Certificate summary" which lists soon-to-expire certificates in a separate group.

27.1. SSL/TLS Encryption in NXLog

The SSL/TLS protocol encrypts the log data on the client side and then decrypts it on the server side. It’s recommended to use at least 2048-bits keys.

There are several modules in NXLog Enterprise Edition that support SSL/TLS encryption:

When using the SSL/TLS, there are two ways to handle authentication.

  • With mutual authentication, both client and log server agents are authenticated, and certificates/keys must be deployed for both agents. This is the most secure and prevents log collection if the client’s certificate is untrusted or expires.

  • With server-side authentication only, only the log server is authenticated. A certificate/key must be deployed for the server only. On the log server, the im_ssl AllowUntrusted directive (or corresponding directive for im_http or im_batchcompress) must be set to TRUE. The client is prevented from sending logs to an untrusted server but the server accepts logs from untrusted clients.

Example 128. Client/Server Encrypted Transfer

With the following configurations, a client reads logs from all log files under the /var/log directory, parses the events with parse_syslog(), converts to JSON with to_json(), and forwards them over a secure connection to the central server.

These configurations use mutual authentication: both agents are authenticated and certificates must be created for both agents.

nxlog.conf (Client) [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
<Extension _syslog>
    Module      xm_syslog
</Extension>

<Extension _json>
    Module      xm_json
</Extension>

<Input messages>
    Module      im_file
    File        "/var/log/*"
    Exec        parse_syslog();
</Input>

<Output central_ssl>
    Module      om_ssl
    Host        192.168.56.103
    Port        516
    CAFile      /opt/ssl/rootCA.pem
    CertFile    /opt/ssl/client.crt
    CertKeyFile /opt/ssl/client.key
    KeyPass     password
    Exec        to_json();
</Output>

The server receives the logs on port 516 and writes them to /var/log/logmsg.log.

nxlog.conf (Central Server) [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<Extension _syslog>
    Module      xm_syslog
</Extension>

<Input input_ssl>
    Module      im_ssl
    Host        0.0.0.0
    Port        516
    CAFile      /opt/ssl/rootCA.pem
    CertFile    /opt/ssl/central.crt
    CertKeyFile /opt/ssl/central.key
    KeyPass     password
</Input>

<Output fileout>
    Module      om_file
    File        "/var/log/logmsg.log"
</Output>

27.2. OpenSSL Certificate Creation

NXLog Manager provides various features for creating, deploying, and managing SSL/TLS certificates, and is especially helpful when managing many NXLog agents across an organization. This section, however, provides steps for creating self-signed certificates with OpenSSL, a Linux-based SSL/TLS cryptography toolkit.

  1. Generate the private root key for your Certification Authority (CA).

    $ openssl genrsa -out rootCA.key 2048
  2. Self-sign the key and create a CA certificate.

    $ openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 730 -out rootCA.pem
  3. Create a certificate for each server.

    1. Generate a private key for the server.

      $ openssl genrsa -out server.key 2048
    2. Generate the certificate signing request for the CA. When prompted for the Common Name, enter the server’s name or IP address.

      $ openssl req -new -key server.key -out server.csr
    3. Sign the request.

      $ openssl x509 -req -in server.csr -CA rootCA.pem -CAkey rootCA.key \
                          -CAcreateserial -out server.crt -days 500 -sha256

28. Reducing Bandwidth and Data Size

There are several ways that NXLog can be configured to reduce the size of log data. This can help lower bandwidth requirements during transport, storage requirements for log data storage, and licensing costs for commercial SIEM systems that charge based on data volume.

There are three sections following.

  • By removing unnecessary or duplicate events at the source, there is less data to be transported and stored—reducing the data size during all subsequent stages of processing. See Filtering Events.

  • Similarly, removing extra content or fields from event records can reduce the total amount of log data. See Trimming Events.

  • For information about reducing data requirements during transport, see Compressing During Transport.

To achieve the best results, it is important to understand how fields work in NXLog and which fields are being transferred or stored. For example, removing or modifying fields without modifying $raw_event will not reduce data requirements at all for an output module instance that uses only $raw_event. See Event Records and Fields for details, as well as the explanation in Compressing During Transport below.

28.1. Filtering Events

Depending on the logging requirements and the log source, it may be possible to simply discard certain events. NXLog can be configured to filter events based on nearly any set of criteria. See also Filtering Messages.

Example 129. Dropping Unnecessary Events

In this example, an NXLog agent is configured to collect Syslog messages from devices on the local network. Events are parsed with the xm_syslog parse_syslog() procedure, which sets the SeverityValue field. Any event with a normalized severity lower than 3 (warning) is discarded.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
<Extension _syslog>
    Module  xm_syslog
</Extension>

<Input syslog>
    Module  im_udp
    Host    0.0.0.0
    Port    514
    Exec    parse_syslog(); if $SeverityValue < 3 drop();
</Input>

Similarly, the pm_norepeat module can be used to detect, count, and discard duplicate events. In their place, pm_norepeat generates a single event with a last message repeated n times message.

Example 130. Dropping Duplicate Events

With this configuration, NXLog collects Syslog messages from hosts on the local network with im_udp and parses them with the xm_syslog parse_syslog() procedure. Events are then routed through a pm_norepeat module instance, where the $Hostname, $Message, and $SourceName fields are checked to detect duplicate messages. Last, events are sent to a remote host with om_batchcompress.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
<Extension _syslog>
    Module      xm_syslog
</Extension>

<Input syslog_udp>
    Module      im_udp
    Host        0.0.0.0
    Port        514
    Exec        parse_syslog();
</Input>

<Processor norepeat>
    Module      pm_norepeat
    CheckFields Hostname, Message, SourceName
</Processor>

<Output out>
    Module      om_batchcompress
    Host        10.2.0.2
    Port        2514
</Output>

<Route r>
    Path        syslog_udp => norepeat => out
</Route>

28.2. Trimming Events

NXLog can be configured to parse events into various fields in the event record. In this case, a whitelist can be used to retain a set of important fields. See Rewriting and Modifying Messages for more information about modifying events.

Example 131. Discarding Extra Fields via Whitelist

This configuration reads from the Windows EventLog with im_msvistalog and uses an xm_rewrite module instance to discard any fields in the event record that are not included in the whitelist. The xm_rewrite instance below could be used with multiple sources; for example, the whitelist would also be suitable for the xm_syslog fields.

Note
The xm_rewrite module does not remove the $raw_event field.
nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<Extension whitelist>
    Module  xm_rewrite
    Keep    AccountName, Channel, EventID, EventReceivedTime, EventTime, Hostname, \
            Severity, SeverityValue, SourceName
</Extension>

<Input eventlog>
    Module  im_msvistalog
    <QueryXML>
        <QueryList>
            <Query Id='0'>
                <Select Path='Security'>*[System/Level&lt;=4]</Select>
            </Query>
        </QueryList>
    </QueryXML>
    Exec    whitelist->process();
</Input>

In some cases, event messages contain a lot of extra data that is duplicated across multiple events of the same time. One example of this is the "descriptive event data" which has been introduced by Microsoft for the Windows EventLog. By removing this verbose text from common events, event sizes can be reduced significantly while still preserving all the forensic details of the event.

Example 132. Removing Descriptive Data From Event Messages

The following configuration collects events from the Application, Security, and System channels. Rules are included for truncating the messages of Security events with IDs 4688 and 4769.

Note
In this example, the $Message field is truncated. However, the $raw_event field is not. For most input modules, $raw_event will include the contents of $Message and other fields (see the im_msvistalog $raw_event field). To update the $raw_event field, include a statement for this (see the comment in the configuration example). See also Compressing During Transport below for more details.
Input Sample (Event ID 4769)
A Kerberos service ticket was requested.

Account Information:
        Account Name:           WINAD$@TEST.COM
        Account Domain:         TEST.COM
        Logon GUID:             {55a7f67c-a32c-150a-29f1-7e173ff130a7}

Service Information:
        Service Name:           WINAD$
        Service ID:             TEST\WINAD$

Network Information:
        Client Address:         ::1
        Client Port:            0

Additional Information:
        Ticket Options:         0x40810000
        Ticket Encryption Type: 0x12
        Failure Code:           0x0
        Transited Services:     -

This event is generated every time access is requested to a resource such as a computer or a Windows service.  The service name indicates the resource to which access was requested.

This event can be correlated with Windows logon events by comparing the Logon GUID fields in each event.  The logon event occurs on the machine that was accessed, which is often a different machine than the domain controller which issued the service ticket.

Ticket options, encryption types, and failure codes are defined in RFC 4120.
nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
<Input eventlog>
    Module  im_msvistalog
    <QueryXML>
        <QueryList>
            <Query Id="0">
                <Select Path="Application">
                    *[System[(Level&lt;=4)]]</Select>
                <Select Path="Security">
                    *[System[(Level&lt;=4)]]</Select>
                <Select Path="System">
                    *[System[(Level&lt;=4)]]</Select>
            </Query>
        </QueryList>
    </QueryXML>
    <Exec>
        if ($Channel == 'Security') and ($EventID == 4688)
            $Message =~ s/\s*Token Elevation Type indicates the type of .*$//s;
        else if $(Channel == 'Security') and ($EventID == 4769)
            $Message =~ s/\s*This event is generated every time access is .*$//s;
        # Additional rules can be added here
        # ...
        # Optionally, update the $raw_event field
        #raw_event = $EventTime + ' ' + $Message;
    </Exec>
</Input>
Output Sample
A Kerberos service ticket was requested.

Account Information:
        Account Name:           WINAD$@TEST.COM
        Account Domain:         TEST.COM
        Logon GUID:             {55a7f67c-a32c-150a-29f1-7e173ff130a7}

Service Information:
        Service Name:           WINAD$
        Service ID:             TEST\WINAD$

Network Information:
        Client Address:         ::1
        Client Port:            0

Additional Information:
        Ticket Options:         0x40810000
        Ticket Encryption Type: 0x12
        Failure Code:           0x0
        Transited Services:     -

28.3. Compressing During Transport

There are several ways that event data can be transported between NXLog agents, including the *m_tcp and *m_ssl modules. However, those modules do not provide data compression. The im_batchcompress and om_batchcompress modules, available in NXLog Enterprise Edition, can be used to transfer events in compressed (and optionally, encrypted) batches.

The following chart compares the data requirements for the *m_tcp, *m_ssl (with TLSv1.2), and *m_batchcompress module pairs. It is based on a sample of BSD Syslog records parsed with parse_syslog(). The values shown reflect the total bi-directional bytes transferred at the packet level. Of course, ratios will vary from this in practice based on network conditions and the compressibility of the event data.

Note that the om_tcp and om_ssl modules (among others) transfer only the $raw_event field by default, but can be configured to transfer all fields with OutputType Binary. The om_batchcompress module transfers all fields in the event record, but it is possible to send only the $raw_event field by first removing the other fields (see Generating $raw_event and Removing Other Fields below).

Data Requirements for Various Transfer Methods

Simply configuring the *m_batchcompress modules for the transfer of event data between NXLog agents can significantly reduce the bandwidth requirements for that part of the log path.

Example 133. Batched Log Transfer

With the following configuration, an NXLog agent uses om_batchcompress to send events in compressed batches to a remote NXLog agent.

Tip
The *m_batchcompress modules also support SSL/TLS encryption; see the im_batchcompress and om_batchcompress configuration details.
nxlog.conf (Sending Agent) [Download file]
1
2
3
4
5
<Output out>
    Module  om_batchcompress
    Host    10.2.0.2
    Port    2514
</Output>

The remote NXLog agent receives and decompresses the received batches with im_batchcompress. All fields in an event are available to the receiving agent.

nxlog.conf (Receiving Agent) [Download file]
1
2
3
4
5
<Input in>
    Module      im_batchcompress
    ListenAddr  10.2.0.2
    Port        2514
</Input>

To further reduce the size of the batches transferred by the *m_batchcompress modules, and if only the $raw_event field will be needed later in the log path, the extra fields can be removed from the event record prior to transfer. This can be done with an xm_rewrite instance for multiple fields or with the delete() procedure (see Renaming and Deleting Fields).

Example 134. Generating $raw_event and Removing Other Fields

In this configuration, events are collected from the Windows EventLog with im_msvistalog, which sets the $raw_event and many other fields. To reduce the size of the events, only the $raw_event field is retained; all the other fields in the event record are removed by the xm_rewrite module instance (called by clean->process()).

Note
Rather than using the default im_msvistalog $raw_event field, it would also be possible to customize it with something like $raw_event = $EventTime + ' ' + $Message or to_json().
nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<Extension clean>
    Module  xm_rewrite
    Keep    raw_event
</Extension>

<Input eventlog>
    Module  im_msvistalog
    <QueryXML>
        <QueryList>
            <Query Id='0'>
                <Select Path='Security'>*[System/Level&lt;=4]</Select>
            </Query>
        </QueryList>
    </QueryXML>
</Input>

<Output out>
    Module  om_batchcompress
    Host    10.2.0.2
    Exec    clean->process();
</Output>

Alternatively, if the various fields in the event record will be handled later in the log path, the $raw_event field can be set to an empty string (but see the warning below).

Example 135. Emptying $raw_event and Sending Other Fields

This configuration collects events from the Windows EventLog with im_msvistalog, which writes multiple fields to the event record. In this case, the $raw_event field contains the same data as other fields. Because the om_batchcompress module instance will send all the fields in the event record, the $raw_event field can be emptied.

Warning
Many output modules operate on the $raw_event field only. It should not be set to an empty string unless the output module sends all the event fields (om_batchcompress or a module using the Binary OutputType) and so on for all subsequent agents and modules. Otherwise, a module instance will encounter an empty $raw_event. For this reason, the following example is in general not recommended.
nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<Input eventlog>
    Module  im_msvistalog
    <QueryXML>
        <QueryList>
            <Query Id='1'>
                <Select Path='Security'>*[System/Level&lt;=4]</Select>
            </Query>
        </QueryList>
    </QueryXML>
</Input>

<Output out>
    Module  om_batchcompress
    Host    10.2.0.2
    Exec    $raw_event = '';
</Output>

29. Reliable Message Delivery

Sometimes regulatory compliance or other requirements mandate that the logging infrastructure function in an ultra-reliable manner. NXLog Enterprise Edition can be configured to guarantee that:

29.1. Crash-Safe Operation

A host or NXLog crash can happen for various reasons, including power failures without a UPS, kernel panics, and software bugs. To protect against data loss in these situations, the following techniques are implemented in NXLog Enterprise Edition.

  • Log messages are buffered in various places in NXLog, and buffered messages can be lost in the case of a crash. Persistent module message queues can be enabled so that these messages are stored on disk instead of in memory. Each log message is removed from the queue only after successful delivery. See the PersistLogqueue and SyncLogqueue global configuration directives, and the PersistLogqueue and SyncLogqueue module directives.

    Warning
    Log message removal from queues in processor modules happens before delivery. This can result in potential data loss. Do not use processor modules when high reliability operation is required.
  • Input positions (for im_file and other modules) are saved in the cache file, and by default this file is only saved to disk on shutdown. In case of a crash some events may be duplicated or lost depending on the value of the ReadFromLast directive. This data can be periodically flushed and synced to disk using the CacheFlushInterval and CacheSync directives.

Example 136. Configuration for Crash-Safe Operation

In this example, the log queues are synced to disk after each successful delivery. The cache file containing the current event ID is also flushed and synced to disk after each event is read from the database. Note that these reliability features, when enabled, significantly reduce the processing speed.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
PersistLogqueue TRUE
SyncLogqueue TRUE
CacheFlushInterval always
CacheSync TRUE

<Input in>
    Module  im_file
    File    'input.log'
</Input>

<Output out>
    Module  om_tcp
    Host    10.0.0.1
    Port    1514
</Output>

29.2. Reliable Network Delivery

The TCP protocol provides guaranteed packet delivery via packet level acknowledgment. Unfortunately, if the receiver closes the TCP connection prematurely while messages are being transmitted, unsent data stored in the socket buffers will be lost since this is handled by the operating system instead of the application (NXLog). This can result in message loss and affects im_tcp, om_tcp, im_ssl, and om_ssl.

The solution to this unreliability in the TCP protocol is application-level acknowledgment. NXLog provides two pairs of modules for this purpose.

  • NXLog can use the HTTP/HTTPS protocol to provide guaranteed message delivery over the network, optionally with TLS/SSL. The client (om_http) sends the event in a HTTP POST request. The server (im_http, only available in NXLog Enterprise Edition) responds with a status code indicating successful message reception.

    Example 137. HTTPS Log Transfer

    In the following configuration example, a client reads logs from a file and transmits the logs over an SSL-secured HTTP connection.

    nxlog.conf (Client/Sending) [Download file]
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    
    <Input in>
        Module              im_file
        File                'input.log'
    </Input>
    
    <Output out>
        Module              om_http
        URL                 https://10.0.0.1:8080/
        HTTPSCertFile       %CERTDIR%/client-cert.pem
        HTTPSCertKeyFile    %CERTDIR%/client-key.pem
        HTTPSCAFile         %CERTDIR%/ca.pem
    </Output>

    The server side accepts the HTTPS connections and stores the received messages in a file. The contents of input.log will be replicated in output.log.

    nxlog.conf (Server/Receiving) [Download file]
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    
    <Input in>
        Module              im_http
        ListenAddr          0.0.0.0
        Port                8080
        HTTPSCertFile       %CERTDIR%/server-cert.pem
        HTTPSCertKeyFile    %CERTDIR%/server-key.pem
        HTTPSCAFile         %CERTDIR%/ca.pem
    </Input>
    
    <Output out>
        Module              om_file
        File                'output.log'
    </Output>
  • The om_batchcompress and im_batchcompress modules, available in NXLog Enterprise Edition, also provide acknowledgment as part of the batchcompress protocol.

    Example 138. Batched Log Transfer

    With the following configuration, a client reads logs from a file and transmits the logs in compressed batches to a remote NXLog agent.

    nxlog.conf (Client/Sending) [Download file]
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    
    <Input in>
        Module         im_file
        File           'input.log'
    </Input>
    
    <Output out>
        Module         om_batchcompress
        Host           10.0.0.1
        UseSSL         true
        CertFile       %CERTDIR%/client-cert.pem
        CertKeyFile    %CERTDIR%/client-key.pem
        CAFile         %CERTDIR%/ca.pem
    </Output>

    The remote NXLog agent receives and decompresses the received message batches and stores the individual messages in a file. The contents of input.log will be replicated in output.log.

    nxlog.conf (Server/Receiving) [Download file]
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    
    <Input in>
        Module          im_batchcompress
        ListenAddr      0.0.0.0
        CertFile        %CERTDIR%/server-cert.pem
        CertKeyFile     %CERTDIR%/server-key.pem
        CAFile          %CERTDIR%/ca.pem
    </Input>
    
    <Output out>
        Module          om_file
        File            'output.log'
    </Output>

29.3. Protection Against Duplication

If the contents of the cache file (which stores the event position) are lost, the module can either read everything from the beginning or risk losing some messages. In the former case, messages may be duplicated. When using persistent queues, after the output module delivers the message it removes the message from the queue. If the crash occurs just before the removal, the message will be sent again (a duplicate) after the restart.

In some cases it may be very important that a log message not be duplicated. For example, a duplicated message may trigger the same alarm a second time or cause an extra entry in a financial transaction log. NXLog Enterprise Edition can be configured to prevent duplicate messages from occurring.

The best way to prevent duplicated messages is with a serial number, as it is only possible to detect duplicates at the receiver. The receiver can keep track of what has been received by storing the serial number of the last message. If a message is received with the same or a lower serial number from the same source, the message is simply discarded.

In NXLog Enterprise Edition, duplication prevention works as follows.

  • Each module which receives a message directly from an input source or from another module in the route assigns a field named $__SERIAL__$ with a monotonically increasing serial number. The serial number is taken from a global generator and is increased after each fetch so that two messages received at two modules simultaneously will not have the same serial number. The serial number is initialized to the seconds elapsed since epoch when NXLog is started. This way it can provide 1,000,000 serial numbers per second without problems in case it is stopped and restarted. Otherwise the value would need to be saved and synced to disk as well after each serial number fetch and again this would result in a huge performance hit. When a module receives a message it checks the value of the field named $__SERIAL__$ against the last saved value.

  • The im_http module keeps the value of the last $__SERIAL__$ for each client. It is only possible to know and identify the client (om_http sender) in HTTPS mode. The Common Name (CN) in the certificate subject is used and is assumed to uniquely identify the client.

    Note
    The remote IP and port number cannot be used to identify the remote sender because the remote port is assigned dynamically and changes for every connection. Thus if a client sends a message, disconnects, reconnects, and then sends the same message again, it is impossible to know if this is the same client or another. For this reason it is not possible to protect against message duplication with plain TCP or HTTP when multiple clients connect from the same IP. The im_ssl and im_batchcompress modules do not have the certificate subject extraction implemented at this time.
  • All other non-network modules use the value of SourceModuleName which is automatically set to the name of the module instance generating the log message. This value is assumed to uniquely identify the source. The value of SourceModuleName is not overwritten if it already exists. Note that this may present problems in some complex setups.

  • The algorithm is implemented in one procedure call named duplicate_guard(), which can be used in modules to prevent message duplication. The dropped() function can be then used to test whether the current log message has been dropped.

Example 139. Disallowing Duplicated Messages

The following client and server configuration examples extend the earlier HTTPS example to provide an ultra-reliable operation where messages cannot be lost locally due to a crash, lost over the network, or duplicated.

nxlog.conf (Client/Sending) [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
PersistLogqueue TRUE
SyncLogqueue TRUE
CacheFlushInterval always
CacheSync TRUE

<Input in>
    Module              im_file
    File                'input.log'
</Input>

<Output out>
    Module              om_http
    URL                 https://10.0.0.1:8080/
    HTTPSCertFile       %CERTDIR%/client-cert.pem
    HTTPSCertKeyFile    %CERTDIR%/client-key.pem
    HTTPSCAFile         %CERTDIR%/ca.pem
    Exec                duplicate_guard();
</Output>

The server side accepts the HTTPS connections and stores the received messages in a file. The contents of input.log will be replicated in output.log

nxlog.conf (Server/Receiving) [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
PersistLogqueue TRUE
SyncLogqueue TRUE
CacheFlushInterval always
CacheSync TRUE

<Input in>
    Module              im_http
    ListenAddr          0.0.0.0
    Port                8080
    HTTPSCertFile       %CERTDIR%/server-cert.pem
    HTTPSCertKeyFile    %CERTDIR%/server-key.pem
    HTTPSCAFile         %CERTDIR%/ca.pem
    Exec                duplicate_guard();
</Input>

<Output out>
    Module              om_file
    File                'output.log'
    Exec                duplicate_guard();
</Output>

OS Support

The following chapters provide short example configurations for collecting log data from sources specific to certain operating systems.

30. IBM AIX

NXLog can collect various types of system logs on the AIX platform. See Supported Platforms for a list of supported IBM AIX versions.

Local Syslog

Messages written to /dev/log can be collected with the im_uds module. Events written to file in Syslog format can be collected with im_file. In both cases, the xm_syslog module can be used to parse the events. See the Syslog section for more information.

Example 140. Reading Syslog Messages From File

This example reads Syslog messages from /var/log/messages and parses them with the parse_syslog() procedure.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
<Extension _syslog>
    Module  xm_syslog
</Extension>

<Input in>
    Module  im_file
    File    "/var/log/messages"
    Exec    parse_syslog();
</Input>
AIX Audit

The im_aixaudit module natively collects logs generated by the AIX Audit system, without depending on auditstream or any other process.

Example 141. Collecting AIX Audit Logs

This example reads AIX audit logs from the /dev/audit device file.

nxlog.conf [Download file]
1
2
3
4
<Input in>
    Module      im_aixaudit
    DeviceFile  /dev/audit
</Input>
Process Accounting

The im_acct module can be used to gather details about who runs what processes.

Example 142. Reading Process Accounting Logs

This configuration turns on process accounting (using /tmp/nxlog.acct as the log file) and watches for messages.

nxlog.conf [Download file]
1
2
3
4
5
<Input acct>
    Module  im_acct
    AcctOn  TRUE
    File    "/tmp/nxlog.acct"
</Input>
File Integrity Monitoring

The im_fim module can be used to monitor files for changes.

Example 143. Monitoring File Integrity

This example monitors files in the /etc and /srv directories, generating events when files are modified or deleted. Files ending in .bak are excluded from the watch list.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
<Input fim>
    Module          im_fim
    File            "/etc/*"
    File            "/srv/*"
    Exclude         "*.bak"
    Digest          sha1
    ScanInterval    3600
    Recursive       TRUE
</Input>
Log Files

The im_file module can be used to collect events from log files.

Example 144. Reading From Log Files

This configuration reads messages from the /opt/test/input.log file. No parsing is performed; each line is available in the $raw_event field.

nxlog.conf [Download file]
1
2
3
4
<Input in>
    Module  im_file
    File    "/opt/test/input.log"
</Input>
Custom Programs

The im_exec module allows log data to be collected from custom external programs.

Example 145. Using an External Command

This example uses the tail command to read from a file.

Note
The im_file module should be used to read log messages from files. This example only demonstrates the use of the im_exec module.
nxlog.conf [Download file]
1
2
3
4
5
6
<Input exec>
    Module  im_exec
    Command /usr/bin/tail
    Arg     -f
    Arg     /var/adm/ras/errlog
</Input>

31. FreeBSD and OpenBSD

NXLog can collect various types of system logs on FreeBSD and OpenBSD platforms. See Supported Platforms for a list of supported FreeBSD and OpenBSD versions.

Kernel

Logs from the kernel can be collected directly with the im_kernel module.

Note
The system logger may need to be disabled or reconfigured to collect logs with im_kernel. To completely disable syslogd on FreeBSD, run service syslogd onestop and sysrc syslogd_enable=NO. On OpenBSD, run rcctl stop syslogd and rcctl disable syslogd.
Example 146. Collecting Kernel Logs

This configuration reads events from the kernel.

nxlog.conf [Download file]
1
2
3
<Input kernel>
    Module  im_kernel
</Input>
Local Syslog

Messages written to /dev/log can be collected with the im_uds module. Events written to file in Syslog format can be collected with im_file. In both cases, the xm_syslog module can be used to parse the events. See the Syslog section for more information.

Example 147. Reading Syslog Messages From File

This example reads Syslog messages from /var/log/messages and parses them with the parse_syslog() procedure.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
<Extension _syslog>
    Module  xm_syslog
</Extension>

<Input in>
    Module  im_file
    File    "/var/log/messages"
    Exec    parse_syslog();
</Input>
Basic Security Mode (BSM) Auditing

The im_bsm module collects logs generated by the BSM auditing system.

Note
OpenBSD does not support BSM Auditing.
Example 148. Collecting BSM Audit Logs

This example reads BSM audit logs from the /dev/auditpipe device file.

nxlog.conf [Download file]
1
2
3
4
<Input bsm>
    Module      im_bsm
    DeviceFile  /dev/auditpipe
</Input>
Process Accounting

The im_acct module can be used to gather details about who runs what processes.

Example 149. Reading Process Accounting Logs

This configuration turns on process accounting (using /var/account/acct as the log file) and watches for messages.

nxlog.conf [Download file]
1
2
3
4
5
<Input acct>
    Module  im_acct
    AcctOn  TRUE
    File    "/var/account/acct"
</Input>
File Integrity Monitoring

The im_fim module can be used to monitor files for changes.

Example 150. Monitoring File Integrity

This example monitors files in the /etc and /srv directories, generating events when files are modified or deleted. Files ending in .bak are excluded from the watch list.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
<Input fim>
    Module          im_fim
    File            "/etc/*"
    File            "/srv/*"
    Exclude         "*.bak"
    Digest          sha1
    ScanInterval    3600
    Recursive       TRUE
</Input>
Log Files

The im_file module can be used to collect events from log files.

Example 151. Reading From Log Files

This configuration reads messages from the /opt/test/input.log file. No parsing is performed; each line is available in the $raw_event field.

nxlog.conf [Download file]
1
2
3
4
<Input in>
    Module  im_file
    File    "/opt/test/input.log"
</Input>
Custom Programs

The im_exec module allows log data to be collected from custom external programs.

Example 152. Using an External Command

This example uses the tail command to read from a file.

Note
The im_file module should be used to read log messages from files. This example only demonstrates the use of the im_exec module.
nxlog.conf [Download file]
1
2
3
4
5
6
<Input exec>
    Module  im_exec
    Command /usr/bin/tail
    Arg     -f
    Arg     /var/log/messages
</Input>

32. GNU/Linux

NXLog can collect various types of system logs on GNU/Linux platforms. See Supported Platforms for a list of supported GNU/Linux versions.

Kernel

The im_kernel module reads logs directly from the kernel log buffer. These logs can be parsed with xm_syslog. See the Linux System Logs section.

Local Syslog

Messages written to /dev/log can be collected with the im_uds module. Events written to file in Syslog format can be collected with im_file. In each case, the xm_syslog module can be used to parse the events. See the Linux System Logs and Collecting and Parsing Syslog sections for more information.

Linux Audit System

The im_linuxaudit module can be used to collect Audit System logs directly from the kernel without using auditd or temporary log files. Audit logs can also be collected from file with im_file; or via the network with the Audit Dispatcher, the audisp-remote plugin, and im_tcp. See Linux Audit System for more details.

Process Accounting

The im_acct module can be used to gather details about who runs what processes. This overlaps with Audit System logging.

File Integrity Monitoring

The im_fim module can be used to monitor files for changes.

Log Files

The im_file module can be used to collect events from log files.

Log Databases

Events can be read from databases with the im_dbi, im_oci, and im_odbc modules.

Custom Programs and Scripts

The im_exec module allows log data to be collected from custom external programs. The im_perl, im_python and im_ruby modules can also be used to implement integration with custom data sources or sources that are not supported out-of-the-box.

33. Apple macOS

NXLog can collect various types of system logs on the macOS platform. See Supported Platforms for a list of supported Apple macOS versions.

Kernel

Logs from the kernel can be collected directly with the im_kernel module. This requires disabling syslogd. Alternatively, kernel logs can be collected via the local log file with im_file; see Local Syslog below.

Newer versions of Apple macOS use ULS (Unified Logging System) with SIP (System Integrity Protection) and users are unable to easily disable syslogd while keeping SIP enabled. For this setup, you can leverage the im_exec module to collect from /usr/bin/log stream --style=json --type=log.

Example 153. Collecting Kernel Logs Directly

This configuration uses the im_kernel module to read events directly from the kernel (via /dev/klog). This requires that syslogd be disabled as follows:

  1. Unload the daemon.

    $ sudo launchctl unload /System/Library/LaunchDaemons/com.apple.syslogd.plist
  2. Rename plist to keep syslogd from starting again at the next reboot.

    $ sudo mv /System/Library/LaunchDaemons/com.apple.syslogd.plist \
      /System/Library/LaunchDaemons/com.apple.syslogd.plist.disabled
nxlog.conf [Download file]
1
2
3
4
5
6
7
8
<Extension _syslog>
    Module  xm_syslog
</Extension>

<Input kernel>
    Module  im_kernel
    Exec    parse_syslog_bsd();
</Input>
Example 154. Collecting ULS Kernel Logs from /usr/bin/log

This configuration uses the im_exec module to read events from the kernel (via /usr/bin/log) and parses the data with the xm_json module.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
<Extension json>
    Module      xm_json
</Extension>

<Extension multiline>
    Module      xm_multiline
    HeaderLine  /^\[{|},{/
</Extension>

<Input in>
    Module      im_exec
    Command     /usr/bin/log
    Arg         stream
    Arg         --style=json
    Arg         --type=log
    InputType   multiline
    <Exec>
        $raw_event =~ s/^\[{|},{/{/;
        $raw_event =~ s/}\]|}$//;
        $raw_event = $raw_event + "\n}";
        parse_json();
    </Exec>
</Input>
Local Syslog

Events written to file in Syslog format can be collected with im_file. The xm_syslog module can be used to parse the events. See the Syslog section for more information.

Example 155. Reading Syslog Messages From File

This configuration file collects system logs from /var/log/system.log. This method does not read from /dev/klog directly, so it is not necessary to disable syslogd.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
<Extension _syslog>
    Module  xm_syslog
</Extension>

<Input in>
    Module  im_file
    File    "/var/log/system.log"
    Exec    parse_syslog();
</Input>
Apple System Logs Files

The im_file and xm_asl modules can be used to collect and parse Apple System Log (*.asl) files.

Example 156. Reading and Parsing Apple System Logs

This example reads events from input.asl and parses them with the xm_asl parser.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
<Extension asl_parser>
    Module  xm_asl
</Extension>

<Input in>
    Module      im_file
    # Example: "/var/log/asl/*"
    File        "foo/input.asl"
    InputType   asl_parser
    Exec        delete($EventReceivedTime);
</Input>
Basic Security Mode (BSM) Auditing

The im_bsm module collects logs directly from the BSM auditing system.

Example 157. Collecting BSM Audit Logs From the Kernel

This configuration reads BSM audit logs directly from the kernel with the im_bsm module.

nxlog.conf [Download file]
1
2
3
4
5
6
Group   wheel

<Input bsm>
    Module  im_bsm
    File    /dev/auditpipe
</Input>

Alternatively, BSM logs can be read from the log files.

Example 158. Reading BSM Audit Logs From File

This configuration reads from the BSM audit log files with im_file and parses the events with xm_bsm.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
Group   wheel

<Extension bsm_parser>
    Module      xm_bsm
</Extension>

<Input bsm>
    Module      im_file
    File        '/var/audit/*'
    InputType   bsm_parser
</Input>
Process Accounting

The im_acct module can be used to gather details about who runs what processes.

Example 159. Reading Process Accounting Logs

With this configuration file, NXLog will enable process accounting to the specified file and reads events from it.

nxlog.conf [Download file]
1
2
3
4
5
6
7
Group   wheel

<Input acct>
    Module  im_acct
    File    '/var/log/acct'
    AcctOn  TRUE
</Input>
File Integrity Monitoring

The im_fim module can be used to monitor files for changes.

Example 160. Monitoring File Integrity

This configuration watches for changes to files and directories under /bin and /usr/bin/.

nxlog.conf [Download file]
1
2
3
4
5
6
7
<Input fim>
    Module          im_fim
    File            "/bin/*"
    File            "/usr/bin/*"
    ScanInterval    3600
    Recursive       TRUE
</Input>
Log Files

The im_file module can be used to collect events from log files.

Example 161. Reading From Log Files

This configuration uses the im_file module to read events from the specified log file.

nxlog.conf [Download file]
1
2
3
4
<Input in>
    Module  im_file
    File    "/foo/in.log"
</Input>
Custom Programs

The im_exec module allows log data to be collected from custom external programs.

Example 162. Using an External Command

This example uses the tail command to read from a file.

Note
The im_file module should be used to read log messages from files. This example only demonstrates the use of the im_exec module.
nxlog.conf [Download file]
1
2
3
4
5
6
<Input systemlog>
    Module  im_exec
    Command /usr/bin/tail
    Arg     -f
    Arg     /var/log/system.log
</Input>

34. Oracle Solaris

NXLog can collect various types of system logs on the Solaris platform. See Supported Platforms for a list of supported Oracle Solaris versions.

Local Syslog

Events written to file in Syslog format can be collected with the im_file module and parsed with the xm_syslog module. See the Syslog section for more information.

Example 163. Reading Syslog Messages From File

This example uses the im_file module to read messages from /var/log/messages and the xm_syslog parse_syslog() procedure to parse them.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
<Extension _syslog>
    Module  xm_syslog
</Extension>

<Input in>
    Module  im_file
    File    "/var/log/messages"
    Exec    parse_syslog();
</Input>
Basic Security Mode (BSM) Auditing

The xm_bsm module can be used to parse logs collected with im_file.

Example 164. Collect BSM Audit Logs From the Kernel

This example configuration reads from files in /var/audit with im_file. The InputType provided by xm_bsm is used to parse the binary format.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
<Extension bsm_parser>
    Module      xm_bsm
</Extension>

<Input in>
    Module      im_file
    File        '/var/audit/*'
    InputType   bsm_parser
</Input>
Process Accounting

The im_acct module can be used to gather details about who runs what processes.

Example 165. Reading Process Accounting Logs

With this configuration file, NXLog will enable process accounting to the specified file and read events from it.

nxlog.conf [Download file]
1
2
3
4
5
<Input acct>
    Module  im_acct
    AcctOn  TRUE
    File    '/tmp/nxlog.acct'
</Input>
File Integrity Monitoring

The im_fim module can be used to monitor files for changes.

Example 166. Monitoring File Integrity

This configuration watches for changes to files and directories under /usr/bin/.

nxlog.conf [Download file]
1
2
3
4
5
6
7
<Input fim>
    Module          im_fim
    File            "/usr/bin/*"
    Digest          SHA1
    ScanInterval    3600
    Recursive       TRUE
</Input>
Log Files

The im_file module can be used to collect events from log files.

Example 167. Reading From Log Files

This configuration uses the im_file module to read events from the specified log file.

nxlog.conf [Download file]
1
2
3
4
<Input in>
    Module  im_file
    File    "/foo/input.log"
</Input>
Custom Programs

The im_exec module allows log data to be collected from custom external programs.

Example 168. Using an External Command

This example uses the tail command to read from a file.

Note
The im_file module should be used to read log messages from files. This example only demonstrates the use of the im_exec module.
nxlog.conf [Download file]
1
2
3
4
5
6
<Input systemlog>
    Module  im_exec
    Command /usr/bin/tail
    Arg     -f
    Arg     /var/log/syslog
</Input>

35. Microsoft Windows

NXLog can collect various types of system logs on the Windows platform. See Supported Platforms for a list of supported Windows versions.

Windows EventLog

See the Windows EventLog section, which covers both local and remote event collection with the im_msvistalog, im_wseventing, im_mseventlog, and im_wmi modules.

Windows Event Tracing (ETW)

Events logged through ETW can be collected with the im_etw module. This includes events logged to the Analytical and Debug logs.

Sysmon

Many additional audit events can be generated with the Sysmon utility, including process creation, system driver loading, network connections, and modification of file creation timestamps. These events are written to the EventLog. See the Sysmon section for more information.

Windows Performance Counters

The im_winperfcount module can be used for collecting data such as CPU and memory usage.

File Integrity Monitoring

The im_fim module can be used to monitor files for changes.

Registry Monitoring

The Windows Registry can be monitored for changes; see the im_regmon module.

Log Files

The im_file module can be used to collect events from log files.

Log Databases

Events can be read from databases with the im_odbc module. Some products write logs into SQL Server databases; see the Microsoft System Center Operations Manager section for example.

Custom Programs

The im_exec module allows log data to be collected from custom external programs.

Microsoft IIS

IIS can be configured to write logs in W3C format, which can be read with im_file and parsed with xm_w3c or xm_csv. Other formats can be parsed with other methods; see Microsoft IIS.

Microsoft SQL Server

Log messages can be collected from the Microsoft SQL Server error log files with the im_file module. See Microsoft SQL Server.

Integration

36. Apache HTTP Server

The Apache HTTP Server provides very comprehensive and flexible logging capabilites. A brief overview is provided in the following sections; see the Log Files section of the Apache HTTP Server Documentation for more detailed information about configuring logging.

36.1. Error Log

Apache error logging is controlled by the ErrorLog, ErrorLogFormat, and LogLevel directives. The error log can be parsed by NXLog with a regular expression.

Example 169. Using the Apache Error Log

The following directives enable error logging of all messages at or above the "informational" severity level, in the specified format, to the specified file. The ErrorLogFormat defined below is equivalent to the default (which includes the timestamp, the module producing the message, the event severity, the process ID, the thread ID, the client address, and the detailed error message).

apache2.conf
LogLevel info
ErrorLogFormat "[%{u}t] [%-m:%l] [pid %P:tid %T] [client %a] %M"
ErrorLog /var/log/apache2/error.log

Following is a typical log message generated by the Apache HTTP Server, an NXLog configuration for parsing it, and the resulting JSON.

Log Sample
[Tue Aug 01 07:17:44.496832 2017] [core:info] [pid 15019:tid 140080326108928] [client 192.168.56.1:60154] AH00128: File does not exist: /var/www/html/notafile.html
nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<Input apache_error>
    Module  im_file
    File    '/var/log/apache2/error.log'
    <Exec>
        if $raw_event =~ /(?x)^\[\S+\ ([^\]]+)\]\ \[(\S+):(\S+)\]\ \[pid\ (\d+):
                          tid\ (\d+)\]\ (\[client\ (\S+)\]\ )?(.+)$/
        {
            $EventTime = parsedate($1);
            $ApacheModule = $2;
            $ApacheLogLevel = $3;
            $ApachePID = $4;
            $ApacheTID = $5;
            if $7 != '' $ClientAddress = $7;
            $Message = $8;
        }
    </Exec>
</Input>
Output Sample
{
  "EventReceivedTime": "2017-08-01T07:17:45.641190+02:00",
  "SourceModuleName": "apache_error",
  "SourceModuleType": "im_file",
  "EventTime": "2017-08-01T07:17:44.496832+02:00",
  "ApacheModule": "core",
  "ApacheLogLevel": "info",
  "ApachePID": "15019",
  "ApacheTID": "140080317716224",
  "ClientAddress": "192.168.56.1:60026",
  "Message": "AH00128: File does not exist: /var/www/html/notafile.html"
}

36.2. Access Log

The access log file and format are configured with the LogFormat and CustomLog directives. The LogFormat directive is used to define a format, while the CustomLog directive configures logging to a specified file in one of the defined formats. Multiple CustomLog directives can be used to enable logging to multiple files.

There are several options for handling logging when using virtual hosts. The examples below, when specified in the main server context (not in a <VirtualHost> section), will log all requests exactly as with a single-host server. The %v format string can be added, if desired, to log the name of the virtual server responding to the request. Alternatively, the CustomLog directive can be specified inside a <VirtualHost> section, and in this case only the requests served by that virtual server will be logged to the file.

Note
Pre-defined format strings for the Common Log and Combined Log Formats may be included by default. These pre-defined formats may use %O (the total sent including headers) instead of the standard %b (the size of the requested file) in order to allow detection of partial requests.
Example 170. Using the Common Log Format for the Access Log

The LogFormat directive below creates a format named common that corresponds to the Common Log Format. The second directive configures the Apache HTTP Server to write entries to the access_log file in the common format.

apache2.conf
LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog /var/log/apache2/access_log common
Example 171. Using the Combined Log Format for the Access Log

The following directives will configure the Apache HTTP Server to write entries to the access_log file in the Combined Log Format.

apache2.conf
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined
CustomLog /var/log/apache2/access_log combined

NXLog configuration examples for parsing these access log formats can be found in the Common & Combined Log Formats section.

37. Apache Tomcat

Apache Tomcat provides flexible logging that can be configured for different transports and formats.

Example 172. Collecting Apache Tomcat Logs

Here is a log sample consisting of three events. The log message of the second event spans multiple lines.

Apache Tomcat Log Example
2001-01-25 17:31:42,136 INFO [org.nxlog.somepackage.Class] - single line
2001-01-25 17:41:16,268 ERROR [org.nxlog.somepackage.Class] - Error retrieving names: ; nested exception is:
        java.net.ConnectException: Connection refused
AxisFault
 faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
 faultSubcode:
 faultString: java.net.ConnectException: Connection refused
 faultActor:
 faultNode:
 faultDetail:
        {http://xml.apache.org/axis/}stackTrace:java.net.ConnectException: Connection refused
2001-01-25 17:57:38,469 INFO [org.nxlog.somepackage.Class] - third log message

This can be very useful to filter messages by the emitting Java class, for example.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
<Input in>
    Module  im_file
    File    "/var/log/tomcat6/catalina.out"
    <Exec>
        if $raw_event =~ /(?x)^(\d{4}\-\d{2}\-\d{2}\ \d{2}\:\d{2}\:\d{2}),\d{3}
                          \ (\S+)\ \[(\S+)\]\ \-\ (.*)/
        {
            $log4j.time = parsedate($1);
            $log4j.loglevel = $2;
            $log4j.class = $3;
            $log4j.msg = $4;
        }
    </Exec>
</Input>

To parse and process multi-line messages such as the above, see Parsing Multi-Line Messages.

38. APC Automatic Transfer Switch

The APC Automatic Transfer Switch (ATS) is capable of sending its logs to a remote Syslog destination via UDP.

Log Sample
Date        Time      Event
------------------------------------------------------------------------
03/26/2017  16:20:55  Automatic Transfer Switch: Communication
                      established.
03/26/2017  16:20:45  System: Warmstart.
03/26/2017  16:19:13  System: Detected an unauthorized user attempting
                      to access the SNMP interface from 192.168.15.11.

The ATS is an independent device, so if there more than one installed in a particular environment the configuration below must be applied to each device individually. For more details about configuring APC ATS logging, go to the APC Support Site and select the product name or part number.

Note
The steps below have been tested on AP7700 series devices and should work for other ATS models also.
  1. Configure NXLog for receiving log entries via UDP (see the example below). Then restart NXLog.

  2. Make sure the NXLog agent is accessible from the device.

  3. Configure Syslog logging on the ATS using either the web interface or the command line. See the following sections.

Example 173. Receiving Logs from APC ATS

The following examples shows the ATS logs as received and processed by NXLog.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<Extension _syslog>
    Module  xm_syslog
</Extension>

<Extension _json>
    Module  xm_json
</Extension>

<Input in_syslog_udp>
    Module  im_udp
    Host    0.0.0.0
    Port    514
    Exec    parse_syslog();
</Input>

<Output file>
    Module  om_file
    File    "/var/log/apc.log"
    Exec    to_json();
</Output>

Logs like the example at the beginning of the chapter will produce output as follows.

Output Sample
{
  "MessageSourceAddress": "192.168.15.22",
  "EventReceivedTime": "2017-03-26 17:03:27",
  "SourceModuleName": "in_syslog_udp",
  "SourceModuleType": "im_udp",
  "SyslogFacilityValue": 23,
  "SyslogFacility": "LOCAL7",
  "SyslogSeverityValue": 7,
  "SyslogSeverity": "DEBUG",
  "SeverityValue": 1,
  "Severity": "DEBUG",
  "Hostname": "192.168.15.22",
  "EventTime": "2017-03-26 16:04:18",
  "SourceName": "System",
  "Message": "Detected an unauthorized user attempting to access the SNMP interface from 192.168.15.11. 0x0004"
}
{
  "MessageSourceAddress": "192.168.15.22",
  "EventReceivedTime": "2017-03-26 17:20:04",
  "SourceModuleName": "in_syslog_udp",
  "SourceModuleType": "im_udp",
  "SyslogFacilityValue": 23,
  "SyslogFacility": "LOCAL7",
  "SyslogSeverityValue": 7,
  "SyslogSeverity": "DEBUG",
  "SeverityValue": 1,
  "Severity": "DEBUG",
  "Hostname": "192.168.15.22",
  "EventTime": "2017-03-26 16:20:54",
  "SourceName": "System",
  "Message": "Warmstart. 0x0002"
}
{
  "MessageSourceAddress": "192.168.15.22",
  "EventReceivedTime": "2017-03-26 17:20:04",
  "SourceModuleName": "in_syslog_udp",
  "SourceModuleType": "im_udp",
  "SyslogFacilityValue": 23,
  "SyslogFacility": "LOCAL7",
  "SyslogSeverityValue": 7,
  "SyslogSeverity": "DEBUG",
  "SeverityValue": 1,
  "Severity": "DEBUG",
  "Hostname": "192.168.15.22",
  "EventTime": "2017-03-26 16:20:55",
  "Message": "Automatic Transfer Switch: Communication established. 0x0C05"
}

38.1. Configuring via the Web Interface

  1. Log in to the web panel.

  2. Go to Network  Syslog.

  3. Enable Syslog.

  4. Select the Facility.

  5. Add up to four Syslog servers and a port for each.

  6. Map the Local Severity to the Syslog Severity as required.

    Syslog Configuration
  7. Click Apply.

38.2. Configuring via the Command Line

  1. Log in to the ATS via Telnet.

  2. Type 2 and then 9 to go to the Syslog settings.

  3. Type 1 to configure the Syslog settings.

  4. Type 1 to enable Syslog.

  5. Type 2 to configure the Syslog facility.

  6. Type 3 to save the changes.

  7. Press ESC to go one level up.

  8. Select one of the four Syslog server slots.

  9. Type 1 to set the Syslog server IP address.

  10. Type 2 to change set the UDP port number.

  11. Type 3 to apply the changes.

  12. Press ESC to go one level up.

  13. Type 6 to map the local severity to the Syslog severity.

  14. Use options from 1 to 4 to choose the mapping.

  15. Type 5 to accept the changes.

Example 174. ATS Syslog Settings

The following shows the Syslog settings screen, which is shown after completing step 2 above.

------- Syslog ---------------------------------------------------------

    Syslog Settings               Severity Mapping
    --------------------------------------------------------------------
    Syslog  : Enabled             Severe : DEBUG          Info: DEBUG
    Facility: LOCAL7              Warning: DEBUG          None: DEBUG

    #  Syslog Server Port   IP
    --------------------------------------------------------------------
    1  514                192.168.15.251
    2  514                0.0.0.0
    3  514                0.0.0.0
    4  514                0.0.0.0

     1- Settings
     2- Server 1
     3- Server 2
     4- Server 3
     5- Server 4
     6- Severity Mapping

     <ESC>- Back, <ENTER>- Refresh, <CTRL-L>- Event Log
> 1

39. ArcSight Common Event Format (CEF)

NXLog can be configured to collect or forward logs in Common Event Format (CEF). NXLog Enterprise Edition provides the xm_cef module for parsing and generating CEF.

CEF is a text-based log format developed by ArcSight™ and used by HP ArcSight™ products. It uses Syslog as transport. The full format includes a Syslog header or "prefix", a CEF "header", and a CEF "extension". The extension contains a list of key-value pairs. Standard key names are provided, and user-defined extensions can be used for additional key names. In some cases, CEF is used with the Syslog header omitted.

CEF Syntax
Jan 11 10:25:39 host CEF:Version|Device Vendor|Device Product|Device Version|Device Event Class ID|Name|Severity|[Extension]
Log Sample
Oct 12 04:16:11 localhost CEF:0|nxlog.org|nxlog|2.7.1243|Executable Code was Detected|Advanced exploit detected|100|src=192.168.255.110 spt=46117 dst=172.25.212.204 dpt=80

For more information, see HPE Security’s Implementing ArcSight Common Event Format guide.

39.1. Collecting and Parsing CEF

NXLog Enterprise Edition can be configured to collect and parse CEF logs with the xm_cef module.

The ArcSight™ Logger can be configured to send CEF logs via TCP with the following steps.

  1. Log in to the Logger control panel.

  2. Browse to Configuration  Data  Forwarders.

  3. Click Add to create a new Forwarder:

    • Name: nxlog

    • Type: TCP Forwarder

    • Type of Filter: Unified Query

  4. Click Next to proceed to editing the new Forwarder:

    • Query: (define as required)

    • IP/Host: (enter the IP address or hostname of the system running NXLog)

    • Port: 1514

  5. Click Save.

Example 175. Receiving CEF Logs

With this configuration, NXLog will collect CEF logs via TCP, convert to plain JSON format, and save to file.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
<Extension _cef>
    Module  xm_cef
</Extension>

<Extension _json>
    Module  xm_json
</Extension>

<Extension _syslog>
    Module  xm_syslog
</Extension>

<Input logger_tcp>
    Module  im_tcp
    Host    0.0.0.0
    Port    1514
    Exec    parse_syslog(); parse_cef($Message);
</Input>

<Output json_file>
    Module  om_file
    File    '/var/log/json'
    Exec    to_json();
</Output>

<Route r>
    Path    logger_tcp => json_file
</Route>

39.2. Generating and Forwarding CEF

NXLog Enterprise Edition can be configured to generate and forward CEF logs with the xm_cef module.

The ArcSight™ Logger can be configured to receive CEF logs via TCP with the following steps.

  1. Log in to the Logger control panel.

  2. Browse to Configuration  Data  Receivers in the navigation menu.

  3. Click Add to create a new Receiver:

    • Name: nxlog

    • Type: CEF TCP Receiver

  4. Click Next to proceed to editing the new Receiver:

    • Port: 574

    • Encoding: UTF-8

    • Source Type: CEF

  5. Click Save.

Example 176. Sending CEF Logs

With this configuration, NXLog will read Syslog logs from file, convert them to CEF, and forward them to the ArcSight Logger via TCP. Default values will be used for the CEF header unless corresponding fields are defined in the event record (see the to_cef() procedure in the Reference Manual for a list of fields).

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
<Extension _cef>
    Module  xm_cef
</Extension>

<Extension _syslog>
    Module  xm_syslog
</Extension>

<Input messages_file>
    Module  im_file
    File    '/var/log/messages'
    Exec    parse_syslog();
</Input>

<Output logger_tcp>
    Module  om_tcp
    Host    192.168.1.1
    Port    574
    Exec    $Message = to_cef(); to_syslog_bsd();
</Output>

<Route r>
    Path    messages_file => logger_tcp
</Route>

39.3. Using xm_csv and xm_kvp

Because NXLog Community Edition does not include the xm_cef module, the xm_csv and xm_kvp modules may be used instead to handle CEF logs.

Warning
The xm_csv and xm_kvp modules may not always correctly parse or generate CEF logs.
Example 177. Using CEF with NXLog Community Edition

Here, the xm_csv module is used to parse the pipe-delimited CEF header, while the xm_kvp module is used to parse the space-delimited key-value pairs in the CEF extension. The required extension configurations are shown below.

nxlog.conf Extensions [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<Extension cef_header>
    Module          xm_csv
    Fields          $Version, $Device_Vendor, $Device_Product, $Device_Version, \
                    $Signature_ID, $Name, $Severity, $_Extension
    Delimiter       |
    QuoteMethod     None
</Extension>

<Extension cef_extension>
    Module          xm_kvp
    KVDelimiter     '='
    KVPDelimiter    ' '
    QuoteMethod     None
</Extension>

<Extension syslog>
    Module          xm_syslog
</Extension>

For CEF input, use an input instance like this one.

nxlog.conf Input [Download file]
1
2
3
4
5
6
7
8
9
10
<Input in>
    Module  im_tcp
    Host    0.0.0.0
    Port    1514
    <Exec>
        parse_syslog();
        cef_header->parse_csv($Message);
        cef_extension->parse_kvp($_Extension);
    </Exec>
</Input>

For CEF output, use an output instance like this one.

nxlog.conf Output [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<Output out>
    Module  om_tcp
    Host    192.168.1.1
    Port    574
    <Exec>
        $_Extension = cef_extension->to_kvp();
        $Version = 'CEF:0';
        $Device_Vendor = 'NXLog';
        $Device_Product = 'NXLog';
        $Device_Version = '';
        $Signature_ID = '0';
        $Name = '-';
        $Severity = '';
        $Message = cef_header->to_csv();
        to_syslog_bsd();
    </Exec>
</Output>

40. AWS CloudWatch

AWS CloudWatch is a set of cloud monitoring services. The Amazon CloudWatch Logs service can be used to collect log data from Elastic Compute Cloud (EC2), CloudTrail, Route 53, and other sources. NXLog is able to retrieve CloudWatch Logs log streams, by either pulling the data via API or listening for a push from Lambda.

See the CloudWatch documentation for more information about configuring and using AWS CloudWatch Logs.

40.1. Pulling via API

NXLog can be configured to poll for logs via the API. This setup is suitable when a short delay in log collection is acceptable. To configure NXLog to perform a periodical pull of logs from the cloud, please follow the steps below.

  1. First of all, a service account to access the logs must be created. In the AWS web interface, go to Services  IAM.

  2. Click the Users option in the left-side panel.

  3. Click the Add user button.

  4. Provide a User name, for example nxlog. Tick the checkbox to allow Programmatic access to this account.

    AWS user configuration, screen 1
  5. Choose to Attach existing policies directly and select the CloudWatchLogsReadOnly policy. Click Next: Review.

    AWS user configuration, screen 2
  6. Click the Create user button.

  7. Save access keys for this user and Close.

Example 178. Using a Python Script for CloudWatch API Input

In this example, the im_python module is used to pull the logs from Amazon cloud. A similar script could be written in Perl or Ruby.

nxlog.conf [Download file]
1
2
3
4
5
6
define PYDIR /opt/nxlog/lib/nxlog/modules/input/python

<Input py>
    Module      im_python
    PythonCode  %PYDIR%/im_python.py
</Input>
Note
In order to use the script below, the AWS SDK for Python (Boto 3) must be installed first. This can be accomplished by running pip install boto3.
aws-logs.py
import nxlog, boto3, json, time

class LogReader:

    def __init__(self, time_interval):
        client = boto3.client('logs', region_name='eu-central-1')

        self.lines = ""
        all_streams = []
        group_name = '<ENTER GROUP NAME HERE>'

        #query CloudWatch for all log streams in the group
        stream_batch = client.describe_log_streams(logGroupName=group_name)
        all_streams += stream_batch['logStreams']
        start_time = int(time.time()-time_interval)*1000
        end_time = int(time.time())*1000

        while 'nextToken' in stream_batch:
            stream_batch = client.describe_log_streams(
                logGroupName=group_name, nextToken=stream_batch['nextToken'])
            all_streams += stream_batch['logStreams']
            nxlog.log_debug(str(len(all_streams)))

        #get log data from all available streams
        for stream in all_streams:
            #get first log batch (up to 10,000 log events)
            logs_batch = client.get_log_events(logGroupName=group_name,
                                               logStreamName=stream['logStreamName'],
                                               startTime=start_time,
                                               endTime=end_time)
            #write events from the first batch in JSON format
            self.json_dump(logs_batch, group_name, stream['logStreamName'])

            #get next log batches till all the data is collected
            while 'nextToken' in logs_batch:
                logs_batch = client.get_log_events(
                    logGroupName=group_name, logStreamName=stream['logStreamName'],
                    startTime=start_time, endTime=end_time,
                    nextToken=logs_batch['nextToken'])
                self.json_dump(logs_batch, group_name, stream['logStreamName'])
        nxlog.log_debug('Pulling logs: ' + gettime(start_time) + ' -  ' +
                        gettime(end_time) +  '\n')

    def json_dump(self, cloudwatch_logs, group_name, stream_name):
        for event in cloudwatch_logs['events']:
            event.update({'group': group_name, 'stream': stream_name })
            self.lines += json.dumps(event) + '\n'

    def getlogs(self):
        if not self.lines:
            return None
        return self.lines

def gettime(time_miliseconds):
    return time.strftime('%Y-%m-%d %H:%M:%S',
                         time.localtime(time_miliseconds/1000))

def read_data(module):
    # log pull time interval in seconds
    time_interval = 300

    module['reader'] = LogReader(time_interval)
    reader = module['reader']
    logdata = module.logdata_new()
    line = reader.getlogs()

    if line:
        logdata.set_field('raw_event', line)
        logdata.post()
        nxlog.log_debug("Data posted")

    module.set_read_timer(time_interval)

nxlog.log_info("INIT SCRIPT")

40.2. Pushing Log Data With Lambda

Using a push model follows an event-driven computing approach and allows for low latency. In this scenario, the AWS Lambda function sends log data in JSON format with the HTTP POST method. NXLog is used as a collector for these requests.

  1. In the AWS web interface, go to Services  Lambda.

  2. Click the Create function button.

  3. Click the Author from scratch button.

  4. Provide the name for your function and choose to create a new role from template. Enter a name for the role associated with Lambda function. Then click the Create function button.

    AWS user configuration, screen 3
  5. Select the Python runtime and choose to Upload a .ZIP file. Upload an archive with the code (and optionally with certificates, if needed). Change the Handler name to the file_name.function_name format (for example lambda_function.lambda_handler). Click Save.

    AWS user configuration, screen 4
  6. From the Configuration tab, change to the Triggers tab. Click + Add trigger.

  7. Choose CloudWatch Logs as a trigger for the Lambda function. Select the log group that should be forwarded and provide a Filter Name. Then click Submit.

    AWS user configuration, screen 5
Example 179. Lambda Collection via HTTPS Input

In this example, the im_http module is used to receive the logs from Amazon cloud. The Lambda function and associated PEM certificates should be uploaded to the cloud in a zip archive, via the AWS management console.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
<Input http>
    Module              im_http
    ListenAddr          127.0.0.1
    Port                8080
    HTTPSCertFile       %CERTDIR%/server-cert.pem
    HTTPSCertKeyFile    %CERTDIR%/server-key.pem
    HTTPSCAFile         %CERTDIR%/ca.pem
    HTTPSRequireCert    TRUE
    HTTPSAllowUntrusted FALSE
</Input>
lambda_function.py
import json, base64, zlib, ssl, http.client

print('Loading function')

def lambda_handler(event, context):
    compressed_logdata = base64.b64decode(event['awslogs']['data'])
    logdata = zlib.decompress(compressed_logdata, 16+ zlib.MAX_WBITS)
    context = ssl.SSLContext(ssl.PROTOCOL_TLSv1_2)
    context.load_verify_locations("ca.pem")
    context.load_cert_chain("client.pem")

    conn = http.client.HTTPSConnection("<HOST>:<PORT>", context=context)
    conn.set_debuglevel(3)

    headers = {"Content-type": "application/json"}

    conn.request('POST', "", logdata, headers)
    conn.close()
Note
Please refer to Python’s ssl module documentation for more details regarding the SSLContext.load_cert_chain(certfile, keyfile=None, password=None) function.

41. Azure Operations Management Suite

The Azure Operations Management Suite (OMS) is a set of Microsoft cloud services providing log management, backup, automation, and high availability features. Azure Log Analytics is the part of OMS used for log collection, correlation, and analysis.

See the Azure OMS and Log Analytics documentation for more information about configuring and using Azure OMS and its log management service.

41.1. Forwarding Data to Log Analytics

In order to configure NXLog to forward log data to the Log Analytics service, complete the following steps.

  1. Log in to the Azure portal and go to the Log Analytics service (for instance by typing the service name into the search bar).

  2. Select an existing OMS Workspace or create a new one by clicking the + Add button.

  3. From the Management section in the main workspace screen, click OMS Portal.

    Shipping data to Log Analytics, screen 1
  4. In the Microsoft Operations Management Suite click the settings icon in the top right corner, navigate to Settings  Connected Sources  Linux Servers, and copy the WORKSPACE ID and PRIMARY KEY. Save them to a text file; they are needed for API access.

    Shipping data to Log Analytics, screen 2
  5. Enable Custom Logs. As of this writing it is a preview feature, available under Settings  Preview Features  Custom Logs.

    Shipping data to Log Analytics, screen 3
Example 180. Forwarding to Azure Log Analytics With a Python Script

The om_exec module can be used in conjunction with a Python script to forward log data to the Log Analytics service.

Note
NXLog must have permission to execute the script.
nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
define PYCODEDIR /opt/nxlog/lib/nxlog/modules/output/python

<Extension _json>
    Module  xm_json
</Extension>

<Output oms>
    Module  om_exec
    Command %PYCODEDIR%/oms-pipe.py
    Exec    to_json();
</Output>

The following Python code implements the OMS API and performs the REST API call.

oms-pipe.py
import requests
import datetime
import hashlib
import hmac
import base64
import fileinput

# Update the customer ID to your Operations Management Suite workspace ID
customer_id = '<cid>'

# For the shared key, use either the primary or the secondary Connected Sources client authentication key
shared_key = "<skey>"

# The log type is the name of the event that is being submitted
log_type = 'STDIN_PY'


# Build the API signature
def build_signature(customer_id, shared_key, date, content_length, method, content_type, resource):
    x_headers = 'x-ms-date:' + date
    string_to_hash = method + "\n" + str(content_length) + "\n" + content_type + "\n" + x_headers + "\n" + resource
    bytes_to_hash = bytes(string_to_hash).encode('utf-8')
    decoded_key = base64.b64decode(shared_key)
    encoded_hash = base64.b64encode(hmac.new(decoded_key, bytes_to_hash, digestmod=hashlib.sha256).digest())
    authorization = "SharedKey {}:{}".format(customer_id,encoded_hash)
    return authorization

# Build and send a request to the POST API
def post_data(customer_id, shared_key, body, log_type):
    method = 'POST'
    content_type = 'application/json'
    resource = '/api/logs'
    rfc1123date = datetime.datetime.utcnow().strftime('%a, %d %b %Y %H:%M:%S GMT')
    content_length = len(body)
    signature = build_signature(customer_id, shared_key, rfc1123date, content_length, method, content_type, resource)
    uri = 'https://' + customer_id + '.ods.opinsights.azure.com' + resource + '?api-version=2016-04-01'

    headers = {
            'content-type': content_type,
            'Authorization': signature,
            'Log-Type': log_type,
            'x-ms-date': rfc1123date
            }

    response = requests.post(uri,data=body, headers=headers)
    if (response.status_code >= 200 and response.status_code <= 299):
        print 'Accepted'
    else:
        print "Response code: {}".format(response.status_code)


for body in fileinput.input():
    post_data(customer_id, shared_key, body, log_type)

41.2. Downloading Data From Log Analytics

NXLog can be used to download data from Log Analytics service. This can be achieved by using the OMS API, for example with a Python script. Enable the API by following these steps.

  1. Register an application in Azure Active Directory.

  2. Generate an access key for this application.

  3. Under your Subscription, go to Access control (IAM) and assign the Log Analytics Reader role to this application.

Detailed instructions on this topic can be found in the Azure documentation.

Example 181. Collecting Logs From Azure Log Analytics With a Python Script

The im_python module can be used in conjunction with a Python script to periodically collect log data from the Log Analytics service.

nxlog.conf [Download file]
1
2
3
4
5
6
define PYDIR /opt/nxlog/lib/nxlog/modules/input/python

<Input oms>
    Module      im_python
    PythonCode  %PYDIR%/oms-download.py
</Input>

The following Python code implements the OMS API and performs the REST API call. In order to authenticate, the Subscription ID, Tenant ID, Application ID, and Application Key are required.

Note
The Tenant ID can be found as "Directory ID" under the Azure Active Directory Properties tab.
oms-download.py
import datetime
import json
import requests

import adal
import nxlog

class LogReader:

    def __init__(self, time_interval):
        # Details of workspace.  Fill in details for your workspace.
        resource_group = '<YOUR_RESOURCE_GROUP>'
        workspace = '<YOUR_WORKSPACE>'

        # Details of query.  Modify these to your requirements.
        query = "Type=*"
        end_time = datetime.datetime.utcnow()
        start_time = end_time - datetime.timedelta(seconds=time_interval)
        num_results = 100000  # If not provided, a default of 10 results will be used.

        # IDs for authentication.  Fill in values for your service principal.
        subscription_id = 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
        tenant_id = 'xxxxxxxx-xxxx-xxxx-xxx-xxxxxxxxxxxx'
        application_id = 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx'
        application_key = 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'

        # URLs for authentication
        authentication_endpoint = 'https://login.microsoftonline.com/'
        resource  = 'https://management.core.windows.net/'

        # Get access token
        context = adal.AuthenticationContext('https://login.microsoftonline.com/' + tenant_id)
        token_response = context.acquire_token_with_client_credentials('https://management.core.windows.net/', application_id, application_key)
        access_token = token_response.get('accessToken')

        # Add token to header
        headers = {
            "Authorization": 'Bearer ' + access_token,
            "Content-Type":'application/json'
        }

        # URLs for retrieving data
        uri_base = 'https://management.azure.com'
        uri_api = 'api-version=2015-11-01-preview'
        uri_subscription = 'https://management.azure.com/subscriptions/' + subscription_id
        uri_resourcegroup = uri_subscription + '/resourcegroups/'+ resource_group
        uri_workspace = uri_resourcegroup + '/providers/Microsoft.OperationalInsights/workspaces/' + workspace
        uri_search = uri_workspace + '/search'

        #store log data for NXLog here
        self.lines = ""

        # Build search parameters from query details
        search_params = {
                "query": query,
                "top": num_results,
                "start": start_time.strftime('%Y-%m-%dT%H:%M:%S'),
                "end": end_time.strftime('%Y-%m-%dT%H:%M:%S')
                }

        # Build URL and send post request
        uri = uri_search + '?' + uri_api
        response = requests.post(uri,json=search_params,headers=headers)

        # Response of 200 if successful
        if response.status_code == 200:

            # Parse the response to get the ID and status
            data = response.json()
            search_id = data["id"].split("/")
            id = search_id[len(search_id)-1]
            status = data["__metadata"]["Status"]

            # If status is pending, then keep checking until complete
            while status == "Pending":

                # Build URL to get search from ID and send request
                uri_search = uri_search + '/' + id
                uri = uri_search + '?' + uri_api
                response = requests.get(uri,headers=headers)

                # Parse the response to get the status
                data = response.json()
                status = data["__metadata"]["Status"]
        else:

        # Request failed
            print (response.status_code)
            response.raise_for_status()

        print ("Total records:" + str(data["__metadata"]["total"]))
        print ("Returned top:" + str(data["__metadata"]["top"]))

    #write a JSON dump of all events
        for event in data['value']:
            self.lines += json.dumps(event) + '\n'

    def getlogs(self):
        if not self.lines:
            return None
        return self.lines

def read_data(module):
    # log pull time interval in seconds
    time_interval = 300

    module['reader'] = LogReader(time_interval)
    reader = module['reader']
    logdata = module.logdata_new()
    line = reader.getlogs()

    if line:
        logdata.set_field('raw_event', line)
        logdata.post()
        nxlog.log_debug("Data posted")

    module.set_read_timer(time_interval)

nxlog.log_info("INIT SCRIPT")

42. Azure SQL Auditing

The Azure SQL is a relational database service that shares its code base with the Microsoft SQL Server database engine and provides the dynamic scalability of the cloud. NXLog can be used as a collector for audit data from an Azure SQL instance.

To start with, auditing for an instance must be enabled; see Get started with SQL database auditing in the Azure documentation for detailed steps. Once this step is done, NXLog can be configured to periodically download the audit logs. Python or Powershell can be used for this purpose. There is also a sync application for Azure OMS which replicates the audit logs into the Azure OMS Log Analytics service. See Azure Operations Management Suite for detailed instructions about integrating NXLog with OMS Log Analytics.

See the Azure SQL Database documentation in the Azure documentation for more information about the database service.

42.1. Using a PowerShell Script

The im_exec module can be used along with a PowerShell script to download Azure SQL audit logs. The script logs in to the Azure account and downloads the latest audit file from the blob storage container. Then it reads the file from disk and prints the events for the latest time period (default is one hour). Finally, the program waits until the next execution.

The script requires Microsoft.SqlServer.XE.Core.dll and Microsoft.SqlServer.XEvent.Linq.dll to run. These libraries are distributed with Microsoft SQL Server installations (including XE edition). Azure PowerShell needs to be installed as well; this can be done by executing Install-Module AzureRM -AllowClobber in PowerShell. For detailed documentation about installing Azure PowerShell, see Install and configure Azure PowerShell in the Azure documentation.

Note
The procedure for non-interactive Azure authentication might vary, depending on the account type. This example assumes that a service principal to access resources has been created. For detailed information about creating an identity for unattended script execution, see Use Azure PowerShell to create a service principal with a certificate in the Azure documentation. Alternatively, Save-AzureRmContext can be used to store account information in a JSON file and loaded later with Import-AzureRmContext.
Example 182. Collecting Azure SQL Audit Logs With PowerShell

This configuration uses im_exec to run a PowerShell script.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
<Extension _json>
    Module  xm_json
</Extension>