Release Date: March 31, 2020
Welcome to version 4.11 of our NetEye v4 Unified Monitoring Solution.
The complete changelog, which includes all fixed issues, can be generated on demand by following the instructions in the updated NetEye documentation.
To begin the upgrade, please follow the instructions in your current NetEye version at User Guide > Upgrading and Updating.
New Features
Asset Management – GLPI SSO Integration
From this Release on, GLPI does not require a separate login anymore. GLPI Entities and Profiles of Users are now configurable in a centralized manner, by mapping them to one or more Roles in the NetEye User Management.
When upgrading from NetEye 4.10 to 4.11, the SSO login is not enabled by default, so you can choose the best moment to migrate. However, please note that it will become mandatory to enable the SSO login with the upgrade to the future NetEye 4.12 Release. Before enabling the SSO login, the NetEye user management and GPLI profiles and entities configurations must be prepared. As soon as those configurations are ready, you can enable the SSO login in the Asset Management module’s configuration tab. The new scheme will be applied for each user individually when that user logs in for the first time after the SSO is enabled. Please note that once the SSO has been enabled, you cannot rollback. For more details on the migration procedure, see User Guide > The Asset Management module > GLPI > How to migrate the GLPI users configuration.
Asset Management – OCS SSO Integration
From this Release on, OCS does not require a separate login anymore. OCS Profiles of Users, and computer tags that they can view, are now configurable in a centralized manner, by mapping them to one or more Roles in the NetEye User Management.
When upgrading from NetEye 4.10 to 4.11, the SSO login is not enabled by default, so rou can choose the best moment to migrate. However, please note that it will become mandatory to enable the SSO login with the upgrade to the future NetEye 4.12 Release. Before enabling the SSO login, the NetEye user management and OCS profiles and tags must be prepared. As soon as those configurations are ready, you can enable the SSO login in the Asset Management module’s configuration tab. The new scheme will be applied for each user individually when that user logs in the first time after the SSO is enabled. Please note that once the SSO has been enabled, you cannot rollback. For more details on the migration procedure, see User Guide > The Asset Management module > OCS Inventory > How to migrate the OCS users configuration.
SLM – Resource Report Integration
The SLM module now offers users the ability to configure a new type of Contract, that collects and shows information about resource consumption and use it to create a Resource Report. Typical resources include, but are not limited to, storage, CPU, RAM, and network. The configuration process allows users to include the single graph contained desired Dashboards created in the ITOA module.
Tornado – Elasticsearch Executor
Tornado now has an Elasticsearch Executor, which permits to write Tornado Events to Elasticsearch.
Tornado – Rsyslog Collector
Starting from this release, the Tornado rsyslog collector is included in the NetEye Core subscription. Previously, subscription to NetEye Logmanagement or SIEM was required.
Tornado – Security
The Tornado Engine and all Tornado collectors now support sending Events via NATS server. This ensures secure TLS communication between all Tornado components, especially remote ones.
Communication via TCP connections is still supported, but has been deprecated from this release. The NetEye Local Self Monitoring Mechanism will check if Tornado is still using the TCP communications, and warn the user accordingly.
The Tornado webhook endpoint can now be called securely with HTTPS on port 443. The URL to reach the webhook has now prefix/tornado/webhook/.
The old Tornado webhook endpoint responding on port 8080 called with HTTP is now deprecated.
To guarantee a higher level of security the Tornado Engine and Collectors are now run as system user tornado instead of root.
When upgrading please check the following:
- If you have scripts that are executed by Tornado actions, they must be executable by the
tornadouser. - If you have configured Tornado Archive actions, please check that the new system user
tornadohas the permissions to write to the path configured in the actions.
Improvements
MariaDB – Improved Performance
We shipped new improved configurations for MariaDB after a long testing phase in a large monitoring environment with 50.000 hosts and 150.000 services. The main result is smoother user interaction with the front end for all NetEye users.
Tornado – Improved Rule & Filter Configuration
From this version, Tornado will provide better suggestions and error messages about Rule and Filter configuration. Because of this improvement, also Rule and Filter checking has become more strict, which means there are a few things you need to verify and correct in your present configuration to flawlessly migrate do NetEye 4.11.
- Filters without
"filter"property are now disallowed, so you must add at least the empty property"filter":{}to each JSON Filter. - Both Rules and Filters may no longer contain properties unknown to Tornado, therefore you must remove them before upgrading.
The tornado check command will help you to search and identify Rules and Filters that need to be modified, without the need to restart Tornado.
SLM – Contracts
From now on, it is possible to configure an SLM Contract that takes into account either Hosts or Services availability or both. A new Monitored Object Type filter makes it easy to add those items in the SLM Contract form.
SLM report – Outages
Outages in SLM reports are now reported in such a way that an outage represents the time during which a monitoring object is continuously unavailable from the perspective of the Operational Time defined inside the SLA Type.
This means that if e.g. the Operational Time is a 24×5 within a SLA calculation period and an object is unavailable on Friday evening, and is still unavailable on the following Monday morning, a single outage is reported.
A detailed description and case analysis of how outages are computed can be found in User Guide > Service Level Management > Outages.
Elastic Stack – Reindex Script for Logs
Starting from this release for the Log Management and SIEM Feature module, if some logs have not been indexed correctly or not indexed at all, you can manually reindex them in Elasticsearch with the
elasticsearch-reindex-logs script that can be found in /usr/share/neteye/backup/elasticsearch/.
Additional information about the script can be found in User Guide > Troubleshooting.
Elastic Stack – Self Monitoring
In addition to the current self-monitoring, that verifies the correctness of the index and that all nodes are connected, from this release on, also the Logstash status is continuously checked by the NetEye Local Self Monitoring Mechanism.
SMS Notifications – Scripts
NetEye now includes two scripts to easily set up SMS notifications for hosts and services. A detailed guide on how to use them in your installation can be found in the User Guide > Initial Configuration > SMS Notification Setup.
Cluster – Self Monitoring
The NetEye Local Self Monitoring Mechanism has been enriched with a critical check that verifies the status of the File System of the resources managed by DRBD. In this way, any DRBD-related issue can be easily spotted.
Cluster – Setup simplification
The cluster service setup now allows a new parameter to specify a custom CIDR. If not specified, by default /24 will be used, to maintain backward compatibility. This prevents any manual intervention for customizing the cluster service setup script.
Moreover, we improved the cluster base setup script by adding the --force parameter (see User Guide > Initial Configuration > Cluster Installation). Now, in case of failures when running the cluster base setup script, simply run it again to overwrite the previous configuration attempt and thus avoiding any manual intervention.
Front End – Cluster awareness
The Front End is now cluster-aware: certificates and sessions used by httpd are moved alongside with the service. This solution allows to store the certificates in a centralized point and avoid session restart when httpd service moves to a different node.
Module Updates
- Elasticsearch from 7.3.1 to 7.5.1
- We suggest having a look at the new great features of Elasticsearch
- Logstash from 7.3.1 to 7.5.1
- Kibana from 7.3.1 to 7.5.1
- Filebeat from 7.3.1 to 7.5.1
- Search Guard from 7.x-37.0.0 to 7.x-40.0.0
- Grafana from 6.2.4 to 6.6.2
- Please have a look at the new Grafana features
- Nats Streaming from 0.11.0 to 0.17.0
- Nats Server from 1.3.0 to 2.1.4
Thomas Forrer
Author
