Re: Scheduled downtime functionality

2009-11-09 Thread Nathan Gibbs
* Nathan Gibbs wrote:
 Has anyone considered adding a Scheduled downtime function to mon.
 
 Why?
 Summary
 Don't do what I could get the machines to do.
 
 Detail
 Invariably, when doing planned maintenance, I forget to.
 Log into mon and disable what I'm working on before the alerts start flying.
 Log into mon and re-enable what I was working on, so the alerts will fly.
 
 I'm currently planning to implement this as a second process that
 continuously reads a flat csv file containing what,when,how long\n.
 Then issues the appropriate disable or enable commands to the mon server.

Ok, I have most of that concept coded up.
Alas my perl-fu isn't sufficient to turn it into a daemon.
Anyone interested in taking it from there.
I'll mail you the code off list.

Now, I just need to built a web front end to manage the data file.
 Would implementing such functionality in the mon server itself be more
 efficient?
 
Yes it would be, don't look at me, I'm not doing it .
:-)





signature.asc
Description: OpenPGP digital signature
___
mon mailing list
mon@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/mon


Re: Scheduled downtime functionality

2009-10-17 Thread Nathan Gibbs
* Jim Trocki wrote:
 On Sat, 17 Oct 2009, Res wrote:
 
 I'm currently planning to implement this as a second process that
 continuously reads a flat csv file containing what,when,how long\n.

 Absolutely yes, IMHO it is the only place to add such a function,
 since it is the governing process.
 

My thoughts exactly.
However, I won't touch the code to mon itself.
I've read some of it, even copied some of it into my current project,
but it is above my coding capabilities.
I refuse to mangle something that is so close to perfect.

On a conceptual level this is how I would go about it.
Create a data structure to hold scheduled downtime events.
Something like
qw ( StartTimeStamp Duration ObjType ( Watch|host|service ) ObjName )
Add a new maintenance state to the watchs|hosts|services
This would work like current Enabled,Disabled or OK, Failed, Failing states.
Add the appropriate functions to Mon::Client to access this state
Something like
list_maintenance
Modify the monitor logic so that if an object is in the maintenance
state, monitors for it don't run.
Could work like an exclusion period.

 i already have something which can do that, with minor mods. i doubt
 anyone knows about it, though :)

Please make them  put it into mon.

 
 http://search.cpan.org/~trockij/
 
 the ones named schedule.
 
 the config is kept in csv format so it can be edited easily with a
 spreadsheet.
 
I'll see if I can leverage that in the current project.

 also there is some discussion of it here:
 
 http://www.kernel.org/pub/software/admin/mon/mon-talk-1.2.pdf
 
Nice paper!  That is so going into my reference file.!
I'd figured there was a way to escalate alerts, somewhere in the
configuration parameters just screaming to get out.
I never even thought of multiple periods.  Its so simple.
Time to hit myself in the head with a keyboard. :-)

-- 
Sincerely,

Nathan Gibbs

Systems Administrator
Christ Media
http://www.cmpublishers.com




signature.asc
Description: OpenPGP digital signature
___
mon mailing list
mon@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/mon


Re: Scheduled downtime functionality

2009-10-16 Thread Res

On Fri, 16 Oct 2009, Nathan Gibbs wrote:


Has anyone considered adding a Scheduled downtime function to mon.

Invariably, when doing planned maintenance, I forget to.
Log into mon and disable what I'm working on before the alerts start flying.
Log into mon and re-enable what I was working on, so the alerts will fly.


Don't we all :)



I'm currently planning to implement this as a second process that
continuously reads a flat csv file containing what,when,how long\n.
Then issues the appropriate disable or enable commands to the mon server.
Would implementing such functionality in the mon server itself be more
efficient?


Absolutely yes, IMHO it is the only place to add such a function, since it 
is the governing process.



--
Res

Time to change the Australian Data Cable and Wiring Laws.
Help get the Digital Data Exemption back so we can legally make
ethernet cables. http://forums.ausics.net/./viewtopic.php?f=1t=61

___
mon mailing list
mon@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/mon


Re: Scheduled downtime functionality

2009-10-16 Thread Jim Trocki

On Sat, 17 Oct 2009, Res wrote:


I'm currently planning to implement this as a second process that
continuously reads a flat csv file containing what,when,how long\n.


Absolutely yes, IMHO it is the only place to add such a function, since it is 
the governing process.


i already have something which can do that, with minor mods. i doubt
anyone knows about it, though :)

http://search.cpan.org/~trockij/

the ones named schedule.

the config is kept in csv format so it can be edited easily with a
spreadsheet.

from the pod:

Schedule::Oncall provides methods to manipulate an on-call schedule.
One or more tables of schedules can be maintained, loaded, and
searched.  An on-call table is composed of seven days, where each
day has a list of minute ranges which correspond to a particular person.

Information such as email address, pager number, etc. may be stored in
the schedule configuration file. Simple variable assignments may also
be made. Other textual information may be stored in the schedule in
order to assist other applications (e.g., html headers or email body
text), and variables substitution may occur within the text blocks.

Schedule files may be chosen based on weekly or monthly rotations,
relative to the first week or month of the year. Weekly schedules
begin on a Monday and end on a Sunday, the same as strftime(3)'s
%W format. Each rotation is stored in a separate file, and the
appropriate rotation is chosen at load time.

also there is some discussion of it here:

http://www.kernel.org/pub/software/admin/mon/mon-talk-1.2.pdf

___
mon mailing list
mon@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/mon