Monday, 2 April 2018

Worker - what does it do exactly?

First question is why we need the workers at all? Without them the Reaction Engine wouldn't be able to be notified about incidents and OS commands (the parts of the remedy process) couldn't be executed.

Let's assume there are 5 applications that have to be monitored and fixed and 2 of the applications have 4 instances (the remaining 3 applications reside in separate server machines). It means that the reader workers have to be installed on 2 * 4 + 3 = 11 server machines.
It seems a lot but one reader worker can monitor more applications (more precisely it can read more log files that belong to the business applications) on the host machines where it was installed to. Every log reading process runs in a separate thread.

When the reader worker reported a possible incident and it turns out in the Reaction Engine that it is really a problem that has to be dealt with then the engine will start an execution flow (which is a series of OS commands). These commands will be executed serially by the executor worker.
How can the executor worker get the command to be executed? All the executor workers poll the Engine (i.e. call a specific REST service every x seconds) and only that executor will receive the command in the REST response where the OS command has to be executed. After the execution of the OS command the result / output will be sent back to the Engine and the next command (if it was successful) will be called by an executor worker.

So the reader / executor workers are like the ants which serve the Reaction Engine (the queen ant) with information but they are vital to make the whole Reaction system work.

In the next blog I will explain how to make the worker work.

No comments:

Post a Comment

Worker - let's make it work