Overview of Unified Logging System (ULS) Logging

SharePoint 2010

Last modified: April 15, 2010

Applies to: SharePoint Foundation 2010

An effective logging strategy has long been recognized by system administrators as a way to keep track of problems with components and applications, provide quantifiable statistics for an application's history, help in troubleshooting issues, as well as help in monitoring the overall health of the systems that administrators are responsible for.

This topic discusses how you, as a developer, can use the logging mechanisms provided by Microsoft SharePoint Foundation to make it easier to develop applications, provide more in-depth information for debugging, and communicate with system administrators when a problem is encountered or a threshold is reached. The primary mechanism is Unified Logging Service (ULS), which writes SharePoint Foundation events to the SharePoint Trace Log, and stores them in the file system. (Note: ULS logs are also sometimes referred to as Trace Logs.)

ULS logging, when implemented effectively, can provide very useful information for the following audiences.

For developers

As developers, you can take advantage of the trace log when you are developing code. Use trace logs as an extension of your development tools and as another debugging tool, to help you investigate issues. By ensuring that useful information is written to the trace log, many issues that arise in development can be resolved without attaching a debugger. Also, a tester can review trace logs to discover problems that may not be visible in the User Interface (UI), and a tester can use trace logs to verify completion of long-running tasks that may not have any UI associated with the actions.

Another advantage of ULS logging for developers is that problems encountered in the UI or notifications do not need to be displayed in the UI. Instead they can be written to the database for administrators and developers to review and analyze.

For server administrators

For an event log message to be important to the system administrator, it must contain enough information and metadata to allow the system administrator to determine what action is necessary, where the action is needed, and why the action is required. Other useful contextual information that could be included in the event log may be the user who initiated the action.Obviously, server performance and monitoring is very important to success in the enterprise environment, and ULS logging can help administrators fine tune system performance after a deployment.

For support personnel

When a problem occurs that must be solved quickly by using Microsoft Customer Support Services, ULS logs can provide in-depth information about the problem to a support group to enable faster resolution.

Caution note Caution

Be aware that, in general, logging text is not security trimmed. Therefore, when you create log messages, be sure that you do not include personal or sensitive company information that gets written to the logs.

In general, the more information a developer can provide about their code, the easier it is to resolve problems that may arise.

In SharePoint Foundation, ULS exposes configurable settings in two ways, through the:

  • object model

  • Windows PowerShell cmdlets

Object Model and ULS Logs

In Windows SharePoint Services 3.0, access to ULS logs was provided through the IDiagnosticsManager interface. However, in SharePoint Foundation it is recommended that you use the SPDiagnosticsServiceBase class. The SPDiagnosticsServiceBase class wraps all calls to the IDiagnosticsManager class, making it easier for developers to interact with event logs. This approach allows you to write directly to the trace service.

For more information about using the object model to manipulate ULS logs, see Using the Trace Logging API

Windows PowerShell and ULS Logs

For more information about how to write Windows PowerShell cmdlets in SharePoint Foundation to manipulate the ULS logs, see Using Windows Powershell Cmdlets with ULS Logging