On Thu, Apr 06, 2006 at 10:26:27PM, Henrik Storner wrote:

On Thu, Apr 06, 2006 at 04:15:59PM -0400, John Glowacki wrote:

...

Does the new log file monitoring have the ability to alert on empty log files? I would like to be alerted if a log file is empty for longer than 16, 21 or 31 minutes. Most of our systems are set to 15 or 20 minute MARK's.

No, it doesn't. It would be pretty easy to implement, if there's enough people asking for it.

I would love to see this as well *sigh*. For most of our systems empty means syslog is not working even though process seems to be running

Henrik

To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

-- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu "..there are two kinds of people: those who work and those who take the credit...try to be in the first group;...less competition there." - Indira Gandhi

On Fri, Apr 07, 2006 at 01:44:14AM -0400, Asif Iqbal wrote:

On Thu, Apr 06, 2006 at 10:26:27PM, Henrik Storner wrote:

...

On Thu, Apr 06, 2006 at 04:15:59PM -0400, John Glowacki wrote:

...

Does the new log file monitoring have the ability to alert on empty log files? I would like to be alerted if a log file is empty for longer than 16, 21 or 31 minutes. Most of our systems are set to 15 or 20 minute MARK's.

No, it doesn't. It would be pretty easy to implement, if there's enough people asking for it.

I would love to see this as well *sigh*. For most of our systems empty means syslog is not working even though process seems to be running

I should know better than to say "pretty easy to implement" ... This took me on a somewhat longer detour than I had expected.

Rather than just implement a check of "go red if the logfile is empty", I've added a new set of checks to the Hobbit client which implement a fairly wide range of checks on files and directories.

So you can check the size of files or directories, how long it's been since they were last updated, what owner/permissions they have, and even do a full MD5, SHA-1 or RIPEMD160 checksum of the file data and match it against a pre-computed value to make sure the file hasn't been tampered with.

File- and directory-sizes can also be tracked in RRD-files, so you have graphs showing e.g. the disk usage for the /home/henrik/hobbit/ directory.

I expect to release the next trial version in a day or two. The adventurous ones can grab the latest snapshot, which should be very close to the "real thing".

(And the docs have improved).

Regards, Henrik

On Mon, Apr 17, 2006 at 08:41:41AM +0200, lars ebeling wrote:

In yesterdays (16/4) snapshot there was a new test "files" with this information about a file:

type:100000 (file) mode:644 (-rw-r--r--) linkcount:1 owner:0 (root) group:0 (root) size:1516 clock:1145255747 (2006/04/17-08:35:47) atime:1145255747 (2006/04/17-08:35:47) ctime:1145249392 (2006/04/17-06:49:52) mtime:1145249392 (2006/04/17-06:49:52)

In todays (17/4) this information is found under the "msgs" test

I assume the file you're referring to is a log-file. Yes, I changed the behaviour slightly. Logfiles will only show up in the "files" column if there is any kind of check defined for them (size, owner, modification time ...) Otherwise, they would tend to clutter the "files" display even though they could never cause any kind of status change in that column.

Henrik