Re: controlling the status logger output?

[Ralph Goers]

Stdout is owned either by your application or the container you are running in. 
 While Log4j will write to wherever stdout is redirected to, it won't "manage" 
stdout.

Ralph

> On Mar 7, 2016, at 3:28 PM, Nicholas Duane <nic...@msn.com> wrote:
> 
> Just realized that maybe you meant we write our own application and handle 
> the rollover in that app when you stated "That said, if you are concerned you 
> can redirect stdout and implement the rolling yourself.".
> 
> Thanks,
> Nick
> 
> From: nic...@msn.com
> To: log4j-user@logging.apache.org
> Subject: RE: controlling the status logger output?
> Date: Mon, 7 Mar 2016 11:19:59 -0500
> 
> 
> 
> 
> I was asking about what's getting logged as I figured we shouldn't have that 
> much in there to be too worried about disk space consumption.  The appender 
> in question is an https appender we wrote.  If it encounters an exception is 
> calls LOGGER.error().  We should have some throttling around that such that 
> we don't generate 1-for-1 errors for each exception we encounter since a 
> problem with the https endpoint could flood the system, but we don't have 
> that throttling yet.  We're redirecting stdout now which is why we're running 
> into some disk consumption issue.  Is there a safe way to implement rolling 
> the file without the generating app knowing about it?  Wouldn't I potentially 
> be deleting the file contents out from under it?
> 
> I have a related question, does log4j2 have some throttling of its own?  If I 
> removed the LOGGER.error() and just let the exception bubble up to log4j2, 
> would it throttle those errors?  I think I was investigating this earlier and 
> noticed some throttling but can't be sure.
> 
> ..
> 
> I guess we could write our own application which takes stdin and writes to 
> files and this could do the rolling file work.  I would think something like 
> that might already exist in linux.
> 
> Thanks,
> Nick
> 
>> Subject: Re: controlling the status logger output?
>> From: ralph.go...@dslextreme.com
>> Date: Mon, 7 Mar 2016 08:54:05 -0700
>> To: log4j-user@logging.apache.org
>> 
>> If you set the status level to ERROR the StatusLogger should generate very 
>> little output. That said, if you are concerned you can redirect stdout and 
>> implement the rolling yourself.
>> 
>> Ralph
>> 
>>> On Mar 7, 2016, at 8:39 AM, Nicholas Duane <nic...@msn.com> wrote:
>>> 
>>> We've written some appenders and I think the prescribed approach is to use 
>>> the status logger in log4j2 components, is that correct?  The problem we're 
>>> running into is that we redirect stdout to a file and thus that file can 
>>> grow unbounded.  It seems there's no way to have something like a rolling 
>>> file appender for the status logger, correct?  Any suggestions for limiting 
>>> the size of the log generated by the status logger when stdout has been 
>>> redirected to a file?
>>> 
>>> Thanks,
>>> Nick
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
>> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>   


-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

RE: controlling the status logger output?

[Nicholas Duane]

Just realized that maybe you meant we write our own application and handle the 
rollover in that app when you stated "That said, if you are concerned you can 
redirect stdout and implement the rolling yourself.".

Thanks,
Nick

From: nic...@msn.com
To: log4j-user@logging.apache.org
Subject: RE: controlling the status logger output?
Date: Mon, 7 Mar 2016 11:19:59 -0500




I was asking about what's getting logged as I figured we shouldn't have that 
much in there to be too worried about disk space consumption.  The appender in 
question is an https appender we wrote.  If it encounters an exception is calls 
LOGGER.error().  We should have some throttling around that such that we don't 
generate 1-for-1 errors for each exception we encounter since a problem with 
the https endpoint could flood the system, but we don't have that throttling 
yet.  We're redirecting stdout now which is why we're running into some disk 
consumption issue.  Is there a safe way to implement rolling the file without 
the generating app knowing about it?  Wouldn't I potentially be deleting the 
file contents out from under it?

I have a related question, does log4j2 have some throttling of its own?  If I 
removed the LOGGER.error() and just let the exception bubble up to log4j2, 
would it throttle those errors?  I think I was investigating this earlier and 
noticed some throttling but can't be sure.

..

I guess we could write our own application which takes stdin and writes to 
files and this could do the rolling file work.  I would think something like 
that might already exist in linux.

Thanks,
Nick

> Subject: Re: controlling the status logger output?
> From: ralph.go...@dslextreme.com
> Date: Mon, 7 Mar 2016 08:54:05 -0700
> To: log4j-user@logging.apache.org
> 
> If you set the status level to ERROR the StatusLogger should generate very 
> little output. That said, if you are concerned you can redirect stdout and 
> implement the rolling yourself.
> 
> Ralph
> 
> > On Mar 7, 2016, at 8:39 AM, Nicholas Duane <nic...@msn.com> wrote:
> > 
> > We've written some appenders and I think the prescribed approach is to use 
> > the status logger in log4j2 components, is that correct?  The problem we're 
> > running into is that we redirect stdout to a file and thus that file can 
> > grow unbounded.  It seems there's no way to have something like a rolling 
> > file appender for the status logger, correct?  Any suggestions for limiting 
> > the size of the log generated by the status logger when stdout has been 
> > redirected to a file?
> > 
> > Thanks,
> > Nick
> >   
> 
> 
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 

  

Re: controlling the status logger output?

[Ralph Goers]

Log4j 2 has a BurstFilter that can be used for throttling.

Ralph

> On Mar 7, 2016, at 9:19 AM, Nicholas Duane <nic...@msn.com> wrote:
> 
> I was asking about what's getting logged as I figured we shouldn't have that 
> much in there to be too worried about disk space consumption.  The appender 
> in question is an https appender we wrote.  If it encounters an exception is 
> calls LOGGER.error().  We should have some throttling around that such that 
> we don't generate 1-for-1 errors for each exception we encounter since a 
> problem with the https endpoint could flood the system, but we don't have 
> that throttling yet.  We're redirecting stdout now which is why we're running 
> into some disk consumption issue.  Is there a safe way to implement rolling 
> the file without the generating app knowing about it?  Wouldn't I potentially 
> be deleting the file contents out from under it?
> 
> I have a related question, does log4j2 have some throttling of its own?  If I 
> removed the LOGGER.error() and just let the exception bubble up to log4j2, 
> would it throttle those errors?  I think I was investigating this earlier and 
> noticed some throttling but can't be sure.
> 
> ..
> 
> I guess we could write our own application which takes stdin and writes to 
> files and this could do the rolling file work.  I would think something like 
> that might already exist in linux.
> 
> Thanks,
> Nick
> 
>> Subject: Re: controlling the status logger output?
>> From: ralph.go...@dslextreme.com
>> Date: Mon, 7 Mar 2016 08:54:05 -0700
>> To: log4j-user@logging.apache.org
>> 
>> If you set the status level to ERROR the StatusLogger should generate very 
>> little output. That said, if you are concerned you can redirect stdout and 
>> implement the rolling yourself.
>> 
>> Ralph
>> 
>>> On Mar 7, 2016, at 8:39 AM, Nicholas Duane <nic...@msn.com> wrote:
>>> 
>>> We've written some appenders and I think the prescribed approach is to use 
>>> the status logger in log4j2 components, is that correct?  The problem we're 
>>> running into is that we redirect stdout to a file and thus that file can 
>>> grow unbounded.  It seems there's no way to have something like a rolling 
>>> file appender for the status logger, correct?  Any suggestions for limiting 
>>> the size of the log generated by the status logger when stdout has been 
>>> redirected to a file?
>>> 
>>> Thanks,
>>> Nick
>>>   
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
>> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>> 
> 



-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: controlling the status logger output?

[Douglas Wegscheid]

On Mon, Mar 7, 2016 at 11:19 AM, Nicholas Duane  wrote:

> I guess we could write our own application which takes stdin and writes to
> files and this could do the rolling file work.  I would think something
> like that might already exist in linux.
>
> Thanks,
> Nick
>

take a look at the rotatelogs util that comes with Apache Httpd.

*■ DOUGLAS E. WEGSCHEID* // Lead Analyst, Information Security
(269) 923-5278 // douglas_e_wegsch...@whirlpool.com

"A wrong note played hesitatingly is a wrong note. A wrong note played with
conviction is interpretation."

-- 
*NOTICE: Whirlpool Corporation e-mail is for the designated recipient only 
and may contain proprietary or otherwise confidential information. If you 
have received this e-mail in error, please notify the sender immediately 
and delete the original. Any other use or disclosure of the e-mail by you 
is unauthorized.*

RE: controlling the status logger output?

[Nicholas Duane]

I was asking about what's getting logged as I figured we shouldn't have that 
much in there to be too worried about disk space consumption.  The appender in 
question is an https appender we wrote.  If it encounters an exception is calls 
LOGGER.error().  We should have some throttling around that such that we don't 
generate 1-for-1 errors for each exception we encounter since a problem with 
the https endpoint could flood the system, but we don't have that throttling 
yet.  We're redirecting stdout now which is why we're running into some disk 
consumption issue.  Is there a safe way to implement rolling the file without 
the generating app knowing about it?  Wouldn't I potentially be deleting the 
file contents out from under it?

I have a related question, does log4j2 have some throttling of its own?  If I 
removed the LOGGER.error() and just let the exception bubble up to log4j2, 
would it throttle those errors?  I think I was investigating this earlier and 
noticed some throttling but can't be sure.

..

I guess we could write our own application which takes stdin and writes to 
files and this could do the rolling file work.  I would think something like 
that might already exist in linux.

Thanks,
Nick

> Subject: Re: controlling the status logger output?
> From: ralph.go...@dslextreme.com
> Date: Mon, 7 Mar 2016 08:54:05 -0700
> To: log4j-user@logging.apache.org
> 
> If you set the status level to ERROR the StatusLogger should generate very 
> little output. That said, if you are concerned you can redirect stdout and 
> implement the rolling yourself.
> 
> Ralph
> 
> > On Mar 7, 2016, at 8:39 AM, Nicholas Duane <nic...@msn.com> wrote:
> > 
> > We've written some appenders and I think the prescribed approach is to use 
> > the status logger in log4j2 components, is that correct?  The problem we're 
> > running into is that we redirect stdout to a file and thus that file can 
> > grow unbounded.  It seems there's no way to have something like a rolling 
> > file appender for the status logger, correct?  Any suggestions for limiting 
> > the size of the log generated by the status logger when stdout has been 
> > redirected to a file?
> > 
> > Thanks,
> > Nick
> >   
> 
> 
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 
  

Re: controlling the status logger output?

[Ralph Goers]

If you set the status level to ERROR the StatusLogger should generate very 
little output. That said, if you are concerned you can redirect stdout and 
implement the rolling yourself.

Ralph

> On Mar 7, 2016, at 8:39 AM, Nicholas Duane  wrote:
> 
> We've written some appenders and I think the prescribed approach is to use 
> the status logger in log4j2 components, is that correct?  The problem we're 
> running into is that we redirect stdout to a file and thus that file can grow 
> unbounded.  It seems there's no way to have something like a rolling file 
> appender for the status logger, correct?  Any suggestions for limiting the 
> size of the log generated by the status logger when stdout has been 
> redirected to a file?
> 
> Thanks,
> Nick
> 



-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: controlling the status logger output?

[Matt Sicker]

The only thing I can think of is logrotate, but I'm not sure if that would
work properly. StatusLogger is intentionally simple so that it will always
work regardless of the rest of the system.

On 7 March 2016 at 09:39, Nicholas Duane  wrote:

> We've written some appenders and I think the prescribed approach is to use
> the status logger in log4j2 components, is that correct?  The problem we're
> running into is that we redirect stdout to a file and thus that file can
> grow unbounded.  It seems there's no way to have something like a rolling
> file appender for the status logger, correct?  Any suggestions for limiting
> the size of the log generated by the status logger when stdout has been
> redirected to a file?
>
> Thanks,
> Nick
>




-- 
Matt Sicker