Welcome to version 4.18 of our NetEye v4 Unified Monitoring Solution.
The first quarter of the year is gone and the snow is slowly melting, leaving only a thin layer on the highest peaks, like shown in this majestic view of the Odle di Funes and Fermeda ridges at the end of the Val di Funes/Villnoesstal.
NetEye salutes a release cycle that brought many new features and the team already plans and works on future improvements, in the relaxing environment around.
In the user guide, it is now easier to distinguish between the current (released) and next (in development) version of the user guide. You will find that labels have been added (i.e., current or next) in the version dropdown along with the numbers.
Also, each version of the user guide is directly accessible with the respective current (https://neteye.guide/current) or next (https://neteye.guide/next) alias.
With NetEye 4.18, the Tornado UI can be used to export and backup or import and restore the entire configuration, a processing tree node (including its sub-nodes) or a single rule. An easy-to-use interface will guide the user through the steps needed for downloading the backup and partially or entirely restoring a previously saved Tornado configuration. See the dedicated User Guide section for more details.
The usability has been improved by a few small changes. In particular, it is now possible to edit a node or a rule with a double click, a link to the list of rules has been added to the rule set edit form and the processing tree node action bar is opened when the mouse hovers over the node.
NetEye now has a new Event Adjustment GUI that completes the already existing CLI feature for Service Level Management. Administrators with the appropriate privileges can add, modify and delete event adjustments related to monitoring objects. The new GUI also has an advanced search filter that is very useful in situations where a user wants to search for any specific adjustment entry.
For SLM Reports it is often desirable to be able to create an SLM Event Adjustment starting from a given Monitoring Event. For this reason from the Monitoring Event Details page, SLM admins will now be able to create an Event Adjustment for the Event, without the need to manually compile the Event Adjustment data in the dedicated Event Adjustment creation form.
Moreover, to enable a quick navigation from Hosts and Services to their respective Event Adjustments, a link pointing to the list of the Event Adjustments is now shown Problem Handling section of the Monitoring module, in case any Event Adjustment is present for the given Host or Service.
To enable SLM non-admin users to navigate through the existing SLM Event Adjustments, the General Module Access permission of the SLM module will now give users the permission to view SLM Event Adjustments.
For further details, please see the dedicated User Guide section
Logs belonging to different entities, or different types of logs, need to be managed separately. For example, I may want to set a different retention policy for each distinct type of log arriving to NetEye. I may want that the validity of the logs of one of my tenants is not influenced by the logs generated by another tenant.
To address these needs, the NetEye 4.18 release introduces the multitenancy support in the Real Time Log Signing architecture of the Log Manager module.
With this improvement, it is now possible to generate different blockchains depending on the characteristic of each incoming log. On each different blockchain, it is then possible to configure a different retention policy.
Indexing a log in Elasticsearch can sometimes fail due to some inconsistencies between what the log contains and what Elasticsearch expects. Since the indexing will never succeed in such cases, it is useless to keep trying to send the log to Elasticsearch and can also cause a relevant waste of resources.
For this reason, a new Error Handling policy has been introduced in the Real Time Log Signing architecture.
When the aforementioned indexing errors are encountered, the El Proxy component tries to index the log with only the minimal information needed to create and verify the log blockchain. This strategy should help to avoid a back pressure situation on the data pipeline.
In case this Elasticsearch indexing also fails, the log is written inside a Dead Letter Queue on the File System. An Icinga2 service will automatically notify the system administrator that some log could not be indexed in Elasticsearch and were written to the Dead Letter Queue.
To make the acknowledgment and the resolution of the error easier, the complete Elasticsearch response is included in a dedicated field of the Dead Letter Queue log. An administrator can fix the reported issue that caused the missing indexing, and re-index the document manually.
For further details, please see the dedicated User Guide section
When a new blockchain of logs is created in the Real Time Log Signing architecture, the initial key used to initiate the blockchain is saved on the filesystem. This key is required to later verify the integrity of the blockchain, but it could be abused by an attacker for malicious activities.
To minimize the risk that an attacker reads the initial key and tampers with the blockchain, these initial keys must be removed from filesystem as soon as possible after creation and kept safely in a separate storage.
A dedicated Icinga2 service will alert the NetEye 4 administrator as soon as a new key is created, such that the administrator can take care of moving the key to a safe place.
We upgraded the Elastic Stack from 7.10.1 to 7.12.1, which brings:
Refer to the Elastic Stack release notes for additional information:
Please note that the Logstash Beats input plugin will not be upgraded to version 6.1.0 due to a bug in the plugin, which incorrectly handles the TLS session metadata.
We updated ITOA from version 7.2.0 to version 7.5.5, which brings multiple improvements:
You can refer to the Grafana release notes for additional information:
https://grafana.com/docs/grafana/next/release-notes/