What Does the SharePoint Logger Do?
The SharePoint Logger is a reusable component that you can use to write messages to the Windows event logs and the ULS trace log. The SharePoint Logger works by exposing and implementing a simple interface named ILogger. This interface defines the two key methods listed in the following table.
ILogger method |
Description |
|---|---|
LogToOperations |
This method writes a message to the Windows event logs and the ULS trace log. Overloads allow you to specify identifiers, categories, severities, and exception details. |
TraceToDeveloper |
This method writes a message to the ULS trace log. Overloads allow you to specify identifiers, categories, severities, and exception details. |
Note
At this stage, you might be wondering why the LogToOperations method writes to both the Windows event logs and the ULS trace log. Generally speaking, the trace log contains much more information than the event logs. If something is worth writing to the event logs, it is also worth writing to the trace log. In other words, the event logs should contain a subset of the information that you write to the trace log.
When you write a message to either log, the SharePoint Logger adds contextual information, such as the current URL and the name of the currently logged-on user, which can help the reader to diagnose the problem. The SharePoint Logger also provides a high level of robustness in case the logging fails. For example, if a message cannot be written to the event log, a LoggingException is thrown that contains both the original message and the reason for the logging failure.
The following code shows a simple example of how you can use the SharePoint Logger to write a message to the ULS trace log.
ILogger logger = SharePointServiceLocator.GetCurrent().GetInstance<ILogger>();
logger.TraceToDeveloper("Unexpected condition");
Notice how the SharePoint Service Locator is used to retrieve an implementation of the ILogger interface. Using this approach ensures that your code will still work if the current ILogger implementation is updated or replaced, and it allows you to plug in different logging implementations. For more information about the SharePoint service locator, see The SharePoint Service Locator.
SharePoint 2010 introduces new functionality that can help administrators to manage diagnostic information. You can now configure diagnostic logging by area and by category:
- Areas correspond to broad areas of SharePoint functionality, such as Access Services, Business Connectivity Services, and Document Management Server.
- The area is used as the event source name in the Windows event logs.
- Each area contains one or more categories, which correspond to more specific areas of functionality. For example, the Document Management Server area includes categories named Content Organizer, Information Policy Management, and Records Center.
- For each category, you can specify the least critical event to report to the event log and the trace log. In other words, this sets the default event throttling threshold for that category. These values are also used as the default severity for a trace or log if no severity level is specified.
Note
Event sources for Windows event logs must be added to the registry on the local machine. To enable SharePoint to use a custom diagnostic area as a Windows event source, you must register the event sources on each Web front end server. For more information, see Using Feature Receivers to Configure Diagnostic Areas and Categories.
The SharePoint Logger allows you to create and register custom areas and categories for use by your own SharePoint applications. This allows administrators to throttle diagnostic logging from your application, along with all the built-in areas and categories, through the SharePoint Central Administration Web site.
Note
Avoid using the built-in areas and categories to log events and traces from your custom solutions. Instead, you should create your own custom areas and categories when you deploy a solution. This enables administrators to set event throttling thresholds that are specific to your solution without affecting other SharePoint functionality.