False positives avoidance

[corez]

Thanks for all answers.
I got one another, is check_multi plugin correct to achive i described or i should strongly use BPI?
Because i've found BPI complex and looks like check_multi is more sophisticated.

[eloyd]

Never used check_multi, so I do not know.

[rhassing]

I also never used this check.
In my case all the engineers are skilled enough to see what business processes will fail if a service check is critical.

I would rather have multiple checks which can be acknowledged as a single check than have just the one check.

But that could be different for everybody.

[eloyd]

Edit: Proper grammar in my final sentence.

Again, never having used check_multi, its documentation says,

The child return code with the highest severity becomes the parent (check_multi) plugin return code

That is different from BPI, which lets you assign a weighted value to each service check in the group, and then the entire BPI check is warning or critical only if the total weighted value is above a threshold.

It sounds like check_multi is a little bit different from what you are trying to accomplish.

[tmcdonald]

check_multi is probably what you want if you want only one Nagios service that does multiple things.

[sreinhardt]

Agreed, check_multi is a very different beast, and the quote you mentioned is one of the prime reasons why. BPI while complex, allows for logical dependencies and relatively easy configuration depending on what you are attempting to do. Check_multi is fine, but it does not concern itself with what you may consider most important, unless you setup the checks very specifically. Even then, there is a fairly decent chance that it may not have the logic you are looking for, as eloyd mentioned, because it just uses the worst of the severity. i would argue that check_multi is much closer related to check_cluster than bpi, but that's just my 2 cents.

[meliezer]

The short version is that you can create a group of services (those three, for instance) that only triggers a warning if a percentage of results are in a warning state. So if you want to wait until all three are bad, you would set your warning at 100%. If you wanted to wait until only two are bad, you would set the threshold to 66%.

Not the original monitored services, but the JSON reply of the different Nagios monitoring a specific service.
My idea is that each group will contain multiple services. Each service is successfule if the result of the JSON query of the related Nagios is OK. So the sentral Nagios makes a decision based on multiple external Nagios.
There is a need for script which parses the JSOn reply for knowing what is the state according to the remote Nagios.
Sounds good?

Best regards,
Menashè

[meliezer]

Actually, reading better, BPI handles only the view. It doesn't tell Nagios what is the right status based on the multiple remote Nagios servers. Nagios will still log false positive alerts and send the related notifications...

[meliezer]

The following design should work: a simple addon that instead of checking the service, compares the JSON reply from multiple Nagios servers and results in the concluded state based on its own logic. No event handler is required.
Any comments?

[eloyd]

My last reply was almost 9 months ago. I will need to review this and see what the original question was before I can respond.