Switching default log4j threshold

Joseph Marques jmarques at redhat.com
Thu Jan 21 19:10:32 UTC 2010


On 01/21/2010 01:40 PM, Mike McCune wrote:
> On 01/20/2010 10:32 PM, Joseph Marques wrote:
>> On 01/21/2010 01:00 AM, Mike McCune wrote:
>>> I spent 30 minutes being frustrated that I couldn't see any changes
>>> affected by adding DEBUG packages to our log4j config file.  No mater
>>> what I did, my console wouldn't show the additional output.
>>>
>>> I realized it was the Threshold setting in our config file.
>>>
>>> Anyone object if I bump this to DEBUG?  Why would we permanently 
>>> want to
>>> hide DEBUG from the console output.  Seems pointless
>>>
>> In a production environment where each individual RHQ Server is
>> communicating with a few dozen (or a few hundred) agents, the amount of
>> debug logging goes through the roof.  I wouldn't mind parameterizing
>> this and having "-Pdev,container" replace the token with DEBUG for our
>> daily development, but we should leave it at INFO for the prod builds so
>> as not to create hundreds of megs of logs at client sights, which would
>> (considering the default log file retention policy) overwrite any
>> meaningful data that would have been useful attachments for customer
>> support cases.
>
> huh?  The setting I'm discussing controls the maximum threshold that 
> will ever get sent to the console, not any kind of global debug level:
>
> <!-- Appender will not log any messages with priority lower than INFO 
> even if the category's priority is set lower.  So essentially, this 
> means DEBUG and TRACE messages will never be output to the console -->
> <param name="Threshold" value="INFO"/>

Ah, I see what you mean now.  I read your initial post too quickly, and 
thought you were suggesting to move the global categories to debug 
level, which would affect what gets logged to file.  The 'threshold' 
parameter is mostly (though not entirely) a legacy thing because...
>
> I was *NOT* suggesting we change these:
>
> <category name="org">
> <priority value="INFO"/>
> </category>
> <category name="com">
> <priority value="INFO"/>
> </category>
> <category name="net">
> <priority value="INFO"/>
> </category>

...when the 'threshold' parameter was added, we never used to have these 
INFO categories at the top-level domains.  Now that we do, having a 
global threshold for the consoler logger is less critical because you 
need to override the top-level domains with DEBUG for the classes you're 
interested in.

In any event, some might still argue that they want to keep the console 
at INFO level and let the debug lines go to file only...a file which 
they might be tailing...a file which they might be tail/grepping...a 
file which they might be tail/grepping several times over in different 
terminals to visually separate the output from different interacting 
subsystems.

I'm indifferent - I'm neither married to keeping the 'threshold' at INFO 
level nor am I all that inclined to move it to DEBUG level either.  I 
defer to the next strongest opinion on this thread.  ; )

>
> why would changing the Threshold cause hundreds of megs of DEBUG to 
> show up?  Scrolling through our jboss-log4j.xml there are only 2 
> packages that have their priority set to DEBUG:
>
> <category name="org.rhq.core.db.ant">
> <category name="org.rhq.core.db.setup">
>
> so, AFAIK, changing the Threshold would only cause these 2 classes to 
> show additional logging and since those are only used during build 
> time, I don't think it is an issue.
>
>
>
>
> The source of my frustration was that I changed the category priority 
> for my package:
>
> <category name="org.rhq.enterprise.server.scheduler">
> <priority value="DEBUG"/>
> </category>
>
>
> yet I never saw anything in the Console until I bumped the Threshold 
> in the Console Appender to DEBUG.  This allowed my package's 
> individual logging settings to be obeyed.   I found it annoying that 
> in order to enable debug you have to change *2* things.  Granted it 
> isn't that big of a deal once you know but annoying nonetheless and 
> confusing to the end user who isn't aware.
>
>
>>
>> In the most abstract sense, the DEBUG level should really only be
>> necessary if something needs to be debugged.  If you are finding that
>> some subsystem logger is not being "chatty" enough, then we should
>> discuss moving more messages to INFO level.
>
> naturally.  I am am not advocating switching our log.info() calls to 
> log.debug() or anything of the sort.  Like any code we write you have 
> to be smart and selective about the levels you choose when you log a 
> class.
>
I was suggesting the opposite.  In some (perhaps rare) circumstances 
it's necessary to move a few of your DEBUG statements up to INFO level, 
because you /always/ want to see what they are chatting about.


More information about the rhq-devel mailing list