Welcome to version 4.27 of our NetEye v4 Unified Monitoring Solution.
This time, NetEye arrives at the same time as one of the most magical periods of the year. It’s, in fact, during the Christmas period that dozens of squares in the South-Tyrolean land are decked out to welcome thousands of people and give them a Christmas in true Alpine tradition. Stroll around the Christmas booths, eat typical sweet desserts like Zelten, Strudel, or Spitzbuben, and look for handcrafted realizations, often handmade on site, that may become original gift ideas: a unique opportunity to experience a moment of relaxation surrounded by South-Tyrolean tradition.
To identify a NetEye system globally, a unique NUUID (NetEye Universal Unique IDentifier) will be assigned to each NetEye Node. Red Hat Subscriptions are now bound to the NUUID.
For more information on the registration of NetEye nodes and NUUID, see the official user guide.
To allow users to access historical network flows and alerts, we integrated ntopng’s Historical Flows functionality in NetEye. Large infrastructures, that record millions of flows every minute, require a high-performance Database backend: the ClickHouse database, which is now integrated into NetEye.
On clusters, Clickhouse runs on each node, optimizing the load and data distribution.
In order to support the integration, we updated ntopng to the latest 5.4 stable release.
Guidelines for the configuration of Clickhouse’s and ntopng’s Retention Policies can be found in the dedicated user guide section.
To improve the readability and interpretation of Outages, they can now be ordered according to duration, start date, and end date, in both ascending or descending order. For each SLM report, you can individually configure how Outages are displayed.
You can refer to the official user guide.
A huge number of new features and bug-fixes are included in the new Icingaweb2 module vSphereDB version 1.5. Most notably, it is now possible to test the connection between the module and the configured vCenters directly from the UI, to insert monitoring rules for hosts and VMs based on memory and CPU consumption. Moreover, role restrictions can be defined to limit user access to specific vCenters.
Please have a look at the official documentation for the full list of improvements.
In multi-tenancy environments where Tenants need to store a lot of metrics in InfluxDB, it may be needed to store data of each Tenant on a different InfluxDB instance. To support this use case, from NetEye 4.27 each NetEye Tenant can be configured to write its metrics on a separate (existing) InfluxDB node.
Different types of metrics may need to have different retention policies, based on their importance and size. For this reason, from NetEye 4.27 the agents that produce the metrics will be able to specify under which InfluxDB retention policy those data must be written.
More information on the online user guide.
The new Alyvix module gives a clear view of test case runs:
you are now able to easily see which run is failing and which is performing correctly thanks to the list of runs in a new tab – called Reports – available in the details of a test case.
To visually analyze the root cause of a failed test case run by comparing screenshots of each transaction and their definitions, a report for each test case run is generated.
The communication between NetEye and Alyvix has been secured by introducing a JWT-based authentication. Only authenticated NetEye clients are now able to communicate with an Alyvix node.
In this release, we focused our efforts on the improvement of The NetEye Architecture. We structured more organically the content, added a new section to better describe the NetEye Master, including Multi-tenancy and updated information on Agents and their installation, and developed the NetEye Single Node, providing more information on this basic building block for any NetEye deployment. New diagrams to visually present the basic architecture were introduced.
The Glossary of the User Guide was updated with more terminology to simplify understanding of NetEye-specific entities and processes.
We also improved and fixed the directions to install NetEye Additional Components, making the procedure clearer in all the required steps.
Finally, we have changed the definition of the Cluster’s Elected NetEye Master into NetEye Active Node to prevent ambiguities and misunderstandings with the Master/Satellite architecture.
Should you be interested to discover more about NetEye feel free to explore our Online User Guide.