Implement relative Operators
Opened this issue · 4 comments
Related problem
When using the BPM to get an overview over a big and evolving landscape, the currently available Operators aren't always sufficient in meeting our needs. This becomes especially true when we want to monitor a growing environment in which the customer wants one third of the devices or services to be reachable, for example. With absolute operators, we would have to reevaluate which one fits best, which is an additional manual step, and might be forgotten.
Preferred solution
Implementing relative Operators allows administrators to choose between hard limits, which are for example more suited for monitoring Business Processes with fewer nodes, and adaptive thresholds, that might be more suited for larger and dynamic BPs. One such relative Operator could be MIN 33%, meaning that at least one third of the subnodes in this node need to be up.
Considered alternatives
Couldn't come up with any, although increasing the number of MIN Operators might also work.
Adding operators is difficult as there are limits because of backwards compatibility.
Maybe it is easier to add a property like weight to nodes and all nodes with weight get evaluated and if a hundred is reached all is well but one could grant nodes a weight higher then a hundred. So 33% would be a weight per node of (100 / number of nodes) * 3.
Defining a Goldilocks range from 100 to 1000 could also solve #319 so by adding a weight of 600 to every node more then one would be >1000 and functionally replace a MAX1 operator.
The weight system sounds very interesting as well, albeit adding some more complexity into the mix. Especially implementing a goldilocks system as well would kill two birds with one stone. Purely from a customer's perspective, adding both would be great; relative operators for quick and easy, weights for even more complex solutions to BPM.
Then again, adding one might prove sufficiently complex already, so asking for I won't dare asking for both. :)
The problem is that the module is in a dead end because of backwards compatibility and the config syntax has severe limitations.
Every operator is represented by a single char (only ASCII special chars and numbers). All the numbers are taken by MIN 1..9. .
This is why it's maybe easier to add a weight possibly as a special comment # weight: 600 and handle the rest in the GUI.