Get Help:Ask a Question in our Forums|Report a Bug|More Help Resources
Last post Feb 08, 2011 03:06 PM by doyleits
Feb 04, 2011 12:50 PM|LINK
We are working on a web application and are using log4Net for logging purpose. Please suggest any best practices for the type of things to log to the log file. Mainly we would like to use the log file to identify and troubleshoot any runtime error that may
occur. What kind of details should be logged for troubleshooting the errors that may come in production environment and suggest any best practices that are available.
Feb 04, 2011 01:13 PM|LINK
We used log4net for code logging and ELMAH for production websites. The ELMAH component is really great for http errors and you can configure it to store the errors in the same DB as log4net.
Feb 07, 2011 08:35 AM|LINK
Exception handling can be maintained in different way :
- use try catch blocks & log the exception in the files/DB as per your needs.
1. You can create one Utility method which log the error in file/DB .
2. Call this Utility method in catch block & throw/show customexception which shows custom error message to user.
3. you can read the DB/files for errors that r logged & can use for further for resolving it..
public static void LogError(Exception expError)
ILog myLog = LogManager.GetLogger("MyLog");
above Utility method needs to be called like this :
catch (SqlException expError) // this exception to be catched
Utility.LogError(expError); //log the error
throw new ContentRecordsNotFoundException(); //rethrow custom exception if needed
Now once you have these information you can able to log the exception message into DB/files
Hope this information will help !!!
Feb 07, 2011 09:50 PM|LINK
The cool thing about log4net and other logging apps is that you can specify information levels - Debug, Trace, Information, Error, etc. If you use a utility class for logging, you can specify the logging level of the message, and the logging app will handle
whether or not it will be logged, based on the current configuration.
As for the content of your logs, it depends :) When developing and testing, logging the full stack trace of an exception (ex.ToString()) is extremely handy, but maybe too much info in Production. If you can, record the application or service name, date/time,
exception type and message, user name if possible, etc. Also, if you can, try to record the name of the method in which the error happened, and if possible, what was being performed (e.g., "Order 12345 failed credit card processing"). With database calls,
it is helpful to record the stored procedure name or SQL. With web service or WCF calls, the URL and method name help immensely.
Feb 08, 2011 12:38 PM|LINK
If we log all the parameters of the method that caused the exception I am thinking it will be beneficial for trouble shooting? Is it suggestable to log such details and if we do like that is going to be too much clutter in the log file? Please suggest the
type of things that should be logged into the logfile along with exception details such as exception message and stack track?
Feb 08, 2011 03:06 PM|LINK
The more information you have in the log message, that helps you diagnose the issue, the better off you will be. Input parameters on a method that threw an exception will definitely help in troubleshooting (BUT be sure to handle Null values, to avoid throwing
an object reference exception). You'll probably find that as your application gets more stable/mature, you can reduce the amount of information you log. This will be the case as you see which types of exceptions are thrown more often, and you can modify code
to handle those cases.
Just avoid putting in unnecessary information that may clutter what you are looking for (like process or thread number, etc). Test out during development if a logged exception tells you who (user), what (operation that was being performed), when, where (executing
assembly, hosting application), why (exception details), and how (supporting info). If you can immediately see what went wrong from the message, or it at least puts you on the right track, you're in pretty good shape.