So who has recently looked at Diagnostic Logging in SharePoint 2010? And who has sat there and compared it to SharePoint 2007, it’s getting more complex but so much more useful.
For those of you who are still learning. Diagnostic logging is where SharePoint logs it’s actions, and will do with varying degrees based on the verbosity that you set for it.
So let’s compare things:
In SharePoint 2007 we had a drop down list of items that you could manage, you could only manage one at a time or all at once and there where no subcategories.
In SharePoint 2010 we have lists that can be expanded so you can select all with one click or select a whole category with one click. And if you really want to be creative you can select any number of categories and subcategories and manage them all at once.
In SharePoint 2007 we had several methods to manage the logging and several settings. You could manage the following settings:
- Verbosity that is logged to event log (None,Error,Warning,Audit Failure,Audit Success, or Information)
- Verbosity that is logged to trace log (None,Unexpected,Monitorable,High,Meduim, or Verbose)
- Local path to write logs to
- Number of log files this is the max number of files that we will keep and once go above this number a timer job will clear up all the files above it.
- Number of minutes to use a log file
There were some holes with these settings, things like there was no easy way to set the categories back to default. And the logs could very easily outgrow your size expectations and fill a drive. Methods to manage the logging:
- API/3rd Party tools
In SharePoint 2010 they changed some of the settings, you can manage the following settings:
- Verbosity that is logged to event log (Reset to default,None,Error,Warning,Audit Failure,Audit Success, or Information)
- Verbosity that is logged to trace log (Reset to Default,None,Unexpected,Monitorable,High,Meduim, or Verbose)
- Enable Event Log Flood Protection this will minimum the size of you logs and the noise. By not logging repetitious events.
- Local path to write log files to
- Number of days to store log files default is set to 14 days
- Restrict trace log disk usage not set by default and is set in GB
While it may not be perfect yet I do believe things are getting better, we now set the log duration to 30 mins automatically and let you decide how much disk space to restrict it to. Then as well we have got the logic in place to remove the noise from your logs so that it is easier to see the whole picture when reviewing them.
3. Correlation Id
Believe it or not the Correlation Id was available in SharePoint 2007 but it was not used.
In SharePoint 2010 when it comes to Diagnostic Logging I believe this is second only to one thing as being the most positive change. You can now filter on a Correlation Id and follow all the history up to the error that you received. As well an added bonus the Correlation Id is presented to the end user with most errors.
Since the Diagnostic logs are just delimited files in SharePoint 2007 days the best way to view your logs was by importing into Excel, that way you could sort and filter.
And now while you can still use Excel there have been ULS Viewer tools released that will parse the ULS logs for you, and allow the viewing of live ULS logs and much more.
- Do not store these logs on your system drive. NOTE: If you leave everything Out-of-the-Box it will write them to ‘%CommonProgramFiles%\Microsoft Shared\Web Server Extensions\14\LOGS\’ this would be on the C:\ drive.
- Insure you restrict the log growth, by setting both of the following settings:
- Number of days to store log files – Default is 14 days
- Restrict Trace Log disk space usage – Default is not set, and value is in GB
- Create a default base line for your enterprise by writing a script to set those categories that you want to Medium (Suggest you don’t set categories to verbose by default) you can use the following commands to do so. This will allow you to change the values to verbose during troubleshooting and then return it to default and at the same time capture good dataset on a day to day basis, with minimal amount of work.
- Enable event log flooding protection to reduce the size of your logs and noise in your logs.