MojoPortal and log4net

Steve Land

StrongEye Solutions LLC

VerifiedAD.com

Viewing logs in MojoPortal

currentlog.config

Log4net.config

Logging vs. Debugging

As a personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places. Clicking over statements takes longer than scanning the output of judiciously-placed displays. It takes less time to decide where to put print statements than to single-step to the critical section of code, even assuming we know where that is. More important, debugging statements stay with the program; debugger sessions are transient. 

--The Practice of Programming by Brian W. Kernighan and Rob Pike 

 Everyone likes to write a logging framework“Writing your own logging framework is the perfect coding crime. If you can convince your manager to put it on the project plan, you are guaranteed to have success. At the end of each day, you will go home feeling happy and satisfied. It will feel like you are doing something creative. You will get the intellectual stimulation without the risk of failure.” Dr. Heinz M. Kabutz, The Java Specialists Newsletter

Stan Wagon, Prof. of Mathematics and Computer Science, Macalester College, St. Paul, Minnesotahttp://decision-making.moshe-online.com/wheel.html

Basic concepts Tracing

Dump every action and step, timestamped Logging

Log business process steps Error Reporting / Debugging

Log exceptions, unexpected cases

Log4Net features Log to multiple targets per log via Appenders Configurable message format Different logging levels off, fatal, error, warn, info, debug, and all

Each logger has its own logging level Runtime control on which statements are

printed Filters allow you to add conditions to

Appenders to restrict what data gets written

http://www.codeproject.com/KB/cs/log4net_XmlConfigurator.aspx#objects

Good things to log Startup / shutdown of application Object creation Scarce resource allocation Failures (recoverable / unrecoverable) How long performance-critical operations took

Levels and tips ALL DEBUG INFO WARN ERROR FATAL OFF

Tips generally follow http://commons.apache.org/logging/guide.html

Selected level and above

are reported

DEBUG level Detailed information on the flow through the

system. Expected exceptions that users of your code

should handle. Logging details that you would not expect to

see in production.

INFO level You generally want exception information

available in production without having to turn on DEBUG log level. Log as INFO with stack trace and generally re-throw the exception.

Components that rely on network boundaries should use INFO, don’t assume exceptions will make it to other components.

Logging details that may be useful in production during troubleshooting.

WARN level Use of deprecated APIs, poor usage of APIs,

“almost” errors, other unexpected and undesirable runtime situations that are not necessarily “wrong”

ERROR level Other runtime errors or unexpected conditions

that may not cause premature termination.

FATAL level Severe errors that cause premature

termination.

Things to be careful about Ensure logs don’t contain sensitive data Consider how attackers could use logs to

defeat your software. Don’t reveal more information than necessary.

Recursive code with logging Definitions of levels Not too much logging When performance is important, don’t create

logging related objects if logging is turned off

Appenders

In the box AdoNetAppender AspNetTraceAppender ConsoleAppender DebugAppender EventLogAppender FileAppender MemoryAppender RemotingAppender RollingFileAppender ( MojoPortal default) SmtpAppender SmtpPickupDirAppender

… and more Or, make your own

Start from scratch (probably don’t need to do this) Start from existing Appender

override methods that don’t do exactly what you want

Locking Models (for file appenders) MinimalLock: Opens the file once for each

cycle. Slower but allows other processes to move/delete the log while logging

ExclusiveLock: Opens the file once for writing and holds it open until CloseFile is called. Higher performance, but not appropriate for Web applications.

Layouts log4net.Layout.PatternLayout

see http://logging.apache.org/log4net/release/sdk/log4net.Layout.PatternLayout.html

Conversion Pattern Name Effectappdomain Used to output the friendly name of the AppDomain where the logging event was generated.

date Used to output the date of the logging event in the local time zone. To output the date in universal time use the %utcdate pattern. The date conversion specifier may be followed by adate format specifier enclosed between braces. For example, %date{HH:mm:ss,fff} or%date{dd MMM yyyy HH:mm:ss,fff}. If no date format specifier is given then ISO8601 format is assumed (Iso8601DateFormatter).The date format specifier admits the same syntax as the time pattern string of the ToString.

exception Used to output the exception passed in with the log message.If an exception object is stored in the logging event it will be rendered into the pattern output with a trailing newline. If there is no exception then nothing will be output and no trailing newline will be appended. It is typical to put a newline before the exception and to have the exception as the last data in the pattern.

file Used to output the file name where the logging request was issued.WARNING Generating caller location information is extremely slow. Its use should be avoided unless execution speed is not an issue.See the note below on the availability of caller location information.

identity Used to output the user name for the currently active user (Principal.Identity.Name).WARNING Generating caller information is extremely slow. Its use should be avoided unless execution speed is not an issue.

location Used to output location information of the caller which generated the logging event.The location information depends on the CLI implementation but usually consists of the fully qualified name of the calling method followed by the callers source the file name and line number between parentheses.The location information can be very useful. However, its generation is extremely slow. Its use should be avoided unless execution speed is not an issue.See the note below on the availability of caller location information.

level Used to output the level of the logging event.

line Used to output the line number from where the logging request was issued.WARNING Generating caller location information is extremely slow. Its use should be avoided unless execution speed is not an issue.See the note below on the availability of caller location information.

logger Used to output the logger of the logging event. The logger conversion specifier can be optionally followed by precision specifier, that is a decimal constant in brackets.If a precision specifier is given, then only the corresponding number of right most components of the logger name will be printed. By default the logger name is printed in full.For example, for the logger name "a.b.c" the pattern %logger{2} will output "b.c".

message Used to output the application supplied message associated with the logging event.

method Used to output the method name where the logging request was issued.WARNING Generating caller location information is extremely slow. Its use should be avoided unless execution speed is not an issue.See the note below on the availability of caller location information.

newline Outputs the platform dependent line separator character or characters.This conversion pattern offers the same performance as using non-portable line separator strings such as "\n", or "\r\n". Thus, it is the preferred way of specifying a line separator.

ndc Used to output the NDC (nested diagnostic context) associated with the thread that generated the logging event.

property Used to output the an event specific property. The key to lookup must be specified within braces and directly following the pattern specifier, e.g.  %property{user} would include the value from the property that is keyed by the string 'user'. Each property value that is to be included in the log must be specified separately. Properties are added to events by loggers or appenders. By default the log4net:HostName property is set to the name of machine on which the event was originally logged.If no key is specified, e.g. %property then all the keys and their values are printed in a comma separated list.The properties of an event are combined from a number of different contexts. These are listed below in the order in which they are searched.the event propertiesThe event has Properties that can be set. These properties are specific to this event only.the thread propertiesThe Properties that are set on the current thread. These properties are shared by all events logged on this thread.the global propertiesThe Properties that are set globally. These properties are shared by all the threads in the AppDomain.

timestamp Used to output the number of milliseconds elapsed since the start of the application until the creation of the logging event.

thread Used to output the name of the thread that generated the logging event. Uses the thread number if no name is available.

type Used to output the fully qualified type name of the caller issuing the logging request. This conversion specifier can be optionally followed by  precision specifier, that is a decimal constant in brackets.If a precision specifier is given, then only the corresponding number of right most components of the class name will be printed. By default the class name is output in fully qualified form.For example, for the class name "log4net.Layout.PatternLayout", the pattern %type{1} will output "PatternLayout".WARNING Generating the caller class information is slow. Thus, its use should be avoided unless execution speed is not an issue.See the note below on the availability of caller location information.

username Used to output the WindowsIdentity for the currently active user.WARNING Generating caller WindowsIdentity information is extremely slow. Its use should be avoided unless execution speed is not an issue.

utcdate Used to output the date of the logging event in universal time. The date conversion specifier may be followed by a  date format specifier enclosed between braces. For example,%utcdate{HH:mm:ss,fff} or %utcdate{dd MMM yyyy HH:mm:ss,fff}. If no date format specifier is given then ISO8601 format is assumed ( Iso8601DateFormatter).The date format specifier admits the same syntax as the time pattern string of the ToString.

The recognized conversion pattern names are:

Demo

Thanks! Steve Land

StrongEye Solutions VerifiedAD.com