For each monitor, we need a monitoring listener, that is able to reflect the current state of tasks, nodes, etc. on to the respective monitoring agents, and keeps track of changing entities and keep the state to the monitoring agent synchronous.
Monitoring listener algorithm (first draft):
- Persist the model in a database (or keep it implicitely through the current state in visor)
- Send response to the monitoring messages to the Kafka queue (Protobuff)
- Set a listener to the messages of the respective targets (newJob, newProcess, deleteProcess, etc.)
- For each existing target (not necessary if you use historic data of the queue, instead of latest state - CAUTION: creating the latest view on the system based on historic messages can be complex):
a) instrument Visor
- For each listener:
a) receive messages
b) filter relevant messages
c) change db (if not implicit view is chosen)
d) instrument visor -> error? -- retry logic = Taskqueue - ExecutionService
e) go to a)
For each monitor, we need a monitoring listener, that is able to reflect the current state of tasks, nodes, etc. on to the respective monitoring agents, and keeps track of changing entities and keep the state to the monitoring agent synchronous.
Monitoring listener algorithm (first draft):
a) instrument Visor
a) receive messages
b) filter relevant messages
c) change db (if not implicit view is chosen)
d) instrument visor -> error? -- retry logic = Taskqueue - ExecutionService
e) go to a)