NetEye Install and Upgrades: Moving to a Parallel Architecture
Hello everyone!
Today, I’d like to share an exciting improvement we’ve made to the installation and upgrade procedures in NetEye, introducing a faster and more efficient parallel architecture!
Why Modernize the Installation and Upgrade Processes?
At Würth Phoenix, we strive to make NetEye not only powerful but also highly efficient and reliable for our users. Yet until recently, the core installation and upgrade procedures of NetEye revealed some issues in their efficiency and maintainability.
The original architecture relied on a sequential execution of scripts, resulting in long execution times, difficult maintenance, and challenges in scaling. For instance, installing NetEye in a cluster setup required manual intervention to orchestrate the scripts node-by-node, a time-intensive process.
We realized that in today’s fast-paced IT environments, where businesses demand agility and resilience, we needed a more modern, maintainable approach. That’s why we embarked on a journey to transition these operations to a parallel architecture.
How a Parallel Approach Transformed NetEye
The foundation of our transformation lies in Ansible, an agentless IT automation tool that enables repeatable, idempotent configurations. We began by replacing our sequential scripting framework with Ansible playbooks, ensuring consistency and reliability regardless of the system’s state.
The highlight of this effort was the creation of a Python-based module that orchestrates the parallel execution of services while respecting interdependencies. Each service defines its dependencies in a JSON file, and the module builds a dependency graph to determine the optimal execution sequence.
This approach significantly reduced execution times for us. For instance, processes that previously took minutes to complete now execute in just a few seconds, a very dramatic improvement.
Challenges Along the Way
Transitioning to a parallel architecture was not without its hurdles. As we migrated from our legacy system, ensuring team-wide adoption and minimizing disruptions became key priorities. We tackled these challenges using Agile methodologies:
Iterative Migration: We introduced the new command neteye install alongside the existing neteye_secure_install for a seamless transition
Continuous Feedback: We conducted frequent reviews and tests to validate changes before deprecating legacy components
Documentation and Training: We produced clear guides and tutorials to ensure both developers and users could adapt to the new procedures
These practices allowed us to manage change effectively and keep our development teams aligned.
What’s Next for NetEye?
While the transition to a parallel architecture has delivered significant performance gains and simplified maintenance, there are several areas where further improvements could enhance the system even more:
Comprehensive Documentation: Ensuring thorough and up-to-date documentation is crucial for maintaining continuity and for easing the onboarding process for new team members. Clear, detailed guides will support both developers and users in navigating the updated procedures effectively.
Continuous Optimization of Parallelization: Although the current implementation has significantly reduced execution times, there is still potential for refinement. Enhancing the logic behind dependency management and service configuration could lead to even greater reductions in execution time and resource utilization.
Advanced Monitoring and Logging: Introducing a more sophisticated monitoring and logging system for installation and upgrade processes will improve reliability by enabling quicker identification and resolution of potential issues. Enhanced logs and dashboards will provide deeper insights into performance and errors, making the system even more robust.
Our work demonstrates how modernizing infrastructure can unlock new efficiencies and make life easier for both developers and users.
Conclusion
The shift to a parallel architecture for NetEye installation and upgrades wasn’t just about improving performance – it was also about building a foundation for scalability, reliability, and innovation. At Würth Phoenix, we’re committed to continuously improving NetEye to meet the evolving needs of our customers.
Have you undertaken similar migrations in your own projects? Share your experiences with us in the comments!
We have resolved an issue that prevented Elastic Agents from successfully connecting to the Fleet Server when their requests were excessively large. Additionally, we addressed a bug in the neteye update and neteye upgrade processes, which was incorrectly initiating a Read More
We fixed a bug which was causing Elastic Agents to disconnect themselves at regular intervals from Fleet. We updated the following packages: elastic-agent, elastic-agent-autosetup, elastic-agent-neteye-config, filebeat, filebeat-autosetup, filebeat-neteye-config, logstash, logstash-neteye-config, logstash-autosetup, logstash-neteye-config-autosetup, kibana, kibana-autosetup, kibana-neteye-config, elasticsearch, elasticsearch-autosetup, elasticsearch-neteye-config, elasticsearch-xpack-license to Read More
When using Kibana in environments that require a proxy to reach external services, you might encounter issues with unrecognized SSL certificates. Specifically, if the proxy is exposed with its own certificate and acts as an SSL terminator, requests made by Read More
In a previous post we went through the configuration of Elastic Universal Profiling in NetEye, seeing how we can profile applications written in programming languages that do not compile to native code (for example Python, PHP, Perl, etc.) But what Read More
Elastic 8.16, which comes with NetEye 4.39, made Elastic Universal Profiling generally available for self-hosted installations. This means that NetEye SIEM installations will now be able to take advantage of the continuous profiling solution by Elastic. In this blog post Read More