Re: file/directory/device services

[Martin Pala]

Jan-Henrik Haukeland wrote:

> I have started to test this a bit more now. And one thing I react to
> is that there is a start/stop program defined for such a service. I'm
> not sure what I shall think about that :-) Well I can see that it may
> be useful, but it also looks very strange.
>
>
> I use this test entry:
>
> check file monitlog with path /home/hauk/monitlog
>   if timestamp /home/hauk/monitlog was changed then stop
>   alert address@hidden
>
>
> I tested now by removing the file and monit sent a restart event for
> the file:
>
>         From: address@hidden
>         Subject: monit alert --  Restarted monitlog
>         To: address@hidden
>         Date: Wed, 06 Aug 2003 02:57:41 +0200
>         
> 	Restarted Service monitlog 
> 	
>         Date: Wed, 06 Aug 2003 02:57:41 +0200
>         Host: 9muf0e
>         
>         Your faithful employee,
>         monit
>         
>         Event: file 'monitlog' doesn't exist
>
> I'm not sure this behaviour is appropriate for this service? 
>
> I may be wrong but I was thinking more along the lines that a
> file/device/dir. check is kind of binary at least at the fundamental
> level. That is; either it exist or it doesn't and if it doesn't it is
> an error. So instead of using start/stop maybe the following entry
> example looks more logical?
>
> check file monitlog with path /home/hauk/monitlog
>   if not exist then exec "<program>
>   if timestamp /home/hauk/monitlog was changed then stop
>   alert address@hidden
>
> But on the other hand if the service is a device it *is* meaningful to
> have start/stop programs:
>
> check device hda with path /dev/hda5
>  start "mount /dev/hda5 /usr/local/"
>  stop  "umount /usr/local/"
>  if not exist then alert
>  alert address@hidden
>
>
> Well, I'm not sure :-) maybe start/stop is good? What are your
> thoughts Martin? 
>
>  
My original thoughs were:

1.) from logical point of view to have  one common parent (ancestor) 
class, which will contain all common attributes (such as start and stop 
methods definition, alert statements, timeout, etc.) and specialized 
child (descendant) classes which will inherite common properties and 
extend it by its own specialized attributes (for tests, etc.) All common 
options  (such as start and stop program, etc.) will be possible to use 
in all services types and they will have  "wellknown" behavior.

2.) from physical point of view it is implemented as only one class 
instance (Service_T), which is logical descendant of  all above 
mentioned classes, some (ugly) ascii art:

                     Common_T
         /         |                    |                 \
       /           |                    |                   \
     /             |                    |                     \
File_T   Device_T   Process_T   Directory_T
   \               |                    |                     /
     \             |                    |                   /
       \           |                    |                 /
                     Service_T

Predecessor classes are not realy declared (they are "as virtual as 
possible" => they don't exist :) Its instances are chained in simple 
list. Specialized elements which are not utilized in particular 
monitoring service type are ignored in appropriate particular Service_T 
instance.


The usage stress active/passive/manual monitoring modes:

1.) to send just alerts in the case that the filesystem doesn't exist 
(in passive mode are start+stop methods ignored and only alert is sent):

check device hda with path /dev/hda5
 start "mount /dev/hda5 /usr/local/"
 stop  "umount /usr/local/"
 alert address@hidden
 mode passive


2.) active mode has EVENT_RESTART by default if the device doesn't exist:

check device hda with path /dev/hda5
 start "mount /dev/hda5 /usr/local/"
 stop  "umount /usr/local/"
 alert address@hidden
 mode active


3.) manual mode will enter active mode as soon as instructed by user: 
"monit start hda". In such case it will mount filesystem and start 
monitoring (usefull for clusters)

check device hda with path /dev/hda5
 start "mount /dev/hda5 /usr/local/"
 stop  "umount /usr/local/"
 alert address@hidden
 mode manual


For monitoring services such as file or directory, it is usefull to 
support start/stop programs too. You can have file or directory which 
*must* exist, or you can need to regenerate it (EVENT_RESTART) under 
some conditions (for example if it is too big, etc.)


I think we should keep start/stop programs support for 
device/directory/file services.


Martin