User Guide Functional Overview Requirements Architecture System Installation NetEye Additional Components Installation Setup The neteye Command Director NetEye Self Monitoring Tornado Business Service Monitoring IT Operation Analytics - Telemetry Geo Maps NagVis Audit Log Shutdown Manager Reporting ntopng Visual Monitoring with Alyvix Elastic Stack IT Operations (Command Orchestrator) Asset Management Service Level Management Cyber Threat Intelligence - SATAYO NetEye Update & Upgrade How To NetEye Extension Packs Troubleshooting Security Policy Glossary
module icon NetEye Update & Upgrade
Before you start Update Procedure Single Node Upgrade from 4.44 to 4.45 Cluster Upgrade from 4.44 to 4.45 Satellite Upgrade from 4.44 to 4.45 DPO machine Upgrade from 4.44 to 4.45 Create a mirror of the RPM repository Sprint Releases Feature Troubleshooting
NetEye Update & Upgrade How To NetEye Extension Packs Troubleshooting Security Policy Glossary Introduction to NetEye Monitoring Business Service Monitoring IT Operation Analytics Visualization Network Visibility Log Management & Security Orchestrated Datacenter Shutdown Application Performance Monitoring User Experience Service Management Service Level Management & Reporting Requirements for a Node Cluster Requirements and Best Practices NetEye Satellite Requirements TCP and UDP Ports Requirements Additional Software Installation Introduction Single Node Cluster NetEye Master Master-Satellite Architecture Underlying Operating System Acquiring NetEye ISO Image Installing ISO Image Single Nodes and Satellites Cluster Nodes Configuration of Tenants Satellite Nodes Only Nodes behind a Proxy Additional NetEye Components Single Node Cluster Node Satellites Nodes only Verify if a module is running correctly Accessing the New Module Cluster Satellite Security Identity and Access Management External Identity Providers Configure federated LDAP/AD Emergency Reset of Keycloak Configuration Advanced Configuration Roles Single Page Application in NetEye Module Permissions and Single Sign On Within NetEye Importing User Federation Groups inside another Group Importing OIDC IdP Groups inside another Group Resources Tuning Advanced Topics Basic Concepts & Usage Advanced Topics Monitoring Environment Templates Monitored Objects Import Monitored Objects Data Fields Deployment Icinga 2 Agents Configuration Baskets Dashboard Monitoring Status VMD Permissions Notifications Jobs API Configuring Icinga Monitoring Retention Policy NetEye Self Monitoring Concepts Collecting Events Add a Filter Node WHERE Conditions Iterating over Event fields Retrieving Payload of an Event Extract Variables Create a Rule Tornado Actions Test your Configuration Export and Import Configuration Example Under the hood Development Retry Strategy Configuration Thread Pool Configuration API Reference Configure a new Business Process Create your first Business Process Node Importing Processes Operators The ITOA Module Configuring User Permissions Telegraf Metrics in NetEye Telegraf Configuration Telegraf on Monitored Hosts Visualizing Dashboards Customizing Performance Graph The NetEye Geo Map Visualizer Map Viewer Configuring Geo Maps NagVis Audit Log Overview Shutdown Manager user Shutdown Manager GUI Shutdown Commands Advanced Topics Overview User Role Management Cube Use Cases ntopng and NetEye Integration Permissions Retention Advanced Topics Overview User Roles Nodes Test Cases Dashboard Use Cases Overview Architecture Authorization Kibana Elasticsearch Cluster Elasticsearch Configuration Replicas on a Single Node Elasticsearch Performance tuning Overview Enabling El Proxy Sending custom logs to El Proxy Configuration files Commands Elasticsearch Templates and Retentions El Proxy DLQ Blockchain Verification Handling Blockchain Corruptions El Proxy Metrics El Proxy Security El Proxy REST Endpoints Agents Logstash Elastic APM Elastic RUM Elastic XDR Log Manager - Deprecated Overview Authorization in the Command Orchestrator Module Configuring CLI Commands Executing Commands Overview Permissions Installation Single Tenancy Multitenancy Communication through a Satellite Asset collection methods Display asset information in monitoring host page Overview Customers Availability Event Adjustment Outages Resource Advanced Topics Introduction Getting Started SATAYO Items Settings Managed Service Mitre Attack Coverage Changelog Before you start Update Procedure Single Node Upgrade from 4.44 to 4.45 Cluster Upgrade from 4.44 to 4.45 Satellite Upgrade from 4.44 to 4.45 DPO machine Upgrade from 4.44 to 4.45 Create a mirror of the RPM repository Sprint Releases Feature Troubleshooting Tornado Networking Service Management - Incident Response IT Operation Analytics - Telemetry Identity Provider (IdP) Configuration NetEye Cluster on Microsoft Azure Introduction to NEP Getting Started with NEPs Online Resources Obtaining NEP Insights Available Packages Advanced Topics Upgrade to NetEye 4.31 Setup Configure swappiness Restarting Stopped Services Enable stack traces in web UI How to access standard logs Director does not deploy when services assigned to a host have the same name How to enable/disable debug logging Activate Debug Logging for Tornado Modules/Services do not start Sync Rule fails when trying to recreate Icinga object How to disable InfluxDB query logging Managing an Elasticsearch Cluster with a Full Disk Some logs are not indexed in Elasticsearch Elasticsearch is not functioning properly Reporting: Error when opening a report Debugging Logstash file input filter Bugfix Policy Reporting Vulnerabilities Glossary

Cluster Upgrade from 4.44 to 4.45

This guide will lead you through the steps specific for upgrading a NetEye Cluster installation from version 4.44 to 4.45.

During the upgrade, individual nodes will be put into standby mode. Thus, overall performance will be degraded until the upgrade is completed and all nodes are revoked from standby mode. Granted the environment connectivity is seamless, the upgrade procedure may take up to 30 minutes per node.

Warning

Remember that you must upgrade sequentially without skipping versions, therefore an upgrade to 4.45 is possible only from 4.44; for example, if you have version 4.27, you must first upgrade to the 4.28, then 4.29, and so on.

Breaking Changes

Ansible 2.16

Ansible has been upgraded to version 2.16. If you have any custom Ansible playbooks, please ensure they are compatible with this version. Refer to the following official release notes for more information:

IcingaDB Web

Since this version of NetEye, the monitoring module has been replaced by IcingaDB Web. This leads to an improved user interface for various pages like Overview, Hosts, Services, Problems and more. The historical data, under the hood, is still saved and loaded from IDO as before and only in next releases will be possible to migrate historical data to IcingaDB and consequently disable IDO.

Due to these changes, the following breaking changes apply:

IcingaDB and monitoring roles

The restrictions and permissions for the monitoring objects are applied in a slightly different way in IcingaDB.

Example 1

Assume to have the following roles configured:

  • Role A

    • Restrictions: Host group = “GroupA”

    • Permissions: General module access

  • Role B

    • Restrictions: Host group = “GroupB”

    • Permissions: General module access + Downtime management

Assume the two roles are not inherited by each other and they are assigned to user Bob.

Old behavior (monitoring module):

  • Bob can see hosts from both GroupA and GroupB in the Hosts list.

  • Bob can schedule downtimes for GroupA and GroupB hosts.

New behavior (IcingaDB Web):

  • Bob can see hosts from both GroupA and GroupB in the Hosts list.

  • Bob can schedule downtimes only for GroupB hosts.

Example 2

Assume to have the following roles configured:

  • Role A

    • Restrictions: Host group = “GroupA”

    • Permissions: General module access

  • Role B

    • Permissions: General module access + Downtime management

    • Inherits Role A

User Alice is assigned to Role B.

The behavior is not changed between monitoring module and IcingaDB Web:

  • Alice can see hosts from GroupA.

  • Alice can schedule downtimes for GroupA hosts.

Example 3

Assume to have the following roles configured:

  • Role A

    • Restrictions: Host group = “GroupA”

    • Permissions: General module access

  • Role B

    • Restrictions: Host group = “GroupB”

    • Permissions: General module access

  • Role C

    • Permissions: General module access + Downtime management

User Charlie is assigned to Role A, Role B and Role C.

The behavior is not changed between monitoring module and IcingaDB Web:

  • Charlie can see hosts from both GroupA and GroupB in the Hosts list.

  • Charlie can schedule downtimes for GroupA and GroupB hosts.

For more information about this new behavior, please refer to the official blog post.

Monitoring URLs have changed

If you have any custom links or bookmarks that point to the old monitoring module pages, please update them in order to point to the new IcingaDB Web pages.

Monitoring View Permission Changes

Due to the migration of monitoring to IcingaDB, some permissions related to the Monitoring View module have been modified. Since the sections in the host and service pages changed slightly, the permission monitoringview/problem-handling is no longer applicable and it has been removed.

To replace its functionality, the following new permissions have been added:

  • monitoringview/actions

  • monitoringview/comments

  • monitoringview/downtimes

  • monitoringview/groups

  • monitoringview/services

In order to maintain the previous behavior, and avoid to hide sections that were previously visible, these new permissions are automatically granted to roles that had the monitoringview/problem-handling permission.

Additionally, the permission monitoringview/check-execution has been renamed to monitoringview/check-statistics without any change in functionality.

Prerequisites

Before starting the upgrade, carefully read the latest release notes on NetEye’s blog and check the features that will change or be deprecated.

  1. All NetEye packages installed on a currently running version must be updated according to the update procedure prior to running the upgrade.

  2. NetEye must be up and running in a healthy state.

  3. Disk Space required:

    • 3GB for / and /var

    • 150MB for /boot

  4. If the NetEye Elastic Stack module is installed:

    1. The rubygems.org domain should be reachable by the NetEye Master only during the update/upgrade procedure. This domain is needed to update additional Logstash plugins and thus is required only if you manually installed any Logstash plugin that is not present by default.

1. Run the Upgrade

The Cluster Upgrade is carried out by running the following command:

cluster# (nohup neteye upgrade &) && tail --retry -f nohup.out

Warning

If the NetEye Elastic Stack feature module is installed and a new version of Elasticsearch is available, please note that the procedure may take a while to upgrade the Elasticsearch cluster. For more information on the Elasticsearch cluster upgrade and how to customize the upgrade process, please consult the dedicated section.

After the command was executed, the output will inform if the upgrade was successful or not:

  • In case of successful upgrade you might need to restart the nodes to properly apply the upgrades. If the reboot is not needed, please skip the next step.

  • In case the command fails refer to the troubleshooting section.

2. Reboot Nodes

Restart each node, one at a time, to apply the upgrades correctly.

  1. Run the reboot command

    cluster-node-N# neteye node reboot

  2. In case of a standard NetEye node, put it back online once the reboot is finished

    cluster-node-N# pcs node unstandby --wait=300

You can now reboot the next node.

3. Cluster Reactivation

At this point you can proceed to restore the cluster to high availability operation.

  1. Bring all cluster nodes back out of standby with this command on the last standard node

    cluster# pcs node unstandby --all --wait=300
cluster# echo $?

    0

    If the exit code is different from 0, some nodes have not been reactivated, so please make sure that all nodes are active before proceeding.

  2. Run the checks in the section Checking that the Cluster Status is Normal. If any of the above checks fail, please contact our service and support team before proceeding.

  3. Re-enable fencing on the last standard node, if it was enabled prior to the upgrade:

    cluster# pcs property set stonith-enabled=true

4. Additional Tasks

In this release, there are no additional tasks required after upgrading NetEye.

Blog Online Demo Training
Contact Us
© 2025, Würth IT Italy s.r.l.
VAT ID 01054690217
Privacy Cookies