Welcome to version 4.21 of our NetEye v4 Unified Monitoring Solution.
NetEye welcomes the winter season and its new release with a majestic snowy panorama view on the Sassolungo/Langkofel range in the Dolomites Alps.
Sassolungo/Langkofel is the highest mountain in the range, which also includes the Cinque Dita/Fünffinger and Sassopiatto/Plattkofel peaks and lays at the border between Val Gardena/Grödental and Val di Fassa, in the Southern Tyrolean Dolomites of Italy. The names translate to “long peak” or “long rock”, “five fingers”, and “flat peak” respectively, owing their names to their shape and appearance.
One of the main principles that guides the NetEye Extension Packs (NEP) project is that they need to be easily installed and set up in NetEye. As a step in this direction, now NEP can be easily installed as a standard RPM from the official NetEye Contrib repository.
Satellite updates, upgrades, and more generally NetEye itself rely on a series of services running on a NetEye Satellite to work correctly. To ensure that this is always the case, a new “systemd target”, dedicated to NetEye Satellite installations, has been created, taking care of starting, and restarting after reboot all services required by NetEye to function correctly.
In order to allow NetEye Satellites to be tailored to situational requirements, new service management capabilities have been added, allowing you to manually add more services to the NetEye Satellite systemd target with the use of a simple command.
One of the main focal points of this release was to render the creation and management of NetEye Satellites more comfortable. In this release, the downtimes for executing these tasks has been reduced to close to zero, as NetEye Satellite configuration and update/upgrade procedures no longer require the user to put cluster nodes in standby. This improvement does not introduce any breaking changes in procedures or configurations.
In the wake of further improving the user experience of the NetEye Satellite configuration procedure, we dramatically reduced the required time to a constant, varying only based on the size of the monitoring configuration, but independent of the number of Satellites.
This was accomplished by reducing the number of restarts of the Icinga2 daemon required for each batch of Satellites to configure to exactly one. In fact, now Icinga2 will restart only once at the end of the full configuration procedure, speeding up both the Satellite configuration and reducing downtimes.
To offer a safe, smooth, and reproducible update/upgrade experience, we refined our suite of update and upgrade tools to achieve a greater level of idempotence. After executing the
neteye update or
neteye upgrade command, it can be re-run as many times as needed to reach an up-to-date state. Subsequent runs of the same command will not run already-completed steps any more, keeping the system in a consistent state.
Moreover, with this release, the need for manual interaction is limited to the migration of existing user customizations. In particular, the
neteye update and
neteye upgrade commands now check for the presence of rpmnew/rpmsave files on the system for you. If none is detected, the remaining scripts of the upgrade procedure,
neteye_finalize_installation will be run automatically when required.
Detailed information is provided in the NetEye Update & Upgrade section of the User Guide.
Every NetEye installation can be adapted to fit every necessary use case, using a wide array of customizable monitoring checks. The performance data generated by these checks is collected by NetEye, allowing for numerical analysis of important aspects of the monitored assets. The performance graphs are the key to visualizing this data.
For this purpose, NetEye displays the performance graphs right inside the monitoring objects overview section, and allows giving context to the graphs’ raw numbers by e.g. scaling, adding units, or changing graph types. In this release, this configuration is shipped out-of-the-box for the most used check commands and services. The number of checks configured out the box will increase more and more with the next releases.
No manual configuration from the is needed, as everything is set up during the system installation or upgrade.
SLM reports now provide aggregated statistics to support the verification of SLAs for customers with more complex contract definitions. Specifically, now every report includes by default the measure of the average availability of all hosts and services in the time period. In addition, it is possible to add to the report a new calendar with the aggregate availability per calculation period.
Data Security has the highest priority in NetEye 4, especially in multi-tenancy environments. Sensitive information used in the monitoring configuration of one tenant must not be visible to other tenants. To ensure that this does not happen after a deployment, we added a section in our online user guide explaining the viable strategies to guarantee the confidentiality of data and why the most obvious (but inadequate) solution using director-global zones cannot provide this kind of isolation.
Detailed information is provided in the official NetEye User Guide.
Tornado now works in a multi-tenant fashion by associating every received event with a tenant. The tenant is inferred by the Tornado engine from the tenant associated with the Satellite that the event originates from.
The veracity of the tenant information is guaranteed by leveraging the multi-tenancy mechanism of the NATS messaging system, used for internal communication between collectors and the Tornado engine. The Tornado engine extracts the tenant identifier from the NATS subject and makes it available to use for creating tenant-aware filters and rules.
In distributed environments, events are now collected out-of-the-box on NetEye Satellites. When hosts cannot or must not contact the NetEye Master directly, they can be sent to a Satellite, which will forward all events via a NATS connection to the Master for processing.
The required setup of collectors on Satellites and the Tornado engine on the master is fully automated and also supports multi-tenant configurations from the get-go. In the case of a pre-existing conflicting configuration, you will be prompted to either migrate or adapt it.
This NetEye release features the new version of the processing tree, whose highlights are more user-friendly navigation and the ability to see the relationships among nodes, building on previous improvements in the Tornado UI, brought about by the Carbon Design System.
The visualization of node and rule details has been integrated into the processing tree, allowing you to see them without losing focus on the hierarchy.
In addition, this new Tornado interface supports multi-tenancy, therefore it is now possible to limit access to a given branch of the processing tree for each user by specifying the tenant’s name in the users’ NetEye roles.
Moreover, events can be tested from the UI, where the results will be visualized in the processing tree, including matched filters, rules and extracted variables.
Finally, the early preview mode is enabled by default, and we’d like to encourage all of you to give it a look and give us valuable feedback by using the banner on the Tornado UI dashboard.
Multi-tenancy support in the new Tornado UI requires the engine to authorize acting on only a specific branch of the processing tree. To achieve this, a new set of endpoints has been added to the Tornado engine.
These new endpoints offer more granular control in terms of security and payload. In fact, users are now limited in their actions based on their position in the processing tree, and based on their assigned roles.
Observability is an essential characteristic of modern software systems. Building on the foundations established in the previous releases, Tornado now further extends its observability by providing real-time metrics through a new monitoring endpoint, exposing them in the well-known and widely used Prometheus text format.
All the historical data of Tornado Monitoring and Statistics metrics will be collected every few seconds and stored in a dedicated InfluxDB database. To get insights on the behavior of Tornado, this data can be explored by creating dedicated ITOA dashboards.
Both ntopng and nProbe are now available in the latest stable version (5.0 and 9.6, respectively) to provide all the latest features, with focus on AIOps and Cybersecurity. For the complete list of features, please refer to the official NTOP blog
To support use cases where the user needs to acknowledge corruptions in the El Proxy blockchains without interacting with the shell, now all the information needed for the acknowledgement process can be passed as parameters to the “acknowledge” command.
The new Elastic Agent is now available in the NetEye repositories as Preview Software. This allows you to experiment with the functionalities of the Elastic Agent in advance with respect to the official integration of the agent in the NetEye environment.
We upgraded the Elastic Stack from 7.12.1 to 7.15.0. This upgrade includes the following features and many more:
Refer to the Elastic Stack release notes for additional information: