20. 12. 2024
Davide Sbetti
Automation, Development, NetEye
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.
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.
Author
Latest posts by Davide Sbetti
30. 03. 2026
APM, Log Management, Log-SIEM, NetEye
Sending OTel Data to Elasticsearch: Tenant Segregation through OAuth