Re: LANGUAGE CHANGES - service templates

[Jan-Henrik Haukeland]

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