Xymon Mailing List Archive search

Is there any equivalent to BB's notifications exclusions?

4 messages in this thread

list Sebastian Auriol · Wed, 21 Jan 2009 17:51:31 -0000 ·
Hi all,

I would like to migrate my notifications rules from BB Server to Hobbit /
Xymon Server.  I use the following BB syntax extensively:

# You can also write rules to exclude recipients based on the
#	previous syntax. Just prefix with ! and any recipient
#	specified in the rule line will be removed from the
#	list of recipients that matches the regular rules
#
#	for all hosts don't send any notifications from 
#	12AM to 6AM and 8PM to 12AM
#
# !*;;*;;*;0000-0600 2000-2359;*
#
#	for all hosts that start with host, don't send any
#	notifications on sat & sun to robert at localhost
#
# !host*;;*;;0 6;*;robert at localhost
#
#	To temporarely disable notifications for a host
#
# !host1;;*;;*;*;*
#

Is there any equivalent to this in Hobbit?  I can't see one in the man
pages.  This is very useful for making sure people don't get woken up in the
middle of the night for issues that are non-critical at night time
  Or for
certain people who just should never get alerts at night time or the weekend
(or outside office hours).  Is the best solution a macro that one uses
instead of an e-mail address in the MAIL lines, where the macro contains a
TIME=timespecification rule?

Many thanks,

SebA
list Henrik Størner · Thu, 22 Jan 2009 14:58:33 +0000 (UTC) ·
quoted from Sebastian Auriol
In <user-55068d5b8051@xymon.invalid> "SebA" <user-7b2156f36779@xymon.invalid> writes:
I would like to migrate my notifications rules from BB Server to 
Hobbit / Xymon Server.  I use the following BB syntax extensively:
# You can also write rules to exclude recipients based on the
#	previous syntax. Just prefix with ! and any recipient
#	specified in the rule line will be removed from the
#	list of recipients that matches the regular rules
#

#	for all hosts don't send any notifications from=20
#	12AM to 6AM and 8PM to 12AM
#
# !*;;*;;*;0000-0600 2000-2359;*
If you only want to send alerts between 6AM and 8PM, then
  TIME=*:0600:2000
will do that. Alternatively, an "EXTIME=*:2000:0600" has the
same effect (a more direct conversion of this rule).
# !host*;;*;;0 6;*;robert at localhost
HOST=* EXHOST=%^host
   MAIL robert at localhost
# !host1;;*;;*;*;*
HOST=* EXHOST=host1


The latter two don't really need the "HOST=*" since that is the
default. But some (myself included) find it easier to read when
you explicitly write "ALL hosts, EXCEPT ..."


Regards,
Henrik
list Sebastian Auriol · Thu, 22 Jan 2009 18:45:33 -0000 ·
quoted from Henrik Størner
Henrik Størner <mailto:user-ce4a2c883f75@xymon.invalid> wrote:
In <user-55068d5b8051@xymon.invalid> "SebA" <user-7b2156f36779@xymon.invalid> writes:
I would like to migrate my notifications rules from BB Server to
Hobbit / Xymon Server.  I use the following BB syntax extensively:
# You can also write rules to exclude recipients based on the
#	previous syntax. Just prefix with ! and any recipient
#	specified in the rule line will be removed from the
#	list of recipients that matches the regular rules #
#	for all hosts don't send any notifications from=20 #	12AM to 6AM
and 8PM to 12AM #
# !*;;*;;*;0000-0600 2000-2359;*
If you only want to send alerts between 6AM and 8PM, then  
TIME=*:0600:2000 will do that. Alternatively, an "EXTIME=*:2000:0600"
has the same effect (a more direct conversion of this rule).
Hi Henrik,

That's not quite the same thing (see below), but I think if I put EXTIME
rules in with the e-mail addresses in macros (for convenience), I will be
able to do what I need to.
# !host*;;*;;0 6;*;robert at localhost
HOST=* EXHOST=%^host
   MAIL robert at localhost
Not really: the BB rule says: for _all_ alerts that were due to be raised
for host*, at the weekend, to robert at localhost (based on higher up rules
with no ! prefix), don't send them out. In other words, cancel all previous
_matching_ MAIL commands for this exclusion. Or sort of like a bitmask. Your
rule says: send alerts to robert at localhost for all hosts except hosts
beginning with 'host'.
# !host1;;*;;*;*;*
HOST=* EXHOST=host1
Same as above. The BB rule disables all notifications for this host 'host1'.
Your rule sends out notifications for all hosts except 'host1'. Although in
Hobbit / Xymon, you wouldn't disable notifications like this, of course,
you'd use the info page to disable them. So this is no big deal.

I still think Xymon may benefit from a notifications exclusions system
though. (Especially for easier migration for BB users! ;)) On the other
hand, it does add complication that is perhaps unnecessary. I currently use
these exclusions extensively. From when someone goes on holiday (turn off
all their alerts no matter what service or host they refer to), or maybe
your e-mail to SMS gateway or provider has a problem and you want to stop
all those e-mails (but not all the internal e-mails) being generated,
queueing up and then coming through in a rather unnecessarrily expensive
flood when the SMS provider starts working again. Maybe this can be solved
with the route or depends tags and appropriate tests, but not if it's a
deeper problem, like with the cellular network...

Kind regards,

SebA
list Henrik Størner · Thu, 22 Jan 2009 21:52:10 +0000 (UTC) ·
quoted from Sebastian Auriol
In <user-ab510e51e443@xymon.invalid> "SebA" <user-7b2156f36779@xymon.invalid> writes:
# You can also write rules to exclude recipients based on the
#	previous syntax. Just prefix with ! and any recipient
#	specified in the rule line will be removed from the
#	list of recipients that matches the regular rules #

#	for all hosts don't send any notifications from=3D20 #	12AM to 6AM
and 8PM to 12AM #
# !*;;*;;*;0000-0600 2000-2359;*
=20
If you only want to send alerts between 6AM and 8PM, then =20
TIME=3D*:0600:2000 will do that. Alternatively, an =
"EXTIME=3D*:2000:0600"
quoted from Sebastian Auriol
has the same effect (a more direct conversion of this rule).
That's not quite the same thing (see below), but I think if I put EXTIME
rules in with the e-mail addresses in macros (for convenience), I will
be able to do what I need to.
# !host*;;*;;0 6;*;robert at localhost
=20
HOST=3D* EXHOST=3D%^host
quoted from Sebastian Auriol
   MAIL robert at localhost
Not really: the BB rule says: for _all_ alerts that were due to be
raised for host*, at the weekend, to robert at localhost (based on higher 
up rules with no ! prefix), don't send them out. In other words, 
cancel all previous _matching_ MAIL commands for this exclusion.
In that case I misunderstood the BB config semantics - which is not
surprising, since they never made much sense to me, and I haven't
used them for more than 5 years :-)
quoted from Sebastian Auriol
I still think Xymon may benefit from a notifications exclusions system
though. (Especially for easier migration for BB users! ;)) On the other
hand, it does add complication that is perhaps unnecessary. I currently
use these exclusions extensively. From when someone goes on holiday 
(turn off all their alerts no matter what service or host they refer to), 
or maybe your e-mail to SMS gateway or provider has a problem and you 
want to stop all those e-mails (but not all the internal e-mails) being 
generated, queueing up and then coming through in a rather unnecessarrily 
expensive flood when the SMS provider starts working again.

I realize that you have a working set of configuration rules, but I think
it would be a lot easier to work out a functionally identical set of
rules for Hobbit/Xymon if you could describe what it is you want to
achieve with the configuration, instead of focusing on how it was 
done in BB.

The closest to what you want to do might be to use the "IGNORE" setting in 
hobbit-alerts.cfg. E.g. your example:
   !host*;;*;;0 6;*;robert at localhost
could be accomplished with something like

   HOST=%^host TIME=06:0000:2359
        IGNORE

although this would kill alerts for all recipients, not just those destined
for "robert at localhost". And note that this must go BEFORE any of the other 
rules for this host.

I can see that the BB exclusion mechanism might be useful in some circumstances,
but it would (obviously) make the alerting mechanism more complicated.
And I'm not convinced that there's enough gained to warrant this.


Regards,
Henrik