a tiny logfile problem
list Kolbjørn Barmen
Due to the nature of the LOG entries in client-local.cfg I keep getting red dots evey now and then. [linux] log:/var/log/messages:10240 ignore MARK The number 10240 is the MAXDATA in bytes that will be cheked. The problem is that this results in uncomplete lines, and hence my IGNORE patterns does not always apply. For instance, on certain machines I log named queries, however I want Hobbit to ignore query errors, so I have a this in hobbit-client.cfg "IGNORE=%(named.*query|floppy|interrupt)" which mostly works. However, every now and then the msgs page for this host shows a "Full log" starting with "med[1327]: client xxx.xxx.xxx.xxx#1057: query: www.errorsafe.com IN A" where "med" is the end of "named" - this ofcourse sneaks past my IGNORE. Would it be possible for the clients to not report on uncomplete lines? I'm tempted to name this a bug, I'm just sorry I didnt catch this before 4.2.0 release, it's just that they pass along quite briefly. Btw.. funny host and domain names with "error" and "warn" and "critical".. :) -- Kolbjørn Barmen UNINETT Driftsenter
list Kolbjørn Barmen
I havent seen any respons on this.. am I the only one experiencing this as a problem? :)
▸
On Mon, 21 Aug 2006, Kolbjørn Barmen wrote:
Due to the nature of the LOG entries in client-local.cfg I keep getting red dots evey now and then. [linux] log:/var/log/messages:10240 ignore MARK The number 10240 is the MAXDATA in bytes that will be cheked. The problem is that this results in uncomplete lines, and hence my IGNORE patterns does not always apply. For instance, on certain machines I log named queries, however I want Hobbit to ignore query errors, so I have a this in hobbit-client.cfg "IGNORE=%(named.*query|floppy|interrupt)" which mostly works. However, every now and then the msgs page for this host shows a "Full log" starting with "med[1327]: client xxx.xxx.xxx.xxx#1057: query: www.errorsafe.com IN A" where "med" is the end of "named" - this ofcourse sneaks past my IGNORE. Would it be possible for the clients to not report on uncomplete lines? I'm tempted to name this a bug, I'm just sorry I didnt catch this before 4.2.0 release, it's just that they pass along quite briefly.
--
Kolbjørn Barmen
UNINETT Driftsenter
list Greg L Hubbard
No, this is an issue for me too. It would be better for me if the chunk that is processed were a set of lines instead of a set of bytes. I get parse errors from incomplete lines, too. GLH
▸
-----Original Message-----
From: Kolbjørn Barmen [mailto:user-5623b4f246b3@xymon.invalid] Sent: Wednesday, August 23, 2006 1:05 PM
To: user-ae9b8668bcde@xymon.invalid
Subject: Re: [hobbit] a tiny logfile problem
I havent seen any respons on this.. am I the only one experiencing this as a problem? :)
On Mon, 21 Aug 2006, Kolbjørn Barmen wrote:
Due to the nature of the LOG entries in client-local.cfg I keep getting red dots evey now and then. [linux] log:/var/log/messages:10240 ignore MARK The number 10240 is the MAXDATA in bytes that will be cheked. The problem is that this results in uncomplete lines, and hence my IGNORE patterns does not always apply. For instance, on certain machines I log named queries, however I want Hobbit to ignore query errors, so I have a this in hobbit-client.cfg "IGNORE=%(named.*query|floppy|interrupt)" which mostly works. However, every now and then the msgs page for this host shows a "Full log" starting with "med[1327]: client xxx.xxx.xxx.xxx#1057: query: www.errorsafe.com IN A" where "med" is the end of "named" - this ofcourse sneaks past my IGNORE. Would it be possible for the clients to not report on uncomplete lines? I'm tempted to name this a bug, I'm just sorry I didnt catch this before 4.2.0 release, it's just that they pass along quite briefly.
-- Kolbjørn Barmen UNINETT Driftsenter
list Henrik Størner
▸
On Mon, Aug 21, 2006 at 12:39:35PM +0200, Kolbjørn Barmen wrote:
Due to the nature of the LOG entries in client-local.cfg I keep getting red dots evey now and then. [linux] log:/var/log/messages:10240 ignore MARK The number 10240 is the MAXDATA in bytes that will be cheked. The problem is that this results in uncomplete lines, and hence my IGNORE patterns does not always apply.
The idea was that logfetch should report only complete lines. I don't know quite where that broke, but I will look into it. It looks like it is a problem only when the maximum amount of logfile data is reached. Regards, Henrik