We proudly announce the latest release of NXLog Enterprise Edition, version 6.0. This major release includes new NXLog language data types, additional TCP and HTTP configuration options, and enhancements to our Elasticsearch and remote administration modules.
Read on to find out more about some of these new features.
|
Important
|
While upgrading, please read our guide on how to migrate from NXLog Enterprise Edition 5 to NXLog Enterprise Edition 6, as there are some incompatibilities between the two, which may require configuration changes. |
New Array and Hash data types
The NXLog language now includes support for compound values with two new data types:
- Array
-
Holds a list of values of any NXLog data type. Individual items can be accessed by their index number.
- Hash
-
Holds a list of key-value pairs. The key is a user-defined string; the value can be any NXLog data type. Individual items can be accessed by the key name.
Support for Elasticsearch data streams
Our Elasticsearch module (om_elasticsearch) can now send data to a data stream in addition to regular indices with the introduction of the DataStream directive.
The configuration is straightforward.
Simply point the URL to your data stream and set DataStream to TRUE (the default is FALSE) to send logs to an Elasticsearch data stream.
More TCP-based modules can reuse the IP address and port
The ReuseAddr and ReusePort directives are now available in all TCP-based input modules (im_batchcompress, im_http, im_ssl, im_tcp) in addition to the UDP (im_udp) input module.
As a result, multiple instances of the same module can listen on the same IP address and port for processing incoming data synchronously, thus using the available system resources better for faster log processing.
More HTTP-based modules support compression
The following modules now also support the Compression directive:
-
Microsoft Azure Logs Ingestion (om_azuremonitor)
-
Google Chronicle (om_chronicle)
-
Google Cloud Logging (im_googlelogging and om_googlelogging)
-
Salesforce (im_salesforce)
New administrative module functionality
We continue to build our administrative module (xm_admin) to improve manageability.
We implemented new GetUid and SetUid methods for retrieving or setting an agent’s unique identifier.
We also worked on enhancing other methods:
-
A request for server information returns more detailed system information and two new fields:
trial_expiry_timecontains the time in epoch seconds until a trial agent expires, anduidcontains the agent’s unique identifier. -
Requesting module information for a Windows Event Collector (im_wseventing) instance now returns client connection statistics like other TCP-based modules.
-
The requests to send or receive a file from the agent support a new
aclparameter, which replaces thefiletypeparameter. We renamed this parameter to reflect the true configuration setting required, i.e., the name of an ACL in the NXLog configuration.filetypeis still accepted for backward compatibility but will be phased out in a future version.
The log queue size is now calculated in bytes
We updated the LogqueueSize global and common module directive to operate on bytes instead of batches of log records for simpler and more accurate resource planning.
This change is not backward compatible; therefore, you must modify your configuration accordingly if updating from an older NXLog agent version.
NXLog Enterprise Edition version 4 end-of-life
With the release of NXLog Enterprise Edition 6.0, all versions of NXLog Enterprise Edition 4 are considered end-of-life and are no longer supported. If you’re still using version 4, we encourage you to upgrade to the latest version. Get in touch with our support team if you need guidance.
Find out more
You can check out all of the new features and fixes in our release notes, and view our changelog for a full list of what’s changed between versions. Check out our comprehensive documentation, and get in touch with us below if you need help upgrading, have a feature request, or have any other questions.
