Process automation refers to the ability of a technological system to execute a series of tasks that were originally performed by humans. Such automation also controls, corrects and increases the visibility of the status of workflows and tasks, and generates reports throughout the process.
The primary benefits of procedure automation are most surely productivity and reliability. You save time and money by eliminating the lag between jobs and minimizing operator intervention. Once a job schedule is established, the automation software executes the commands precisely and in the correct sequence, eliminating operator error. Automated operations ensure that elements of each job are neither forgotten nor run out of sequence, that prerequisite jobs are completed successfully, that the input data is correct, and that any special processing has been performed.
The NetEye R&D team is an enthusiastic supporter of automation. Our goal is to ship a NetEye product that does not require anyone to perform a large number of manual actions in order to install and configure it.
One of the most annoying parts of the upgrade or installation procedure is the manual steps required to reload service configurations (e.g. service restart). Our first step towards automating a safe service restart is now included as part of the new NetEye 4.6 release.
We developed an intelligent algorithm that restarts a service when an update to that service is installed on the system. This script is automatically launched at the end of the
neteye_secure_install command. The logic behind this algorithm can be summarized by the following diagram.
Consider the Elasticsearch service, for instance. Once the service has been correctly restarted, a unique key with the service name and RPM version is saved, ensuring that no unnecessary service restarts will be performed in the future.
The first check this algorithm performs is determining whether the service needs to be restarted after an upgrade or not. To do that, it searches for the
unique service restart key. If this key is already saved in the system, no restart is needed.
If instead the service needs to be restarted, the algorithm determines whether it is a cluster resource or a local service.
This check ensures that if NetEye is running on a cluster and the service is local (as Elasticsearch is) then the restart will be correctly performed on each individual node.
If a service is not recognized as either a cluster resource or a local one, the system checks if it is installed on NetEye. If none of the related RPMs are found on the system, the algorithm skips the selected service (meaning that it is not installed on the system). Otherwise, it throws an error because it has found a broken service configuration.
Thanks to this new logic, the upgrade from NetEye 4.5 to 4.6 is quite smooth and has only a single, standard update procedure, with no special manual steps, for either single node or cluster installations.