How do *you* handle Xymon alerts when you are on vacation (holiday in British English)? 🔗 link

Hi all,
 I'm interested in the different ways that people handle alerts when they are
on vacation (holiday in British English)...  I'm (still!) migrating from Big Brother BTF (still mostly use that for alerts, Xymon for the rest), and if I

went on vacation, I'd just put 1 line at the bottom of bb-alerts excluding
me from all alerts (as they get SMSed to my mobile) and someone else would get them (as I was never the only one to get them anyway).  But you can't do
that in Hobbit / Xymon (as I posted about last year).
 So how do you do it, or what do you recommend for a network containing a variety of different machines, routers, O/Ses and services, where the
primary, secondary and tertiary responsibilities for each service may be different people depending on the service - in the case where one of those people goes
on vacation?
 A few ways I can think of doing it using features I know already exist:

1.	have a distinct e-mail address for each person that receives alerts,

	that should only receive alerts and no other e-mails, and then 	redirecting that address to another person when they go on holiday
and 	then redirecting back to the original person when they come back
(has 	the downsides of meaning that the other person gets all their
alerts, 	even if they are not the most suitable person or getting those
alerts 	anyway and so ending up with 2 copies of them - particularly
annoying 	if they are SMSes like we use;  another downside is remembering to
put 	it back when you get back from holiday) 2.	going through all the services for which the person going on
vacation 	receives alerts, and changing them so that they go to someone
else...  	Has the downsides of the tedium involved in doing it and reverting

	it...  Might be easier if you have a special macro for each set of 	changes, e.g. PersonA->PersonB, PersonA->PersonC and PersonA->Person
C 	is 3 macros...  It is easy to change the macro when you get back (if

	you remember). 3.	following on from #2, I suppose instead of defining macros for each 	recipient (which is already one layer of abstraction better then the

	'default'), you could define a macro for each set of primary,
secondary 	and tertiary recipients (although that could make quite a few 	permutations in a large office).  Then you just have to change each
of 	those macros when someone goes on holiday, and then again when they
get 	back.
4.	A custom script, possibly with a database and putting all the
	intelligence in there (but that probably doesn't help others here,
	unless the script is publicly available).
5.	Er, and passing mobile (cell) phones back and forth - leaving your
work 	mobile with someone else when you have the day off - but that only 	works if you have a work mobile!

And then there are the ways using features that have not so far been built:

1.	being able to define vacations (I know public holidays has been
added 	to a revent version) for recipients, when they start and when they 	finish...  being able to set a VACATIONRECIPIENT who gets the alert
if 	the first recipient is on vacation (they will need to not get it if 	they are listed as the 2nd recipient too) 2.	as above, but without the VACATIONRECIPIENT.  Instead if one of the 	recipients is defined as on vacation, all the others automatically 	shift up in terms of any DURATION> required before sending them an 	alert 3.	having the exclude feature that BB had, but, althought that was easy
to 	do before going on holiday, it was a poor solution anyway in terms
of 	handling of alerts 4.	some other way...  I'm not going to spend too much time thinking of 	them now when there may be a good solution already! ;)

Kind regards, 
SebA
18:34:00

SebA wrote:
...

I pre-wrapped my e-mail to 80 characters but something wrapped it to fewer characters and messed up my formatting, so here it is again, hopefully more readable!

Hi all,
 I'm interested in the different ways that people handle alerts when they are

on vacation (holiday in British English)...  I'm (still!) migrating from Big

Brother BTF (still mostly use that for alerts, Xymon for the rest), and if I

went on vacation, I'd just put 1 line at the bottom of bb-alerts excluding me from all alerts (as they get SMSed to my mobile) and someone else would get them (as I was never the only one to get them anyway).  But you can't do

that in Hobbit / Xymon (as I posted about last year).
 So how do you do it, or what do you recommend for a network containing a variety of different machines, routers, O/Ses and services, where the primary, secondary and tertiary responsibilities for each service may be different people depending on the service - in the case where one of those people goes on vacation?
 A few ways I can think of doing it using features I know already exist:

1.	have a distinct e-mail address for each person that receives alerts,

	that should only receive alerts and no other e-mails, and then 	redirecting that address to another person when they go on holiday 	and then redirecting back to the original person when they come back

	(has the downsides of meaning that the other person gets all their 	alerts, even if they are not the most suitable person or getting 	those alerts anyway and so ending up with 2 copies of them - 	particularly annoying if they are SMSes like we use;  another 	downside is remembering to put it back when you get back from 	holiday) 2.	going through all the services for which the person going on 	vacation receives alerts, and changing them so that they go to 	someone else...  Has the downsides of the tedium involved in doing 	it and reverting it...  Might be easier if you have a special macro 	for each set of changes, e.g. PersonA->PersonB, PersonA->PersonC and

	PersonA->Person C is 3 macros...  It is easy to change the macro 	when you get back (if you remember). 3.	following on from #2, I suppose instead of defining macros for each 	recipient (which is already one layer of abstraction better then the

	'default'), you could define a macro for each set of primary, 	secondary and tertiary recipients (although that could make quite a 	few permutations in a large office).  Then you just have to change 	each of those macros when someone goes on holiday, and then again 	when they get back. 4.	Er, and passing mobile (cell) phones back and forth - leaving your 	work mobile with someone else when you have the day off - but that 	only works if you have a work mobile!

And then there are the ways using features that have not so far been built:

1.	being able to define vacations (I know public holidays has been 	added to a revent version) for recipients, when they start and when 	they finish...  being able to set a VACATIONRECIPIENT who gets the 	alert if the first recipient is on vacation (they will need to not 	get it if they are listed as the 2nd recipient too) 2.	as above, but without the VACATIONRECIPIENT.  Instead if one of the 	recipients is defined as on vacation, all the others automatically 	shift up in terms of any DURATION> required before sending them an 	alert 3.	having the exclude feature that BB had, but, althought that was easy

	to do before going on holiday, it was a poor solution anyway in 	terms of handling of alerts 4.	some other way...  I'm not going to spend too much time thinking of 	them now when there may be a good solution already! ;)

Kind regards, 
SebA
18:34:00

Vacation / holiday?  What's that?

But seriously.  Since my Xymon server is a fully capable Linux box, my
hobbit-alerts.cfg sends emailto aliases defined in the /etc/aliases.
If/when someone wants messages disabled for vacation, I just change the
alias to send the message somewhere else.  I like this method as it prevents
needing to make changes to my fairly complex/convoluted hobbit-alerts.cfg
file and an errant update to the hobbit-alerts.cfg could cause alerting to
not work.

I don't use a native SMS gateway and instead use the cell provider's email
to text/SMS gateway.

Robert Herron
user-8b27ea4290da@xymon.invalid


On Fri, Oct 8, 2010 at 2:30 PM, <user-d416b53ee243@xymon.invalid> wrote:

---------- Forwarded message ----------