|
From: | Martin Pala |
Subject: | Re: timestamp monitoring + code simplification patch |
Date: | Fri, 29 Nov 2002 15:53:01 +0100 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020913 Debian/1.1-1 |
Jan-Henrik Haukeland wrote:
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)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?
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.)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..
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).
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 :)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@hiddenThis 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
Martin
[Prev in Thread] | Current Thread | [Next in Thread] |