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.Cloud Solution Monitoring Asset Management SOC System Administrator SOC Attacker Centric Cyber Threat Intelligence - SATAYO NetEye Update & Upgrade Backup and Restore How To NetEye Extension Packs Troubleshooting Security Policy Glossary
module icon NetEye Update & Upgrade
Before you start Update Procedure Single Node Upgrade from 4.49 to 4.50 Cluster Upgrade from 4.49 to 4.50 Satellite Upgrade from 4.49 to 4.50 DPO machine Upgrade from 4.49 to 4.50 Create a mirror of the RPM repository Sprint Releases Feature Troubleshooting
NetEye Update & Upgrade Backup and Restore 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 Kubernetes 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 Satellites Nodes only Verify if a module is running correctly Accessing the New Module Cluster Satellite Security Backup and Restore Identity and Access Management External Identity Providers Configure federated LDAP/AD Emergency Reset of Keycloak Configuration Keycloak Hostname 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 Resource 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 Integration with Elasticsearch 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 Grafana 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 RDP Client Building Tools Editor: Interface Overview Editor: Script Building Editor: Managing Scripts Designer: Interface Overview Designer: Interface Options Designer: Component Tree Selector: Interface Overview Test Case Management 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 Rsyslog Elastic APM Elastic RUM Multitenant OpenTelemetry Collector Elastic XDR 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 The Intelligence We Produce Mitre Attack Coverage Getting Started Settings SATAYO Items Intelligence Requirements Managed Service Request Form FAQ Changelog SATAYO Community NetEye.Cloud as a SaaS solution NetEye.Cloud Subscription Base Concepts Authentication Options Authentication via IdP Group Claims for Authorization Management Authentication via Microsoft Entra ID Authorization Navigating the UI Monitoring with NetEye.Cloud Monitored Objects Finding and Filtering Hosts Exporting Monitoring Data Viewing Host and Service Details Organizing with Groups Tactical Overview Problems View Dashboard Scheduled Downtime Business Service Monitoring VMD Asset Management in NetEye.Cloud Automatic Inventory Collection Software & License Management Contract & Supplier Management Change & Lifecycle Management SOC System Administrator (AdS) Access to NetEye and Elastic Elastic Dashboards Elastic Discover Elastic Alerts Elastic Rules Introduction to SOC Attacker Centric Service Description NetEye SIEM About SATAYO Threat Intelligence and Security Operations How SATAYO works MITRE ATT&CK Coverage SATAYO Findings SaaS & Managed Mode Before you start Update Procedure Single Node Upgrade from 4.49 to 4.50 Cluster Upgrade from 4.49 to 4.50 Satellite Upgrade from 4.49 to 4.50 DPO machine Upgrade from 4.49 to 4.50 Create a mirror of the RPM repository Sprint Releases Feature Troubleshooting Backup and Restore Tornado Networking Service Management - Incident Response IT Operation Analytics - Telemetry Identity Provider (IdP) Configuration NetEye Cluster on Microsoft Azure NetEye Cluster on AWS Introduction to NEP Getting Started with NEPs Online Resources Obtaining NEP Insights Available Packages Advanced Topics NEP Updates & Upgrades 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.49 to 4.50

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

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.50 is possible only from 4.49; for example, if you have version 4.27, you must first upgrade to the 4.28, then 4.29, and so on.

Breaking Changes

No breaking changes are present in this release.

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.

    2. There is a number of configuration items that should not be modified in order to avoid issues during the update/upgrade of your instance. Please check out Protected Configuration Items for details.

    3. Port 4317 should be available on the NetEye Master nodes to allow the deployment of the new Multitenant OpenTelemetry Collector component, which is used to collect and forward telemetry data to the Elastic Stack.

  5. To prepare for integration of RKE2, please ensure that the following requirements are met:

    • The system must have at least 12GB of disk space available on the /neteye/local/rke2 directory for the RKE2 installation.

    Note

    It is recommended to create a separate logical volume for the /neteye/local/rke2 directory to avoid running out of disk space on the root filesystem.

    • The following ports must be available for RKE2 to function properly on 0.0.0.0:

      • TCP 6442: load balancer for the Kubernetes API server

      • TCP 6443: Kubernetes API server

      • TCP 6444: used in case of restore procedures

      • TCP 9345: RKE2 local supervisor

      • TCP 9346: load balancer for the RKE2 local supervisor

    • RKE2 official RPM repository must be reachable from the NetEye system. The repository URL is https://rpm.rancher.io/.

    • In case of cluster installations, you must ensure the correct roles are assigned to the nodes in order to meet the minimum requirements for a Kubernetes cluster. For more information on the roles and their requirements, please refer to the Kubernetes roles section.

    • You should have created and synced on all nodes the /etc/neteye-environment.yaml. For more information please refer to Step 9 of the Part 1: Single Nodes and Satellite Nodes section.

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. 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.

  2. 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

The IDO database is not removed automatically during the upgrade, so if you want to delete it you have to run the following commands:

mysql -e "DROP DATABASE icinga;"
mysql -e "DROP USER 'icinga'@'localhost';"

If you have the Elastic Stack installed, the retention-policy-neteyelocal service will be removed during the upgrade procedure. After the upgrade is complete, you will need to Director deploy to make the changes effective.

Keycloak Hostname Strict Mode

To avoid disrupting existing installations, the upgrade keeps KC_HOSTNAME_STRICT disabled (false), so the public hostname continues to be resolved dynamically from incoming requests.

Important

Configuring a fixed hostname is a prerequisite for upgrading to NetEye 4.50. This requirement is enforced for security reasons. Follow the Keycloak Hostname Configuration section to complete this configuration.

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