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

GLPI Bundled Plugins

NetEye 4.50 comes with a set of bundled plugins for GLPI, available by default in the GLPI container. These plugins are shipped in the folder /usr/share/glpi/plugins and can be installed and enabled directly from the GLPI web interface. The complete list of bundled plugins is available in the Plugins section.

During the upgrade, all the plugins present in /usr/share/glpi/plugins and included in that list will be moved to a backup directory /root/glpi_plugins_backup. All the other plugins, except for icingaweb2sso and inventorymultitenancy, will be moved to the directory /neteye/shared/glpi/data/marketplace.

From NetEye 4.50, you can add a plugin to GLPI by placing the plugin files in the folder /neteye/shared/glpi/data/marketplace on the host system.

Elastic Stack Upgrade to v9.5

In NetEye 4.50, Elastic Stack upgrades from version 9.4 to 9.5. To ensure compatibility, review the official breaking changes linked below:

• Elasticsearch

• Kibana

• Elastic Agent

• Logstash

• Beats

Icinga 2 Upgrade to v2.16

NetEye 4.50 upgrades Icinga 2 from version 2.15 to 2.16.

Please review the official upstream upgrade guide.

To address the deprecations regarding ElasticsearchWriter, Elasticsearch Datastream Writer and FilterExpression permission, please refer to the 4. Additional Tasks section.

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.

5. NetEye services are progressively moving to Kubernetes to improve scalability, security, resource management and the speed of updates.

   Access to the following domains is not strictly required to upgrade to NetEye 4.50, but we recommend configuring it in advance. It will be mandatory before upgrading to NetEye 4.51, allowing Kubernetes to retrieve the container images required during the upgrade and subsequent updates. Ensure that all NetEye nodes can reach these domains over HTTPS (TCP port 443):

   Domain	Port	Intended Use
   ghcr.io	443 TCP	GitHub container images
   api.github.com	443 TCP	GitHub container images
   pkg-containers.githubusercontent.com	443 TCP	GitHub container images
   quay.io	443 TCP	Quay container images
   cdn01.quay.io	443 TCP	Quay container images
   docker.io	443 TCP	Docker Hub container images
   hub.docker.com	443 TCP	Docker Hub container images
   auth.docker.io	443 TCP	Docker Hub container images
   index.docker.io	443 TCP	Docker Hub container images
   registry-1.docker.io	443 TCP	Docker Hub container images
   production.cloudfront.docker.com	443 TCP	Docker Hub container images
   *.cloudflarestorage.com	443 TCP	Container images
   rpm.rancher.io	443 TCP	Rancher packages
   docker.elastic.co	443 TCP	Elastic container images (only with the Elastic Stack)
   docker-auth.elastic.co	443 TCP	Elastic container images (only with the Elastic Stack)

Important

If you are using NetEye Extra Packages (NEP) with multi-tenancy:

• The custom variable nx_neteye_tenant has been deprecated and replaced by neteye_tenant.

• Prior to upgrading your installed NEPs, verify that the neteye_tenant variable is correctly set on all relevant Host Objects.

• For complete details, refer to the NEP Updates and Upgrades 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

Icinga 2 v2.16 migration tasks

This section explains how to migrate Icinga 2 features ElasticsearchWriter and ElasticsearchDatastreamWriter that have been deprecated in v2.16 and will be removed in future releases. Moreover, it explains how to migrate to the new FilterExpression permission that will also be enforced in future releases.

These procedure should be executed after the NetEye 4.50 upgrade, to ensure a smooth transition to future NetEye versions.

FilterExpression Permission

Icinga 2 v2.16 introduces the FilterExpression permission, which controls whether an ApiUser is allowed to use DSL filter expressions in API requests. This permission is required for future Icinga 2 releases and should be prepared in advance.

In NetEye 4.50, existing API users can still use DSL filters, since the permission is not yet fully enforced. Starting with the next upstream Icinga 2 release (v2.17), however, it will be enforced and access will be denied unless the permission is explicitly granted.

To prepare your environment, review all Icinga2 ApiUser entries and enable FilterExpression for those users that need to query the API with DSL filters.

NetEye also provides a service check named neteye-local!icinga2-filter-expression-permission-configured-neteyelocal, which enters a warning state when an ApiUser has used DSL filters in the last 24 hours without the FilterExpression permission enabled. This allows you to identify affected users before the permission becomes mandatory.

For more information you can refer to the official Icinga 2 documentation.

Deprecation of ElasticsearchWriter and Elasticsearch Datastream Writer

Starting with Icinga 2 v2.16, the legacy ElasticsearchWriter and ElasticsearchDatastreamWriter Icinga2 features are deprecated and will be removed in a future NetEye release. They are replaced by the upstream OTLPWriter model, which is exposed in NetEye through the NetEye OTLPMetrics Writer feature.

If your environment still uses either of these legacy writers, you should migrate to the recommended OTLP-based solution to ensure compatibility with future NetEye releases.

To migrate, disable the deprecated Icinga 2 feature, enable the new OTLP-based writer as explained in NetEye OTLPMetrics Writer, and review any dashboards, integrations, or alerting rules that still depend on the previous datastream naming and structure. If needed, update them to use the new Elasticsearch datastreams produced by the OTLP metrics workflow.

NEP Variable Cleanup (nx_neteye_tenant)

Following the upgrade of NetEye and all installed NetEye Extra Packages (NEP), the legacy custom field nx_neteye_tenant is no longer required and can be safely deleted:

1. In the NetEye UI, navigate to Director > Define Data Fields (under Do more with custom data).

2. Search for nx_neteye_tenant and select it.

3. Click Delete, set Wipe related vars to Yes, and confirm deletion.

4. Repeat if multiple field instances exist.

For more details on this change, please consult the NEP Updates and Upgrades section.