How much information to log from errors?

Question

At the company I work for, I have created a Error Logging class to handle errors in my ASP.net application. It is a custom class because we are not allowed to install additional software on our servers (nLog, log4net, etc).

I currently use it in two of my projects and have seen some good results from it. Right now I am trapping the errors that cause page and application errors. It sends and stores the error message and all inner exceptions.

The problem I am having now is, I am receiving errors that I am not quite sure how to reproduce. I have not heard any error reports from any of my users. I am not sure what they are doing, or even if they are seeing these as errors.

I am thinking about creating an Event Log on each page, or the ones I want additional information on. Keeping it as a Session variable on the page, and writing events to it (start/end of functions, variable changes, etc). Then only if an error is called to have that send along with the error message to see if it gives a better picture of what is going on. I am hoping that doing it this way will not give me tons of event logs when all users access the application, just want was going on right before the error happen with the one user.

Do you know of any pitfalls I should watchout with method?

Do you have any advise for things to look for?

Update:

@Saret: I understnad where you are coming from with that response and I agree. I am fairly new to this company and still need to learn how they do things. In the past I have had conversations with my coworkers how it would be great to have this product, or use this open source project. The problem comes down to is, we work on secure systems and getting approval to get these things takes a lot of time, top cover, and dealing with all the red tape. I will look into the situation further because I believe having a good error logging system in place is important, currently nothing is being used.

@Jim Blizard: I wanted to try to get away from logging/storing everything someplace to come back and find out what is important to the situation that caused the error. I didn't want to fall into overload of information that is talked about in artical that Roberto Barros linked. My current method of thinking is, keeping a string in memory on each page, and if an error is rasied, on the pages Page_Error event, grab that string and attach it to the exception that is getting logged. That way I am only logging the error/exceptions that occured and storing the event log with that error. If nothing happens, that log that was being created is dropped into the bit bucket never to be seen again.

@Roberto Barros: Thanks for that link, I remember reading it somewhere but forgot to save it.

Answer 1

For errors, I'm a big fan of logging A LOT. When things go wrong information is very valuable. I would keep the entire log in one place (text file or database table) with a session identifier to group relevant events together.

Answer 2

This might not be the exact answer you are looking for, but why develop your own error logging mechanism when there are powerful tools (which you mention) that handle all these key issues for you?

I can appreciate you are not allowed to install additional software but aren't logging libraries just classes like your custom code? Where is the fundamental difference? I would reckon the time spent worrying about implementing a logging framework might be better spent advocating and making a business case for a decent logging solution.

Answer 3

I once worked for an agency that would not allow installation of anything that wasn't purely my own code or their (horrid) COM objects. If you have this type of limitation, then see if you can grab the source for log4net and include in your project.

There is nothing better than log4net currently when it comes to logging.

Answer 4

Here's what I like to log:

• error/debug level (info, debug, problem, crash, etc...)
• time
• descriptive text (usually one line)
• stack trace (if possible)
• data (user, session, variable values, etc...)

The simplest way is to write to a text file, but it can be nice to have it in a database. You can also use the Windows event log. Some things to watch out for. Hmm... You'll need to clear out your logs periodically.

Funny story: one time we had an error logger that logged to the database, but we had bad database credentials which caused an error which was then logged... Ended up getting stack overflows from the recursion (IIRC).

Answer 5

Look what Jeff Atwood has to say: http://www.codinghorror.com/blog/archives/001192.html

Answer 6

I personally took the following approach on logging erros (and only log errors) in an asp.net application:

• use protected void Application_Error(object sender, EventArgs e) { Server.Transfer("~/Support/ServerErrorSupport.aspx", true); } (I do a Server.Transfer to preserve all post data.)

• Generate an error ID which is unique for this error (so subsequent repports for the same error can be grouped). The ID is an hash calculated from a concatenated string consisting of: file, method, lineNr and error.Message. I get the file, method and lineNr values through a regex on the stacktrace.

• I log all the following data to an xml structure (depending on the data type, I store the value differently, value types => ToString(), ISerializable => serialize, ...):

  1. MachineName: Application.Server.MachineName
  2. PhysicalRoot: Application.Server.MapPath("~/")
  3. RequestUrl: Application.Request.Url.ToString()
  4. ApplicationSettings: WebConfigurationManager.AppSettings
  5. ConnectionSettings: WebConfigurationManager.ConnectionStrings
  6. QueryString: Application.Request.QueryString
  7. FormPost: Application.Request.Form
  8. Session: Application.Session
  9. HttpHeaders: Application.Request.Headers

• Save the xml structure as a local file containing the error ID and a timestamp. I chose this approach because:

  • I can mail the rapport (xml-file) to myself (during test/debugging very easy)
  • store it locally or in a database during production
  • because the file is just a (dump to hd) save not much can go wrong during the creation of the error report (like a server connection, db problems, etc), just make sure you have write permissions.
  • Additionally on the servererrorsupport.aspx page, after saving the xml file, the user gets the option to include extra information and to add an emailaddress to keep updated on progress regarding the bug. This gets appended to the xml document.
  • I use an xslt file to format the error data (xml) in a nice error report.