[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: file/directory/device services
From: |
Martin Pala |
Subject: |
Re: file/directory/device services |
Date: |
Wed, 06 Aug 2003 13:25:39 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030711 |
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