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.
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.
above Utility method needs to be called like this :
try
{
//your code
}
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 !!!
Please mark the answer if it helps you.
Ramani Sandeep (My Blog)
(MCTS, MCC-2011)
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.
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?
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.
ranumula
Member
20 Points
23 Posts
Error logging best practice
Feb 04, 2011 12:50 PM|LINK
Hi,
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.
Thank you,
Raghu
error handling Error logging
DarthSwian
Star
12879 Points
2380 Posts
Re: Error logging best practice
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.
http://code.google.com/p/elmah/
Seek and ye shall find or http://lmgtfy.com/
sandy060583
Star
8728 Points
1626 Posts
Re: Error logging best practice
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"); myLog.Error(expError); }above Utility method needs to be called like this :
try { //your code } 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 !!!
Ramani Sandeep (My Blog)
(MCTS, MCC-2011)
doyleits
Contributor
3580 Points
549 Posts
Re: Error logging best practice
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.
Collabroscape LLC [www.collabroscape.com]
ranumula
Member
20 Points
23 Posts
Re: Error logging best practice
Feb 08, 2011 12:38 PM|LINK
Hi,
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?
Regards,
Raghu
Error logging
doyleits
Contributor
3580 Points
549 Posts
Re: Error logging best practice
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.
Collabroscape LLC [www.collabroscape.com]