On Feb 7, 2008, at 3:38 PM, Mike Baker wrote:
The reason for getting into the source is we are interested in
changing the way log filtering is done. Rather than having levels
of fatal, error, info, warn, debug, etc., which are hierarchically
enabled (i.e., if you set the level for debug, you get all the
rest), we would like to be able to selectively enable different
logging by log category/type, for example:
LOG_FATAL: Reserved for module-fatal unrecoverable conditions,
indicating the module cannot continue normal operations. Normally
never filtered.
LOG_ERROR: Reserved for module errors which are recoverable.
Normally never filtered.
LOG_STATUS: Catch-all, used to report status / information.
LOG_CONFIG: Used to report configuration change activities.
LOG_FUNC: Used to report entry / exit from functions.
LOG_TIMING: Used to report performance, i.e., the module has
reached an observable event.
LOG_COMM: Used to report the module is attempting / has completed
intermodule communications.
LOG_DBA: Used to report database activities.
LOG_USER08…LOG_USER31: TBD usage, perhaps to accomplish special
debug logging / filtering for troubleshooting a system problem.
We would like these log messages from these various categories/types
to be enabled / disabled independently. For example, if we are
trying to optimize performance, we might only turn on LOG_TIMING to
try identify what is running slow. Profiling helps on this, but if
a call varies significantly in how long it takes depending upon the
parameters passed, logging will help us focus on the problem.
In a previous company that I worked, there was a C++ logging library
that supported both logging priority (hi, med, low – analogous to
log4net’s fatal, error, etc.), but also included logging category,
like described above. We found was that logging category was quite
useful in actual debugging, and having the logging priority, even
though there were 3 levels, we essentially used them more like
boolean flags.
Has anyone else considered something similar to what I described
above for log4net?
Thanks,
-Mike
It is a pretty common temptation to want to use levels to indicate
topic or audience which is precisely what the logger name hierarchy
(which was originally called category in log4j, but was renamed as
logger to be consistent with JDK 1.4's logging) is intended to do.
Most new users wrongly assume that logger names MUST mirror class
names. That is one useful pattern, but not the only pattern for
organizing your logging messages,
If you attempt to use level to indicate topic, then you come up with
the dilemma on how to prioritize highly significant TIMING or COM or
DBA messages from less significant messages.
I would suggest that you use logger names like:
"com.example.myapp.myclass" for generic diagnostic logging
"dba.com.example.myapp.myclass" for database relative logging in that
specific class.
"comm.com.example.myapp.myclass" for communication relative logging in
that specific class.
"timing.com.example.myapp.myclass" for timing relative logging in that
specific class.
You could flip the order if the class is a more significant than
function for filtering or routing.
