-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement relative Operators #362
Comments
Adding operators is difficult as there are limits because of backwards compatibility. |
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. |
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 |
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.
The text was updated successfully, but these errors were encountered: