[Xymon] Why IGNORE HOST and EXHOST work differently with UNMATCHED?

[Märt Laak]

So you actually suggest to write two rules instead of one, like this:
---
HOST=somehost EXSERVICE=someservice
  MAIL admin at domain.com

HOST=* EXHOST=somehost
  MAIL admin at domain.com
---

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 supervisor at domain.com
>
> 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 admin at domain.com
>>
>> HOST=*
>>   MAIL supervisor at domain.com 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 admin at domain.com
>>
>> HOST=*
>>   MAIL supervisor at domain.com 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 <mart.laak at active.ee
>>> <mailto:mart.laak at active.ee>> 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 admin at domain.com
>>>
>>>     HOST=*
>>>        MAIL supervisor at domain.com UNMATCHED
>>>     ---
>>>
>>>     2: using EX...
>>>     ---
>>>     HOST=* EXHOST=somehost
>>>        MAIL admin at domain.com
>>>
>>>     HOST=*
>>>        MAIL supervisor at domain.com UNMATCHED
>>>     ---
>>>
>>>     However, the first (IGNORE HOST) construction does NOT send alert to
>>>     supervisor at admin.com <mailto:supervisor at admin.com> in case of
>>>     somehost alert, as expected.