Working with Log4net - Using log4net
(Page 3 of 4 )
The use you will make of log4net will depend on whether you are a developer (as we assume to be the case, since you’re reading this book) or an administrator (a role you may fill from time to time):
For developers
Logging aids debugging during development by showing the flow through the application. Logging tools complement other development tools, such as debuggers and profilers. Logging should never be removed from an application; if it was useful once, it may prove useful again.
For system administrators
Logging is an invaluable tool for aiding system administrators in the diagnosis of problems with their applications in a production environment. Administrators are better able to communicate with the development team when they have extensive logs available with which to detect and diagnose issues.
The log4net framework makes use of three key concepts and provides the mechanisms for configuring each:
Loggers
Loggers are named objects that a developer can use to output contextual logging information from within an application. The loggers are in a hierarchy based on their names, such that a logger with the namefoois the parent offoo.bar. The most commonly used scheme is to use one logger per type and to name the logger with its namespace and type name. There is always arootlogger, which exists at the top of the hierarchy.
Loggers expose an API enabling output at one of the following levels of severity:DEBUG,INFO,WARN,ERROR,orFATAL. Each logger can be configured with a severity level; loggers that are not explicitly configured inherit the level from their closest ancestor. Therootlogger must be explicitly assigned a severity level.
This structure allows the developer to insert logging code into an application, knowing that he can control the output so that only messages at and above a certain level of severity will be logged. Crucially, he can achieve this without recompiling, or even restarting, the application or component.
Appender
It’s easy to output logging messages from applications and to control which messages are logged, but where do the messages end up, and how can you view them? The purpose of log4net appenders is to handle the outputting of messages. Table 4-1 lists the most commonly used appenders currently included in the standard log4net distribution. Developers can also create their own appenders.
Table 4-1. Popular logging appenders
| Appender | Description |
| AdoNetAppender | Writes logging events to a database using either prepared statements or stored procedures. |
| ConsoleAppender | Writes logging events to the application’s console. The events can go to either the standard out stream or the standard error stream. |
| EventLogAppender | Writes logging events to the Windows Event Log. |
| RemoteSyslogAppender | Writes logging events to a remote syslog service using UDP networking. |
| RemotingAppender | Writes logging events to a remoting sink using .NET remoting. |
| RollingFileAppender | Writes logging events to a file in the filesystem. TheRollingFileAppendercan be configured to log to multiple files based upon date or file-size constraints. |
| SmtpAppender | Sends logging events to an email address. |
A major benefit of using log4net overSystem.Console.WriteLine()is that log4net can output messages to multiple destinations. In combination with message severity levels, logging to multiple destinations can be extremely useful.
Consider an application running in production. Administrators are generally interested only in monitoring errors. It would be ideal if they could be actively notified if something goes very badly wrong, but it would also be nice to have some detailed information about the circumstances causing the failure. To achieve this, you can use a three-appender log4net configuration such as this:
EventLogAppender
Output all messages atERROR andFATALlevels to the Windows Application Event Log.
RollingFileAppender
Output all messages atINFO,WARN,ERROR, and FATALlevels to a set of rolling files, and set a file-size limit on these files to prevent excessive disk space usage.
SmtpAppender
Output messages atFATALlevel for delivery to a notification email address.
This configuration provides notification of fatal conditions by email, stores a persistent record of all errors in the Windows Event Log, and keeps a detailed activity trace for a short period of time to facilitate problem diagnosis.
Finally, the log4net framework can be configured so that loggers output to specific appenders, enabling messages from different aspects of an application to be handled appropriately.
Layout
Appenders use layouts to customize the output format of messages. log4net includes thePatternLayout, which enables the user to specify the message output format according to conversion patterns similar to theprintf()function in C. For example, the pattern:
%timestamp [%thread] %-5level %logger - %message%newline
outputs messages formatted like this:
234 [main] WARN story.children.littleredridinghood – There is a wolf in
grandma's bed!
Table 4-2 lists the most popular layouts currently included in the standard log4net distribution. Of course, developers can also create their own layouts.
Table 4-2. Popular layouts
Layout | Description |
PatternLayout | Formats the logging event according to a flexible set of formatting flags |
SimpleLayout | Formats the logging event very simply ([level] -[message]) |
table 4-2. Popular layouts (continued)
Layout | Description |
XmlLayout | Formats the logging event as an XML element |
XmlLayoutSchemaLog4j | Formats the logging event as an XML element that complies with the log4j event DTD |
Next: Configuring log4net >>
More BrainDump Articles
More By O'Reilly Media
|
 This article is excerpted from chapter four of Windows Developer Power Tools, written by James Avery and Jim Holmes (O'Reilly, 2006; ISBN: 0596527543). Check it out today at your favorite bookstore. Buy this book now.
|
|
