RE: [xymon] Managing who gets alerts - shifts and rotations

[Tim McCloskey <tm (at) freedom.com>]

my .04 cents:

1. Henrick: I don't really see any need to change the alerting system.  It works fine, it's flexible and highly customizable.  The flexibility of the system allows each entity to configure alerts to match their own environment.  Complex envirornment or not, it still works well.  Some years back when I moved portions of an environment to hobbit from BB I learned to do as Vernon suggests, divide and conquer.  The majority of my configurations are in included files.  But that was my choice, not some mandated requirement. 

2. Vernon: I mentioned a similar solution on Saturday, it's going to take some work to set it up.  I divided it further, my alerts cfg does not change, only the names of the poor sap who gets paged are changed, via cron at their scheduled time or via a CGI that allows someone to push the button and flip alerts to someone else.

3. Besty:  Maybe I'm over-simplifying things but frankly I don't see a need for 186 alerts as you mentioned.  Have a look at my mail from Saturday and reconsider.  Also understand that manual work needs to be performed to deploy quality systems, standard sysadmin tasks do need to be performed, this includes scripting things that you'll be doing over and over, in cron or from a prompt on a Monday after coffee.  Automation is cool, but it's a choice and I respect those that choose either automation or manually logging in and poking around at their systems.

I've deployed hobbit in an environment with _many_ hosts in several locations and several folks that need to be paged when foo happens to host bar at xyz time.  There is a constant which is perhaps overlooked in this discussion.  The constant is the service foo on host bar.  It is always monitored and always triggers an alert.  With one alert for service foo on host bar we can have different people paged at different times, it's really not that complicated.  If it's not true that you always watch foo:bar then I'm wrong.

Again, remove the people from the main alerts config and put in roles, page-primary, page-secondary, etc.  Call these rolls using the SCRIPT function and use perl to change the values on x time.  You mention different time zones, changing shifts and so on, this only one variable: time.  Time:person = cron/perl.  Nothing else needs to change, script the basic alert rules configured in a 24x7 setup and never change the alert rules directly.  Just swap the names at x time.


Thanks Henrick and Group for the excellent software and support.

-t


________________________________________
From: Vernon Everett [everett.vernon (at) gmail.com]
Sent: Monday, October 11, 2010 1:16 AM
To: xymon (at) xymon.com
Subject: Re: [xymon] Managing who gets alerts - shifts and rotations

Hmmm.
What an interesting thread this is turning out to be. :-)

With regards the problem, how about this one. Divide and conquer.
hobbit-alerts.cfg supports "include" statements.
The config also doesn't get grumpy if we have 2 instances of the same server with the same tests and different email alerts.
You could then have this in the file
include /path/to/alerts-teamX.cfg
include /path/to/alerts-teamY.cfg
include /path/to/alerts-teamZ.cfg
Permissions allow each team to edit their own files, and each team is then responsible for ensuring their shifts are updated correctly.

Each team will then have their own version of hobbit-alerts.cfg, which will then be merged by the includes.
This still allows you to use the mechanism Henrik proposed earlier within each team config file, but also gives each team a simpler, team-centric config file.

Of course, this doesn't exclude the possibility of somebody writing a nice editor :-)

Cheers
      V