We use Log4J and Log4CXX in certain products we've made. Our usage is simple:
Logger.Hierarchy.Names -> for normal logging
Alerts.Logger.Hierarchy.Names -> for ALERTS meant for Network Operations Staff, Technicians etc. (usually important msgs)
Statistics.Logger.Hierarchy.Names -> System operations stats
--- PS. I can't post to the Log4J list as I'm not a subscriber. ---
Renny Koshy
President & CEO
--------------------------------------------
RUBIX Information Technologies, Inc.
www.rubixinfotech.com
| Curt Arnold <[EMAIL PROTECTED]>
01/19/2005 05:38 PM
|
To: Log4J Users List <log4j-user@logging.apache.org> cc: Log4CXX User <log4cxx-user@logging.apache.org> Subject: [SPAM] Re: Advice requested on best way to implement log4* to support non-hierarchal categories |
I'm continuing the initial cross-posting just to tell anyone interested
in following or responding to the thread to do so on
[EMAIL PROTECTED]
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".
