[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [hobbit] Bug Report: Critical error in log couldn't be sent to server every time
- To: hobbit (at) hswn.dk
- Subject: Re: [hobbit] Bug Report: Critical error in log couldn't be sent to server every time
- From: "s_aiello (at) comcast.net" <s_aiello (at) comcast.net>
- Date: Thu, 24 Jul 2008 08:40:58 -0400
- References: <980B46CCEFAE3F4A836BBF54E4DBCB160ADC4AFF (at) SJEXVS01.ehi.ehealth.com> <200807230950.12729.s_aiello (at) comcast.net> <980B46CCEFAE3F4A836BBF54E4DBCB160AE4BD62 (at) SJEXVS01.ehi.ehealth.com>
- User-agent: KMail/1.9.9
On Wednesday 23 July 2008, Samuel Cai wrote:
>> It really depends on what log level your application is logging at. If
>> you are
>> logging at 'INFO' level, then there will be alot of data to process. As
>> you
>> see, Hobbit implements a limit on how much log data it will parse. This
>> is a
>> good thing, at least in my opinion.
>>
>> It all depends what is in your log... and why soo much data is being
>> written.
>> If they are all errors, well hobbit would be catching them telling you
>> there
>> are errors. Since this is not the case.. would guess your log has data
>> other
>> than errors.
>>
>> Suggestions:
>> 1. tune your application log settings so that only errors are written.
>> 2. make use of the client-local.cfg log's setting of ignore. This will
>> allow
>> the hobbit client to identify what is an extraneous message, and ignore
>> it.
>> Per the man page:
>>
>> The ignore PATTERN line (optional) defines lines in the logfile which
>> are
>> ignored entirely, i.e. they are stripped from the logfile data before
>> sending
>> it to the Hobbit server. It is used to remove completely unwanted
>> "noise"
>> entries from the logdata processed by Hobbit. "PATTERN" is a regular
>> expression.
>>
>> I hope this helps you,
>> ~Steve
>
> It's great to hear you guys, Hubbard and Steve, that you also find this
> is a limitation (more than a bug), not wrong in my configuration.
>
> I was thinking to modify source codes before, but it might be difficult
> for me. I'll try your suggestions, thanks!
>
> Samuel Cai
>
In my reply to your email, I said that this behavior "was a good thing". I do
not find this to be a limitation at all. I offered you two possible
solutions, were any of these applicable ?
The "limitation" really resides in whatever application is logging soo
verbosely. Production level applications should have their logging limited as
much as possible whenever possible, only logging indicators of errors. And
whenever this isn't possible, make use of the IGNORE option.
~Steve