Skip to content
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

Open
Nayakum opened this issue Oct 10, 2022 · 4 comments
Open

Implement relative Operators #362

Nayakum opened this issue Oct 10, 2022 · 4 comments

Comments

@Nayakum
Copy link

Nayakum commented Oct 10, 2022

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.

@slalomsk8er
Copy link

slalomsk8er commented Oct 12, 2022

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.

@slalomsk8er
Copy link

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.

@Nayakum
Copy link
Author

Nayakum commented Oct 25, 2022

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. :)

@slalomsk8er
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants