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 chapters included in this Guide provide detailed information about NXLog, including features, architecture, configuration, and integration with other software and devices. The 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 these two NXLog editions, see the About NXLog and Available modules chapters.

This Guide was last updated on 16 September 2021 at 08:51:35 UTC.

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 5.4.7313. 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 Event Log, 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 entire 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 Event Log, 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. NXLog 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 which are crucial in a professional environment. The Enterprise Edition provides the following enhancements.

Additional platform support

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

Signed installer packages

Installer packages are digitally signed to ensure that the binaries are not corrupted or compromised. In many cases, this is a compliance mandate.

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.

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 and Linux too.

Remote management

The dedicated xm_admin extension module enables NXLog agents to be managed remotely over a secure SOAP/JSON SSL connection or to be integrated with existing monitoring and management tools. The configurations, correlation rules, patterns, and certificates can all be updated remotely from the NXLog Manager web interface or from scripts. In addition, the NXLog agents 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/HTTPS support

The im_http and om_http input and output modules make it possible to send or receive log message data over HTTP or HTTPS.

TCP and UDP support

Accepting and initiating TCP and UDP connections to a remote server can be achieved using the dedicated protocol-specific im_tcp and om_tcp modules, as well as the im_udp and om_udp modules respectively.

UDP source IP address spoofing

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

File integrity 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.

Registry monitoring

The im_regmon module facilitates the monitoring of the Windows Registry and generates event records in case of changes in the monitored registry entries.

Network monitoring

The passive monitoring of network traffic can be implemented via utilizing the im_pcap module.

XML support

The xm_xml extension module can parse nested XML and data stored in XML attributes.

JSON support

Parsing of nested JSON is implemented in the xm_json module. UTF-8 character encoding validation can be enforced to avoid parser failures caused by invalid UTF-8 encoding from other tools.

Support of key-value pairs

Parsing and generation of key-value formatted data can be accomplished by using the xm_kvp module.

Parsing with patterns
  • The xm_grok module can parse data using Grok patterns.

  • The database of patterns in XML format can be applied using the xm_pattern module.

Parsing multi-line logs

Messages which span multiple lines can be processed with the xm_multiline module. The flexible configuration of the module is reached through the specification of the header line, the footer line, and the number of lines in a message.

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 data processing. 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 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 or an IP address for example. The files are cached in memory and any changes are automatically picked up without the need to reload NXLog.

Custom input, output, and extension modules

The Enterprise Edition of NXLog supports custom modules which can be developed in the following programming languages:

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.

Check Point LEA input

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

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 and pull data to and 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 Event Log using Windows Event Forwarding. While NXLog Enterprise Edition can collect Windows Event Log remotely over WMI and MSRPC, this module provides improved security for collecting from Windows machines in agentless 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 Event Log files directly

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

Additional Windows Event Log 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 Windows Event Log record can be resolved to account names to produce the same output that Windows Event Viewer gives.

Event Tracing for Windows

The im_etw module provides direct reading of event tracing data of both kernel and user-mode applications.

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.

Named pipes and domain sockets

The Enterprise Edition supports communicating logs via:

Testing facilities

Simple test events can be generated using the im_testgen module according to the specified counter. The im_null and om_null module can be used for testing purposes as well.

The om_blocker module can be used for blocking messages to simulate a blocked route.

Mark messages

Via the im_mark module, NXLog can send mark messages confirming its correct operation.

Data transformation

NXLog Enterprise Edition supports conversion of message strings between various character sets. This may be useful when the encoding of accepted messages differs from UTF-8.
Compression and encryption operations with logs are available via the xm_zlib and xm_crypto modules.

Manipulation with files

NXLog Enterprise Edition provides retention and rotation policies which can be applied to files, such as log retention based on the file size and age, and cyclic rotation and retention of files. All these features are available via the xm_fileop module.

Execution of external scripts

External scripts can be run on startup at the input, output, and extension levels using the im_exec, om_exec, and xm_exec modules respectively.

Support of various log sources

NXLog Enterprise Edition supports a wider variety of log sources and provides additional functionalities to the modules which exist in both the Enterprise and Community versions of NXLog.

Buffering of messages

Using the pm_buffer prevents from losing messages which arrive over UDP.

Regular hot fixes

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

World class support

For NXLog Enterprise Edition, a dedicated professionally trained support team is available and ready to act at request. They can be available 24/7 with a world-class, 4-hour SLA.

Extensive documentation

Our constantly updated, ever-growing documentation, already well above 1500 pages, is a stand-alone product in itself. It is complete with configuration samples, real-world examples, and integration guides offering much more than a generic manual.

2.3. Comparison of features

This section compares the features of the NXLog Community Edition and the NXLog Enterprise Edition as well as highlights the differences between them.

There are three possible scenarios in how the features overlap and differentiate between the two editions:

  • The feature is present only in NXLog Enterprise Edition.

  • The feature is present in both editions of NXLog with the exact same functionality.

  • The feature is present in both editions of NXLog, but NXLog Enterprise Edition provides additional or enhanced functionality. In such cases, a link to a more detailed description of these differences is provided in the first column of the matrix table.

For easier interpretation, all NXLog features are grouped into the following logical subsections:

An NXLog Community Edition installation can be upgraded to NXLog Enterprise Edition. See the Deployment guide for your platform for more information.

2.3.1. Supported formats

One of the most important aspects of logs is the format. It is crucial for log files that need to be read by other applications. Above all, it is best if logs are stored as structured data, rather than unstructured text. The format affects availability, readability, manageability, and size.

This subsection compares the data formats NXLog supports. In addition to these formats, NXLog can read and process log data using pattern matching to transform unstructured data into normalized, structured data.

Table 1. Supported formats and patterns
Format and Pattern Name NXLog Community Edition NXLog Enterprise Edition Feature advantage

The existing log formats

AIX Audit Format (xm_aixaudit)

20

20

In combination with the im_file module, this module can collect and parse AIX Audit events.

Apple System Log (xm_asl)

20

20

Apple system logs stored as ASL files and can be read and parsed using this module.

Solaris OS Basic Security Module (BSM) Auditing API (im_bsm, xm_bsm)

20

20

Reads and processes BSM audit events either from file (xm_bsm) or directly from the kernel (im_bsm).

ArcSight Common Event Format (xm_cef)

20

20

Using this feature, the ArcSight CEF-formatted events can be both generated and read.

CSV (xm_csv)

20

20

Generation and parsing of delimiter-separated data is an essential feature of the xm_csv module.

Graylog Extended Log Format (xm_gelf)

20

20

This module enables receiving data in GELF format over the network as well as formatting data to GELF while forwarding it over the network.

JSON (xm_json)

20

20

Converts raw events to JSON format as well as parses events from received JSON logs.

Key-Value Pairs (xm_kvp)

20

20

Convenient method for distilling data formatted as key-value pairs (KVPs).

Log Event Extended Format (xm_leef)

20

20

Generates and reads the Log Event Extended Format (LEEF) commonly used by IBM Security QRadar products.

DNS Server Logs (xm_msdns)

20

20

Reads Windows DNS Server logs and parses over 20 fields commonly used with these events.

Multiline Log Messages (xm_multiline)

20

20

A complete solution for processing multiline log events. Supports any combination of header lines, footer lines, and fixed line counts.

NetFlow Payload (xm_netflow)

20

20

In combination with the im_udp module, this feature provides convenient parsing of Netflow protocol versions v1, v5, v7, v9, and IPFIX.

Radius NPS (xm_nps)

20

20

Allows for parsing file-based data in NPS Database format across all implementations, i.e. both IAS and NPS formatted data.

SNMP Trap Messages (xm_snmp)

20

20

Provides capabilities for reading SNMP v1, v2c, and v3 trap messages.

Syslog (xm_syslog)

20

20

Support for reading and writing all Syslog formats: BSD, IETF, and Snare.

W3C Extended Log File Format (xm_w3c)

20

20

Supports parsing of data in the W3C Extended Log File Format, Zeek format, and Microsoft Exchange Message Tracking logs.

Binary WTMP Files (xm_wtmp)

20

20

Enables processing of binary wtmp files when used in conjunction with the im_file module.

XML (xm_xml)

21

21

Enables parsing and writing XML-formatted data.

Parsing with patterns

Parsing with Grok Patterns (xm_grok)

20

20

Functionality for reading any kind of text log messages using Grok patterns.

Parsing with the Pattern Database (xm_pattern)

20

20

Efficient, non-linear pattern matching using a pattern database in XML format. Each pattern definition can contain multiple field definitions thus allowing multi-dimensional pattern matching.

The following features are available in both editions of NXLog, but NXLog Enterprise Edition provides additional or enhanced functionality.

2.3.1.1. CSV

Although both versions of NXLog support processing CSV data, only NXLog Enterprise Edition provides Field Count Enforcement with its StrictMode directive that accepts a boolean value. When set to TRUE, the parser will ignore any CSV line not having the same number of fields as those listed in the Fields directive.

2.3.1.2. Graylog Extended Log Format (GELF)

NXLog Enterprise Edition enables these additional options for processing data in the Graylog Extended Log Format:

TCP input

When set to GELF_TCP and used in conjunction with the im_tcp input module, the InputType directive allows GELF data to be received over TCP.

Hidden fields

The IncludeHiddenFields directive, with a default boolean value of TRUE, supports inclusion of fields with names having a leading dot (.) or underscore (_) which would otherwise be discarded.

Event enrichment

GELF events are enriched with some additional fields: $EventTime, $FullMessage, $Hostname, $SeverityValue, $ShortMessage, $SourceLine, $SyslogFacility, and $version.

2.3.1.3. JSON

The xm_json module of NXLog Enterprise Edition has several directives for customizing how JSON data is parsed and prepared for output:

Custom datetime formats

The xm_json DateFormat overrides the global DateFormat.

Nested structure detection

By default, DetectNestedJSON is set to TRUE and preserves nested structures. FALSE will turn detection off and convert any values containing a JSON key-value pair to a flat string, e.g. {"key":{"subkey":42}} would be converted to {"key":"{\"subkey\":42}"}.

Flatten nested structures

The Flatten directive takes nested JSON fields and creates field names with dot notation to flatten the structure. For example, the following JSON structure:

{"event":{"time":"2015-01-01T00:00:00.000Z","severity":"ERROR"}}

will be converted to

{"event.time":"2015-01-01T00:00:00.000Z","event.severity":"ERROR"}
ForceUTF8

Converts the output to validated UTF-8 encoding regardless of the input encoding.

IncludeHiddenFields

Preserves hidden fields, i.e. those having names with a leading dot (.) or underscore (_).

ParseDate

Enables automatic parsing of strings beginning with a 4-digit year as timestamps.

PrettyPrint

Takes single-line JSON records, puts each key-value pair on a new line, and indents elements based on the depth of nesting for creating a more human-readable data record.

UnFlatten

Is the inverse of the Flatten process when using to_json() to recreate nested structures on output.

2.3.1.4. Multiline log messages

The xm_multiline module of NXLog Enterprise Edition supports the AutoFlush directive to automatically flush its read buffer once the PollInterval time has elapsed. This enables a more timely processing of the last event while it waits for new events to be read.

2.3.1.5. Syslog

NXLog Enterprise Edition can improve readability of Syslog data by replacing line breaks inside messages with other characters using the ReplaceLineBreaks directive. This option can be used with the to_syslog_bsd(), to_syslog_ietf(), and to_syslog_snare() procedures. The to_syslog_ietf() procedure’s local time information can be replaced with UTC/GMT timestamps using the UTCTimestamp directive.

2.3.1.6. XML

NXLog Enterprise Edition additionally provides features for working with XML, such as:

IgnoreRootTag

Results in fields being "flattened" by not having the XML root tag Event prefixed to them with dot notation. For example, $Event.timestamp will be simply $timestamp.

IncludeHiddenFields

Preserves hidden fields, i.e. those having names with a leading dot (.) or underscore (_).

ParseAttributes

Provides the ability to parse an XML field’s attributes in addition to its value. Given this XML sample

<Msg time='2014-06-27T00:27:38' type='ERROR'>foo</Msg>

will be parsed as $Msg.time, $Msg.type, and $Msg fields. Otherwise, only $Msg with its string value foo would be added to event record.

PrefixWinEvent

In the context of XML-formatted Windows events, this is the inverse process of IgnoreRootTag, in which events gleaned from parse_windows_eventlog_xml() will have their fields prefixed with either EventData or UserData using dot notation depending on which XML section they belong to.

2.3.2. Programming languages support

Supporting programming languages means that events can be read, processed, and forwarded using methods and procedures written in any of the supported languages. Being able to choose from a list of popular programming languages for developing custom modules offers a great deal of flexibility.

NXLog Enterprise Edition supports programming languages via the following types of modules:

  • Input modules to replace the existing NXLog input modules

  • Extension modules to process data coming from the input modules

  • Output modules to replace the existing NXLog output modules

The table below lists supported programming languages.

Table 2. Support for programming languages
Supported Language NXLog Community Edition NXLog Enterprise Edition Feature Advantage

Go (im_go, om_go, xm_go)

20

20

Enables developing log processing modules using the Go or Golang programming language

Java (im_java, om_java, xm_java)

20

20

Facilitates developing custom Java applications that can easily integrate with the NXLog infrastructure

Perl (im_perl, om_perl, xm_perl)

20

20

Perl, with its native regular expression capabilities, allows rapid development of terse scripts for high performance, complex parsing of logs.

Python (im_python, om_python, xm_python)

20

20

Python scripts can be developed to customize how logs are read, processed, and output.

Ruby (im_ruby, om_ruby, xm_ruby)

20

20

Ruby, with its native support for structured data formats like XML and JSON, can be used to develop applications for custom log processing.

The following feature is available in both editions of NXLog, but NXLog Enterprise Edition provides additional or enhanced functionality.

2.3.2.1. Perl

NXLog Community Edition only supports the Perl extension module, whereas NXLog Enterprise Edition allows Perl scripts to be loaded and executed as input and output modules as well.

In addition, NXLog Enterprise Edition can also parse configuration parameters of Perl scripts using the Config directive.

2.3.3. Data transformation

The ability to transform captured log data is an essential feature of any log collection strategy.

The following table shows the features that can be used to transform data according to each edition of NXLog.

Table 3. Support for data transformation
Supported Feature NXLog Community Edition NXLog Enterprise Edition Feature Advantage

Converting via Character Sets (xm_charconv)

20

20

Log data can be converted between character sets (codepages) prior to parsing.

Blacklisting and Whitelisting of Log Entries (xm_filelist)

20

20

Based on the contents of each file, files can be whitelisted or blacklisted using this feature.

File Operations (xm_fileop)

20

20

Provides convenient methods for implementing log rotation and retention policies for the specified log files.

Manipulating Fields (xm_rewrite)

20

20

Enables renaming and dropping of specific fields, as well as the enrichment of events with new fields defined in Exec statements.

Encryption and Decryption of Logs (xm_crypto)

20

20

Enables log files to be encrypted and decrypted using AES symmetric encryption for secure storage and/or transport over a network.

Compression and Decompression of Logs (xm_zlib)

20

20

Allows compressing log files using either gzip or zlib prior to transport.

Resolving IP addresses to Hostnames (xm_resolver)

20

20

When log data needs to be human readable, enriching log events with the hostnames, user names, and groups names is preferable to IP addresses, user IDs, and group IDs.

The following features are available in both editions of NXLog, but NXLog Enterprise Edition provides additional or enhanced functionality.

2.3.3.1. Converting via character sets

The following optional directives are only available with NXLog Enterprise Edition:

2.3.3.2. File operations

NXLog Enterprise Edition has a file_hash() function to return the calculated hash of the specified file.

2.3.4. Administration and monitoring

NXLog provides several administration and monitoring features, such as remote administration of agents as well as monitoring network traffic and file systems.

Table 4. Administration and monitoring support
Supported Feature NXLog Community Edition NXLog Enterprise Edition Feature Advantage

Secure Remote Administration (xm_admin)

20

20

Enables secure remote administration for NXLog agents and various monitoring tools using JSON or SOAP over HTTP/HTTPS.

Execution of External Scripts (im_exec, om_exec, xm_exec)

20

20

Supports the execution of an external program or script on startup.

Changes in Files and Directories (im_fim)

20

20

This feature enables the monitoring of changes in specific files and directories for integrity monitoring.

Passive Monitoring of Network Traffic (im_pcap)

20

20

Enables NXLog to passively monitor and log network traffic for various protocols.

Windows Registry Monitoring (im_regmon)

20

20

Provides scanning of Windows registry and generates event records when changes are detected.

The following features are available in both editions of NXLog, but NXLog Enterprise Edition provides additional or enhanced functionality.

2.3.4.1. Execution of external scripts

The xm_exec module of NXLog Enterprise Edition additionally supports execution of commands as a function.

The Restart directive of NXLog Enterprise Edition can restart a process if it terminates unexpectedly.

2.3.5. Log sources

NXLog supports log collection and processing from a wide variety of log sources. Practically any operating system found in enterprise computing environments is supported, as well as their native log sources. In most cases, the native modules that ship with NXLog for collecting logs suffice without any need for any additional software. The following table lists the modules designed for specific log sources.

Table 5. Log source types supported
Source Name NXLog Community Edition NXLog Enterprise Edition Feature Advantage

Accounting Logs From a Linux or BSD Kernel (im_acct)

20

20

Enables collecting and processing logs from a Linux or BSD kernel.

AIX Audit (im_aixaudit)

20

20

Along with the xm_aixaudit module, AIX Audit logs can be read and parsed directly from the kernel.

Microsoft Azure Application Logs (im_azure)

20

20

Parses logs from Microsoft Azure applications received over various TLS and SSL protocols.

Check Point Device Logs (im_checkpoint)

20

20

Remote collection of logs from Check Point devices using the OPSEC LEA protocol.

Database Logs via the libdbi library (im_dbi, om_dbi)

20

20

Convenient method for pulling and saving data to external databases using the libdbi database abstraction library.

Kernel Application Logs Using Event Tracing for Windows (im_etw)

20

20

High-performance log collection using Event Tracing for Windows (ETW).

Internal NXLog Logs (im_internal)

21

21

Enables reading internal NXLog logs.

Elasticsearch Server (om_elasticsearch)

20

20

Enables forwarding logs to an Elasticsearch server.

Kafka Server Logs (im_kafka, om_kafka)

20

20

Enables the collecting of event records from a Kafka topic as well as publishing event records to a Kafka topic.

Logs From the Kernel Log Buffer (im_kernel)

20

20

Collects events from the kernel log buffer on Unix-like operating systems.

Windows Event Log (im_mseventlog, im_msvistalog)

20

20

Collects Windows Event Log messages using its native API.

Windows Event Collector (im_wseventing)

20

20

Using the Windows Event Forwarding infrastructure, this feature enables collecting events from Windows Event Log.

Kernel Logs via Audit Rules (im_linuxaudit)

20

20

Collects logs directly from the kernel using custom rules without the need for installing auditd or other userspace software.

Writing Logs to MySQL (om_eventdb)

20

20

Writes logs to a MySQL database using a special schema. Unix domain sockets can be utilized for faster throughput.

Database Table Logs via ODBC (im_odbc, om_odbc)

20

20

Uses ODBC for storing logs in ODBC-compliant databases.

Forwarding Logs to Raijin Server (om_raijin)

20

20

Sends batched JSON records to Raijin Server for further analysis and archival.

Redis Server Log Tranfers (im_redis, om_redis)

20

20

Enables the retrieval of data stored in a Redis server as well as populating a Redis server with log data.

Systemd Journal Logs (im_systemd)

20

20

Reads, parses, and processes events from the systemd journal.

Windows Performance Counters (im_winperfcount)

20

20

Enables the polling of various Windows Performance Counters to create event records.

The following features are available in both editions of NXLog, but NXLog Enterprise Edition provides additional or enhanced functionality.

2.3.5.1. Internal NXLog logs
LogqueueSize

Sets the number messages which are queued if delivery is delayed or blocked.

Event log enrichment

Additional fields which contain the module name and type.

2.3.5.2. Logs from the kernel log buffer

NXLog Enterprise Edition supports collecting kernel logs from various Linux, BSD, and macOS systems. However, NXLog Community Edition supports only Linux systems.

NXLog Enterprise Edition also provides the following directives:

DeviceFile

For accessing the device file to read events on non-Linux systems.

PollInterval

Sets the interval to check for new events.

2.3.5.3. Windows Event Log

The Enterprise Edition’s im_msvistalog module supports the following optional directives not found in NXLog Community Edition:

AddPrefix

Adds the EventData prefix to fields which are parsed from the EventData section of the event.

ReadBatchSize

Specifies the number of event records the Windows Event Log API will pass to NXLog for further processing.

CaptureEventXML

Enables the $EventXML field to store the raw XML-formatted event data.

File

Enables NXLog to read directly from the .evt, .evtx, or .etl log files.

Language

Sets the locale to use for rendering language/region-specific event fields such as date/time, currency, etc.

RemoteAuthMethod

Sets the authentication method.

RemoteDomain

Specifies the authentication domain of the remote server for collecting event logs.

RemotePassword

Accepts the user password of the remote server for collecting event logs.

RemoteServer

Sets the name of the remote server from which event logs will be captured.

RemoteUser

Sets the user name on the remote server for collecting event logs.

ResolveGUID

Enables GUID to resolve values of the object names in the $Message field.

ResolveSID

Enables SID to resolve values of the object names in the $Message field.

TolerateQueryErrors

Will prevent the module from starting if any source is invalid when set to FALSE (the default value).

2.3.6. Protocols

Both editions of NXLog provide support for various protocols for working with logs, see the table below.

Table 6. Supported protocols
Protocol Name NXLog Community Edition NXLog Enterprise Edition Feature Advantage

Batched Compression (im_batchcompress, om_batchcompress)

20

20

Enables sending/receiving batches of log messages that are compressed and optionally encrypted to/from a remote NXLog agent.

Files (im_file, om_file)

20

20

Facilities reading log messages from files and writing processed data to them.

WebHDFS (om_webhdfs)

20

20

Using the WebHDFS protocol, this feature can be used to store logs in Hadoop HDFS.

HTTP (im_http, om_http)

20

20

Convenient log message communication using over the HTTP protocol, both inbound and outbound.

Named Pipes (im_pipe, om_pipe)

20

20

With this feature, named pipes of Unix-like operating systems can be utilized to send and receive log messages.

TLS/SSL (im_ssl, om_ssl)

20

20

Provides TLS/SSL transportation capabilities for secure forwarding and retrieval of logs.

TCP (im_tcp, om_tcp)

20

20

Accepts TCP connections for receiving event data and can send events to remote hosts over TCP.

UDP (im_udp, om_udp)

20

20

Enables log data to be sent and received as datagrams using the UDP protocol.

UDP With Spoofing (om_udpspoof)

20

20

With spoofing enabled, UDP packets will contain the IP address of the originating client that produced the message instead of the forwarding server.

Unix Domain Sockets (im_uds, om_uds)

20

20

Enables log data to be sent or received over a Unix domain socket.

ZeroMQ (im_zmq, om_zmq)

20

20

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

The following features are available in both editions of NXLog, but NXLog Enterprise Edition provides additional or enhanced functionality.

2.3.6.1. Files

The im_file module of NXLog Enterprise Edition additionally provides the following optional directives:

Exclude

Specifies a file or a set of files to be excluded.

InputType

Sets the input reader function.

NoEscape

Specifies whether the backslash (\) in file paths should be disabled as an escape sequence.

OnEOF

A group of statements to be executed after a file has been completely read (on end-of-file).

The om_file module provides the optional CacheSize directive to keep files open and reduce the overhead caused by open/close operations.

2.3.6.2. HTTP

NXLog Community Edition provides only the output HTTP capabilities via the om_http module. NXLog Enterprise Edition supports the input and output capabilities via the im_http and om_http modules.

NXLog Enterprise Edition supports the add_http_header() procedure to dynamically add a custom HTTP header to requests.

The Enterprise Edition’s om_udp module supports multiple definitions of the Host directive which can be used to configure failover.

The URL directive of NXLog Enterprise Edition can be specified multiple times for configuring failover. Its HTTPSCADir and HTTPSCAFile directives provide additional support for self-signed certificates.

NXLog Enterprise Edition supports the following optional directives not found in NXLog Community Edition:

AddHeader

An additional header to be added to each HTTP request.

BatchMode

Toggles whether the data is sent as single event or a batch of events.

ContentType

Specifies the Content-Type HTTP header which can be used in conjunction with the BatchMode directive.

FlushInterval

Sets the period of time after which accumulated data will be sent in batch mode.

FlushLimit

The number of events to be batched together in a single POST request.

HTTPSCAThumbprint

The certificate thumbprint of the certificate authority (CA) which can be used to look up the CA certificate from the Windows certificate store.

HTTPSCertThumbprint

The certificate thumbprint to be used for the SSL handshake.

HTTPSCRLDir

The path to the certificate revocation list. This list is used for verifying the certificate of the remote HTTPS server.

HTTPSSSLCipher

Can be used to set the permitted SSL cipher list, overriding the default.

HTTPSSSLCiphersuites

Can be used to define the permitted SSL cipher list in case the HTTPSSSLProtocol directive is set to TLSv1.3.

HTTPSSSLProtocol

Can be used to set the allowed TLS/SSL protocol(s).

HTTPSSSLCompression

Enables data compression when sending over the network.

HTTPSSSLProtocol

Sets the allowed TLS/SSL protocol(s).

ProxyAddress

The IP address of the proxy server.

ProxyPort

The port number of the proxy server.

SNI

The host name for Server Name Indication (SNI) in HTTPS mode.

2.3.6.3. TLS/SSL

The im_ssl module of NXLog Enterprise Edition supports self-signed certificates and the following optional directives:

CAThumbprint

The certificate thumbprint of the certificate authority (CA) which can be used to look up the CA certificate from the Windows certificate store.

CertThumbprint

The certificate thumbprint to be used for the SSL handshake.

SSLCipher

Can be used to set the permitted SSL cipher list, overriding the default.

SSLCiphersuites

Can be used to define the permitted SSL cipher list in case the HSSLProtocol directive is set to TLSv1.3.

SSLCompression

Enables data compression when sending over the network.

SSLProtocol

Sets the allowed TLS/SSL protocol(s).

The om_ssl module of NXLog Enterprise Edition provides additional functionalities to the following directives:

Host

Can be specified multiple times to work in a failover configuration.

CADir and CAFile

Support self-signed certificates.

It also supports the following optional directives:

CAThumbprint

The certificate thumbprint of the certificate authority (CA) which can be used to look up the CA certificate from the Windows certificate store.

CertThumbprint

The certificate thumbprint to be used for the SSL handshake.

LocalPort

The local port number of the connection.

SNI

The host name for Server Name Indication (SNI).

SSLCipher

Can be used to set the permitted SSL cipher list, overriding the default.

SSLCiphersuites

Can be used to define the permitted SSL cipher list in case the SSLProtocol directive is set to TLSv1.3.

SSLCompression

Enables data compression when sending over the network.

SSLProtocol

Sets the allowed TLS/SSL protocol(s).

TCPNoDelay

Can be used to turn off the network optimization performed by Nagle’s algorithm.

2.3.6.4. TCP

The im_tcp module of NXLog Enterprise Edition supports the ReusePort directive to enable synchronous listening on the same port by multiple module instances.

The Host directive of the om_tcp module can be defined several times to work in a failover configuration.

The om_tcp module also supports the following optional directives:

LocalPort

The local port number of the connection.

Reconnect

Sets the reconnect interval in seconds.

TCPNoDelay

Turns off network optimization performed by Nagle’s algorithm.

2.3.6.5. UDP

The im_udp module of NXLog Enterprise Edition provides the following directives:

ReusePort

Enables synchronous listening on the same port by multiple module instances.

UseRecvmmsg

Specifies that the recvmmsg() system call should be used whenever possible. This improves performance by enabling the reception of multiple messages per call.

The Enterprise Edition’s om_udp module supports multiple definitions of the Host directive which can be used to configure failover.

The om_udp module of NXLog Enterprise Edition also supports the following directives:

LocalPort

The local port number of the connection.

OutputType

Sets the output writer function for UDP datagrams.

Reconnect

Sets the reconnect interval in seconds.

2.3.7. Miscellaneous modules

Table 7. Supported operations
Operation Name NXLog Community Edition NXLog Enterprise Edition Feature Advantage

Collecting Mark (im_mark)

20

20

For indicating periodic activity to ensure the logger is running when there are no log messages being received in from other sources.

Testing NXLog Configuration (im_null, om_null)

20

20

Provides testing capabilities and allows creating dummy routes.

Generating Test Events (im_testgen)

20

20

For generating simple events which can be read and processed before running the system in production.

Simulation of Output Messages Blocking (om_blocker)

20

20

Additional testing capability which can block messages to simulate a blocked route.

Buffering of Log Messages (pm_buffer)

20

20

Eliminates loss of log data by configuring log message buffers.

Event Correlation (pm_evcorr)

20

20

Provides event correlation functionality in addition to available NXLog features, such as variables and statistical counters.

ASLR (address space layout randomization)

20

20

Binaries built using ASLR are more resistant to memory allocation exploits. (Windows only).

The following features are available in both editions of NXLog, but NXLog Enterprise Edition provides additional or enhanced functionality.

2.3.7.1. Buffering of log messages

NXLog Enterprise Edition supports the CreateDir directive to create an output directory before opening the output file for writing.

2.3.7.2. Event correlation

NXLog Enterprise Edition supports the Group rule to group messages based on the specified correlation context.

2.3.8. Supported core functionalities

As opposed to module instance directives which do not extend beyond the scope of their respective instances, general and global directives can be applied to the entire NXLog configuration. Both of these directives are compared in this section:

2.3.8.1. General directives

General directives provide configuration reusability. This reduces the amount of configuration needed, increases flexibility, and eliminates errors by using well-tested configuration components.

This subsection compares general directives which are supported by both editions of NXLog.

Table 8. Supported general directives
Directive Name NXLog Community Edition NXLog Enterprise Edition Feature Advantage

define

20

20

This feature allows you to define a constant or macro which can be used as directory name, code snippet, or regular expression. Once defined, you can insert it in a uniform manner within any of the module instances.

envvar

20

20

Retrieves environment values to make them available for use with various NXLog components or in any module instance.

include

20

20

Specifies a file or set of files which can extend the current NXLog configuration. After being included, the file configuration can be reused within the scope of the configuration.

include_stdout

20

20

Using this directive, the configuration content can be read through external commands. This may be useful when a configuration is generated dynamically and cannot be known beforehand.

2.3.8.2. Global directives

Global directives control the overall behavior of NXLog and provide additional features which can improve its functionality.

2.3.8.2.1. Caching and batching

Caching adjusts the NXLog performance to specific needs. Batching log messages saves resources and optimizes the network performance by grouping messages together before forwarding them.

The following global directives can be used to fine-tune NXLog’s caching and batching settings.

Table 9. Caching and batching directives
Directive Name NXLog Community Edition NXLog Enterprise Edition Feature Advantage

Caching directives

CacheDir

20

20

Specifies the directory where the cache file will be stored.

CacheFlushInterval

20

20

This option adjusts logging performance by specifying the interval for flushing the in-memory position cache to the cache file.

CacheInvalidationTime

20

20

Prevents the cache from growing indefinitely by discarding cache entries after their storage period exceeds this directive’s setting.

CacheSync

20

20

Guarantees crash-safe operation by delaying the in-memory cache flush to disk.

NoCache

20

20

Globally disables NXLog’s caching mechanism.

Batching directives

BatchSize

20

20

Specifies the maximum number of records to collect in a batch before forwarding them to the next instance(s) in the route.

BatchFlushInterval

20

20

Sets a timeout before forwarding each batch of messages to the next instance(s) in the route.

2.3.8.2.2. Preventing data loss

Persistent queuing provides the capability of temporarily writing the incoming log data to disk in case the in-memory queue overflows. Using flow control, NXLog operations can be suspended in case any module instance (input, processor, or output) becomes blocked or unable to process events. Both persistent queuing and flow control help prevent data loss.

The following general directives provide options for customizing NXLog’s persistent queuing and flow control features.

Table 10. Persistent queuing directives
Directive Name NXLog Community Edition NXLog Enterprise Edition Feature Advantage

Persistent queuing

LogqueueDir

20

20

Specifies the directory where files of the persistent queue will be stored. Persistent storage prevents data loss and thus improves logging reliability.

LogqueueSize

20

20

In addition to the LogqueueDir, this directive offers flexibility in controlling the log queue size needed for persistent queuing.

PersistLogqueue

20

20

This directive determines whether or not log queues should be saved to disk when necessary.

SyncLogqueue

20

20

To make the logging process more reliable and crash-safe, this option provides syncing capabilities for disk-based queues of processor and output module instances.

Flow control

FlowControl

20

20

This feature specifies whether the input-to-output flow should be controlled by NXLog to prevent data loss in case of failure at any stage.

FlowControlFIFO

20

20

A convenient way to enable FIFO mode for modules with disabled flow control functionality.

2.3.8.2.3. Processing dates

Customization of date formatting can be important when date/time information needs to be normalized and indexed for enabling it to used in time-based queries.

Table 11. Supported date-related directives
Directive Name NXLog Community Edition NXLog Enterprise Edition Feature Advantage

DateFormat

20

20

Overrides the default date/time pattern which is used by the internal NXLog logging mechanism for converting datetime value to string value.

GenerateDateInUTC

20

20

Allows using UTC instead of local time when generating dates in the YYYY-MM-DD hh:mm:ss format.

ParseDateInUTC

20

20

Enables parsing the date in the YYYY-MM-DD hh:mm:ss format as UTC instead of processing it as local time.

2.3.8.2.4. Memory and performance

These NXLog directives can be used to adjust performance and memory consumption.

Table 12. Supported directives
Directive Name NXLog Community Edition NXLog Enterprise Edition Feature Advantage

StringLimit

20

20

To avoid memory exhaustion, each message string can be limited to a maximum size. This will guard NXLog against denial-of-service scenarios.

SuppressRepeatingLogs

20

20

To avoid excessive consumption of disk space, this directive restricts the number of messages the internal logger can accept.

Threads

20

20

For fine-tuning NXLog’s performance, its number of threads can be explicitly set. If not specified, the number of threads is selected automatically.

2.3.8.2.5. Debugging capabilities

The following directives are available for setting NXLog’s debugging options.

Table 13. Supported debugging directives
Directive Name NXLog Community Edition NXLog Enterprise Edition Feature Advantage

LogFile

20

20

Provides self-logging capabilities for convenient monitoring and debugging of NXLog-related problems.

LogLevel

20

20

Specifies the logging level for internal NXLog messages set by the LogFile directive. It features a granularity of five levels: either CRITICAL, ERROR, WARNING, INFO, or DEBUG.

NoFreeOnExit

20

20

Additional debugging option which allows showing proper stack trace in module function calls.

2.3.8.2.6. Other global directives

These remaining directives offer diverse features and options available with NXLog that do not fit exactly in any the previous categories covered in this section.

Table 14. List of global directives
Directive Name NXLog Community Edition NXLog Enterprise Edition Feature Advantage

Capabilities

20

20

Allows specifying the required Linux capabilities to enable privileged kernel calls.

EscapeGlobPatterns

20

20

Specifies the backslash (\) character to escape glob patterns or wildcarded entries; this measure provides convenience and unification with other company-wide approaches, standards, or other requirements.

Group

20

20

Linux-only directive to specify the group ID that NXLog run as.

IgnoreErrors

20

20

With this directive enabled, NXLog will continue to run even if it encounters configuration-related problems. If set to FALSE, NXLog will stop if errors are encountered.

ModuleDir

20

20

This option allows you to override the standard location where NXLog loadable modules are stored by default.

Panic

20

20

This directive provides a choice of three options, HARD, SOFT, or OFF, that will determine how NXLog should react when it finds itself in a panic condition (a critical state).

PidFile

20

20

To make configuration more convenient, this feature allows overriding the default PID file name which NXLog uses during its operation.

ReadTimeout

20

20

Using this feature, the default exit condition timeout of the nxlog-processor(8) software can be overridden.

RootDir

20

20

As with the SpoolDir directive, this feature offers flexibility in setting a custom root directory location for NXLog.

SpoolDir

20

20

As with the RootDir directive, this feature offers flexibility in setting a custom working directory location for NXLog.

User

20

20

For Unix-like operating systems this directive specifies the user NXLog will run as and consequently which permissions it will have.

2.4. 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

3.1. Event records and fields

In NXLog, 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. Event 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:

    1. $EventReceivedTime (type: datetime) The time when the event is received. The value is not modified if the field already exists.

    2. $SourceModuleName (type: string) The name of the module instance, for input modules. The value is not modified if the field already exists.

    3. $SourceModuleType (type: string) The type of module instance (such as im_file), for input modules. The value is not modified if the field already exists.

  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. Processing a syslog message

This example shows a Syslog event and its corresponding fields as processed by NXLog. A few fields are omitted for brevity.

  1. NXLog receives an event:

    <38>Nov 22 10:30:12 myhost sshd[8459]: Failed password for invalid user linda from 192.168.1.60 port 38176 ssh2
  2. The raw event data is stored in the $raw_event field when NXLog receives a log message. The NXLog core and input module add additional fields.

    {
      "raw_event": "<38>Nov 22 10:30:12 myhost sshd[8459]: Failed password for invalid user linda from 192.168.1.60 port 38176 ssh2",
      "EventReceivedTime": "2019-11-22 10:30:13",
      "MessageSourceAddress": "192.168.1.1",
  3. The xm_syslog parse_syslog() procedure parses the basic format of the Syslog message, reading from $raw_event by default. This procedure adds a few more fields:

      "SyslogFacility": "USER",
      "SyslogSeverity": "NOTICE",
      "EventTime": "2019-11-22 10:30:12",
      "Hostname": "myhost",
      "SourceName": "sshd",
      "ProcessID": 8459,
      "Message": "Failed password for invalid user linda from 192.168.1.60 port 38176 ssh2",
  4. Further metadata can be extracted from the free-form $Message field with regular expressions or other methods; see Extracting data.

      "Status": "failed",
      "AuthenticationMethod": "password",
      "Reason": "invalid user",
      "User": "linda",
      "SourceIPAddress": "192.168.1.60",
      "SourcePort": 38176,
      "Protocol": "ssh2"
    }

3.1.3. Preservation of forwarded data

By default, when the OutputType directive is set to LineBased, only data of the $raw_event field can be forwarded over the network. Contents of other fields from the event record are discarded if not initially converted to a structured format such as JSON, XML, or CSV. Among these formats, JSON provides human-readable syntax, wide support from various software platforms, and inclusion of nested structures.

For example, below is the log message containing the EventTime and Message fields.

"EventTime":2020-05-13 00:00:00
"Message":"The service has started"

After applying to_json() procedure, the message obtains the additional raw_event field containing the EventTime and Message fields in the JSON format.

"EventTime":2020-05-13 00:00:00
"Message":"The service has started"
"raw_event":"{"EventTime":"2020-05-13 00:00:00", "Message":"The service has started"}"

When forwarding over TCP via the default LineBased type, NXLog sends only the contents of the raw_event field.

{"EventTime":"2020-05-13 00:00:00", "Message":"The service has started"}

After this message has been forwarded, the raw_event name returns to it and and other fields are added automatically to create the event record.

"raw_event":"{"EventTime":"2020-05-13 00:00:00", "Message":"The service has started"}"
...

Before it can be processed by the receiving NXLog instance, the event record should be parsed. Consequently, preservation of all fields in the LineBased mode requires conversion and parsing procedures before and after forwarding.

Application of the Binary function in the OutputType directive preserves all fields for forwarding without conversion and parsing procedures, so the forwarded event record will contain unmodified fields.

"EventTime":2020-05-13 00:00:00
"Message":"The service has started"

The binary format is best suited the following cases:

  • Logs needing long-term archival for compliance reasons

  • Logs that need to preserve timestamps

  • Logs unlikely to be read or processed by other applications.

Application of both approaches to the same set of data, i.e. conversion to JSON and NXLog binary formats will duplicate and significantly increase the size of forwarded data.

"EventTime":2020-05-13 00:00:00
"Message":"The service has started"
"raw_event":"{"EventTime":"2020-05-13 00:00:00", "Message":"The service has started"}

The examples below provide detailed explanations of preservation via JSON and NXLog binary format.

Example 2. Preserving data via JSON

This example demonstrates how to preserve forwarded data through conversion to JSON. The sample of the forwarded message is shown below.

"EventTime":2020-05-13 00:00:00 "Message":"The service has started"

The configuration below defines the EVENT_REGEX regular expression to read messages, and the Exec block contains parsing instructions as per this expression.

nxlog.conf (sender) [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
define EVENT_REGEX /(?x)^"EventTime":(\d+-\d+-\d+)\s+\
                    (\d+:\d+:\d+)\s+"Message":"(.*)"/

<Extension json>
    Module         xm_json
</Extension>

<Input from_file>
    Module         im_file
    File           '/tmp/input'
    <Exec>
        if $raw_event =~ %EVENT_REGEX%
            {
                $EventTime = strptime($1 + $2,'%Y-%m-%d %T');
                $Message = $3;
                to_json();
            }
        else drop();
    </Exec>
</Input>

<Output to_tcp>
     Module        om_tcp
     Host          192.168.31.122
     Port          10500
</Output>

After the message is parsed, this configuration creates the following fields for the event record:

  • $EventTime is combined from the date and time values of the source log message using the strptime() function,

  • $Message contains The service has started text of the message.

  • Fields that are added by NXLog automatically:

    • $EventReceivedTime contains the time when the message was received by NXLog,

    • $SourceModuleName contains the name of the module instance which initially received the message,

    • $SourceModuleType contains the NXLog module name which initially received the message.

Finally, the event record is converted to JSON using to_json() procedure of the xm_json module and can be sent via TCP using the om_tcp module. The result of conversion is shown in the sample below.

Output sample
{
  "EventReceivedTime": "2020-06-18T09:06:03.891218+00:00",
  "SourceModuleName": "from_file",
  "SourceModuleType": "im_file",
  "EventTime": "2020-05-13T00:00:00.000000+00:00",
  "Message": "The service has started"
}

After forwarding, this message can be parsed into fields using the parse_json() procedure, see the configuration below.

nxlog.conf (receiver) [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
<Extension json>
    Module      xm_json
</Extension>

<Input from_tcp>
    Module      im_tcp
    Host        192.168.31.122
    Port        10500
    <Exec>
        parse_json();
        $EventTime = parsedate($EventTime);
        $Message = $Message;
    </Exec>
</Input>

The example below demonstrates conversion to the Binary format.

Example 3. Preserving data via the NXLog binary format

The configuration below reads messages from a file. In the Exec block, the $raw_event length is calculated using the size() function. The message is dropped in case its length is not 5 characters or longer. Otherwise, the message length is stored into the $MessageSize field for forwarding over the network.

nxlog.conf (sender) [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<Input from_file>
    Module          im_file
    File            '/tmp/input'
    ReadFromLast    TRUE
    <Exec>
        if size($raw_event) < 5 drop();
        $MessageSize = size($raw_event);
    </Exec>
</Input>

<Output to_tcp>
    Module          om_tcp
    Host            192.168.31.150
    Port            10500
    OutputType      Binary
</Output>

This configuration creates the following fields:

  • $raw_event contains the log message,

  • $EventReceivedTime contains the time when the message was received by NXLog,

  • $SourceModuleName contains the name of the module instance which initially received the message,

  • $SourceModuleType contains the NXLog module name which initially received the message,

  • $MessageSize contains the size of the $raw_event field.

Finally, the event record is converted to NXLog binary format and forwarded over the network using the om_tcp module.

To accept a message, the InputType directive of the im_tcp module instance can be configured to the Binary function.

nxlog.conf (receiver) [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
<Input from_tcp>
    Module          im_tcp
    Host            192.168.31.150
    Port            10500
    InputType       Binary
</Input>

<Output to_file>
    Module          om_file
    File            '/tmp/output'
    Exec            to_json();
</Output>

3.2. Modules and routes

While the NXLog core is responsible for managing the overall log processing operation, 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.

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 and routes run concurrently, the global log processing flow remains parallelized.

3.2.1. Modules

A module is a foo.so or foo.dll that can be loaded by the NXLog core and provides a particular capability. A module instance is a configured module that can be used in 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 4. 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 5. 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 6. 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 7. 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 8. 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. Buffering and flow control

NXLog implements several buffering features. Of these, two are particularly important and are enabled by default: log queues and flow control.

Log queues

Every processor and output module instance has an input log queue for events that have not yet been processed by that module instance. When the preceding module has processed an event, it is placed in this queue. Log queues are enabled by default for all processor and output module instances; adjusting log queue sizes is the preferred way to control buffering behavior.

diag d29522d7e67540d0e54c3cf122084ed6
Flow control

NXLog’s flow control functionality provides automatic, zero-configuration handling of many cases where buffering would otherwise be required. Flow control takes effect when the following sequence of events occurs in a route:

  1. a processor or output module instance is not able to process log data at the incoming rate,

  2. that module instance’s log queue becomes full, and

  3. the preceding input or processor module instance has flow control enabled (which is the default).

In this case, flow control will cause the input or processor module instance to suspend processing until the succeeding module instance is ready to accept more log data.

diag 4c363452ab62c980f13415f522a4af26

For more information about these and other buffering features, including log queue persistence, disabling flow control, read/write buffers, and examples for specific scenarios, see Using buffers.

3.4. Batch processing

NXLog implements an internal batch processing mechanism to efficiently process and move events along the defined routes. Batch settings can be specified globally or at the module level using the BatchSize and BatchFlushInterval directives. The module-level settings override the global settings.

Starting with NXLog version 5.2, events are organized in batches by the input modules. Events are accumulated until the batch size or flush interval is met. Once either of these limits is reached, the batch of events is written to a queue for processing by the next module(s) in the route. Output modules read the batched events from their log queues, process them, and write them to the output buffer in the same order as they were read.

diag 98448babcfa9e3481fc68b989c23b28c
Note
In versions prior to 5.2, events were organized in batches by the output modules, some of which supported the FlushLimit and FlushInterval module directives. This is no longer the case and these directives have been deprecated.

3.5. 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.5.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 agentless 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 which ensure your log data reaches its destination. You can monitor the health of the NXLog agent to verify its operational integrity.

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.5.2. Agentless 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 agentless 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.

Agentless 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.

Agentless log collection has some disadvantages that should be taken into consideration.

  • Agentless 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.

  • Data transfers are less secure when using agentless collection since most Syslog sources transfer data over unencrypted UDP.

Agentless collection is commonly used with the following protocols.

3.5.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. For detailed information about which modules are available for specific platforms, see the Modules by Platform and Modules by Package sections.

4.1. Extension modules

The following extension (xm_*) modules are available.

Table 15. Available extension modules
Module Description

xm_admin — Remote Management (Enterprise Edition only)

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

xm_aixaudit — AIX Auditing (Enterprise Edition only)

Parses AIX audit events that have been written to file.

xm_asl — Apple System Logs (Enterprise Edition only)

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

xm_bsm — Basic Security Module Auditing (Enterprise Edition only)

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

xm_cef — CEF (Enterprise Edition only)

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

xm_charconv — Character Set Conversion

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

xm_crypto — Encryption (Enterprise Edition only)

Provides encryption and decryption of logs by using data converters which implement the AES symmetric-key algorithm.

xm_csv — CSV

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

xm_exec — External Program Execution

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

xm_filelist — File Lists (Enterprise Edition only)

Implements file-based blacklisting or whitelisting.

xm_fileop — File Operations

Provides functions and procedures to manipulate files.

xm_gelf — 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.

xm_go — Go or Golang (Enterprise Edition only)

Provides support for processing log data with methods written in the Go language.

xm_grok — Grok Patterns (Enterprise Edition only)

Provides support for parsing events with Grok patterns.

xm_java — Java (Enterprise Edition only)

Provides support for processing log data with methods written in the Java language.

xm_json — JSON

Provides functions and procedures to generate data in JSON (JavaScript Object Notation) format or to parse JSON data.

xm_kvp — Key-Value Pairs

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

xm_leef — LEEF (Enterprise Edition only)

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

xm_msdns — DNS Server Debug Log Parsing (Enterprise Edition only)

Parses Microsoft Windows DNS Server debug logs

xm_multiline — Multi-Line Message Parser

Parses log entries that span multiple lines.

xm_netflow — NetFlow (Enterprise Edition only)

Provides a parser for NetFlow payload collected over UDP.

xm_nps — NPS (Enterprise Edition only)

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

xm_pattern — Pattern Matcher (Enterprise Edition only)

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

xm_perl — Perl

Processes log data using Perl.

xm_python — Python (Enterprise Edition only)

Processes log data using Python. Only versions 3.x of Python are supported.

xm_resolver — Resolver (Enterprise Edition only)

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.

xm_rewrite — Rewrite (Enterprise Edition only)

Transforms event records by modifying or discarding specific fields.

xm_ruby — Ruby (Enterprise Edition only)

Processes log data using Ruby.

xm_snmp — SNMP Traps (Enterprise Edition only)

Parses SNMPv1 and SNMPv2c trap messages.

xm_stdinpw — Passwords on standard input (Enterprise Edition only)

Reads passwords on standard input. This module has been deprecated.

xm_syslog — Syslog

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

xm_w3c — W3C (Enterprise Edition only)

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

xm_wtmp — WTMP

Provides a parser function to process binary wtmp files.

xm_xml — XML

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

xm_zlib — Compression (Enterprise Edition only)

This module compresses and decompresses log data using the gzip data format defined in RFC 1952 and the zlib format defined in RFC 1950.

4.2. Input modules

The following input (im_*) modules are available.

Table 16. Available input modules
Module Description

im_acct — BSD/Linux Process Accounting (Enterprise Edition only)

Collects process accounting logs from a Linux or BSD kernel.

im_aixaudit — AIX Auditing (Enterprise Edition only)

Collects AIX audit events directly from the kernel.

im_azure — Azure (Enterprise Edition only)

Collects logs from Microsoft Azure applications.

im_maculs — macOS ULS (Enterprise Edition only)

Collects logs from Apple’s unified logging system (ULS) on macOS.

im_batchcompress — Batched Compression over TCP or SSL (Enterprise Edition only)

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

im_bsm — Basic Security Module Auditing (Enterprise Edition only)

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

im_checkpoint — Check Point OPSEC (Enterprise Edition only)

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

im_dbi — DBI

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

im_etw — Event Tracing for Windows (ETW) (Enterprise Edition only)

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

im_exec — Program

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

im_file — File

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

im_fim — File Integrity Monitoring (Enterprise Edition only)

Scans files and directories and reports detected changes.

im_go — Go or Golang (Enterprise Edition only)

Provides support for collecting log data with methods written in the Go language.

im_http — HTTP/HTTPS (Enterprise Edition only)

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

im_internal — Internal

Collect log messages from NXLog.

im_java — Java (Enterprise Edition only)

Provides support for processing log data with methods written in the Java language.

im_kafka — Apache Kafka (Enterprise Edition only)

Implements a consumer for collecting from a Kafka cluster.

im_kernel — Kernel (Enterprise Edition only for some platforms)

Collects log data from the kernel log buffer.

im_linuxaudit — Linux Audit System (Enterprise Edition only)

Configures and collects events from the Linux Audit System

im_mark — Mark

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

im_mseventlog — Event Logging for Windows XP/2000/2003

Collects event log messages on the Windows platform.

im_msvistalog — Windows Event Log for Windows 2008/Vista and later

Collects Windows Event Log records on the Windows platform.

im_null — Null

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

im_oci — OCI (Enterprise Edition only)

Reads log messages from an Oracle database. This module has been deprecated.

im_odbc — ODBC (Enterprise Edition only)

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

im_pcap — Packet Capture (Enterprise Edition only)

Provides support to passively monitor network traffic by generating logs for various protocols.

im_perl — Perl (Enterprise Edition only)

Captures event data directly into NXLog using Perl code.

im_pipe — Named Pipes (Enterprise Edition only)

This module can be used to read log messages from named pipes on UNIX-like operating systems.

im_python — Python (Enterprise Edition only)

Captures event data directly into NXLog using Python code. Only versions 3.x of Python are supported.

im_redis — Redis (Enterprise Edition only)

Retrieves data stored in a Redis server.

im_regmon — Windows Registry Monitoring (Enterprise Edition only)

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

im_ruby — Ruby (Enterprise Edition only)

Captures event data directly into NXLog using Ruby code.

im_ssl — SSL/TLS

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

im_systemd — Systemd (Enterprise Edition only)

This module accepts messages from the Linux systemd journal.

im_tcp — TCP

Collects log data over a TCP network connection.

im_testgen — Test Generator

Generates log data for testing purposes.

im_udp — UDP

Collects log data over a UDP network connection.

im_uds — Unix Domain Socket

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

im_winperfcount — Windows Performance Counters (Enterprise Edition only)

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

im_wseventing — Windows Event Forwarding (Enterprise Edition only)

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

im_zmq — ZeroMQ (Enterprise Edition only)

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

4.3. Processor modules

The following processor (pm_*) modules are available.

Table 17. Available processor modules
Module Description

pm_blocker — Blocker

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

pm_buffer — Buffer

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

pm_evcorr — Event Correlator

Perform log actions based on relationships between events.

pm_filter — Filter

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

pm_hmac — HMAC Message Integrity (Enterprise Edition only)

Protect messages with HMAC cryptographic checksumming. This module has been deprecated.

pm_hmac_check — HMAC Message Integrity Checker (Enterprise Edition only)

Check HMAC cryptographic checksums on messages. This module has been deprecated.

pm_norepeat — Message De-Duplicator

Drops messages that are identical to previously-received messages. This module has been deprecated. This functionality can be implemented with module variables.

pm_null — 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.

pm_pattern — Pattern Matcher

Applies advanced pattern matching logic to log data, which can give greater performance than normal regular expression statements in Exec directives. This module has been deprecated. Use the xm_pattern module instead.

pm_transformer — Message Format Converter

Provides parsers for various log formats, and converts between them. This module has been deprecated. Use the xm_syslog, xm_csv, xm_json, and xm_xml modules instead.

pm_ts — Timestamping (Enterprise Edition only)

Add cryptographic Time-Stamp signatures to messages. This module has been deprecated.

4.4. Output modules

The following output (om_*) modules are available.

Table 18. Available output modules
Module Description

om_azure — Microsoft Azure Sentinel (Enterprise Edition only)

Sends data to a Microsoft Azure Sentinel server.

om_batchcompress — Batched Compression over TCP or SSL (Enterprise Edition only)

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

om_blocker — Blocker

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

om_dbi — DBI

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

om_elasticsearch — Elasticsearch (Enterprise Edition only)

Stores logs in an Elasticsearch server.

om_eventdb — EventDB (Enterprise Edition only)

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

om_exec — Program

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

om_file — File

Writes log data to a file on the file system.

om_go — Go or Golang (Enterprise Edition only)

Provides support for forwarding log data with methods written in the Go language.

om_http — HTTP/HTTPS

Send events over HTTP or HTTPS using POST requests.

om_java — Java (Enterprise Edition only)

Provides support for processing log data with methods written in the Java language.

om_kafka — Apache Kafka (Enterprise Edition only)

Implements a producer for publishing to a Kafka cluster.

om_null — Null

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

om_oci — OCI (Enterprise Edition only)

Writes log messages to an Oracle database. This module has been deprecated.

om_odbc — ODBC (Enterprise Edition only)

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

om_perl — Perl (Enterprise Edition only)

Uses Perl code to handle output log messages from NXLog.

om_pipe — Named Pipes (Enterprise Edition only)

This module allows log messages to be sent to named pipes on UNIX-like operating systems.

om_python — Python (Enterprise Edition only)

Uses Python code to handle output log messages from NXLog. Only versions 3.x of Python are supported.

om_raijin — Raijin (Enterprise Edition only)

Stores log messages in a Raijin server.

om_redis — Redis (Enterprise Edition only)

Stores log messages in a Redis server.

om_ruby — Ruby (Enterprise Edition only)

Uses Ruby code to handle output log messages from NXLog.

om_ssl — SSL/TLS

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

om_tcp — TCP

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

om_udp — UDP

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

om_udpspoof — UDP with IP Spoofing (Enterprise Edition only)

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.

om_uds — UDS

Sends log data to a Unix domain socket.

om_webhdfs — WebHDFS (Enterprise Edition only)

Stores log data in Hadoop HDFS using the WebHDFS protocol.

om_zmq — ZeroMQ (Enterprise Edition only)

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

4.5. Modules by Platform

4.5.2. AmazonLinux 2

Table 20. Available Modules in nxlog-5.4.7313_amzn2_aarch64.tar.bz2
Package Input Output Processor Extension

nxlog-5.4.7313_amzn2_aarch64.rpm

nxlog-dbi-5.4.7313_amzn2_aarch64.rpm

nxlog-java-5.4.7313_amzn2_aarch64.rpm

nxlog-kafka-5.4.7313_amzn2_aarch64.rpm

nxlog-odbc-5.4.7313_amzn2_aarch64.rpm

nxlog-pcap-5.4.7313_amzn2_aarch64.rpm

nxlog-perl-5.4.7313_amzn2_aarch64.rpm

nxlog-python-5.4.7313_amzn2_aarch64.rpm

nxlog-ruby-5.4.7313_amzn2_aarch64.rpm

nxlog-systemd-5.4.7313_amzn2_aarch64.rpm

nxlog-wseventing-5.4.7313_amzn2_aarch64.rpm

nxlog-zmq-5.4.7313_amzn2_aarch64.rpm

4.5.3. CentOS 6, RHEL 6

Table 21. Available Modules in nxlog-5.4.7313_rhel6_x86_64.tar.bz2
Package Input Output Processor Extension

nxlog-5.4.7313_rhel6_x86_64.rpm

nxlog-checkpoint-5.4.7313_rhel6_x86_64.rpm

nxlog-dbi-5.4.7313_rhel6_x86_64.rpm

nxlog-java-5.4.7313_rhel6_x86_64.rpm

nxlog-kafka-5.4.7313_rhel6_x86_64.rpm

nxlog-odbc-5.4.7313_rhel6_x86_64.rpm

nxlog-perl-5.4.7313_rhel6_x86_64.rpm

nxlog-wseventing-5.4.7313_rhel6_x86_64.rpm

4.5.4. CentOS 7, RHEL 7

Table 22. Available Modules in nxlog-5.4.7313_rhel7_x86_64.tar.bz2
Package Input Output Processor Extension

nxlog-5.4.7313_rhel7_x86_64.rpm

nxlog-checkpoint-5.4.7313_rhel7_x86_64.rpm

nxlog-dbi-5.4.7313_rhel7_x86_64.rpm

nxlog-java-5.4.7313_rhel7_x86_64.rpm

nxlog-kafka-5.4.7313_rhel7_x86_64.rpm

nxlog-odbc-5.4.7313_rhel7_x86_64.rpm

nxlog-pcap-5.4.7313_rhel7_x86_64.rpm

nxlog-perl-5.4.7313_rhel7_x86_64.rpm

nxlog-python-5.4.7313_rhel7_x86_64.rpm

nxlog-ruby-5.4.7313_rhel7_x86_64.rpm

nxlog-systemd-5.4.7313_rhel7_x86_64.rpm

nxlog-wseventing-5.4.7313_rhel7_x86_64.rpm

nxlog-zmq-5.4.7313_rhel7_x86_64.rpm

4.5.5. CentOS 8, RHEL 8

Table 23. Available Modules in nxlog-5.4.7313_rhel8_x86_64.tar.bz2
Package Input Output Processor Extension

nxlog-5.4.7313_rhel8_x86_64.rpm

nxlog-checkpoint-5.4.7313_rhel8_x86_64.rpm

nxlog-java-5.4.7313_rhel8_x86_64.rpm

nxlog-kafka-5.4.7313_rhel8_x86_64.rpm

nxlog-odbc-5.4.7313_rhel8_x86_64.rpm

nxlog-pcap-5.4.7313_rhel8_x86_64.rpm

nxlog-perl-5.4.7313_rhel8_x86_64.rpm

nxlog-python-5.4.7313_rhel8_x86_64.rpm

nxlog-ruby-5.4.7313_rhel8_x86_64.rpm

nxlog-systemd-5.4.7313_rhel8_x86_64.rpm

nxlog-wseventing-5.4.7313_rhel8_x86_64.rpm

nxlog-zmq-5.4.7313_rhel8_x86_64.rpm

4.5.7. Debian Buster

Table 25. Available Modules in nxlog-5.4.7313_debian10_amd64.tar.bz2
Package Input Output Processor Extension

nxlog-5.4.7313_debian10_amd64.deb

nxlog-checkpoint_5.4.7313_debian10_amd64.deb

nxlog-dbi_5.4.7313_debian10_amd64.deb

nxlog-java_5.4.7313_debian10_amd64.deb

nxlog-kafka_5.4.7313_debian10_amd64.deb

nxlog-odbc_5.4.7313_debian10_amd64.deb

nxlog-pcap_5.4.7313_debian10_amd64.deb

nxlog-perl_5.4.7313_debian10_amd64.deb

nxlog-python_5.4.7313_debian10_amd64.deb

nxlog-ruby_5.4.7313_debian10_amd64.deb

nxlog-systemd_5.4.7313_debian10_amd64.deb

nxlog-wseventing_5.4.7313_debian10_amd64.deb

nxlog-zmq_5.4.7313_debian10_amd64.deb

4.5.8. Debian Jessie

Table 26. Available Modules in nxlog-5.4.7313_debian8_amd64.tar.bz2
Package Input Output Processor Extension

nxlog-5.4.7313_debian8_amd64.deb

nxlog-checkpoint_5.4.7313_debian8_amd64.deb

nxlog-dbi_5.4.7313_debian8_amd64.deb

nxlog-java_5.4.7313_debian8_amd64.deb

nxlog-kafka_5.4.7313_debian8_amd64.deb

nxlog-odbc_5.4.7313_debian8_amd64.deb

nxlog-pcap_5.4.7313_debian8_amd64.deb

nxlog-perl_5.4.7313_debian8_amd64.deb

nxlog-python_5.4.7313_debian8_amd64.deb

nxlog-ruby_5.4.7313_debian8_amd64.deb

nxlog-systemd_5.4.7313_debian8_amd64.deb

nxlog-wseventing_5.4.7313_debian8_amd64.deb

nxlog-zmq_5.4.7313_debian8_amd64.deb

4.5.9. Debian Stretch

Table 27. Available Modules in nxlog-5.4.7313_debian9_amd64.tar.bz2
Package Input Output Processor Extension

nxlog-5.4.7313_debian9_amd64.deb

nxlog-checkpoint_5.4.7313_debian9_amd64.deb

nxlog-dbi_5.4.7313_debian9_amd64.deb

nxlog-java_5.4.7313_debian9_amd64.deb

nxlog-kafka_5.4.7313_debian9_amd64.deb

nxlog-odbc_5.4.7313_debian9_amd64.deb

nxlog-pcap_5.4.7313_debian9_amd64.deb

nxlog-perl_5.4.7313_debian9_amd64.deb

nxlog-python_5.4.7313_debian9_amd64.deb

nxlog-ruby_5.4.7313_debian9_amd64.deb

nxlog-systemd_5.4.7313_debian9_amd64.deb

nxlog-wseventing_5.4.7313_debian9_amd64.deb

nxlog-zmq_5.4.7313_debian9_amd64.deb

4.5.15. SLES 12

Table 33. Available Modules in nxlog-5.4.7313_sles12_x86_64.tar.bz2
Package Input Output Processor Extension

nxlog-5.4.7313_sles12_x86_64.rpm

nxlog-checkpoint-5.4.7313_sles12_x86_64.rpm

nxlog-dbi-5.4.7313_sles12_x86_64.rpm

nxlog-java-5.4.7313_sles12_x86_64.rpm

nxlog-kafka-5.4.7313_sles12_x86_64.rpm

nxlog-odbc-5.4.7313_sles12_x86_64.rpm

nxlog-pcap-5.4.7313_sles12_x86_64.rpm

nxlog-perl-5.4.7313_sles12_x86_64.rpm

nxlog-python-5.4.7313_sles12_x86_64.rpm

nxlog-systemd-5.4.7313_sles12_x86_64.rpm

nxlog-wseventing-5.4.7313_sles12_x86_64.rpm

nxlog-zmq-5.4.7313_sles12_x86_64.rpm

4.5.16. SLES 15

Table 34. Available Modules in nxlog-5.4.7313_sles15_x86_64.tar.bz2
Package Input Output Processor Extension

nxlog-5.4.7313_sles15_x86_64.rpm

nxlog-checkpoint-5.4.7313_sles15_x86_64.rpm

nxlog-dbi-5.4.7313_sles15_x86_64.rpm

nxlog-java-5.4.7313_sles15_x86_64.rpm

nxlog-kafka-5.4.7313_sles15_x86_64.rpm

nxlog-odbc-5.4.7313_sles15_x86_64.rpm

nxlog-pcap-5.4.7313_sles15_x86_64.rpm

nxlog-perl-5.4.7313_sles15_x86_64.rpm

nxlog-python-5.4.7313_sles15_x86_64.rpm

nxlog-ruby-5.4.7313_sles15_x86_64.rpm

nxlog-systemd-5.4.7313_sles15_x86_64.rpm

nxlog-wseventing-5.4.7313_sles15_x86_64.rpm

nxlog-zmq-5.4.7313_sles15_x86_64.rpm

4.5.19. Ubuntu 16.04

Table 37. Available Modules in nxlog-5.4.7313_ubuntu16_amd64.tar.bz2
Package Input Output Processor Extension

nxlog-5.4.7313_ubuntu16_amd64.deb

nxlog-checkpoint_5.4.7313_ubuntu16_amd64.deb

nxlog-dbi_5.4.7313_ubuntu16_amd64.deb

nxlog-java_5.4.7313_ubuntu16_amd64.deb

nxlog-kafka_5.4.7313_ubuntu16_amd64.deb

nxlog-odbc_5.4.7313_ubuntu16_amd64.deb

nxlog-pcap_5.4.7313_ubuntu16_amd64.deb

nxlog-perl_5.4.7313_ubuntu16_amd64.deb

nxlog-python_5.4.7313_ubuntu16_amd64.deb

nxlog-ruby_5.4.7313_ubuntu16_amd64.deb

nxlog-systemd_5.4.7313_ubuntu16_amd64.deb

nxlog-wseventing_5.4.7313_ubuntu16_amd64.deb

nxlog-zmq_5.4.7313_ubuntu16_amd64.deb

4.5.20. Ubuntu 18.04

Table 38. Available Modules in nxlog-5.4.7313_ubuntu18_amd64.tar.bz2
Package Input Output Processor Extension

nxlog-5.4.7313_ubuntu18_amd64.deb

nxlog-checkpoint_5.4.7313_ubuntu18_amd64.deb

nxlog-dbi_5.4.7313_ubuntu18_amd64.deb

nxlog-java_5.4.7313_ubuntu18_amd64.deb

nxlog-kafka_5.4.7313_ubuntu18_amd64.deb

nxlog-odbc_5.4.7313_ubuntu18_amd64.deb

nxlog-pcap_5.4.7313_ubuntu18_amd64.deb

nxlog-perl_5.4.7313_ubuntu18_amd64.deb

nxlog-python_5.4.7313_ubuntu18_amd64.deb

nxlog-ruby_5.4.7313_ubuntu18_amd64.deb

nxlog-systemd_5.4.7313_ubuntu18_amd64.deb

nxlog-wseventing_5.4.7313_ubuntu18_amd64.deb

nxlog-zmq_5.4.7313_ubuntu18_amd64.deb

4.5.21. Ubuntu 20.04

Table 39. Available Modules in nxlog-5.4.7313_ubuntu20_amd64.tar.bz2
Package Input Output Processor Extension

nxlog-5.4.7313_ubuntu20_amd64.deb

nxlog-checkpoint_5.4.7313_ubuntu20_amd64.deb

nxlog-dbi_5.4.7313_ubuntu20_amd64.deb

nxlog-java_5.4.7313_ubuntu20_amd64.deb

nxlog-kafka_5.4.7313_ubuntu20_amd64.deb

nxlog-odbc_5.4.7313_ubuntu20_amd64.deb

nxlog-pcap_5.4.7313_ubuntu20_amd64.deb

nxlog-perl_5.4.7313_ubuntu20_amd64.deb

nxlog-python_5.4.7313_ubuntu20_amd64.deb

nxlog-ruby_5.4.7313_ubuntu20_amd64.deb

nxlog-systemd_5.4.7313_ubuntu20_amd64.deb

nxlog-wseventing_5.4.7313_ubuntu20_amd64.deb

nxlog-zmq_5.4.7313_ubuntu20_amd64.deb

4.6. Modules by Package

Table 40. Input Modules

im_acct

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

im_aixaudit

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

im_azure

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

im_batchcompress

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

im_bsm

nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc)

im_checkpoint

nxlog-checkpoint-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-checkpoint-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-checkpoint-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-checkpoint_5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-checkpoint_5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-checkpoint_5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-checkpoint-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-checkpoint-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-checkpoint_5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-checkpoint_5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-checkpoint_5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

im_dbi

nxlog-dbi-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-dbi-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-dbi-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-dbi_5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-dbi_5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-dbi_5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-dbi-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-dbi-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-dbi_5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-dbi_5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-dbi_5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

im_etw

nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano)

im_exec

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

im_file

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

im_fim

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

im_go

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

im_http

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

im_internal

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

im_java

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-java-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-java-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-java-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-java-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-java_5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-java_5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-java_5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-java-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-java-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-java_5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-java_5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-java_5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

im_kafka

nxlog-kafka-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-kafka-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-kafka-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-kafka-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-kafka_5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-kafka_5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-kafka_5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-kafka-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-kafka-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-kafka_5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-kafka_5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-kafka_5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

im_kernel

nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

im_linuxaudit

nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

im_maces

nxlog-5.4.7313_macos_x86_64.pkg (MacOS)

im_maculs

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

im_mark

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

im_mseventlog

nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano)

im_msvistalog

nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano)

im_null

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

im_odbc

nxlog-odbc-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-odbc-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-odbc-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-odbc-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-odbc_5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-odbc_5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-odbc_5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-odbc-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-odbc-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-odbc_5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-odbc_5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-odbc_5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

im_pcap

nxlog-pcap-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-pcap-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-pcap-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-pcap_5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-pcap_5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-pcap_5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-pcap-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-pcap-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-pcap_5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-pcap_5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-pcap_5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

im_perl

nxlog-perl-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-perl-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-perl-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-perl-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-perl_5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-perl_5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-perl_5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-perl-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-perl-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-perl_5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-perl_5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-perl_5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

im_pipe

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

im_python

nxlog-python-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-python-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-python-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-python_5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-python_5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-python_5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-python-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-python-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-python_5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-python_5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-python_5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

im_redis

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

im_regmon

nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano)

im_ruby

nxlog-ruby-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-ruby-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-ruby-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-ruby_5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-ruby_5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-ruby_5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-ruby-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-ruby_5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-ruby_5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-ruby_5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

im_ssl

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

im_systemd

nxlog-systemd-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-systemd-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-systemd-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-systemd_5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-systemd_5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-systemd_5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-systemd-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-systemd-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-systemd_5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-systemd_5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-systemd_5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

im_tcp

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

im_testgen

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

im_udp

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

im_uds

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

im_winperfcount

nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano)

im_wseventing

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-wseventing-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-wseventing-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-wseventing-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-wseventing-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-wseventing_5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-wseventing_5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-wseventing_5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-wseventing-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-wseventing-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-wseventing_5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-wseventing_5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-wseventing_5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

im_zmq

nxlog-zmq-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-zmq-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-zmq-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-zmq_5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-zmq_5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-zmq_5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-zmq-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-zmq-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-zmq_5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-zmq_5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-zmq_5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)
Table 41. Output Modules

om_azure

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

om_batchcompress

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

om_blocker

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

om_dbi

nxlog-dbi-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-dbi-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-dbi-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-dbi_5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-dbi_5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-dbi_5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-dbi-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-dbi-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-dbi_5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-dbi_5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-dbi_5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

om_elasticsearch

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

om_eventdb

nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

om_exec

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

om_file

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

om_go

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

om_http

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

om_java

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-java-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-java-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-java-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-java-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-java_5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-java_5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-java_5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-java-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-java-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-java_5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-java_5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-java_5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

om_kafka

nxlog-kafka-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-kafka-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-kafka-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-kafka-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-kafka_5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-kafka_5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-kafka_5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-kafka-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-kafka-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-kafka_5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-kafka_5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-kafka_5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

om_null

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

om_odbc

nxlog-odbc-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-odbc-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-odbc-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-odbc-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-odbc_5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-odbc_5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-odbc_5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-odbc-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-odbc-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-odbc_5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-odbc_5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-odbc_5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

om_perl

nxlog-perl-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-perl-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-perl-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-perl-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-perl_5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-perl_5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-perl_5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-perl-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-perl-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-perl_5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-perl_5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-perl_5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

om_pipe

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

om_python

nxlog-python-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-python-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-python-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-python_5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-python_5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-python_5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-python-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-python-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-python_5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-python_5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-python_5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

om_raijin

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

om_redis

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

om_ruby

nxlog-ruby-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-ruby-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-ruby-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-ruby_5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-ruby_5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-ruby_5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-ruby-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-ruby_5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-ruby_5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-ruby_5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

om_ssl

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

om_tcp

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

om_udp

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

om_udpspoof

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

om_uds

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

om_webhdfs

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

om_zmq

nxlog-zmq-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-zmq-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-zmq-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-zmq_5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-zmq_5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-zmq_5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-zmq-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-zmq-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-zmq_5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-zmq_5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-zmq_5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)
Table 42. Extension Modules

[[modules_by_package_java/jni/libjavanxlog]]java/jni/libjavanxlog

nxlog-5.4.7313_nano.zip (Microsoft Windows Nano)

xm_admin

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

xm_aixaudit

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

xm_asl

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

xm_bsm

nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc)

xm_cef

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

xm_charconv

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

xm_crypto

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

xm_csv

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

xm_exec

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

xm_filelist

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

xm_fileop

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

xm_gelf

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

xm_go

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

xm_grok

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

xm_java

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-java-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-java-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-java-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-java-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-java_5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-java_5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-java_5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-java-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-java-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-java_5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-java_5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-java_5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

xm_json

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

xm_kvp

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

xm_leef

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

xm_msdns

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

xm_multiline

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

xm_netflow

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

xm_nps

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

xm_pattern

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

xm_perl

nxlog-perl-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-perl-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-perl-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-perl-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-perl_5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-perl_5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-perl_5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-perl-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-perl-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-perl_5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-perl_5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-perl_5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

xm_python

nxlog-python-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-python-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-python-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-python_5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-python_5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-python_5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-python-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-python-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-python_5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-python_5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-python_5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

xm_resolver

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

xm_rewrite

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

xm_ruby

nxlog-ruby-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-ruby-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-ruby-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-ruby_5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-ruby_5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-ruby_5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-ruby-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-ruby_5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-ruby_5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-ruby_5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

xm_snmp

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

xm_soapadmin

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

xm_syslog

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

xm_w3c

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

xm_wtmp

nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

xm_xml

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

xm_zlib

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)
Table 43. Processor Modules

pm_blocker

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

pm_buffer

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

pm_evcorr

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

pm_filter

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

pm_hmac

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

pm_hmac_check

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

pm_norepeat

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

pm_null

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

pm_pattern

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

pm_transformer

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

pm_ts

nxlog-5.4.7313-1.aix7.1.ppc.rpm (AIX 7.1) nxlog-5.4.7313_amzn2_aarch64.rpm (AmazonLinux 2) nxlog-5.4.7313_rhel6_x86_64.rpm (CentOS 6, RHEL 6) nxlog-5.4.7313_rhel7_x86_64.rpm (CentOS 7, RHEL 7) nxlog-5.4.7313_rhel8_x86_64.rpm (CentOS 8, RHEL 8) nxlog-5.4.7313_generic_deb_amd64.deb (DEB Generic) nxlog-5.4.7313_debian10_amd64.deb (Debian Buster) nxlog-5.4.7313_debian8_amd64.deb (Debian Jessie) nxlog-5.4.7313_debian9_amd64.deb (Debian Stretch) nxlog-5.4.7313_fbsd_x86_64.tgz (FreeBSD 11) nxlog-5.4.7313_macos_x86_64.pkg (MacOS) nxlog-5.4.7313_windows_x64.msi (Microsoft Windows 64bit) nxlog-5.4.7313_nano.zip (Microsoft Windows Nano) nxlog-5.4.7313_generic_x86_64.rpm (RPM Generic) nxlog-5.4.7313_sles12_x86_64.rpm (SLES 12) nxlog-5.4.7313_sles15_x86_64.rpm (SLES 15) nxlog-5.4.7313_solaris_x86.pkg.gz (Solaris 10 i386) nxlog-5.4.7313_solaris_sparc.pkg.gz (Solaris 10 sparc) nxlog-5.4.7313_ubuntu16_amd64.deb (Ubuntu 16.04) nxlog-5.4.7313_ubuntu18_amd64.deb (Ubuntu 18.04) nxlog-5.4.7313_ubuntu20_amd64.deb (Ubuntu 20.04)

Deployment

5. Supported platforms

The following operating systems and architectures are fully supported, except as noted. For more information about types of log collection that are available for specific platforms, see the corresponding chapter in OS Support.

Table 44. 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

RedHat Enterprise Linux 8

x86 (see note), x86_64

CentOS Linux 6

x86 (see note), x86_64

CentOS Linux 7

x86 (see note), x86_64

CentOS Linux 8

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

Debian GNU/Linux 10 (Buster)

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

Ubuntu 20.04 (Focal Fossa)

x86 (see note), x86_64

SUSE Linux Enterprise Server 12

x86 (see note), x86_64

SUSE Linux Enterprise Server 15

x86 (see note), x86_64

Other distributions

(See note)

Note

NXLog also provides generic packages compiled against glibc 2.5 to support RPM based legacy distributions such as Redhat 5.11 and SLES 11 on both 32 and 64 bit hardware.

The packages are named as nxlog-X.XX.XXXX_generic_glibc2.5_rpm_x86_64.rpm and nxlog-X.XX.XXXX_generic_glibc2.5_rpm_i386.rpm respectively and available in the beta version as well.

For a listing of GNU/Linux-related log sources, see GNU/Linux.

Table 45. 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

For listings of BSD-related log sources, see FreeBSD and OpenBSD.

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 46. Supported Windows platforms
Operating System Architectures

Microsoft Windows Server 2008

x86_64

Microsoft Windows Server 2012

x86_64

Microsoft Windows Server 2016 (Certified)

x86_64

Microsoft Windows Server 2019 (Certified)

x86_64

Microsoft Windows Nano Server

x86_64 (see note)

Microsoft Windows Vista

x86_64

Microsoft Windows 7

x86_64

Microsoft Windows 8

x86_64

Microsoft Windows 10

x86_64

For a listing of Windows-related log sources, see Microsoft Windows.

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 47. Other supported platforms
Operating System Architectures

Apple OS X 10.11 (El Capitan)

x86_64

Apple macOS 10.12 (Sierra)

x86_64

Apple macOS 10.13 (High Sierra)

x86_64

Apple macOS 10.14 (Mojave)

x86_64

Apple macOS 10.15 (Catalina)

x86_64

Apple macOS 11 (Big Sur)

ARM64

Docker

x86_64

IBM AIX 7.1

PowerPC

IBM AIX 7.2

PowerPC

Oracle Solaris 10

x86, SPARC

Oracle Solaris 11

x86, SPARC

For log sources of the above platforms, see Apple macOS, IBM AIX, and Oracle Solaris.

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

Table 48. 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. Product life cycle

NXLog Enterprise Edition, NXLog Community Edition, and NXLog Manager all use the versioning scheme X.Y.Z.

  • X denotes the MAJOR release version. Long-term support is provided for each major release when applicable.

  • Y denotes the MINOR version. Minor releases provide backward compatible enhancements and features during the lifetime of a major release.

  • Z denotes the REVISION NUMBER. Hot-fix revisions may be released within the same minor version.

Upgrades within the same major version are backward compatible. Features and changes that may not be backward compatible are added to major releases only.

For supported products, the end-of-life (EOL) date is at least one year after the next major version is released.

Table 49. End-of-Life for NXLog products
NXLog Product End-of-Life

NXLog Enterprise Edition 3.x

2019-01-01

NXLog Enterprise Edition 4.x

The release date of NXLog Enterprise Edition 6.0

NXLog Enterprise Edition 5.x

The release date of NXLog Enterprise Edition 7.0

NXLog Manager 4.x

2019-01-01

NXLog Manager 5.x

One year after the release of NXLog Manager 6.0

NXLog Community Edition

No official support

7. System requirements

In order to function efficiently, each NXLog product requires a certain amount of available system resources on the host system. The table below provides 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 with the NXLog Manager’s System Requirements cumulatively for systems running both NXLog Enterprise Edition and NXLog Manager.
Table 50. NXLog Enterprise Edition requirements
Minimum Recommended

Processor cores

1

2

Memory/RAM

60 MB

250 MB

Disk space

50 MB

150 MB

8. NXLog digital signature verification

Security regulations for organizations may require verifying the identity of software sources as well as the integrity of the software obtained from those software sources. In order to facilitate such regulation compliance, and to guarantee the authenticity and integrity of downloaded installer files, NXLog installer packages are digitally signed.

In some cases, like with RPM packages, a public key is required to verify the digital signature. For this, the Public PGP Key can be downloaded from NXLog’s public contrib repository.

8.1. Signature verification for DEB packages

The verification of the NXLog DEB packages requires the debsig-verify package to be installed.

Note

For simplicity, this section explains how to verify NXLog packages using a shell script from the NXLog contrib repository.

The details of the verification process without the script application can be found in the HOWTO: GPG sign and verify deb packages and APT repositories section of the Packagecloud website.

  1. To install debsig-verify, run the following command:

    # apt install debsig-verify
  2. Download the contents of the deb-verify directory from the NXLog contrib repository.

  3. Run the deb-verify script with the path to the NXLog deb-package as its parameter. For example, it may be the following command:

    # ./deb-verify ../nxlog-4.8.4835_ubuntu20_amd64.deb
  4. The script output should look similar to this:

    Verified package from 'Nxlog package' (Nxlog)

8.2. Signature verification for RPM packages

The procedure is the same for SUSE Linux Enterprise Server, Red Hat Enterprise Linux, and CentOS. However, there is a slight difference in the output messages as noted below.

Note
This example uses the generic RPM package. Change the name of the package to match the package used in your environment.
  1. Import the downloaded NXLog public key into the RPM with the following command:

    # rpm --import nxlog-pubkey.asc
  2. Verify the package signature with the imported public key using the following command:

    # rpm --checksig nxlog-{productVersion}_generic_rpm_x86_64.rpm.
  3. The output should look similar to the following examples.

    On SUSE Linux Enterprise Server:

    nxlog-{productVersion}_generic_rpm_x86_64.rpm: digests signatures OK

    On Red Hat Enterprise Linux and CentOS:

    nxlog-{productVersion}_generic_rpm_x86_64.rpm: rsa sha1 (md5) pgp md5 OK

8.3. Signature verification for Windows

To verify the installer package for Windows before installing, follow these steps:

  1. Right-click the downloaded installer file, then select Properties.

  2. Select the Digital Signatures tab.

    NXLog is displayed as a signer for the installer. The algorithm used for the signature and the timestamp is also visible.

  3. In the Signature list, select NXLog, then click Details to display additional information about the signature.

    In the General tab, the signer information and countersignatures are displayed. Click on View Certificate to display the certificate or select the Advanced tab to display signature details.

8.4. Signature verification on macOS

To verify the installer package for macOS before installing, follow these steps:

  1. Double-click the installer package.

  2. Click on the padlock icon in the upper-right corner of the installer window to display information about the certificate.

    For valid packages a green tick is displayed, indicating the validity of the certificate.

  3. Click on the triangle next to Details to display additional information about the certificate.

9. Red Hat Enterprise Linux & CentOS

This topic describes the steps to install and upgrade NXLog on Red Hat Enterprise Linux and its derivatives.

9.1. Installing

First, download the appropriate NXLog installation 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 the correct file for the target platform.

    Table 51. Available RHEL/CentOS Files
    Platform Archive

    RHEL 6 or CentOS 6

    nxlog-5.4.7313_rhel6_x86_64.tar.bz2

    RHEL 7 or CentOS 7

    nxlog-5.4.7313_rhel7_x86_64.tar.bz2

    RHEL 8 or CentOS 8

    nxlog-5.4.7313_rhel8_x86_64.tar.bz2

    Generic RPM

    nxlog-5.4.7313_generic_rpm_x86_64.rpm

    Note

    The RHEL 6, RHEL 7 and RHEL 8 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.

  3. Transfer the file to the target server using SFTP or a similar secure method.

  4. Log in to the target server and extract the contents of the archive (unless you are using the generic package):

    # tar -xf nxlog-5.4.7313_rhel7.x86_64.tar.bz2
    Table 52. Packages in a RHEL Archive
    Package Description

    nxlog-5.4.7313_rhel7.x86_64.rpm

    The main NXLog package

    nxlog-checkpoint-5.4.7313_rhel7.x86_64.rpm

    Provides the im_checkpoint module

    nxlog-dbi-5.4.7313_rhel7.x86_64.rpm (available for RHEL 6 and RHEL 7 only)

    Provides the im_dbi and om_dbi modules

    nxlog-java-5.4.7313_rhel7.x86_64.rpm

    Provides the xm_java, im_java, and om_java modules

    nxlog-kafka-5.4.7313_rhel7.x86_64.rpm

    Provides the im_kafka and om_kafka modules

    nxlog-odbc-5.4.7313_rhel7.x86_64.rpm

    Provides the im_odbc and om_odbc modules

    nxlog-pcap-5.4.7313_rhel7.x86_64.rpm

    Provides the im_pcap module

    nxlog-perl-5.4.7313_rhel7.x86_64.rpm

    Provides the xm_perl, im_perl, and om_perl modules

    nxlog-python-5.4.7313_rhel7.x86_64.rpm

    Provides the xm_python, im_python, and om_python modules

    nxlog-ruby-5.4.7313_rhel7.x86_64.rpm

    Provides the xm_ruby, im_ruby, and om_ruby modules

    nxlog-systemd-5.4.7313_rhel7.x86_64.rpm

    Provides the im_systemd module

    nxlog-wseventing-5.4.7313_rhel7.x86_64.rpm

    Provides the im_wseventing module

    nxlog-zmq-5.4.7313_rhel7.x86_64.rpm

    Provides the im_zmq and om_zmq modules

  5. Optional: To change the NXLog user and group for the installation, set the NXLOG_USER and NXLOG_GROUP environment variables. During installation a new user and and a new group will be created based on these environment variables. They will be used for User and Group directives in nxlog.conf, and 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
  6. Download the public key file from the NXLog’s public contrib repository and import it to the RPM database.

    # rpm --import nxlog-pubkey.asc
    Note

    For more details about the package verification, see the Signature Verification for RPM Packages section in the User Guide.

  7. If you are installing the nxlog-zmq package, enable the EPEL repository so ZeroMQ dependencies will be available:

    # yum install -y epel-release
  8. Use yum to install the required NXLog packages (or the generic package) and dependencies.

    # yum install nxlog-5.4.7313_rhel7.x86_64.rpm
  9. 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.

  10. Verify the configuration file syntax.

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

    # service nxlog start
  12. Check that the NXLog service is running.

    # service nxlog status
    nxlog (pid  9218) is running...

9.2. Upgrading

To upgrade an NXLog installation to the latest release, or to replace a trial installation of NXLog Enterprise Edition with a licensed copy, use yum as in the installation instructions above. It is recommended to make a backup of the configuration files before starting this process.

# yum install nxlog-5.4.7313_rhel7.x86_64.rpm
Note
The same procedure is used to upgrade from NXLog Community Edition to NXLog Enterprise Edition. However, in such case, you will need to manually copy the previous configuration to the new installation.
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 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!

# yum remove 'nxlog-*'
Note
This procedure may not remove all files that were created while configuring NXLog. Likewise, any files created as a result of NXLog’s logging operations will not be removed. To find these files, examine the configuration files that were used with NXLog and check the installation directory (/opt/nxlog).

10. Debian & Ubuntu

This topic describes the steps to install and upgrade NXLog on Debian GNU/Linux and its derivatives.

10.1. Installing

First, download the appropriate NXLog installation 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 the correct file for the target platform.

    Table 53. Available Debian/Ubuntu Archives
    Platform Archive

    Debian 8 (Jessie)

    nxlog-5.4.7313_debian8_amd64.tar.bz2

    Debian 9 (Stretch)

    nxlog-5.4.7313_debian9_amd64.tar.bz2

    Debian 10 (Buster)

    nxlog-5.4.7313_debian10_amd64.tar.bz2

    Ubuntu 16.04 (Xenial Xerus)

    nxlog-5.4.7313_ubuntu16_amd64.tar.bz2

    Ubuntu 18.04 (Bionic Beaver)

    nxlog-5.4.7313_ubuntu18_amd64.tar.bz2

    Ubuntu 20.04 (Focal Fossa)

    nxlog-5.4.7313_ubuntu20_amd64.tar.bz2

    Generic DEB

    nxlog-5.4.7313_generic_deb_amd64.deb

    Note

    The NXLog installer packages are digitally signed. For more details about package verification, see the Signature Verification for DEB Packages section in the User Guide.

  3. Transfer the file to the target server using SFTP or a similar secure method.

  4. Log in to the target server and extract the contents of the archive (unless you are using the generic package):

    # tar -xjf nxlog-5.4.7313_debian9_amd64.tar.bz2
    Table 54. Packages in a Debian/Ubuntu Archive
    Package Description

    nxlog-5.4.7313_amd64.deb

    The main NXLog package

    nxlog-checkpoint-5.4.7313_amd64.deb

    Provides the im_checkpoint module

    nxlog-dbi-5.4.7313_amd64.deb

    Provides the im_dbi and om_dbi modules

    nxlog-java-5.4.7313_amd64.deb

    Provides the xm_java, im_java, and om_java modules

    nxlog-kafka-5.4.7313_amd64.deb

    Provides the im_kafka and om_kafka modules

    nxlog-odbc-5.4.7313_amd64.deb

    Provides the im_odbc and om_odbc modules

    nxlog-pcap-5.4.7313_amd64.deb

    Provides the im_pcap module

    nxlog-perl-5.4.7313_amd64.deb

    Provides the xm_perl, im_perl, and om_perl modules

    nxlog-python-5.4.7313_amd64.deb

    Provides the xm_python, im_python, and om_python modules

    nxlog-ruby-5.4.7313_amd64.deb

    Provides the xm_ruby, im_ruby, and om_ruby modules

    nxlog-systemd-5.4.7313_amd64.deb

    Provides the im_systemd module

    nxlog-wseventing-5.4.7313_amd64.deb

    Provides the im_wseventing module

    nxlog-zmq-5.4.7313_amd64.deb

    Provides the im_zmq and om_zmq modules

  5. Install the NXLog package(s) and their dependencies.

    1. Optional: To change the NXLog user and group for the installation, set the NXLOG_USER and NXLOG_GROUP environment variables. During installation a new user and and a new group will be created based on these environment variables. They will be used for User and Group directives in nxlog.conf, and 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 dpkg to install the required NXLog packages (or the generic package, if you are using that).

      # dpkg -i nxlog-5.4.7313_amd64.deb
    3. If dpkg returned errors about uninstalled dependencies, use apt-get to install them and complete the NXLog installation.

      # apt-get -f install
  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.

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

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

    # 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
    [...]

10.2. Upgrading

To upgrade an NXLog installation to the latest release, or to replace a trial installation of NXLog Enterprise Edition with a licensed copy, use dpkg as explained in the installation instructions above. It is recommended to make a backup of the configuration files before starting this process.

# dpkg -i nxlog-5.4.7313_amd64.deb
Note
The same procedure is used to upgrade from NXLog Community Edition to NXLog Enterprise Edition. However, in such case, you will need to manually copy the previous configuration to the new installation.
Note

When upgrading to a licensed copy with additional NXLog trial packages installed, such as nxlog-trial-python, use dpkg -i --auto-configure.

# dpkg -i --auto-configure nxlog-5.4.7313_amd64.deb \
  nxlog-python_5.4.7313_amd64.deb

Make sure to edit this example to include all nxlog-trial packages that are actually installed.

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

# 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.

10.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!

# 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).

11. SUSE Linux Enterprise Server

This topic describes the steps to install and upgrade NXLog on SUSE Linux Enterprise Server.

11.1. Installing

First, 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, download the correct archive for your system.

    Table 55. Available SLES Files
    Platform Archive

    SUSE Linux Enterprise Server 12

    nxlog-5.4.7313_sles12_x86_64.tar.bz2

    SUSE Linux Enterprise Server 15

    nxlog-5.4.7313_sles15_x86_64.tar.bz2

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

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

    # tar xjf nxlog-5.4.7313_sles15_x86_64.tar.bz2
    Table 56. Packages in an SLES Archive
    Package Description

    nxlog-5.4.7313_sles15.x86_64.rpm

    The main NXLog package

    nxlog-checkpoint-5.4.7313_sles15.x86_64.rpm

    Provides the im_checkpoint module

    nxlog-dbi-5.4.7313_sles15.x86_64.rpm

    Provides the im_dbi and om_dbi modules

    nxlog-java-5.4.7313_sles15.x86_64.rpm

    Provides the xm_java, im_java, and om_java modules

    nxlog-kafka-5.4.7313_sles15.x86_64.rpm

    Provides the im_kafka and om_kafka modules

    nxlog-odbc-5.4.7313_sles15.x86_64.rpm

    Provides the im_odbc and om_odbc modules

    nxlog-pcap-5.4.7313_sles15.x86_64.rpm

    Provides the im_pcap module

    nxlog-perl-5.4.7313_sles15.x86_64.rpm

    Provides the xm_perl, im_perl, and om_perl modules

    nxlog-python-5.4.7313_sles15.x86_64.rpm

    Provides the xm_python, im_python, and om_python modules

    nxlog-ruby-5.4.7313_sles15.x86_64.rpm

    Provides the xm_ruby, im_ruby, and om_ruby modules

    nxlog-systemd-5.4.7313_sles15.x86_64.rpm

    Provides the im_systemd module

    nxlog-wseventing-5.4.7313_sles15.x86_64.rpm

    Provides the im_wseventing module

    nxlog-zmq-5.4.7313_sles15.x86_64.rpm

    Provides the im_zmq and om_zmq modules

  5. Optional: To change the NXLog user and group for the installation, set the NXLOG_USER and NXLOG_GROUP environment variables. During installation a new user and and a new group will be created based on these environment variables. They will be used for User and Group directives in nxlog.conf, and 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
  6. Download the public key file from the NXLog’s public contrib repository and import it to the RPM database.

    # rpm --import nxlog-pubkey.asc
    Note

    For more details about the package verification, see the Signature Verification for RPM Packages section in the User Guide.

  7. Install the required NXLog packages and their dependencies (this example installs the main NXLog package only).

    # zypper install nxlog-5.4.7313_sles15.x86_64.rpm
  8. 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.

  9. Verify the configuration file syntax.

    # /opt/nxlog/bin/nxlog -v
    2020-10-17 08:05:06 INFO configuration OK
  10. Start the service using the service command:

    # systemctl start nxlog.service
  11. Check that the NXLog service is running with the systemctl command.

    # systemctl | grep nxlog
    nxlog.service
    loaded active running  NXLog daemon

11.2. Upgrading

To update an NXLog installation to the latest release, use zypper as in the installation instructions above. It is recommended to make a backup of the configuration files before starting this process.

# zypper install nxlog-5.4.7313_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.

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, 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!

# zypper remove 'nxlog*'
Note
This procedure may not remove all files that were created while configuring NXLog. Likewise, any files created as a result of NXLog’s logging operations will not be removed. To find these files, examine the configuration files that were used with NXLog and check the installation directory (/opt/nxlog).

12. FreeBSD

This topic describes the steps to install and upgrade NXLog on FreeBSD.

12.1. Installing

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

First, 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-5.4.7313_fbsd_x86_64.tgz package.

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

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

  5. Optional: To change the NXLog user and group for the installation, set the NXLOG_USER and NXLOG_GROUP environment variables. During installation a new user and and a new group will be created based on these environment variables. They will be used for User and Group directives in nxlog.conf, and 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
  6. Install NXLog with the pkg(7) utility.

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

    The installation path 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.

  7. 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 summary.

  8. Verify the configuration file syntax.

    # /opt/nxlog/bin/nxlog -v
    2017-03-17 08:05:06 INFO configuration OK
  9. 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

12.2. Upgrading

To upgrade NXLog, first remove the old version and then install the new version. Make a backup of the configuration files before starting this process to be able to use them with the new installation.

  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-5.4.7313-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-5.4.7313-fbsd...
    [1/1] Deleting files for nxlog-5.4.7313-fbsd: 100%
  2. Install the new version as described in the installation instructions above.

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

    # service nxlog restart

12.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-5.4.7313-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-5.4.7313-fbsd...
    [1/1] Deleting files for nxlog-5.4.7313-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

13. OpenBSD

This topic describes the steps to install and upgrade NXLog on OpenBSD.

13.1. Installing

NXLog is available as precompiled packages for OpenBSD upon request. Follow these steps to install NXLog.

  1. Contact us to request the OpenBSD packages.

  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. During installation a new user and and a new group will be created based on these environment variables. They will be used for User and Group directives in nxlog.conf, and 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-5.4.7313-obsd6_2_x86_64.tgz
    nxlog-5.4.7313-obsd6_2: ok
    The following new rcscripts were installed: /etc/rc.d/nxlog
    See rcctl(8) for details.

    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.

  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 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)

13.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 5.4.7313. It is recommended to make a backup of the configuration files before starting this process.

# pkg_add -U nxlog-5.4.7313-obsd6_2_x86_64.tgz
nxlog-3.0.1865-obsd6_2->5.4.7313-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-5.4.7313-obsd6_2_x86_64.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.

13.3. Uninstalling

To uninstall NXLog, follow these steps.

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

    # pkg_delete nxlog
    nxlog-5.4.7313-obsd6_2: ok
    Read shared items: ok
    --- -nxlog-5.4.7313-obsd6_2 -------------------

    The uninstall script will remove NXLog along with the user, group, and files. The pkg_delete utility will not remove new files or modified configuration 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

14. Microsoft Windows

This topic describes how to install and upgrade NXLog on Microsoft Windows. It details the procedure for installing NXLog using an MSI and explains how to install NXLog via Group Policy.

14.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, choose the correct package for your system.

    Table 57. Available Windows installers
    Platform Package

    Microsoft Windows, 64-bit

    nxlog-5.4.7313_windows_x64.msi

    Important
    Starting from versions 5.x, the 32-bit version of NXLog is no longer supported. Only versions 4.x and older provide 32-bit installers.
    Warning
    Using the 32-bit installer to install NXLog on a 64-bit system is unsupported and not recommended. To override the installer check and proceed anyway, use the SKIP_X64_CHECK=1 property (for example, msiexec /i nxlog-4.x.xxxx_windows_x86.msi /q SKIP_X64_CHECK=1).
Note

The NXLog installer packages are digitally signed. For more details about package verification, see the Signature Verification for Windows section in the User Guide.

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

See also the MSI for NXLog agent setup add-on, which provides an example MSI package for bootstrapping NXLog agents.

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.

14.1.1. Installing interactively

  1. Run the installer by double-clicking the MSI file. After accepting the license agreement an option for choosing an alternate installation directory is presented. Click Install, to start the installation. Click Finish once it has completed which will result in the README.txt file being opened by Notepad.

  2. Configure NXLog by editing nxlog.conf (by default, C:\Program Files\nxlog\conf\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.

  3. The configuration file syntax can be checked by running the NXLog executable with the -v (verify) option.

    > "C:\Program Files\nxlog\nxlog.exe" -v
    2017-03-17 08:05:06 INFO configuration OK
  4. Start NXLog by opening the Service Manager, finding the nxlog service in the list, and starting it. To run it in the foreground instead, invoke the nxlog.exe executable with the -f command line argument.

  5. Open the NXLog log file (by default, C:\Program Files\nxlog\data\nxlog.log) 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.

14.1.2. Installing with msiexec

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

> msiexec /i nxlog-5.4.7313_windows_x64.msi /q

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

> msiexec /i nxlog-5.4.7313_windows_x64.msi /qb

To specify a non-default installation directory, use the INSTALLDIR property.

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

14.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. 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-5.4.7313_windows_x64.msi, managed.conf, and CA certificate agent-ca.pem. If not using NXLog Manager, use a custom nxlog.conf instead of managed.conf, omit the CA certificate, and include any other files required by the configuration.

      NOTE

      The file managed.conf is located in the C:\Program Files\nxlog\conf\nxlog.d\ directory. Prior to NXLog version 5, it had the name log4ensics.conf and was located in the C:\Program Files\nxlog\conf\ directory.

  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-5.4.7313_windows_x64.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 remote computers.

    3. Select the Assigned deployment method.

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

    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\managed.conf or \\WINSERV1\nxlog-dist\agent-ca.pem).

    4. Type in the destination path for the file (for example, C:\Program Files\nxlog\conf\nxlog.d\managed.conf or C:\Program Files\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 managed.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:

14.2. Upgrading

To upgrade NXLog to the latest release, or to replace a trial installation of NXLog Enterprise Edition with a licensed copy, follow these steps. It is recommended to make a backup of the configuration files before starting this process.

Note
To upgrade from NXLog Community Edition to NXLog Enterprise Edition, you need to uninstall NXLog Community Edition and then follow the instructions to install NXLog Enterprise Edition. Make a backup of the configuration files before uninstalling NXLog Community Edition, you will need to copy these manually to the new installation.
  1. Run the new MSI installer as described in the Installing section (interactively, with Msiexec, or via Group Policy). The installer will detect the presence of the previous version and perform the upgrade within the current installation directory.

    Note
    To upgrade from v3.x, uninstall the previous version before installing the new version (see Uninstalling). This is necessary to transition from a per-user to a per-machine installation. This check can be skipped by passing the SKIP_PERUSER_CHECK property (such as msiexec /i nxlog-5.4.7313_windows_x64.msi /q SKIP_PERUSER_CHECK=1). Note that using SKIP_PERUSER_CHECK is unsupported and not recommended.
    Note
    If the Services console (services.msc) is running, the installer may request the computer to be rebooted or display a permission denied error. Please ensure that the Services console is not running before attempting an upgrade.
  2. Start the upgraded NXLog service via the Services console (services.msc) or by rebooting the system. Check the log file (by default, C:\Program Files\nxlog\data\nxlog.log) to verify 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.

14.3. Uninstalling

NXLog can be uninstalled in several different ways.

  • From the Control Panel (not discussed here).

  • By using msiexec and the original NXLog MSI.

  • Via the GPO it was originally deployed with in an AD Domain environment.

  • Via a downloadable batch script.

In addition to the above, NXLog provides a method to remove the Windows Registry traces after uninstalling.

Warning
NXLog v3.x installers will remove log4ensics.conf and nxlog.conf during the uninstallation process, even if they have been modified. If these files need to be preserved, they should be backed up to another location before uninstalling NXLog v3.x.

14.3.1. Uninstalling with msiexec

Uninstall NXLog using msiexec with the following command:

> msiexec /x nxlog-5.4.7313_windows_x64.msi /qb
Note
This procedure may not remove all files that were created while configuring NXLog. Likewise, any files created as a result of NXLog’s logging operations will not be removed (except for v3.x installers as noted above). You may wish to remove the installation directory (by default, C:\Program Files\nxlog) once the uninstallation process has completed.

14.3.2. Uninstalling via Group Policy

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.

14.3.3. Remove the traces of NXLog

After uninstalling NXLog there will be some traces left in the Windows Registry. NXLog provides a list of Windows Registry entries to be removed in a form of a .reg file. Download the reg-entries.reg file from the public contrib repository of NXLog. It needs to be used as an argument for the Registry Editor regedit.exe.

To remove the possibly left Windows Registry entries, use the following command:

> regedit.exe /S reg-entries.reg

14.3.4. Uninstalling with the uninstall-x64.bat script

The script combines the steps of the Uninstalling with msiexec and Remove the traces of NXLog procedures as well as prompts for the removal of the installation directory.

To complete the procedure, the following files need to be present in the same directory:

  • uninstall-x64.bat - The main script.

  • reg-entries.reg - The list of Windows Registry entries to remove.

  • The exact version of the MSI installer, with which NXLog was installed.

The necessary files can be downloaded from the windows-uninstall directory of NXLog’s public contrib repository.

To start the automatic uninstall and trace removal procedure, use the following command:

> uninstall-x64.bat nxlog-{productVersion}_windows_x64.msi

The Readme.MD file in the public contrib repository explains details of the script operation.

14.4. Configure with a custom MSI

NXLog can be configured using a custom built MSI package. The MSI will install the CA certificate and chosen custom configuration files. The package can be deployed alongside the NXLog MSI. For more information, see the MSI for NXLog agent setup add-on.

Note
Deployment via Group Policy already provides a way to deploy the configuration files. For this reason, it might be more preferable to configure NXLog via GPO instead of creating a custom MSI as described in this section.

15. Microsoft Nano Server

This topic describes how to install and upgrade NXLog on a Microsoft Windows Nano Server. It also includes instructions on how to install using a custom directory and how to change the service startup type.

15.1. Installing

Follow these steps to deploy NXLog on a Microsoft 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.

First, 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-5.4.7313_nano.zip.

  3. 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-5.4.7313_nano.zip -DestinationPath 'C:\Program Files\nxlog'
  4. To register NXLog as a service, navigate to the installation directory and execute the following.

    PS C:\Program Files\nxlog> .\nxlog.exe -i
  5. 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.
  6. 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.

15.1.1. Installing in a Custom Directory

This section deals with installation options outside the typical scenario.

Note

The following installation options require altering the Windows Registry. Incorrect modifications could potentially render the system unusable. Always double check the commands and ensure it will be possible to revert to a known working state before altering the registry.

NXLog can be installed in a non-default location on Nano Server.

  1. Follow the same installation procedure outlined above, 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 update the location of both the NXLog executable and the configuration file. For example, if NXLog is installed in 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 be edited to reflect this change to a non-default installation directory. Make sure define ROOT points to the correct location.

15.1.2. Service Startup Type

The service Startup type of newer versions of NXLog defaults 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
Note

This command requires altering the Windows Registry. Incorrect modifications could potentially render the system unusable. Always double check the commands and ensure it will be possible to revert to a known working state before altering the registry.

15.2. Upgrading

To upgrade NXLog to the latest release, follow these steps. It is recommended to make a backup of the configuration files before starting this process.

  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, managed.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-5.4.7313_nano.zip -DestinationPath 'C:\Program Files\nxlog'
  4. Restore any configuration files and certificates.

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

15.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. Delete the NXLog directory.

16. Apple macOS

This topic describes the steps to install and upgrade NXLog on Apple macOS.

16.1. Installing

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

First, 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 correct package for your system.

    Table 58. Available macOS Packages
    Platform Package

    macOS 10.14 and earlier (pre-Catalina)

    nxlog-5.4.7313_macos-precatalina_x86_64.pkg

    macOS 10.15 (Catalina)

    nxlog-5.4.7313_macos_x86_64.pkg

    macOS 11 (Big Sur)

    nxlog-5.4.7313_macos_arm64.pkg

    Note

    The NXLog installer packages are digitally signed. For more details about package verification, see the Signature Verification on macOS section in the User Guide.

  3. Optional: To change the NXLog user and group for the installation, create a /tmp/.nxlog file with the following command. During installation a new user and a new group will be created using the values specified in this command. They will be used for User and Group directives in nxlog.conf, and 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
  4. Install the NXLog package. You can do the installation interactively or with the command line installer.

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

      As of version 4.5 the installer should be signed with our developer certificate. If you see the following message with an earlier version, go to System Preferences  Security & Privacy and click Open Anyway, then follow the instructions shown by the installer.

      "nxlog-5.4.7313_macos.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-5.4.7313_macos.pkg -target /
      Password:
      installer: Package name is nxlog-5.4.7313-macos-x86
      installer: Upgrading at base path /
      installer: The install 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/.

  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 macOS, see the Apple macOS summary.

  6. Verify the configuration file syntax.

    $ sudo /opt/nxlog/bin/nxlog -v
    2017-03-17 08:05:06 INFO configuration OK
  7. 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
  8. To permanently stop NXLog, the service must be unloaded.

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

16.2. Upgrading

To upgrade NXLog, follow the installation instructions.

The installation script will not modify the existing configuration files, however it is recommended to make a backup of the configuration files before starting this process. After the installation has completed, NXLog will restart automatically.

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

16.3. Uninstalling

To properly uninstall NXLog, follow these steps.

  1. Start the uninstaller script as user root.

    Warning
    This will remove custom configuration files, certificates, and any 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 the -n switch (instead of -y) 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 custom configuration files, certificates, and any 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

17. Docker

This topic describes the steps to install and upgrade NXLog on a Docker image.

17.1. Installing

First, 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-5.4.7313_docker.tar.gz archive (which is based on CentOS 7).

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

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

    $ tar -xzf nxlog-5.4.7313_docker.tar.gz
    Table 59. Files in the Docker Archive
    Package Description

    Dockerfile

    The main NXLog Docker definition file

    README.md

    Readme for building NXLog Docker image

    nxlog-5.4.7313_rhel7_x86_64.tar.bz2

    The NXLog RHEL7 package

  5. 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/nxlog.d directory. The default NXLog configuration file includes all .conf files found in this directory.

  6. 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> .
  7. Run the container using the docker command.

    $ docker run -p <HostPort>:<ContainerPort> -d nxlog
  8. 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
    [...]

17.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.

17.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>

18. IBM AIX

This topic describes the steps to install and upgrade NXLog on IBM AIX.

18.1. Installing

First, 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-5.4.7313_aix_ppc.rpm package.

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

  4. 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. During installation a new user and and a new group will be created based on these environment variables. They will be used for User and Group directives in nxlog.conf, and 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-5.4.7313_aix_ppc.rpm
  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 AIX, see the IBM AIX summary.

  6. Verify the configuration file syntax.

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

    # ./init start

18.2. Upgrading

To update an NXLog installation to the latest release, use rpm as in the installation instructions above. It is recommended to make a backup of the configuration files before starting this process.

# rpm -Uvh nxlog-5.4.7313_aix_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.

18.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 while configuring NXLog. Likewise, any files created as a result of NXLog’s logging operations will not be removed. To find these files, examine the configuration files that were used with NXLog and check the installation directory (/opt/nxlog).

19. Oracle Solaris

This topic describes the steps to install and upgrade NXLog on Oracle Solaris.

19.1. Installing

First, 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 60. Available Solaris Files
    Platform Archive

    Solaris 10/11 x86 archive

    nxlog-5.4.7313_solaris_x86.pkg.gz

    Solaris 10/11 SPARC archive

    nxlog-5.4.7313_solaris_sparc.pkg.gz

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

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

    $ gunzip nxlog-5.4.7313_solaris_sparc.pkg.gz
  5. 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. During installation a new user and and a new group will be created based on the names specified. They will be used for User and Group directives in nxlog.conf, and 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
  6. Install the NXLog package.

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

      $ sudo pkgadd -d nxlog-5.4.7313.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-5.4.7313.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=
  7. 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.

  8. Verify the configuration file syntax.

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

    $ svcs nxlog
     online     12:40:37 svc:system/nxlog:default
  10. 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
Note
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).

19.2. Upgrading

19.2.1. Updating to a Minor Release

To update an NXLog installation to the latest minor 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-5.4.7313.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

19.2.2. Upgrading 4.x to 5.x

To upgrade an NXLog 4.x installation to a 5.x release, remove the old version, install the new version, and perform additional manual configuration steps.

  1. Perform steps 1-3 from Updating to a Minor Release. Do not use restore (step 4).

  2. Manually migrate the necessary parts of the backup content to the new installation.

    From NXLog version 5.0, the configuration file log4ensics.conf changed to managed.conf and it is in a different location. This file contains NXLog Manager related configuration.

    Note
    nxlog.conf shipped with v5.0 has NXLog Manager integration disabled by default.
    Table 61. Configuration to migrate
    v 4.x v 5.0

    /opt/nxlog-backup-date_time/lib/nxlog/log4ensics.conf

    /opt/nxlog/etc/nxlog.d/managed.conf

    /opt/nxlog-backup-date_time/nxlog/cert/*

    /opt/nxlog/var/lib/nxlog/cert/

  3. Optional: To discard the backup files, remove the backup directory.

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

19.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 while configuring NXLog. Likewise, any files created as a result of NXLog’s logging operations will not be removed. To find these files, examine the configuration files that were used with NXLog and check the installation directory (/opt/nxlog).

20. Hardening NXLog

20.1. Running under a non-root user on Linux

NXLog can be configured to improve security by running as a non-root user. The User and Group global directives specify the user and group for the NXLog process to run as. On Linux installations, NXLog is configured by default to run as 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 grant only the required privileges and to avoid running NXLog as root. See the following sections for more information.

20.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.

20.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.

Note
In certain rare conditions, such as when NXLog is initially started with an empty configuration before receiving a configuration update from NXLog Manager, the required capabilities might not be set automatically.
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. This can be configured with the capabilities directive.

Example 9. Setting Linux capabilities

This capability directive configuration sets the CAP_NET_BIND_SERVICE capability.

Capabilities cap_net_bind_service+ep

This capability directive configuration sets both the CAP_NET_BIND_SERVICE and the CAP_NET_RAW capabilities.

Capabilities "cap_net_bind_service,cap_net_raw=+ep"

20.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.

Note
In certain rare conditions, such as when NXLog is initially started with an empty configuration before received a configuration update from NXLog Manager, the required capabilities might not be set automatically.
Set the capability manually

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

20.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 a 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.

20.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.

20.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.

20.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.

20.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. Using permissive mode reduces system security, it is recommended that this mode is only used 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 10. 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 11. 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.

20.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), expand Local Users and Groups and right-click on Users. 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), expand Local Policies, then select 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 Manage auditing and security log policy also.

  9. Open the Local Users and Groups console (lusrmgr.msc), click on Groups and add the new user to the Event Log Readers group. This step is required for collecting events from the Security channel.

  10. If the agent is managed by NXLog Manager, the user also needs to be added to the Performance Monitor Users group.

  11. 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
  12. In the Services console (services.msc), right-click the nxlog service and select Restart.

    Restarting the nxlog service
  13. 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-5.4.7313 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 Event Log:

WARNING [im_msvistalog|windows] failed to subscribe to msvistalog events,access denied [error code: 5]: Access is denied.

or

WARNING [im_msvistalog|windows] ignoring source as it cannot be subscribed to (error code: 5)

See the Windows Event Log error section of the Troubleshooting chapter for how to resolve this error.

21. 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.

21.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

21.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

21.3. NXLog 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 the following command will update the configuration file.

# sed -i s,/opt/nxlog,/opt/nxlog_new,g /opt/nxlog_new/etc/nxlog.conf

Alternatively, the file can be manually edited 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%/etc/nxlog.d
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.

21.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 in which the libraries are statically linked against the binaries. To list the shared libraries used by NXLog, use the ldd command with the full path to the nxlog binary

# ldd /opt/nxlog_new/bin/nxlog

The output should look similar to this:

        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.

Note

Depending on the distribution, chrpath may have a limitation on the path length for the -r <path> | --replace <path> option: "The new path must be shorter or the same length as the current path."

# chrpath -r /opt/nxlog_new/lib /opt/nxlog_new/bin/nxlog

Returns this error:

  /opt/nxlog_new/bin/nxlog: RUNPATH=/opt/nxlog/lib
  new rpath '/opt/nxlog_new/lib' too large; maximum length 14

If your system has the chrpath limitation documented above, skip to Modifying rpath with patchelf.

21.4.1. Modifying rpath with chrpath

If the current rpath is longer than the new rpath, issue the following command if the nxlog binary is in your current path. Otherwise, the final chrpath argument needs to include the appropriate relative or absolute path to nxlog (as implemented in the example above).

# chrpath -r /opt/nxlog_new/lib nxlog

Upon success, a message similar to this will be output:

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.

21.4.2. Modifying rpath with patchelf

If chrpath is not an option for modifying rpath, using patchelf as follows will achieve the same goal:

# patchelf --set-rpath /opt/nxlog_new/lib /opt/nxlog_new/bin/nxlog

On success the command prompt returns with no message, or if this is the first time patchelf has been run after installation, the following warning will be shown:

warning: working around a Linux kernel bug by creating a hole of 1748992 bytes in ‘nxlog’

To confirm the modification of rpath, run ldd again on the binary. The new path should displayed in the output:

# ldd /opt/nxlog_new/bin/nxlog
        linux-vdso.so.1 =>  (0x00007ffc15d36000)
        libpcre.so.1 => /opt/nxlog_new/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_new/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)

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. Unlike chrpath which accepts a (*) wildcard for all modules (or binaries) in a given directory, patchelf can only be run on a single file. To automate the process of changing rpath on multiple files, a shell script will need to be written if relocating NXLog will need to be done on a regular basis, or on more than one installation.

22. Monitoring and recovery

Considerable resources continue to be invested in maintaining the quality and reliability of NXLog. However, due to the complexity of modern software, producing bug-free software is practically impossible. This section describes potential ways to automatically recover from an NXLog crash. Note that there are other monitoring solutions besides these presented here which may also be of interest.

22.1. Monitoring on Unix platforms

Monit can both monitor and recover NXLog after a crash. It supports macOS, Solaris, and several Linux distributions. Monit can be installed directly from your distribution’s package manager—see Installation on the Monit wiki for more information about the various installation options. Precompiled binaries can also be found here.

While Monit can monitor and react to several conditions, the configuration presented here instructs Monit to restart NXLog after a crash. To do so, include the following in the Monit configuration. It may be necessary to edit the paths to match your 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, terminate the nxlog process by issuing the following command (where <PID> represents the current nxlog process ID).

# kill -9 <PID>

22.2. Monitoring on Windows

The Service Control Manager (SCM) in Microsoft Windows includes recovery options for each service. In the list of available services, find nxlog and right-click it. Select Properties and then choose the Recovery tab. As shown below, there are a number of different recovery options which can be configured.

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

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

PS> Taskkill /PID <PID> /F

Configuration

23. 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 NXLog configuration file is comprised of blocks and directives. Blocks are similar to XML tags containing multiple directives. Directive names are not case-sensitive but arguments sometimes are.

23.1. Multiple lines

A directive and its argument must be specified on the same line. Values spanning multiple lines must have the newline escaped with a backslash (\), see the sample below.

Example 12. Arguments spanning multiple lines
nxlog.conf
1
2
Fields    $Version, $Device_Vendor, $Device_Product, $Device_Version, \
          $Signature_ID, $Name, $Severity, $_Extension

A typical case of the backslash use is the Exec directive.

nxlog.conf
1
2
Exec    if ($QueryName == 'wpad') OR \
        ($QueryType != '1') drop();

Breaking regular expressions into multiple lines improves their readability. Below is the sample of the define directive which includes backslashes to continue the expression on the new line.

nxlog.conf
1
2
3
define EVENT_REGEX /(?x)^(\d+.\d+.\d+)\s+(\d+:\d+:\d+).\d+\
                         \s+PID=(\d+)\s+TID=(\d+)\s+(\w+)\s+\
                         \S(\w+):\s+(.*)/

Link to this example.

23.2. Comments

Blank lines in configuration files are ignored.

Lines starting with the hash mark (#) are also ignored and can be used as comments.

Example 13. Using comments
nxlog.conf
1
# This is the comment line

Each comment should start with a new line. Application of inline comments is impossible because each directive can only contain the directive definition and the argument.

Comments spanning multiple lines should start with the # mark on each line. Escaping multi-line comments with a backslash (\) is not supported.

nxlog.conf
1
2
# This is a comment
# spanning multiple lines

Comments inside the QueryXML directive must be XML-style comments using <!-- and -->, see the sample below.

nxlog.conf [Download file]
1
2
3
4
5
<!--
XML-style comments can
span multiple lines in
QueryXML blocks like this.
-->

Link to this example.

23.3. File paths

File paths are used by global and module directives, and may be quoted with either single (') or double quotes (").

Example 14. Using file paths
nxlog.conf
1
File    "/tmp/input"

Several modules, however, require that file paths must be unquoted.

nxlog.conf
1
DeviceFile    /dev/auditpipe

Link to this example.

23.4. Configuration structure

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

Example 15. Configuration file structure

This configuration exemplifies the logical structure. The global parameters section contains two directives. The modules section contains both an input and output instance. The route section contains a single route with a path directing a single input to a single output.

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>

Link to this example.

23.5. 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. If for some reason, any capabilities are required to be held permanently, the capabilities directive can be used. These directives are ignored if running on Windows.

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.

23.6. 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.

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

Link to this example.

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

23.7. Routes

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

Example 17. 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>

Link to this example.

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 18. 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>

Link to this example.

23.8. 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 19. 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>

Link to this example.

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 20. 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(); }

Link to this example.

23.9. 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 21. 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>

Link to this example.

23.10. 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 NXLog configuration.

Example 22. 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

Link to this example.

Example 23. Using defines to include a configuration file

In this example, two define directives are used to include an eventlog.conf configuration file on Windows by defining parts of the path to this file.

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

Link to this example.

The include directive also supports filenames containing the wildcard character (*). For example, multiple .conf files could be saved in the nxlog.d directory—​or some other custom configuration directory—​and then automatically included in the NXLog configuration in ascending alphabetical order along with the nxlog.conf file.

Each included file might contain a small set of configuration information focused exclusively on a single log source. This essentially establishes a modular design for maintaining larger configurations. One benefit of this modular configuration approach is the ability to add/remove .conf files to/ from such a directory for enabling/disabling specific log sources without ever needing to modify the main nxlog.conf configuration.

This solution could be used to specify OS-specific configuration snippets (like windows2003.conf) or application-specific snippets (such as syslog.conf).

Including subdirectories inside the configuration directory is not supported, neither are wildcarded directories.

Example 24. Including a configuration directory on Linux

This example includes all .conf files located under the /opt/nxlog/etc/nxlog.d path.

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

The files can also be included using the define directive.

nxlog.conf
define CONFDIR /opt/nxlog/etc/nxlog.d
include %CONFDIR%/*.conf

Link to this example.

Example 25. Including a configuration directory on Windows

This example includes all .conf files from the nxlog.d folder on Windows.

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

The files can also be included using the define directive.

nxlog.conf
1
2
define CONFDIR C:\Program Files\nxlog\conf\nxlog.d
include %CONFDIR%\*.conf

Link to this example.

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 26. 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

Link to this example.

24. 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 pseudo-code. If a syntax error is found, NXLog will print the error. This 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 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 available to the user, except for function return values. 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 that the message will be dropped. If sophisticated error handling or more complex processing is required, additional 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 27. 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 one 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>

24.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’s 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, for example, to prepare a timestamp for comparison with another timestamp. This is a situation where typing is helpful: by converting all timestamps to the datetime type they can be easily compared—​and converted back to strings later if required—​using the functions and procedures provided. The same applies to other types.

Example 28. Typed fields in a syslog event record

The following illustrates the four steps NXLog performs with this configuration as it manually processes a Syslog event record using only regular expressions on the core field $raw_event and the core function parsedate().

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.

24.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 29. Using parentheses (round 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 30. Using an expression in a statement

This simple statement uses the log_info() procedure with an expression as its argument. In this case the expression 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 31. 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.

24.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 can be declared using the constants TRUE or FALSE. Both are case-insensitive.

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.

24.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 32. 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 33. 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 matching also supports named capturing groups. This can be useful when writing long regular expressions. Each captured group is automatically added to the event record as a field with the same name.

Example 34. Named capturing groups

This regular expression uses the named groups TestNumber and TestName to add corresponding $TestNumber and $TestName fields to the event record.

1
2
3
4
if $raw_event =~ /TEST(?<TestNumber>\d): (?<TestName>.+)/
{
    $Message = $TestNumber + ' ' + $TestName;
}

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 35. 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 36. 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 37. 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 !~.

24.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 38. Assigning a value to a field

This statement uses assignment to set the $Department field on log messages.

1
$Department = 'customer-service';
Example 39. 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 40. 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);

24.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 41. 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 42. 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 43. 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.

24.2.5. Functions

A function is an expression which returns a value. The returned value can be used to set fields, output log data, or make logic decisions. Functions can be polymorphic, meaning that 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, functions do not modify the state of the NXLog engine, the state of the module, or the current event.

See the list of available core functions. Modules can provide additional functions for use with the NXLog language.

Example 44. Function calls

These expressions call the now() function to return the current time and the hostname() function to return the hostname of the system where NXLog is installed. The returned values are used to set the $EventTime and $Relay fields.

1
2
$EventTime = now();
$Relay = hostname();

In the example below, the size() function is called to calculate the size of the $Message field. If the field is over 4096 bytes, an internal log is generated.

1
if size($Message) > 4096 log_info('Large message received.');
Example 45. Calling a function of a specific module instance

Functions for a specific module instance can be called using the -> operator. This expression calls the file_name() and file_size() functions of an om_file instance named out. The returned values are used to log the name and size of its current output file.

1
log_info('Size of output file ' + out->file_name() + ' is ' + out->file_size());

Calling functions of a specific instance is especially useful when the configuration contains more than one instance of the same module. These expressions call the to_xml() function of two xm_xml instances, one named xml_a and the other named xml_b.

1
2
xml_a->to_xml();
xml_b->to_xml();

24.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 46. 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 47. 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>

The following configuration is functionally equivalent to the previous configuration above. However, by creating an Exec block, multiple statements can be specified without the need for a backslash (\) line continuation at the end of each line.

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 example. Because its execution depends solely on a schedule instead of any incoming log events, there is no event record that can be associated with it. The $File field assignment in the example above would be impossible.

Example 48. 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.

24.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 49. 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>

24.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 50. 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>

24.3.3. Procedures

A procedure is a statement that performs a set of actions. Procedures can accept arguments. Unlike a function, a procedure modifies its arguments, the state of the NXLog engine, the state of a module, or the current event. Procedures can be polymorphic, meaning that the same procedure can take different argument types.

Many NXLog language features are provided through procedures. See the list of available core procedures. Modules can provide additional procedures for use with the NXLog language.

Example 51. Calling a procedure

This example uses the parse_syslog() procedure, provided by the xm_syslog module, to parse syslog records 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>
Example 52. Calling a procedure of a specific module instance

Procedures for a specific module instance can be called using the -> operator. This statement calls the rotate_to() procedure of an om_file instance named out to rotate the current output file.

1
out->rotate_to("output_logs");

Calling procedures of a specific instance is especially useful when the configuration contains more than one instance of the same module. These statements call the parse_xml() procedure of two xm_xml instances, one named xml_a and the other named xml_b.

1
2
xml_a->parse_xml();
xml_b->parse_xml();

24.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 53. 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>

24.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 54. 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 (although the event time could be stored in another variable).

24.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. With NXLog Enterprise Edition v4.x and earlier, 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 55. 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>

25. Reading and receiving logs

This chapter discusses log sources that you may need to use with NXLog, including:

25.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 56. 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 system under heavy load. 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 57. Using the im_tcp module

This input module instance accepts TCP connections from any host 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 58. 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 59. 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>

25.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 60. 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 61. 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 id, DateOccured as EventTime, \
                               data as Message from logtable WHERE RecordNumber > ?
</Input>

25.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 62. 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 63. 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>

25.4. Receiving from an executable

The im_exec module can be used to read logs from external programs and scripts over a pipe.

Example 64. 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>

26. Processing logs

This chapter deals with various tasks that might be required after a log message is received by NXLog.

26.1. Parsing various log 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.

26.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 62. 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 65. 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 66. Parsing the combined log format

This example is like the previous one, except it parses the two additional fields unique to the Combined Log Format. An om_file instance is also shown here which has been configured to discard all events not related to the user john and write 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.

26.1.2. Parsing syslog events

The xm_syslog module provides the parse_syslog() procedure, which will parse a BSD or IETF Syslog formatted raw event to create fields in the event record.

Example 67. 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 execute the parse_syslog() procedure for each event.

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

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

<Output out>
    Module  om_null
</Output>

This results in the following fields being added to the event record by parse_syslog().

Table 63. 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

26.1.3. Field Delimited Formats (CSV)

Log files containing fields and their values delimited by commas, spaces, or semicolons are commonly created and consumed using such formats. The xm_csv module can both generate and parse these log formats. Multiple xm_csv instances can be used to reorder, add, remove, or modify fields before outputting to a different CSV log format.

Example 68. Complex CSV format conversion

This example reads from the input file and parses it with the parse_csv() procedure from the csv1 instance where the field names, types, and order within the record are defined. 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 to_csv() procedure from 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

26.1.4. JSON

The xm_json module provides procedures for generating and parsing log data in JSON format.

Example 69. Using the xm_json module for parsing JSON

This example reads JSON-formatted data 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 70. Using the xm_json module for generating JSON logs

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>

26.1.5. 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 71. 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 log format can also be parsed with the xm_csv module if using NXLog Community Edition.

Example 72. 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>

26.1.6. XML

The xm_xml module can be used for generating and parsing structured data in XML format.

Example 73. Using the xm_xml module for parsing XML formatted logs

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 74. Using the xm_xml module for generating XML logs

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>

26.2. Alerting

NXLog can be configured to generate alerts when specific conditions are met. Here are some ways alerting could be implemented.

26.2.1. Sending messages to an external program

The om_exec module can pipe messages to an external program or script, which will be executed once the om_exec module has started. The external script is required to run continuously until the om_exec module is stopped and the pipe is closed. This functionality can be used for alerting.

Example 75. Using 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 script.

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 script as defined by the Command directive. The optional Arg directive passes its value to the Command script.

26.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 76. 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 77. 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>

26.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 78. 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>

26.3. Using buffers

The following sections describe the various types of buffering features provided by NXLog and give examples for configuring buffering in specific scenarios.

26.3.1. Read and write buffers

Input and output module instances have read and write buffers, respectively. These buffers can be configured for a particular module instance with the BufferSize directive.

Example 79. Read/write buffers in a simple route

This example shows the default read and write buffers used by NXLog for a simple route. Each buffer is limited to 65,000 bytes.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<Input file>
    Module      im_file
    File        '/tmp/in.log'

    # Set read buffer size, in bytes (default)
    BufferSize  65000
</Input>

<Output tcp>
    Module      om_tcp
    Host        192.168.1.1

    # Set write buffer size, in bytes (default)
    BufferSize  65000
</Output>

<Route r>
    Path        file => tcp
</Route>
diag 1cd740c97f0db95c40f4561d61d58875

26.3.2. Log queues

Every processor and output module instance has an input log queue for events that have not yet been processed by that module instance. When the preceding module has processed a batch of events, they are placed in this queue. Because log queues are enabled by default for all processor and output module instances, they are the preferred way to adjust buffering behavior.

The size of a module instance’s log queue can be configured with the LogqueueSize directive.

Example 80. A log queue in a basic route

This example shows the default log queue used by NXLog in a simple route. A maximum of 100 batches of events will be placed in the queue to be processed by the om_batchcompress instance.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<Input eventlog>
    Module          im_msvistalog
</Input>

<Output batch>
    Module          om_batchcompress
    Host            192.168.2.1

    # Set log queue size, in batches of events (default)
    LogqueueSize    100
</Output>

<Route r>
    Path            eventlog => batch
</Route>
diag 096c7bbba4145312938f309bfc80e141

By default, log queues are stored in memory. NXLog can be configured to persist log queues to disk with the PersistLogqueue directive. NXLog will further sync all writes to a disk-based queue with SyncLogqueue. These directives can be used to prevent data loss in case of interrupted processing—​at the expense of reduced performance—​and can be used both globally or for a particular module. For more information, see Reliable message delivery.

Note
Any events remaining in the log queue will be written to disk when NXLog is stopped, regardless of the value of PersistLogqueue.
Example 81. A persistent log queue

In this example, the om_elasticsearch instance is configured with a persistent and synced log queue. Each time an event is added to the log queue, the event will be written to disk and synced before processing continues.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<Input acct>
    Module          im_acct
</Input>

<Output elasticsearch>
    Module          om_elasticsearch
    URL             http://192.168.2.2:9200/_bulk

    # Set log queue size, in batches of events (default)
    LogqueueSize    100

    # Use persistent and synced log queue
    PersistLogqueue TRUE
    SyncLogqueue    TRUE
</Output>

<Route r>
    Path            acct => elasticsearch
</Route>
diag f0e68d59ae04fb5ea8b1925e5b93e8d8

26.3.3. Flow control

To effectively leverage buffering, it is important to understand NXLog’s flow control feature. Flow control has no effect unless the following sequence of events occurs in a route:

  1. a processor or output module instance is not able to process log data at the incoming rate,

  2. that module instance’s log queue becomes full, and

  3. the input or processor module instance responsible for feeding the log queue has flow control enabled.

In this case, flow control will cause the input or processor module instance to suspend processing until the succeeding module instance is ready to accept more log data.

Example 82. Flow control enabled

This example shows the NXLog’s default flow control behavior with a basic route. Events are collected from the Windows Event Log with im_msvistalog and forwarded with om_tcp. The om_tcp instance will be blocked if the destination is unreachable or the network can not handle the events quickly enough.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<Input eventlog>
    Module      im_msvistalog

    # Flow control enabled (default)
    FlowControl TRUE
</Input>

<Output tcp>
    Module      om_tcp
    Host        192.168.1.1
</Output>

<Route r>
    Path        eventlog => tcp
</Route>

The om_tcp instance is unable to connect to the destination host and its log queue is full. Because the im_msvistalog instance has flow control enabled and the next module in the route is blocked, it has been paused. No events will be read from the Windows Event Log until the tcp instance becomes unblocked.

diag ea3d508dea8f8985814c533a9e5dbdbb

Flow control is enabled by default, and can be set globally or for a particular module instance with the FlowControl directive. Generally, flow control provides automatic, zero-configuration handling of cases where buffering would otherwise be required. However, there are some situations where flow control should be disabled and buffering should be explicitly configured as required.

Example 83. Flow control disabled

In this example, Linux Audit messages are collected with im_linuxaudit and forwarded with om_http. Flow control is disabled for im_linuxaudit to prevent processes from being blocked due to an Audit backlog. To avoid loss of log data in this case, the LogqueueSize directive could be used as shown in Increasing the log queue size to protect against UDP message loss.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<Input audit>
    Module      im_linuxaudit
    <Rules>
        -D
        -w /etc/passwd -p wa -k passwd
    </Rules>

    # Disable flow control to prevent Audit backlog
    FlowControl FALSE
</Input>

<Output http>
    Module      om_http
    URL         http://192.168.2.1:8080/
</Output>

<Route r>
    Path        audit => http
</Route>

The om_http instance is unable to forward log data, and its log queue is full. Because it has flow control disabled, the im_linuxaudit instance remains active and continues to process log data. However, all events will be discarded until the om_http log queue is no longer full.

diag 6c90d4189cd994f8ce5d002b88c87607

26.3.4. The pm_buffer module

Log queues are enabled by default for processor and output modules instances, and are the preferred way to configure buffering behavior in NXLog. However, for cases where additional features are required, the pm_buffer module can be used to add a buffer instance to a route in addition to the above buffers normally used by NXLog.

Additional features provided by pm_buffer include:

  • both memory- and disk-based buffering types,

  • a buffer size limit measured in kilobytes,

  • a WarnLimit threshold that generates a warning message when crossed, and

  • functions for querying the status of a pm_buffer buffer instance.

Note
In a disk-based pm_buffer instance, events are not written to disk unless the log queue of the succeeding module instance is full. For this reason, a disk-based pm_buffer instance does not reduce peformance in the way that a persistent log queue does. Additionally, pm_buffer (and other processor modules) should not be used if crash-safe processing is required; see Reliable message delivery.
Example 84. Using the pm_buffer module

This example shows a route with a large disk-based buffer provided by the pm_buffer module. A warning message will be generated when the buffer size crosses the threshold specified.

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
<Input udp>
    Module      im_udp
</Input>

<Processor buffer>
    Module      pm_buffer
    Type        Disk

    # 40 MiB buffer
    MaxSize     40960

    # Generate warning message at 20 MiB
    WarnLimit   20480
</Processor>

<Output ssl>
    Module      om_ssl
    Host        10.8.0.2
    CAFile      %CERTDIR%/ca.pem
    CertFile    %CERTDIR%/client-cert.pem
    CertKeyFile %CERTDIR%/client-key.pem
</Output>

<Route r>
    Path        udp => buffer => ssl
</Route>

The SSL/TLS destination is unreachable, and the disk-based buffer is filling.

diag 9eaf62ec26309e87fd6c4dc3e74f2b7e

26.3.5. Other buffering functionality

Buffering in NXLog is not limited to the functionality covered above. Other modules implement or provide additional buffering-related features, such as the ones listed below. (This is not intended to be an exhaustive list.)

Example 85. All buffers in a basic route

The following diagram shows all buffers used in a simple im_udp => om_tcp route. The socket buffers are only applicable to networking modules.

diag ee8394953ce66f682f1fccde47543e2a

26.3.6. Receiving logs via UDP

Because UDP is connectionless, log data sent via plain UDP must be accepted immediately. Otherwise the log data is lost. For this reason, it is important to add a buffer if there is any possibility of the route becoming blocked. This can be done by increasing the log queue size of the following module instance or adding a pm_buffer instance to the route.

Example 86. Increasing the log queue size to protect against UDP message loss

In this configuration, log messages are accepted with im_udp and forwarded with om_tcp. The log queue size of the output module instance is increased to 500 batches to buffer messages in case the output becomes blocked. To further reduce the risk of data loss, the socket buffer size is increased with the SockBufSize directive and the route priority is increased with Priority.

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
<Input udp>
    Module          im_udp

    # Raise socket buffer size
    SockBufSize     150000000
</Input>

<Output tcp>
    Module          om_tcp
    Host            192.168.1.1

    # Keep up to 500 batches of events in the log queue
    LogqueueSize    500
</Output>

<Route udp_to_tcp>
    Path            udp => tcp

    # Process events in this route first
    Priority        1
</Route>

The output is blocked because the network is not able to handle the log data quickly enough.

diag b888e869071714e30405e8caeb6127b6
Example 87. Using a pm_buffer instance to protect against UDP message loss

Instead of raising the size of the log queue, this example uses a memory-based pm_buffer instance to buffer events when the output becomes blocked. A warning message will be generated if the buffer size exceeds the specified WarnLimit threshold.

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
<Input udp>
    Module      im_udp

    # Raise socket buffer size
    SockBufSize 150000000
</Input>

<Processor buffer>
    Module      pm_buffer
    Type        Mem

    # 5 MiB buffer
    MaxSize     5120

    # Warn at 2 MiB
    WarnLimit   2048
</Processor>

<Output http>
    Module      om_http
    URL         http://10.8.1.1:8080/
</Output>

<Route udp_to_http>
    Path        udp => buffer => http

    # Process events in this route first
    Priority    1
</Route>

The HTTP destination is unreachable, the http instance log queue is full, and the buffer instance is filling.

diag be67a6fe500921173773eacb5d1ab791

26.3.7. Reading logs from /dev/log

Syslog messages can be read from the /dev/log/ socket with the im_uds module. However, if the route becomes blocked and the im_uds instance is suspended, the syslog() system call will cause blocking in programs attempting to log a message. To prevent that, flow control should be disabled.

With flow control disabled, events will be discarded if the route becomes blocked and the route’s log queues become full. To reduce the risk of lost log data, the log queue size of a succeeding module instance in the route can be increased. Alternatively, a pm_buffer instance can be used as in the second UDP example above.

Example 88. Buffering syslog messages from /dev/log

This configuration uses the im_uds module to collect Syslog messages from the /dev/log socket, and the xm_syslog parse_syslog() procedure to parse them.

To prevent the syslog() system call from blocking as a result of the im_uds instance being suspended, the FlowControl directive is set to FALSE. The LogqueueSize directive raises the log queue limit of the output instance to 500 batches. The Priority directive indicates that this route’s events should be processed first.

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 _syslog>
    Module          xm_syslog
</Extension>

<Input dev_log>
    Module          im_uds
    UDS             /dev/log
    Exec            parse_syslog();

    # This module instance must never be suspended
    FlowControl     FALSE
</Input>

<Output elasticsearch>
    Module          om_elasticsearch
    URL             http://192.168.2.1:9022/_bulk

    # Keep up to 500 batches of events in the log queue
    LogqueueSize    500
</Output>

<Route syslog_to_elasticsearch>
    Path            dev_log => elasticsearch

    # Process events in this route first
    Priority        1
</Route>

The Elasticsearch server is unreachable and the log queue is filling. If the log queue becomes full, events will be discarded.

diag 999cf4f23bbb9d960046224725a82370

26.3.8. Forwarding logs from file

Because flow control will pause an im_file instance automatically, it is normally not necessary to use any additional buffering when reading from files. If the route is blocked, the file will not be read until the route becomes unblocked. If the im_file SavePos directive is set to TRUE (the default) and NXLog is stopped, the file position of the im_file instance will be saved and used to resume reading when NXLog is started.

Example 89. Forwarding from file with default buffering

This configuration reads a log file with im_file and forwards them with om_tcp. No extra buffering is necessary because flow control is enabled.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<Input file>
    Module      im_file
    File        '/tmp/in.log'

    # Enable flow control (default)
    FlowControl TRUE

    # Save file position on exit (default)
    SavePos     TRUE
</Input>

<Output tcp>
    Module      om_tcp
    Host        10.8.0.2
</Output>

<Route r>
    Path        file => tcp
</Route>

The TCP destination is unreachable, and the im_file instance is paused. No messages will be read from the source file until the om_tcp instance becomes unblocked.

diag 50140beb8a5eebbaf977d0d4eadec0a4

Sometimes, however, there is a risk of the input log file becoming inaccessible while the im_file instance is suspended (due to log rotation, for example). In this case, the tcp log queue size can be increased (or a pm_buffer instance added) to buffer more events.

Example 90. Forwarding from file with additional buffering

In this example, log messages are read from a file with im_file and forwarded with om_tcp. The om_tcp log queue size has been increased in order to buffer more events because the source file may be rotated away.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<Input file>
    Module          im_file
    File            '/tmp/in.log'
</Input>

<Output tcp>
    Module          om_tcp
    Host            192.168.1.1

    # Keep up to 200 batches of events in the log queue
    LogqueueSize    200
</Output>

<Route r>
    Path            file => tcp
</Route>

The TCP destination is unreachable and the om_tcp instance is blocked. The im_file instance will continue to read from the file (and events will accumulate) until the tcp log queue is full; then it will be paused.

diag 823f3342162bdc177d60e591bb5cf326

26.3.9. Discarding events

NXLog’s flow control mechanism ensures that input module instances will pause until all output module instances can write. This can be problematic in some situations when discarding messages is preferable to blocking. For this case, flow control can be disabled or the drop() procedure can be used in conjunction with the pm_buffer module. These two options differ somewhat in behavior, as described in the examples below.

Example 91. Disabling flow control to selectively discard events

This example sends UDP input to two outputs, a file and an HTTP destination. If the HTTP transmission is slower than the rate of incoming UDP packets or the destination is unreachable, flow control would normally pause the im_udp instance. This would result in dropped UDP packets. In this situation it is better to selectively drop log messages in the HTTP route than to lose them entirely. This can be accomplished by simply disabling flow control for the input module instance.

Note
This configuration will also continue to send events to the HTTP destination in the unlikely event that the om_file output blocks. In fact, the input will remain active even if both outputs block (though in this particular case, because UDP is lossy, messages will be lost regardless of whether the im_udp instance is suspended).
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
<Input udp>
    Module          im_udp

    # Never pause this instance
    FlowControl     FALSE
</Input>

<Output http>
    Module          om_http
    URL             http://10.0.0.3:8080/

    # Increase the log queue size
    LogqueueSize    200
</Output>

<Output file>
    Module          om_file
    File            '/tmp/out.log'
</Output>

<Route udp_to_tcp>
    Path            udp => http, file
</Route>

The HTTP destination cannot accept events quickly enough. The om_http instance is blocked and its log queue is full. New events are not being added to the HTTP output queue but are still being written to the output file.

diag 3e0ce7e5339f1a4fc3602ab895ee8216
Example 92. Selectively discarding events with pm_buffer and drop()

In this example, process accounting logs collected by im_acct are both forwarded via TCP and written to file. A separate route is used for each output. A pm_buffer instance is used in the TCP route, and it is configured to discard events with drop() if its size goes beyond a certain threshold. Thus, the pm_buffer instance will never become full and will never cause the im_acct instance to pause—events will always be written to the output file.

Note
Because the im_acct instance has flow control enabled, it will be paused if the om_file output becomes blocked.
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
<Input acct>
    Module      im_acct

    # Flow control enabled (default)
    FlowControl TRUE
</Input>

<Processor buffer>
    Module      pm_buffer
    Type        Mem
    MaxSize     1000
    WarnLimit   800
    Exec        if buffer_size() >= 80k drop();
</Processor>

<Output tcp>
    Module      om_tcp
    Host        192.168.1.1
</Output>

<Output file>
    Module      om_file
    File        '/tmp/out.log'
</Output>

<Route udp_to_tcp>
    Path        acct => buffer => tcp
</Route>

<Route udp_to_file>
    Path        acct => file
</Route>

The TCP destination is unreachable and the om_tcp log queue is full. Input accounting events will be added to the buffer until it gets full, then they will be discarded. Input events will also be written to the output file, regardless of whether the buffer is full.

diag 75658d0873230d79f737ea74cdcda6a9

26.3.10. Scheduled buffering

While buffering is typically used when a log source becomes unavailable, NXLog can also be configured to buffer logs programmatically. For this purpose, the pm_blocker module can be added to a route.

Example 93. Buffering logs and forwarding by schedule

This example collects log messages via UDP and forwards them to a remote NXLog agent. However, events are buffered with pm_buffer during the week and only forwarded on weekends.

  • During the week, the pm_blocker instance is blocked and events accumulate in the large on-disk buffer.

  • During the weekend, the pm_blocker instance is unblocked and all events, including those that have accumulated in the buffer, are forwarded.

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
<Input udp>
    Module      im_udp
    Host        0.0.0.0
</Input>

<Processor buffer>
    Module      pm_buffer

    # 500 MiB disk buffer
    Type        Disk
    MaxSize     512000
    WarnLimit   409600
</Processor>

<Processor schedule>
    Module  pm_blocker
    <Schedule>
        # Start blocking Monday morning
        When    0 0 * * 1
        Exec    schedule->block(TRUE);
    </Schedule>
    <Schedule>
        # Stop blocking Saturday morning
        When    0 0 * * 6
        Exec    schedule->block(FALSE);
    </Schedule>
</Processor>

<Output batch>
    Module      om_batchcompress
    Host        10.3.0.211
</Output>

<Route scheduled_batches>
    Path        udp => buffer => schedule => batch
</Route>

It is currently a weekday and the schedule pm_blocker instance is blocked.

diag a533147082f1deada7e38c23ed62a650

If it is possible to use flow control with the log sources, then it is not necessary to use extra buffering. Instead, the inputs will be paused and read later when the route is unblocked.

Example 94. Collecting log data on a schedule

This configuration reads events from the Windows Event Log and forwards them to a remote NXLog agent in compressed batches with om_batchcompress. However, events are only forwarded during the night. Because the im_msvistalog instance can be paused and events will still be available for collection later, it is not necessary to configure any extra buffering.

  • During the day, the pm_blocker instance is blocked, the output log queue becomes full, and the eventlog instance is paused.

  • During the night, the pm_blocker instance is unblocked. The events in the schedule log queue are processed, the eventlog instance is resumed, and all pending events are read from the Windows Event Log and forwarded.

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
<Input eventlog>
    Module      im_msvistalog
</Input>

<Processor schedule>
    Module  pm_blocker
    <Schedule>
        # Start blocking at 7:00
        When    0 7 * * *
        Exec    schedule->block(TRUE);
    </Schedule>
    <Schedule>
        # Stop blocking at 19:00
        When    0 19 * * *
        Exec    schedule->block(FALSE);
    </Schedule>
</Processor>

<Output batch>
    Module      om_batchcompress
    Host        10.3.0.211
</Output>

<Route scheduled_batches>
    Path        eventlog => schedule => batch
</Route>

The current time is within the specified "day" interval and pm_blocker is blocked.

diag a9291036fe12ed936111959b76f4541d

26.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 95. Character set auto-detection of various input encodings

This configuration shows an example of character set auto-detection. The input file may contain differently encoded lines, but by invoking the convert_fields() procedure, each message will have the character set encoding of its fields detected and then converted to UTF-8 as needed.

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>

26.5. Detecting an inactive 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 network connectivity issues, a server which is down, or an unresponsive 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 designed as means of monitoring the health of the NXLog agent by generating "mark" messages every 30 minutes. The message text and interval are configurable.

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 address this issue and this method may not be optimal for all situations.

Example 96. 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 no logs have been received within the last 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>

26.6. Event correlation

It is possible to write correlation rules in the NXLog language using the built-in features such as variables and statistical counters. While these features are quite powerful, some cases cannot be detected with them, especially when conditions require a sliding window correlation.

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 97. Correlation rules

The following configuration provides samples for each type of rule: Absence, Pair, Simple, Suppressed, and Thresholded.

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>

26.7. 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 Event Log collected via im_msvistalog) already contain structured data. In this case, there is often no additional extraction required; see Log classification.

26.7.1. Log parsing with regular expressions via the Exec directive

NXLog supports the use of regular expressions for parsing log fields. For detailed information about regular expressions in NXLog, see the Reference Manual Regular Expressions section.

Example 98. Parsing logs 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 Syslog message shown above 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. Regex named groups are automatically added to the event record as a field with the same name.

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 64. Additional fields parsed by regular expression
Field Value

$AuthMethod

password

$AccountName

linda

$SourceIPAddress

192.168.1.60

26.7.2. Pattern matching with Grok

The xm_grok module provides parsing for unstructured log messages with Grok patterns.

The examples below demonstrate how to parse Apache logs using Grok patterns.

Example 99. Creating the pattern to parse the Access log

The message below is a sample of an Apache Access log.

Apache Access log
192.168.3.20 - - [28/Jun/2019] "GET /cgi-bin/try/ HTTP/1.0" 200 3395

The above Apache message can be parsed using the Grok pattern below.

Pattern for the Access log
ACCESS_LOG %{IP:ip_address} - - \[%{TIMESTAMP_ACCESS:timestamp}\]
"%{METHOD:http_method} %{UNIXPATH:uri} HTTP/%{HTTP_VERSION:http_version}"
%{INT:http_status_code} %{INT:response_size}
Example 100. Creating the pattern to parse the Error Message

The message below is a sample of an Apache error message.

Apache Error Message
[Fri Dec 16 01:46:23 2019] [error] [client 1.2.3.4] Directory index forbidden
by rule: /home/test/

The above Apache log message can be parsed using the Grok pattern below.

Pattern for the Error Message
ERROR_LOG \[%{TIMESTAMP_ERROR:timestamp}\] \[%{LOGLEVEL:severity}\]
\[client %{IP:client_address}\] %{GREEDYDATA:message}

Lists of Grok patterns are available in various repositories. As an example, see the logstash-plugin section on Github.

Example 101. Configuring NXLog to parse Apache logs

The following configuration reads messages from the apache_entries.log file using the im_file module and stores the result in the $raw_event field.

The match_grok() function reads patterns from the patterns.txt file and attempts a series of matches on the $raw_event field. If none of the patterns match, an internal message is logged.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<Extension grok>
    Module     xm_grok
    Pattern    patterns.txt
</Extension>

<Input messages>
    Module     im_file
    File       "apache_entries.log"
    <Exec>
        if not ( match_grok($raw_event, "%{ACCESS_LOG}") or
                 match_grok($raw_event, "%{ERROR_LOG}"))
        {
            log_info('Event did not match any pattern');
        }
    </Exec>
</Input>

This example uses the patterns.txt file, which contains all necessary Grok patterns.

patterns.txt
INT (?:[+-]?(?:[0-9]+))
YEAR (?>\d\d){1,2}
MONTH \b(?:[Jj]an(?:uary|uar)?|[Ff]eb(?:ruary|ruar)?|[Mm](?:a|ä)?r(?:ch|z)?|[Aa]pr(?:il)?|[Mm]a(?:y|i)?|[Jj]un(?:e|i)?|[Jj]ul(?:y)?|[Aa]ug(?:ust)?|[Ss]ep(?:tember)?|[Oo](?:c|k)?t(?:ober)?|[Nn]ov(?:ember)?|[Dd]e(?:c|z)(?:ember)?)\b
DAY (?:Mon(?:day)?|Tue(?:sday)?|Wed(?:nesday)?|Thu(?:rsday)?|Fri(?:day)?|Sat(?:urday)?|Sun(?:day)?)
HOUR (?:2[0123]|[01]?[0-9])
MINUTE (?:[0-5][0-9])
SECOND (?:(?:[0-5]?[0-9]|60)(?:[:.,][0-9]+)?)
UNIXPATH (/([\w_%!$@:.,+~-]+|\\.)*)+
GREEDYDATA .*
IP (?<![0-9])(?:(?:[0-1]?[0-9]{1,2}|2[0-4][0-9]|25[0-5])[.](?:[0-1]?[0-9]{1,2}|2[0-4][0-9]|25[0-5])[.](?:[0-1]?[0-9]{1,2}|2[0-4][0-9]|25[0-5])[.](?:[0-1]?[0-9]{1,2}|2[0-4][0-9]|25[0-5]))(?![0-9])
LOGLEVEL ([Aa]lert|ALERT|[Tt]race|TRACE|[Dd]ebug|DEBUG|[Nn]otice|NOTICE|[Ii]nfo|INFO|[Ww]arn?(?:ing)?|WARN?(?:ING)?|[Ee]rr?(?:or)?|ERR?(?:OR)?|[Cc]rit?(?:ical)?|CRIT?(?:ICAL)?|[Ff]atal|FATAL|[Ss]evere|SEVERE|EMERG(?:ENCY)?|[Ee]merg(?:ency)?)
TIMESTAMP_ACCESS %{INT}\/%{MONTH}\/%{YEAR}(:%{HOUR}:%{MINUTE}:%{SECOND} %{GREEDYDATA})?
TIMESTAMP_ERROR %{DAY} %{MONTH} %{INT} %{HOUR}:%{MINUTE}:%{SECOND} %{YEAR}
METHOD (GET|POST|PUT|DELETE|HEAD|TRACE|OPTIONS|CONNECT|PATCH){1}
HTTP_VERSION 1.(0|1)

ACCESS_LOG %{IP:ip_address} - - \[%{TIMESTAMP_ACCESS:timestamp}\] "%{METHOD:http_method} %{UNIXPATH:uri} HTTP/%{HTTP_VERSION:http_version}" %{INT:http_status_code} %{INT:response_size}
ERROR_LOG \[%{TIMESTAMP_ERROR:timestamp}\] \[%{LOGLEVEL:severity}\] \[client %{IP:client_address}\] %{GREEDYDATA:message}

26.7.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 102. 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 65. 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 103. 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.

26.7.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).

26.8. Filtering logs

Log filtering is a process where only some of the received log messages are kept. Filtering is possible using regular expressions or other operators using any of the fields. See the NXLog language section for complete details on expressions.

26.8.1. Using the drop() procedure

Use the drop() procedure in an Exec directive to conditionally discard logs.

Example 104. Using drop() to discard unmatched 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
<Input