Why IGNORE HOST and EXHOST work differently with UNMATCHED?

4 messages in this thread

list Märt Laak · Fri, 31 Jul 2015 09:34:28 +0300 ·

Hi Henrik and others who help to develop this invaluable piece of software, Xymon!

I've been used BB more than 15 years for now and now trying to migrate to Xymon because it seems more flexible and powerful to me. Now I'm in the middle of converting my existing (fairly complex) bbwarnrules to alerts.cfg

Everything works great except some strange to me cases with UNMATCHED.

For example, if you look at these two configurations - they seem similar to human eye:

1: using IGNORE
---
HOST=*
   IGNORE HOST=somehost
   MAIL user-d7ae79a03f32@xymon.invalid

HOST=*
   MAIL user-0003ff222856@xymon.invalid UNMATCHED
---

2: using EX...
---
HOST=* EXHOST=somehost
   MAIL user-d7ae79a03f32@xymon.invalid

HOST=*
   MAIL user-0003ff222856@xymon.invalid UNMATCHED
---

However, the first (IGNORE HOST) construction does NOT send alert to user-039bea1231df@xymon.invalid in case of somehost alert, as expected.

Is it bug or is there some explanation for this behavior?

With kindest regards,
Märt

list Jeremy Laidman · Mon, 3 Aug 2015 11:25:40 +1000 ·

I think this can be explained from the man page:

"IGNORE - This is used to define a recipient that does NOT trigger any
alerts, and also terminates the search for more recipients."

What this means is that the rule matched the host "somehost" but the alert
for the recipient was suppressed.  The fact that it matched means that the
UNMATCHED rule will not be invoked.

By contrast, the EXHOST causes the rule to not match "somehost", hence will
match the UNMATCHED rule.

I hope this explains.

Cheers
Jeremy

▸ quoted from Märt Laak



On 31 July 2015 at 16:34, Märt Laak <user-0093eef803ca@xymon.invalid> wrote:

Hi Henrik and others who help to develop this invaluable piece of
software, Xymon!

I've been used BB more than 15 years for now and now trying to migrate to
Xymon because it seems more flexible and powerful to me. Now I'm in the
middle of converting my existing (fairly complex) bbwarnrules to alerts.cfg

Everything works great except some strange to me cases with UNMATCHED.

For example, if you look at these two configurations - they seem similar
to human eye:

1: using IGNORE
---
HOST=*
  IGNORE HOST=somehost
  MAIL user-d7ae79a03f32@xymon.invalid

HOST=*
  MAIL user-0003ff222856@xymon.invalid UNMATCHED
---

2: using EX...
---
HOST=* EXHOST=somehost
  MAIL user-d7ae79a03f32@xymon.invalid

HOST=*
  MAIL user-0003ff222856@xymon.invalid UNMATCHED
---

However, the first (IGNORE HOST) construction does NOT send alert to
user-039bea1231df@xymon.invalid in case of somehost alert, as expected.

Is it bug or is there some explanation for this behavior?

With kindest regards,
Märt

list Märt Laak · Mon, 03 Aug 2015 22:04:39 +0300 ·

Thank you for explaining things, Jeremy!

But don't you think this behavior can easily lead to unwanted non-alerting?

And, more important, IMHO makes impossible to exclude alerts based 
multiple types together.

Consider if admin does not want to be alerted on somehost.someservice. 
How to configure that?

Fe. This does not work:
---
HOST=* EXHOST=somehost EXSERVICE=someservice
   MAIL user-d7ae79a03f32@xymon.invalid

HOST=*
   MAIL user-0003ff222856@xymon.invalid UNMATCHED
---
Using this construction admin does not get alert on 
somehost.someotherservice, not to mention that all other host 
someservice-s are also ignored. However, supervisor gets alerted correctly.

I could rewrite this so that admin is happy:
---
HOST=*
   IGNORE HOST=somehost SERVICE=someservice
   MAIL user-d7ae79a03f32@xymon.invalid

HOST=*
   MAIL user-0003ff222856@xymon.invalid UNMATCHED
---
But in this case supervisor is not happy, as he gets no alerts when 
nobody is alerted (as he expects by UNMATCHED) - on somehost.someservice 
nobody gets alerted.

So please help me how to configure alerts in this situation?

With kindest regards,
Märt

▸ quoted from Jeremy Laidman


On 3.08.2015 4:25, Jeremy Laidman wrote:

I think this can be explained from the man page:

"IGNORE - This is used to define a recipient that does NOT trigger any
alerts, and also terminates the search for more recipients."

What this means is that the rule matched the host "somehost" but the
alert for the recipient was suppressed.  The fact that it matched means
that the UNMATCHED rule will not be invoked.

By contrast, the EXHOST causes the rule to not match "somehost", hence
will match the UNMATCHED rule.

I hope this explains.

Cheers
Jeremy


On 31 July 2015 at 16:34, Märt Laak <user-0093eef803ca@xymon.invalid
<mailto:user-0093eef803ca@xymon.invalid>> wrote:

    Hi Henrik and others who help to develop this invaluable piece of
    software, Xymon!

    I've been used BB more than 15 years for now and now trying to
    migrate to Xymon because it seems more flexible and powerful to me.
    Now I'm in the middle of converting my existing (fairly complex)
    bbwarnrules to alerts.cfg

    Everything works great except some strange to me cases with UNMATCHED.

    For example, if you look at these two configurations - they seem
    similar to human eye:

    1: using IGNORE
    ---
    HOST=*
       IGNORE HOST=somehost
       MAIL user-d7ae79a03f32@xymon.invalid

    HOST=*
       MAIL user-0003ff222856@xymon.invalid UNMATCHED
    ---

    2: using EX...
    ---
    HOST=* EXHOST=somehost
       MAIL user-d7ae79a03f32@xymon.invalid

    HOST=*
       MAIL user-0003ff222856@xymon.invalid UNMATCHED
    ---

    However, the first (IGNORE HOST) construction does NOT send alert to


    user-039bea1231df@xymon.invalid <mailto:user-039bea1231df@xymon.invalid> in case of

▸ quoted from Jeremy Laidman

    somehost alert, as expected.

    Is it bug or is there some explanation for this behavior?

    With kindest regards,
    Märt

list Märt Laak · Tue, 04 Aug 2015 10:57:29 +0300 ·

So you actually suggest to write two rules instead of one, like this:
---
HOST=somehost EXSERVICE=someservice
  MAIL user-d7ae79a03f32@xymon.invalid

HOST=* EXHOST=somehost
  MAIL user-d7ae79a03f32@xymon.invalid
---

IMHO this "hostrules plus catch-all rule with these hosts excepted" 
makes rule writing more complex and error-prone than with one catch-all 
rule with several IGNORE-s needed. As I said for human eye they seem 
equal (only catch-all rule with ignores is more readable).

But, can somebody point the use-case where this "IGNORE is not part of 
rule and therefore is blocking UNMATCHED to trigger" behavior is 
actually useful and needed?
As I said, IMHO this behavior leads to unwanted non-alerting only.

Man page says about UNMATCHED:
---
UNMATCHED - The alert is sent to this recipient ONLY if no other 
recipients received an alert for this event.
---
No mention of IGNORE is blocking UNMATCHED. So I somehow suggest not 
only me was confused...

Can this behavior be considered to be changed (or configurable in 
xymonserver.cfg)? I volunteer to be alpha-tester...

Märt

On 3.08.2015 23:00, Mike Burger wrote:

If you want to exclude someservice on a specific host, don't you use:

HOST=somehost EXSERVICE=someservice
    MAIL user-0003ff222856@xymon.invalid

▸ quoted from Märt Laak


On 2015-08-03 3:04 pm, Märt Laak wrote:

Thank you for explaining things, Jeremy!

But don't you think this behavior can easily lead to unwanted
non-alerting?

And, more important, IMHO makes impossible to exclude alerts based
multiple types together.

Consider if admin does not want to be alerted on somehost.someservice.
How to configure that?

Fe. This does not work:
---
HOST=* EXHOST=somehost EXSERVICE=someservice
  MAIL user-d7ae79a03f32@xymon.invalid

HOST=*
  MAIL user-0003ff222856@xymon.invalid UNMATCHED
---
Using this construction admin does not get alert on
somehost.someotherservice, not to mention that all other host
someservice-s are also ignored. However, supervisor gets alerted
correctly.

I could rewrite this so that admin is happy:
---
HOST=*
  IGNORE HOST=somehost SERVICE=someservice
  MAIL user-d7ae79a03f32@xymon.invalid

HOST=*
  MAIL user-0003ff222856@xymon.invalid UNMATCHED
---
But in this case supervisor is not happy, as he gets no alerts when
nobody is alerted (as he expects by UNMATCHED) - on
somehost.someservice nobody gets alerted.

So please help me how to configure alerts in this situation?

With kindest regards,
Märt

On 3.08.2015 4:25, Jeremy Laidman wrote:

I think this can be explained from the man page:

"IGNORE - This is used to define a recipient that does NOT trigger any
alerts, and also terminates the search for more recipients."

What this means is that the rule matched the host "somehost" but the
alert for the recipient was suppressed.  The fact that it matched means
that the UNMATCHED rule will not be invoked.

By contrast, the EXHOST causes the rule to not match "somehost", hence
will match the UNMATCHED rule.

I hope this explains.

Cheers
Jeremy


On 31 July 2015 at 16:34, Märt Laak <user-0093eef803ca@xymon.invalid
<mailto:user-0093eef803ca@xymon.invalid>> wrote:

    Hi Henrik and others who help to develop this invaluable piece of
    software, Xymon!

    I've been used BB more than 15 years for now and now trying to
    migrate to Xymon because it seems more flexible and powerful to me.
    Now I'm in the middle of converting my existing (fairly complex)
    bbwarnrules to alerts.cfg

    Everything works great except some strange to me cases with
UNMATCHED.

    For example, if you look at these two configurations - they seem
    similar to human eye:

    1: using IGNORE
    ---
    HOST=*
       IGNORE HOST=somehost
       MAIL user-d7ae79a03f32@xymon.invalid

    HOST=*
       MAIL user-0003ff222856@xymon.invalid UNMATCHED
    ---

    2: using EX...
    ---
    HOST=* EXHOST=somehost
       MAIL user-d7ae79a03f32@xymon.invalid

    HOST=*
       MAIL user-0003ff222856@xymon.invalid UNMATCHED
    ---

    However, the first (IGNORE HOST) construction does NOT send alert to
    user-039bea1231df@xymon.invalid <mailto:user-039bea1231df@xymon.invalid> in case of
    somehost alert, as expected.

Why IGNORE HOST and EXHOST work differently with UNMATCHED? 🔗 link

Why IGNORE HOST and EXHOST work differently with UNMATCHED?