Re: timestamp monitoring + code simplification patch

[Martin Pala]

Jan-Henrik Haukeland wrote:

> Martin Pala <address@hidden> writes:
>
>  
>
> > Hi,
> >
> > i wrote feature for monit to allow monitoring timestamp of file or
> > directory recently.
> >
> >
> > I need this feature to watch health of iPlanet Messaging server stored
> > process (it is critical) - this process periodicaly updates timestamp
> > of 3 independent state files. As soon as timestamp of any of these
> > files is older than expected, it signalizes, that one of tasks, that
> > stored deamon does failed and real hell is starting. New statement has
> > following syntax:
> >
> >
> >  TIMESTAMP object [operator] value [unit] [action]
> >    
>
> Such functionality is not a big issue for me, but never the less it's
> an interesting feature and here's my +1 vote for including it in monit.
>
> Another thing, since this is connected to the filesystem and we
> already have decided to do file-system check (that is, raise an alert
> if the size of a device or file system is passing a specified
> treshold) and maybe with a little extra work you can extend this to
> include such a check? I know Rory has this in his pipeline but I do
> not think he has started yet? And if I'm right you will on only need
> to do a little bit more work to finalize such a function?
Yeah, it could be probably easy to do so. I have yet some stuff on my 
personal "todo" list, maybe on the weekend i will look on it (but i 
think more likely next week)

> Yet another thing, we should discuss the syntax. Up until know we have
> only had one major statement which is the 'check name with pidfile'
> and with option. This is going to be a stand-alone statement with the
> same scope as the check-statement.
>
> I'm wondering if we should keep with the check idiom and we could also
> combine this with the new filesystem test and use something like
> (instead of IF TIMESTAMP and such):
>
>
> CHECK DEVICE NAME ..options..
> CHECK DIRECTORY NAME ..options..
> CHECK FILE NAME ..options..
Present "timestamp" statement is presently only optional extension of 
current "check process_name ..." stuff. I think it should stay as it is, 
while it is process object property - it indigates in adition to 
protocol tests another sort of failure, that is regarded to the given 
process. If error is detected, it will use common process property (such 
as mailinglist, start/stop methods, etc.)

It could be useful to provide this (and other feautures as Jan described 
bellow, such as size, deleted, etc.) as standalone tests, so it will 
allow to check just that file, directory or device and etc. (in the case 
it is not regarded to any process).

> and here are some examples combining it with your timestamp
> functionality:
>
> check file "/usr/iplanet/msg-ims1/config/stored.ckp"
>    if timestamp  > 5 minutes  then alert martin
>    if size > 10Mb then alert hauk #New option
>    if deleted then alert address@hidden
>
> check directory "/foo/directory"
>    if timestamp < 10 minutes then alert martin
>    if size > 100Mb then alert #New option
>    if deleted then alert address@hidden
>    
>
> This one probably does not need a timestamp check?
>
> check device /dev/hda1
>    if used > 100Gb then alert martin or
>    if available < 100Mb the alert martin
>
>
>  
I'm +1 for (Jan's) described syntax. We can add new major syntax to 
allow watch another standalone/independent objects. We have some 
functionality, that could be use for it now (for major file types we can 
use "timestamp" and "checksum" tests + write another). If there is 
someone, who can go for it, i'll be happy, or i can start on it next week :)

Martin