I’ve been asked recently what the “best” or “correct” settings are for the SharePoint Diagnostic Logs (aka “ULS” logs) in a production environment. Of course, the immediate answer is “it depends”. 😉
First, consider that the ULS logs are designed with a singular purpose in mind: To allow an administrator identify and resolve issues in SharePoint. They are not used for any other purpose within SharePoint, and most administrators won’t bother looking at them until there is an issue they are investigating. From this perspective, if your environment is “perfect” (yes it is possible), then the best answer for you is to simply turn them off. They consume system a small amount of system resources, and can consume a considerable amount of disk space. However, turning them off will prevent you from being able to do any kind of retrospective on significant one-time events. Your call.
On the other hand, some customers have them all set to verbose, all the time. This is a little rediculous if you’re not actively investigating an issue. You’re consuming extremely large amounts of drive space and potentially significant system resources and somewhat degrading performance for end users to capture data that you have no interest in actually looking at. I suggest resetting them to the default settings or even turning them off.
Now, if you ARE investigating a reproducible issue, then by all means, turn the appropriate logging level on to verbose, reproduce the problem (likely several times), then turn them back down. If the problem is difficult to reproduce and/or happens randomly, then leave them at an elevated level until you are able to capture an instance or two of the error, then turn them back down. The main point is, turn them up to capture the data you need, then turn them back down or off if you’re not actively researching an issue.
Finally, the one thing you should ABSOLUTELY do is move them off of the system drive. ULS is designed to stop logging if it percieves a disk space issue… but that doesn’t excuse you from properly managing both your disk space and your logging methods. Moving the logs off of the system drive ensures that logging isn’t going to fill up the system drive, and that ULS logging isn’t going to contend with your page file for disk IO. Note that in order to change the location fo the log file, the path must exist on ALL SharePoint servers, and the folder’s permissions must be set to allow the SharePoint service to write to it. Errors in which you change the location and don’t see log files get created in this location is typically one of these two problems.
So… here’s a cheat-sheet for the general recommendation:
- FOR MOST ENVIRONMENTS: Keep the logs at the “Default” logging settings using one of the two following commands.
- SharePoint 2007 : STSADM -o SetLoggingLevel -Default
- SharePoint 2010: (PowerShell) Clear-SPLogLevel
- For “Perfect” environments – everything works well, few/no user complaints, exceptionally well managed.
- SharePoint 2007 : Central Admin, select “All” categories, and “Error”, “Error”.
- SharePoint 2010 : (PowerShell) Set-SPLogLevel -TraceSeverity Unexpected -EventSeverity Error
- For temprary troubleshooting purposes only, use verbose
- SharePoint 2007 : Central Admin, select “All” categories, and “Verbose”, “Verbose”.
- SharePoint 2010 : (PowerShell) Set-SPLogLevel -TraceSeverity Verbose -EventSeverity Verbose
Of course, there are various permutations of these combinations. For example, I might want the log files at “Verbose” while maintaining the event logs at “Error” so that I don’t flood the event logs. The keys are 1) Know what you’re looking for and where you might best find it, 2) Know that increased logging demands increased space and system resources for the logging activity itself, 3) Use the lowest level logging available to meet your needs, adjusting when necessary, 4) Use “Verbose” ONLY when troubleshooting an issue.