That would actually work perfectly to fix a problem I have. Because of the startup time of a java monitor, if they happen to all start at the same time, it throws the time it takes to complete off, thereby producing false alerts. Current solution is to restart mon and hope that the random time is spread out upon restarting. (Because of what the monitor is monitoring, this alert can not be parallelized.)
One other possible enhancement thought would be to have the ability to have mon re-read the configuration file, and implement/drop any changes, but not affect the timing schedule of the services that have not been changed. Nicholas Cook -----Original Message----- From: Gary Richardson [mailto:[EMAIL PROTECTED] Sent: Thursday, June 19, 2003 11:40 AM To: [EMAIL PROTECTED] Subject: RE: Calling alerts and monitors This could work really well. The key would be to keep the communication very open -- ie make it have the ability to pass custom arguments. I'm thinking a soap interface would work very well. Most programming languages have decent soap support, especially perl. In fact, SOAP::Lite works well with most programming languages (according to the man page :)). -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jim Trocki Sent: Thursday, June 19, 2003 6:26 AM To: Gary Richardson Cc: [EMAIL PROTECTED] Subject: RE: Calling alerts and monitors On Wed, 18 Jun 2003, Gary Richardson wrote: > To save perl startup time, would it be worth while to add the ability > to tell mon to fork and eval the application if it is a perl script? i've thought about this in the past, and here's the idea i have: have the option of two different types of monitors: type "a": the existing type which are forked for every invocation. these are easy to write so they have great utility for quick site-specific customizations, but can be inefficient if you have a huge and complicated mon configuration with many hundreds of services. also, you can write these monitors sloppily and not worry about memory leaks because their lifetime is very short. type "b": these are started when the mon server initially starts (or after a configuration reload or reset). they receive orders from a connection to a local socket or some form of ipc. the orders are "test this list of hosts and get me the results", just like regular monitors, but the invocation and communication mechanism is different. there is a "master" monitor which accepts these connections and forks off a child to handle each request. the child is the same program but a different function, so no exec is done to load a new program. this is somewhat similar to how apache handles http requests. when mon schedules a test for a type "b" monitor, rather than forking and execing, it simply makes an ipc connection to the already-running monitor and delivers its orders, and waits for the results. this type of monitor is more complicated to write, but it can scale much better than the fork-and-exec type of monitor. since these are long-running processes, you need to worry about memory leaks, but it could be possible to perodically restart these monitors without causing a noticeable drop in performance. there will likely be a very few number of these types of monitors. sound reasonable? _______________________________________________ mon mailing list [EMAIL PROTECTED] http://linux.kernel.org/mailman/listinfo/mon _______________________________________________ mon mailing list [EMAIL PROTECTED] http://linux.kernel.org/mailman/listinfo/mon _______________________________________________ mon mailing list [EMAIL PROTECTED] http://linux.kernel.org/mailman/listinfo/mon
