Fields people capture when logging - log4net

Question

Hi guys

I interested in knowing what fields people actual capture and use when logging within their applications when using loggers like log4net.

This can range from debugging to testing to production and can be for thick client apps but I am thinking more about semantics of web apps (i.e. asp.net).

Also, in the context of web (and for thick clients to a certain extent) I am interested in how people build up the hierarchy of log entires for a given request and how you identify the individual request, etc.

Cheers Anthony

The following is what i have cine up with thus far:

LogId, ServerName, ServerIP, ApplicationAbbrv, ApplicationVersion, ApplicationAppDomain, LogDateTime, LogTimeStamp, LogLogger, CodeType, CodeClass, CodeFile, CodeLocation, CodeMethod, CodeLine, CodeStackPosition, LogMessage, LogException, LogEntityOrigin, ContextSessionId, ContextUserName, ContextThread, ContextObjectPropertyData, ContextMachineId, ContextMachineIP

Answer 1

Log everything that is an Error.

Log as Warnings events that are handled but should be recorded.

Beyond that, it's up to you how much detail you want to Log as Info. You could Log as Info every entry/exit point to methods. Personally I think that is overkill and symptomatic of code which devs are not confident with. I'd Log all 'major' actions that occur during processing.

Answer 2

Humm... cheers I agree on the entry/exit being overkill, for the answer though what i was thinking is trying to build up a list.

Debug: date, timestamp, username, level, logger, message, exception, servername, pagename, methodname, classname, etc

I'm trying to see if there is anything that I have missed or should be doing and just trying to see what others are logging

Also I was interested in the "how people build up the hierarchy of log entires for a given request"...

Answer 3

In order to create an "interaction stack" for the request we assign a sessionid(guid) to the user in a cookie when they first access the application. Then we order by sessionid/datetime to see what the order of events was.

Another thing we always log is the data(minus sensitive data like ssn) the user was attempting to manipulate (insert/delete/update) as data quality seems to be a primary source of error.