When Less is More: NetEye Update and Upgrade Checkpoints
Hello everyone!
Today, I’d like to briefly discuss an improvement to the update and upgrade procedures that we’ve started to adopt with NetEye 4.39!
What we wanted to improve
One aspect that made quite an impact was that whenever the update or upgrade procedure stopped, even for legitimate reasons such as rpmnew or rpmsave files, it took a certain amount of time to reach the same step upon relaunching.
And yes, it’s true that our procedure is based on Ansible and hence targets the maximum possible idempotence, but the evaluation of the each step (to understand if it needs to be performed or not) still requires some time, and especially in large environments, this may be a slowdown during the update and upgrade procedure.
How to solve this?
Okay, so how could we improve on this?
Well, the first aspect that we need to consider is that our procedure is generally divided into blocks, especially for those services that have a dedicated upgrade procedure. Simplifying a bit, we can summarize both procedures into something similar to the diagram below, where each block can be assumed to be a set of Ansible tasks:
Now, NetEye 4.39 brings the architecture to a point where potentially upon the successful conclusion of a block, we can set a checkpoint! What do we mean by a checkpoint?
Well, it’s just a way to signal that, for that particular procedure (round of update or upgrade to a specific version), a specific step has already been performed successfully.
Why does this help? Because if the procedure stops at a later point, relaunching it will then allow us to skip all those blocks up to the last successful checkpoint, without having to “enter the block” and evaluate the conditions of all single Ansible tasks that made up that block, leading to quite a significant speed-up!
What NetEye 4.39 brings, concretely
Okay, so that’s the general idea. Now, what does NetEye 4.39 bring?
First of all it updates the architecture, allowing us to set, retrieve and evaluate the checkpoints.
Further, it already applies some checkpoints, which can already play a role in the upgrade from NetEye 4.38 to NetEye 4.39, to the update and upgrade procedures of the Elastic Stack components (yes, all of them!) and to the secure install stages, as shown below:
Of course, we look forward to an expansion of the checkpoints to all “blocks” of our procedures to ensure a smoother and faster experience during updates and upgrades.
See you at the next blog post and… happy holidays 🎅❄️
These Solutions are Engineered by Humans
Did you find this article interesting? Are you an “under the hood” kind of person? We’re really big on automation and we’re always looking for people in a similar vein to fill roles like this one as well as other roles here at Würth Phoenix.
Hi! I'm Davide and I'm a Software Developer with the R&D Team in the "IT System & Service Management Solutions" group here at Würth IT Italy. IT has been a passion for me ever since I was a child, and so the direction of my studies was...never in any doubt! Lately, my interests have focused in particular on data science techniques and the training of machine learning models.
Author
Davide Sbetti
Hi! I'm Davide and I'm a Software Developer with the R&D Team in the "IT System & Service Management Solutions" group here at Würth IT Italy. IT has been a passion for me ever since I was a child, and so the direction of my studies was...never in any doubt! Lately, my interests have focused in particular on data science techniques and the training of machine learning models.
Bug Fix We updated the version of GLPI in order to fix some relevant vulnerabilities. List of updated packages The following packages have been updated for NetEye 4.45: glpi, glpi-autosetup, glpi-configurator, glpi-neteye-config to version 10.0.22_neteye1.17.5-1.
Bug Fix in Tornado Module We solved an issue in Tornado's rule configuration where the action_name field in director actions was being cleared after saving and deploying. When users created a rule with a director action and filled in both Read More
Important: Elastic Stack security update Type/Severity NetEye Product Security has rated this update as having a High security impact. Topic An update for the elastic-stack packages (elasticsearch, kibana, filebeat, logstash and elastic-agent) is now available for NetEye 4. Security Fix for NetEye 4.45 Read More
Elastic Enterprise license renewal Previously, the Elastic Enterprise license was scheduled to expire on February 28, 2026.With this update, the Elastic Enterprise license has been renewed and will now expire on December 31, 2026. In the case the health-check light/01004_elastic_license_check.sh is preventing Read More
Important: Elastic Stack security update Type/Severity NetEye Product Security has rated this update as having a High security impact. Topic An update for the elastic-stack packages (elasticsearch, kibana, filebeat, logstash and elastic-agent) is now available for NetEye 4. Security Fix for NetEye 4.45 Read More