SharePoint 2013 collects data in the diagnostic log that can be useful for troubleshooting. The default settings are sufficient for most situations. However, you may want to customize the settings, depending on the business requirements and the life cycle of the farm. If you are deploying a new feature or making large-scale changes to the environment, you can change the logging level.
For example, you can change it to a more verbose level to capture as much data as possible about the state of the system during the changes. You can also change it to a lower level to reduce the size of the log and the resources that you require to log the data. You can set the level of diagnostic logging for the event log and for the trace log. This will limit the types and amount of information that will be written to each log.
Best practices
The SharePoint 2013 environment may require configuration of the diagnostic logging settings after initial deployment and throughout the system's life cycle. Use the following guidelines as best practices:
- Change the drive that logging writes to. By default, diagnostic logging is configured to write logs to the drive and partition where SharePoint 2013 is installed. Diagnostic logging can use large amounts of drive space and writing to the logs can affect drive performance; therefore, you should configure logging to write to a different physical drive. You should also consider the connection speed of the drive; if verbose-level logging is configured, many entries are written to the log. Consequently, a slow connection may result in poor log performance.
- Restrict log disk space usage. SharePoint 2013 does not limit the amount of disk space that diagnostic logging can use. You should limit the disk space that logging uses to ensure that it does not fill the disk, especially if you configure logging to write verbose-level events. When the space that is available to the log file is used, the oldest logs are removed and new logging data information is recorded.
- Use the Verbose setting sparingly. Verbose logging logs every action that SharePoint 2013 takes. Verbose-level logging can quickly use drive space and affect drive and server performance. You can use verbose-level logging to record a greater level of detail when you are making critical changes and then reconfigure logging to record only higher-level events after you make the change.
- Regularly back up logs. The diagnostic logs contain important data. Therefore, back them up regularly to be sure that this data is preserved. SharePoint automatically deletes when you restrict log drive space usage, or if you keep logs for only a few days. When the threshold is met, the oldest logs are deleted first.
- Enable event log flooding protection. You enable this setting to configure the system to detect repeating events in the Windows event log. When the same event is logged repeatedly, the repeating events are detected and suppressed until conditions return to a typical state.
Unified Logging Service
SharePoint uses the Unified Logging Service (ULS) to write content to log files. In SharePoint 2013, by default, the ULS log is located at:
%PROGRAMFILES%\Common Files\Microsoft Shared\Web Server Extensions\15\LOGS
When you plan file permissions for farm administrators, you should consider allowing access to this folder so that the Farm Administrator can read the log directly. The ULS log can be difficult to interpret in text form. You can download an open source tool named ULS Viewer from CodePlex and you should make the ULS Viewer available to those who must read the log.
The ULS Viewer enables users with access to ULS log files to view the logs using a user-friendly interface. You can filter, sort, highlight and append logs to help locate data that is relevant to the issue that you are attempting to resolve. You can use this information to diagnose problems with computers running ULS services or to monitor machines and the events that they create. SharePoint 2013 uses correlation IDs, that are identifiers that are internally associated with every request and are displayed with error messages. By searching the ULS log for the correlation ID, you can identify the request that caused the error and resolve the issue.