Optimizing SharePoint Application Design -
     SharePoint ULS

Ramona Maxwell’s study notes, ©2011 All rights reserved

There are two portions of the SP2010 exam that relate to Unified Logging Service [ULS] logs, determining the proper information to record in them and knowing the method to place it there and then knowing how to read and utilize the recorded events. ULS logs are sometimes referred to as Trace Logs because the ULS writes events to the SharePoint Trace Log and then stores them in the file system. As to appropriate uses for ULS, it is a helpful development tool that can reveal problems not evident from the UI and also can be used to test for completion of long-running tasks that do not have a UI. It also provides a level of security for this troubleshooting info, in that error information doesn't need to be displayed in the UI and can be instead perused by the administrator or developer. Since the ULS doesn't edit the information it records to mask sensitive portions, this is important.

If the data collected fits the reporter's essential who, what, where, why and how then it will be useful to the person retrieving it. Where did the error occur, who was accessing what feature, why was it flagged and how do they fix it? You may find some hints as to what could be logged by searching MSDN for "SPDiagnosticsServiceBase Members." There are a lot of functions related to backups and object management.

The iDiagnosticsManager interface is listed as deprecated in the SP2010 documentation, and the current preferred method is to use the SPDiagnosticsBase class with which you can write directly to the Trace Log and Event Log. Search MSDN for “Trace Log Example” the the SP2010 documentation to read a well-commented code walkthrough. Powershell cmdlets are your friend when manipulating the ULS, they let you get and set the diagnostic configuration, find and throttle logging levels or set them back to default values, start a new log file, query the the log file and merge log files from several servers into one. Several references for the SPDiagnosticsBase class mention it writing to and wrapping around the iDiagnosticsLevel interface, which I find confusing since at the top of the MSDN documentation page for both the iDiagnosticsManager and the iDiagnosticsLevel Interfaces it states "NOTE: This API is now obsolete." Is this one of those :we wish we could get rid of it: deprecations that hangs around anyway because it has so many dependent processes, or is there a new API that replaces it? [Posted that question as a comment on MSDN] The ULS log files have a 14 day or 2GB lifespan, when either threshold is reached older files will be eliminated to make room for new, therefore procrastination about tracking down problems does not seem advisable unless you protect yourself by changing the default number of days or disk space (up to a TB). Just remember pruning will trigger on whichever limit it hits first.

I did not see a reference to the Developer Dashboard [DDB – my acronym not theirs] in the exam outline, but it seemed like it would be a preferred method to collect the type of information stored in the ULS logs. When building a page you can code the DDB to monitor the entire thing, or set a scope-specific monitoring task. It can for example monitor process threads and their execution times, monitor SQL Server queries including both their performance and the code used to generate them and WCF call details. All of the information gathered is then recorded in the ULS, but its presentation in the DDB is preferable to slogging through notepad files because it's correlated to events (like buying a little package of shells at the tourist trap vs. beachcombing?). It also outputs to a browser page. It can be set to always-on or on-demand, but if it is in on-demand mode anyone who clicks on the page-side icon can view the logged information. The DDB can be launched using STSADM, a Powershell cmdlet or within the code of your page using the DeveloperDashobardLauncher. If you are coding the DDB into a master page you must close out with the rendering control at the bottom of the page, as anything after the rendering control will not be monitored.

Return to www.sqlsolver.com