[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LANGUAGE CHANGES - service templates
From: |
Jan-Henrik Haukeland |
Subject: |
Re: LANGUAGE CHANGES - service templates |
Date: |
Wed, 06 Aug 2003 14:23:55 +0200 |
User-agent: |
Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Civil Service, linux) |
Martin Pala <address@hidden> writes:
> we can write:
>
> check file myfile with path /foo/bar
> if timestamp > 1 day then alert
> if checksum and expect the sum 123456
> if size > 100 MB then alert
Hehe, excellent, that was going to be my next suggestion.
> check stored with pidfile /msg-foo/config/pidfile.store
> start program "/usr/iplanet/msg-ims-1/start-msg store"
> stop program "/usr/iplanet/msg-ims-1/stop-msg store"
> depend stored_ckp
> depend stored_lcu
> depend stored_per
> depend stored_bin
>
> check file stored_ckp with path /msg-foo/config/stored.ckp
> if failed timestamp > 1 minute then alert
>
> check file stored_lcu with path /msg-foo/config/stored.lcu
> if failed timestamp > 5 minutes then alert
>
> check file stored_per with path /msg-foo/config/stored.per
> if failed timestamp > 1 hour then alert
>
> check file stored_bin with path /msg-foo/bin/stored
> if failed checksum and expect the sum 123456 then stop
> if failed permission 755 then stop
> if failed uid iplanet then stop
> if failed gid iplanet then stop
> if failed size != 655476 then stop
Well, I simply think this is beautiful :-) Very inventive!
> Timestamp, checksum and probably other file/device/directory
> directives need not to be supported under process.
Agree. This is true OO thinking, specialization are done in
sub-classes. In this case if a process needs to check files it should
do so in a specialized "check file" entry (the sub-class) and to
continue the OO metaphor, sub-classing is done via depends.
> In such case it will involve incompatible change, but because we
> already did some such changes, it could be better to make all
> changes and language cleanup now, then make another incompatible
> changes in the future.
Agree, it should not be a problem, since we are stepping up to monit
4.0. Incompatible changes is allowed in a new major release, and it's
better to do them now, since we already have done incompability
changes in the grammar already.
> With IF/THEN/ELSE syntax it can provide good language base for the
> future.
Absolutely!
> We have now generic monitoring service template (currently
> process/file/directory/device) which could be extended for new
> types. It is similar to OOP templates - there is one common
> "predecessor class" containing common inherited atributes (such as
> start, stop, alert, timeout, etc.) and "descendants classes" with
> context related extensions (size, checksum, timestamp). Each
> monitoring service type can support all related attributes which are
> logical for it.
>
> We can use dependency between particular services to create the tree
> which will describe the system properly.
>
> What do you think?
I think I should fly down to Prague and by you a big beer. This is
nice. BTW, what are your feelings on removing start/stop from
file/device/directory entries? Via the depend usage pattern you have
invented they are not necessary really, are they?. Okay, well if a
"check device|file/directory" was used by itself without any depending
process you may want to execute something if an error occurs. How
about replacing start/stop with "if not exist then exec ".."? Or maybe
there is no need for exec either, and that a simple alert is the right
thing to do?
check device sybase_raw_device with path /dev/sybase
if not exist then exec "/opt/sybase/bin/stop_database"
or only alert
check device sybase_raw_device with path /dev/sybase
alert address@hidden # alert is sent if there is an error
I think maybe that alert is the right thing to do, for instance if
there was a device error, the problem would probably require more than
a single exec to fix and thus monit should not try to fix it, but
instead alert the sys. adm. to fix it. What do you think?
--
Jan-Henrik Haukeland