Learn more about SQL Server tools

mssqltips logo
 

Tutorials          DBA          Dev          BI          Career          Categories          Webcasts          Whitepapers          Today's Tip          Join

Tutorials      DBA      Dev      BI      Categories      Webcasts

DBA    Dev    BI    Categories

Special Announcement: SQL Server Performance Tuning Tips and Tricks Webinar
 

Diagnostic logging in SharePoint 2010


By:   |   Read Comments   |   Related Tips: > Sharepoint

Problem

For diagnostic logging, the Unified Logging Service (ULS) has been available since previous versions of SharePoint. But what improvements and refinements have been done in SharePoint 2010? What are the options available for diagnostic logging in SharePoint 2010? How better we can control the amount of diagnostic information to be logged in SharePoint 2010?

Solution

SharePoint 2010 has improved the way the ULS logs information and now these diagnostic logging data can be written to trace files, Windows Event Viewer and a new SharePoint reporting database (new in SharePoint 2010). Trace log files are created in a Log folder under the root folder where SharePoint has been installed by default; that is also called the 14 Hive. In my case, I have a stand alone installation on the C drive and hence path goes like this:

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\LOGS folder.

Before digging more into this log folder and file information, lets see how to configure the diagnostic logging. Go to the Monitoring link on the left side of SharePoint 2010 Central Administration and click on "Configure diagnostic logging" under "Reporting" as shown below:

sharepoint

On the diagnostic logging page, you will see several parameters to configure for diagnostic logging. The first one is Event throttling. Here you can see multiple categories and sub categories of events for finer control.

sharepoint

If you scroll down below, you will see two combo boxes "Least critical event to report to event log" and "Least critical event to report to trace log" which you choose after selecting categories and sub categories as above. The first one tells the least critical event which will be logged to the Windows event log; similarly, the second one tells the least critical event which will be logged to trace log. All critical events higher than the 'least' will also be logged. As the severity decreases, the number of events being logged will increase, so be watchful on this.

Event Log Flood Protection is a great feature and you should keep it enabled always unless there is an absolute need of changing it. When you enable it, SharePoint does not log repeating messages again and again. It logs for the first time and then detects and suppresses all the messages until the condition returns back to normal.

Ideally you should set the "Number of days" for the log to be maintained or "restrict the log space" growth or both. If you set both "Number of days" for the log to be maintained and "restrict the log space" growth then whichever comes first will be given preference.

For example, consider you have given 30 days of logs to be maintained and maximum storage space is 100GB. And suppose on the 10th day, 100GB of space has been consumed. Then on the 11th day, the 1st day's log will be removed so as to occupy a maximum of 100GB - only even though you have 30 days setting.

site actions

As mentioned before, by default, trace files are created in the log folder of the SharePoint root folder. But now with SharePoint 2010, the best part is that these files are compressed and consume much less space. The naming convention that SharePoint uses for these trace files is "ServerName-YYYYMMDD-HHMM" and each subsequent file is created in 30 minutes intervals by default. This can be changed if needed, as you can see below:

common files

You can use your favorite Notepad tool to open trace files for analysis or you can use any ULS log viewer tool, like this one which shows log information in a more user friendly interface instead of using standard log file viewers. When you open any of these files, you will notice a host of information. Though it may seem confusing, SharePoint 2010 helps you here as well with the Correlation ID. 

notepad

If you look at the image above, finding a specific entry in the log file, especially when you have enabled verbose logging, can be really difficult. SharePoint 2010 comes to the rescue here as well by assigning each log entry a unique GUID value called Correlation Id (also known as the Correlation Token). When there is any error on the page SharePoint 2010 shows this correlation Id on the page, you can take this Correlation Id and search in the log files to find the reason for failure. Now the best part is that the Correlation Id is grouped on the same conversation/session (initiated by a user) on the server and across the servers, which helps you to troubleshoot slow loading of a page.

notepad

Best Practices and Notes

  • Verbose logging is great for troubleshooting showing a greater level of detail logging, but can slow performance. You should use this option prudently or during troubleshooting only and turn it off immediately once you are done.
  • By default information is logged in the Log folder under the root folder where SharePoint has been installed. You should consider changing this location to some other drive (or high speed drive especially in case if you are using verbose logging) than the drive on which SharePoint has been installed. Also make sure that the same location is available on all the servers of the farm.
  • Event Log Flood Protection is a great feature and you should keep it enabled always unless there is an absolute need of changing it. When you enable it, SharePoint does not log repeating messages again and again. It logs for the first time and then detects/suppresses all the messages until the condition returns back to normal.
  • You can specify the number of days for which logs are to be maintained by SharePoint, oldest files are deleted by SharePoint to maintain those many days log files. If you have some critical logging messages which you want saved, you should consider taking a backup of those files.
  • By default, diagnostic logging will keep on growing on the disk. So ideally you should restrict the disk space to be used for logging. When you set a restriction and the log grows beyond that, then the oldest log is removed to make room for new log entries.
  • If you set both the "Number of days" for the log to be maintained and "restrict the log space" growth, then whichever comes first will be given preference.
  • A developer can write custom messages for diagnostic logging using the SPDiagnosticsService class. You can even control the diagnostic logging behavior programmatically using this class. Please note it does not work in a Sandboxed environment (unless you create full trusted proxy and call it from Sandboxed solutions).
  • There is an unsupported ULS log viewer which you can use to view the log in a more user friendly interface instead of using standard log file viewers, click here for more details.
Next Steps


Last Update:


next webcast button


next tip button



About the author
MSSQLTips author Arshad Ali Arshad Ali is a SQL and BI Developer focusing on Data Warehousing projects for Microsoft.

View all my tips





Post a comment or let the author know this tip helped.

All comments are reviewed, so stay on subject or we may delete your comment. Note: your email address is not published. Required fields are marked with an asterisk (*).

*Name    *Email    Email me updates 


Signup for our newsletter
 I agree by submitting my data to receive communications, account updates and/or special offers about SQL Server from MSSQLTips and/or its Sponsors. I have read the privacy statement and understand I may unsubscribe at any time.



    



Learn more about SQL Server tools