log4net nested loggers .config example

Question

Hi, I'm working on setting up log4net in a multi-tiered application. I have most of my logging set up as desired, but now I'm trying to get the entries in .config set up in a way to allow maximum flexibility on the levels being output.

My logger naming convention goes something like:
ExecutableName.WorkerThreadName.[ExternalModuleName(s)].ClassName

My current logger definition section in the .config file looks something like:

<root>
  <level value="DEBUG" />
  <appender-ref ref="MyAppender" />
</root>

<logger name = "ExecutableName">
  <level value="FATAL" />   
</logger>

<logger name = "ExecutableName.WorkerThreadName">
  <level value="OFF" />  
</logger>

<logger name = "ExecutableName.WorkerThreadName.ClassName">
  <level value="INFO" />     
</logger>
<!--repeat as necessary--->

Hopefully you get the idea... It seem like this has the potential to explode in to a mess of hard to maintain entries (especially when the app reaches a support phase). Any suggestions on how to best manage the level definitions for the nested loggers? I've played around a bit with actually nesting the xml statements, but that doesn't seem to work.

Thanks in advance,

Dan

Answer 1

Generally I want to catch all messages, at least WARNings and severe levels. Since loggers inherit their level from loggers higher in the hierarchy and ultimately from the root logger, I assign levels only to the top-level loggers. In your case that would be the "ExecutableName" loggers.

For those special case loggers from which I'm e.g. not interested in seeing other than FATAL messages I will add a specific level setting. But this is usually not the general case and will thus be of manageable size.

I find it useful to set e.g. WARN or INFO at those top-level loggers and then use appenders with filters on the various levels. The result is that the potentially vast amount of messages get grouped into different storages depending on level. You could even have separate appenders for each top-level logger to get even more fine grained control over the message stream.