Two monitor processors run types

[mitar]

We should support two lists (types) of monitor processors, list of processors which we can run often and list of processors we can run less often. For example, we could have a list which just checks OLSR status and updates and we could run this every 30 seconds. And then another run which would run every 5 minutes to fetch all data from nodes.

So, we could have that user can define multiple lists. Or that there is a flag to the processor if it is "light" or "heavy" run. In general, we might want to support arbitrary number of such lists/types and leave to admin to define how often they want to be running. If using types, processors should know how to support them, if using queues, processors could be the same, but user could put them into multiple lists. The issue with lists is that some work could be duplicated.

Hm, in fact, this could be with our support for nested processors. We could have a processor RateLimit which would run its children only so and so often, the main processor loop would run much more often (like 30 seconds).

[mitar]

(It is possible that this was already planned and/or is supported. I might forget.)

[kostko]

Something similar was mentioned in ticket #298. I have closed that one as this now has more relevant information.

[mitar]

Support is now available for arbitrary monitor runs. By default we have three runs:

• topology from OLSR (every 1 minute), reads topology from local OLSR daemon, so we can do this often
• latency measurements (every 10 minutes), sends many ping packets of various sizes to all nodes, so we do not want to make too much load on the network too often
• telemetry fetching (every 5 minutes), fetches nodewatcher data from nodes