|[Date Prev] [Date Next]||[Thread Prev] [Thread Next]||[Date Index] [Thread Index]|
Re: [nocol-users] MySQL monitor?
"Nathan Clemons [Staff]" wrote: > > I'd love to write a good Perl DBI monitor, where you could specify > username, password, port, and DBD type in the config file and have a SQL > statement to use to test it. > > If anyone feels up to writing a FAQ on how to write a Perl based monitor, > I'll be happy to contribute it when complete. Nathan, A 'sample' perl monitor is located in perlnocol/SAMPLE-perl-monitor. Ideally (and also in the case of the Perl DBI monitor), it only needs 2 functions: sub readconf() = read config file and build 'item' list sub dotest() = which test's one host, and calls &calc_status() &nocol_main() will then automatically call these above routines, etc. Yes, these need to be documented better. Regarding the issue with handling a "HUP" signal, the problem lies in the fact that it is difficult to determine the changes in the config files. Consider the case of 'portmon'... I might edit an existing file and change just the IP address in an entry, or just the 'return-string'. On getting a HUP, the monitors would have to go thru each of these parameters, decide what has been changed, and then delete that 'item'. It is specific for each monitor, hence it cannot be made into a library function. One simple way to do this, is upon getting a HUP, a monitor can: - erase the old file (effectively as good as restarting) - but on the first pass, dont reinit everything to 'unknown' instead just directly escalate each event to the 'highest' severity directly. The only downside to this could be if a site just went down, then all the monitors would NOT step thru the severities (info -> warning -> error -> critical), but directly escalate the site to 'critical'. This is the easiest approach to the problem, and with the least impact. On another note... Once we have all the events in a database (courtsey firstname.lastname@example.org), we should be able to assign 'nodenames' to each monitor and refer to each event using 'nodename.event'. A meta database could collect data from all these differnt databases, and co-relation between nodeA.eventX and nodeB.eventX can be done (this idea from Velocet folks). Ofcourse, the tool to do any kind of analysis is also TBD. -vikas