You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Daniel Einspanjer <de...@gmail.com> on 2005/01/19 22:00:28 UTC
Advice requested on best way to implement log4* to support non-hierarchal categories
My company is looking to standardize our logging across all of our C++
(and eventually Java) projects and we would certainly rather use a
well-known architecture such as log4j/log4cxx rather than growing our
own.
My biggest challenge is that one of the key desires our developers
have is to be able to mix and match the selectiveness of the logging.
The easiest way to explain would probably be by example.
We would like to be able to easily mix and match any of the following
categories of log messages:
* performance/timing related
* search result related
* search result quality related
* any messages in the hierarchy com.foo
* no messages from the class/hierarchy com.foo.bar
We were hoping to be able to define the characteristics of log
messages within the class com.foo.bar so that we could have overall
performance log messages, search result performance messages, search
result quality messages, overall search result messages, etc. and then
via configuration we could say, "hrm, lets take a look at the search
result quality across all of com.foo.
Is anyone else doing anything like this out there? I have done quite
a bit of reading on the log4j and log4cxx documentation, but I have
not found a good resource for explaining the Filter class hierarchy.
Any pointers or advice is welcome.
Thanks,
Daniel E.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Advice requested on best way to implement log4* to support non-hierarchal categories
Posted by Curt Arnold <ca...@apache.org>.
There wasn't as much thought behind it as the fairly cool name would
imply. Basically, if you had a hierarchy of loggers derived from
"metrics" and a hierarchy of logger for diagnostics, you could do
something like:
<log4j:configuration>
<logger name="metrics">
<level value="INFO"/>
<appender-ref ref="metrics-log"/>
</logger>
<logger name="com.example.foobar">
<level value="INFO"/>
<appender-ref ref="foobar-log"/>
</logger>
<logger name="metrics.com.example.foobar">
<level value="INFO"/>
<appender-ref ref="foobar-log"/>
</logger>
</log4j:configuration>
On Jan 20, 2005, at 10:51 AM, Daniel Einspanjer wrote:
> Curt,
>
> Could you provide any more information on this concept of "bridging
> loggers" by routing to the same appenders? It sounds like a tactic
> that might be useful to me, and I haven't seen this mentioned anywhere
> else yet.
>
>
> On Wed, 19 Jan 2005 16:38:16 -0600, Curt Arnold <ca...@apache.org>
> wrote:
>> One problem is when a message is of interest to multiple audiences.
>> For example, the search metrics may be of interest to both the
>> diagnostician and the performance analyst. Since these would
>> typically
>> be low volume, it might be simplest just to repeat the message on both
>> the diagnostic and performance logger. Otherwise, you might be able
>> to
>> bridge loggers by routing "performance.com.example.foobar" to the same
>> appenders as "com.example.foobar".
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Advice requested on best way to implement log4* to support non-hierarchal categories
Posted by Daniel Einspanjer <de...@gmail.com>.
Curt,
Could you provide any more information on this concept of "bridging
loggers" by routing to the same appenders? It sounds like a tactic
that might be useful to me, and I haven't seen this mentioned anywhere
else yet.
On Wed, 19 Jan 2005 16:38:16 -0600, Curt Arnold <ca...@apache.org> wrote:
> One problem is when a message is of interest to multiple audiences.
> For example, the search metrics may be of interest to both the
> diagnostician and the performance analyst. Since these would typically
> be low volume, it might be simplest just to repeat the message on both
> the diagnostic and performance logger. Otherwise, you might be able to
> bridge loggers by routing "performance.com.example.foobar" to the same
> appenders as "com.example.foobar".
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Advice requested on best way to implement log4* to support non-hierarchal categories
Posted by Curt Arnold <ca...@apache.org>.
I'm continuing the initial cross-posting just to tell anyone interested
in following or responding to the thread to do so on
log4j-user@logging.apache.org.
I think that you need to design your use of the log4X frameworks so
that they can readily evolve as you discover the best hierarchy for
your applications. The hierarchical metaphor used in the log4X is
useful, but not perfect, for configuring logging. Even a bad hierarchy
is better than individually configuring each logger.
The logging hierarchy should be designed to make typical configurations
simple to express. Configuration precedes collection which precedes
analysis. If you make configuration or collection difficult, you won't
have anything to analyze.
You should should consider the audiences for the log messages and the
frequency of the potential logging requests and their impact on
performance.
The most common "audience" for log4X messages are diagnosticians trying
to figure out why something is going wrong. Your audience is assumed
to be familiar with the source code for the application and fully
qualified class names make an effective hierarchy. The logging
requests are frequent and should be very low cost in normal operation.
Some other "audiences" would be security analysts, performance
analysts, and business analysts. Obviously one individual might be a
diagnostician in one instance and a performance analyst in another, but
thinking in terms of discrete audiences is helpful. Logging requests
intended for these other audiences are typically much less frequent, so
the need to suppress "unnecessary" messages for performance reasons is
much less important.
I would recommend using distinct Logger references for each of these
audiences within the implementation. For example:
public class Query {
private static final Logger logger = Logger.getLogger(Query.class);
private static final Logger performanceLogger =
MyLoggerHelper.getPerformanceLogger(Query.class);
private static final Logger securityLogger =
MyLoggerHelper.getSecurityLogger(Query.class);
}
Your implementation of MyLoggerHelper.getPerformanceLogger could start
out as simple as returning Logger.getLogger("performance") or
Logger.getLogger("performance." + clz.getName());
One problem is when a message is of interest to multiple audiences.
For example, the search metrics may be of interest to both the
diagnostician and the performance analyst. Since these would typically
be low volume, it might be simplest just to repeat the message on both
the diagnostic and performance logger. Otherwise, you might be able to
bridge loggers by routing "performance.com.example.foobar" to the same
appenders as "com.example.foobar".
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Advice requested on best way to implement log4* to support
non-hierarchal categories
Posted by Ceki Gülcü <ce...@qos.ch>.
Daniel,
In log4j 1.4, (the version after 1.3), log4j will offer ways of
classifying loggers in multiple dimensions. This is designed to solve
exactly the same problem you are trying to solve. For log4j 1.2 and
1.3, the suggestions provided by Scott and Curt remain valid.
At 10:00 PM 1/19/2005, you wrote:
>My company is looking to standardize our logging across all of our C++
>(and eventually Java) projects and we would certainly rather use a
>well-known architecture such as log4j/log4cxx rather than growing our
>own.
>
>My biggest challenge is that one of the key desires our developers
>have is to be able to mix and match the selectiveness of the logging.
>The easiest way to explain would probably be by example.
>
>We would like to be able to easily mix and match any of the following
>categories of log messages:
>* performance/timing related
>* search result related
>* search result quality related
>* any messages in the hierarchy com.foo
>* no messages from the class/hierarchy com.foo.bar
>
>We were hoping to be able to define the characteristics of log
>messages within the class com.foo.bar so that we could have overall
>performance log messages, search result performance messages, search
>result quality messages, overall search result messages, etc. and then
>via configuration we could say, "hrm, lets take a look at the search
>result quality across all of com.foo.
>
>Is anyone else doing anything like this out there? I have done quite
>a bit of reading on the log4j and log4cxx documentation, but I have
>not found a good resource for explaining the Filter class hierarchy.
>Any pointers or advice is welcome.
>
>Thanks,
>
>Daniel E.
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Advice requested on best way to implement log4* to support non-hierarchal categories
Posted by Curt Arnold <ca...@apache.org>.
I'm continuing the initial cross-posting just to tell anyone interested
in following or responding to the thread to do so on
log4j-user@logging.apache.org.
I think that you need to design your use of the log4X frameworks so
that they can readily evolve as you discover the best hierarchy for
your applications. The hierarchical metaphor used in the log4X is
useful, but not perfect, for configuring logging. Even a bad hierarchy
is better than individually configuring each logger.
The logging hierarchy should be designed to make typical configurations
simple to express. Configuration precedes collection which precedes
analysis. If you make configuration or collection difficult, you won't
have anything to analyze.
You should should consider the audiences for the log messages and the
frequency of the potential logging requests and their impact on
performance.
The most common "audience" for log4X messages are diagnosticians trying
to figure out why something is going wrong. Your audience is assumed
to be familiar with the source code for the application and fully
qualified class names make an effective hierarchy. The logging
requests are frequent and should be very low cost in normal operation.
Some other "audiences" would be security analysts, performance
analysts, and business analysts. Obviously one individual might be a
diagnostician in one instance and a performance analyst in another, but
thinking in terms of discrete audiences is helpful. Logging requests
intended for these other audiences are typically much less frequent, so
the need to suppress "unnecessary" messages for performance reasons is
much less important.
I would recommend using distinct Logger references for each of these
audiences within the implementation. For example:
public class Query {
private static final Logger logger = Logger.getLogger(Query.class);
private static final Logger performanceLogger =
MyLoggerHelper.getPerformanceLogger(Query.class);
private static final Logger securityLogger =
MyLoggerHelper.getSecurityLogger(Query.class);
}
Your implementation of MyLoggerHelper.getPerformanceLogger could start
out as simple as returning Logger.getLogger("performance") or
Logger.getLogger("performance." + clz.getName());
One problem is when a message is of interest to multiple audiences.
For example, the search metrics may be of interest to both the
diagnostician and the performance analyst. Since these would typically
be low volume, it might be simplest just to repeat the message on both
the diagnostic and performance logger. Otherwise, you might be able to
bridge loggers by routing "performance.com.example.foobar" to the same
appenders as "com.example.foobar".
Re: Advice requested on best way to implement log4* to support
non-hierarchal categories
Posted by Larry Young <ly...@dalmatian.com>.
Daniel,
This is exactly what I did for all of our projects about a year
ago, with help from the folks on this list! I generally disagree that
there is any necessary relationship between the various types of loggers,
which the levels in log4j enforce.
Basically, I created a logging class that WRAPS the log4j Logger
class, and then I subclass it for each logger type that I need to define (I
currently have one for Error, Data, CodeBlock/Timing, DB, Info, and
PageTracing with more planned). The trick (thanks to Paul Smith!) was to
prefix the class specification with the logger type, and then simply set
the level to either ALL or OFF to enable/disable them based on the
prefix. So I can turn on PageTracing without also getting DB, Timing,
etc. Each one is independent of the other. And because I'm wrapping the
Logger class, I can hide all these details from my developers (except a
little exposure in the log4j.xml file!). BTW, I'm using log4j 1.2.8 for
this. When 1.3 is available, it sounds like it might have something in
there to help do this, which would be nice.
--- regards ---
Larry
At 02:00 PM 1/19/05, you wrote:
>My company is looking to standardize our logging across all of our C++
>(and eventually Java) projects and we would certainly rather use a
>well-known architecture such as log4j/log4cxx rather than growing our
>own.
>
>My biggest challenge is that one of the key desires our developers
>have is to be able to mix and match the selectiveness of the logging.
>The easiest way to explain would probably be by example.
>
>We would like to be able to easily mix and match any of the following
>categories of log messages:
>* performance/timing related
>* search result related
>* search result quality related
>* any messages in the hierarchy com.foo
>* no messages from the class/hierarchy com.foo.bar
>
>We were hoping to be able to define the characteristics of log
>messages within the class com.foo.bar so that we could have overall
>performance log messages, search result performance messages, search
>result quality messages, overall search result messages, etc. and then
>via configuration we could say, "hrm, lets take a look at the search
>result quality across all of com.foo.
>
>Is anyone else doing anything like this out there? I have done quite
>a bit of reading on the log4j and log4cxx documentation, but I have
>not found a good resource for explaining the Filter class hierarchy.
>Any pointers or advice is welcome.
>
>Thanks,
>
>Daniel E.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-user-help@logging.apache.org
--------------------------
Larry Young
The Dalmatian Group
www.dalmatian.com
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org