[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [xymon] How do *you* handle Xymon alerts when you are on vacation (holiday in British English)?
- To: <xymon (at) xymon.com>
- Subject: RE: [xymon] How do *you* handle Xymon alerts when you are on vacation (holiday in British English)?
- From: "SebA" <spa (at) syntec.co.uk>
- Date: Fri, 8 Oct 2010 20:00:45 +0100
- References: <!&!AAAAAAAAAAAuAAAAAAAAAL60wriLM9cRsTVojW0AAAABAFEdQVQs6tMRsLEAoMxarIMAAAABk2cAABAAAAA3BvebjsndS7Oghx5dYWHbAQAAAAA= (at) syntec.co.uk>
- Thread-index: ActVzFl2+5XvI11NSGu510uThvuOKgOA1LpQAC0goLAApG6CYAABJhpg
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
No virus found in this outgoing message.
Checked by AVG - www.avg.com
Version: 8.5.448 / Virus Database: 271.1.1/3149 - Release Date: 10/07/10
18:34:00