Diagnostic Logging Enhancements in SharePoint 2010
December 13, 2009 2 Comments
One of the big things I am happy that has been “upgraded” from SharePoint 2007 to SharePoint 2010 is diagnostic logging. Let’s take a look and see at a few of the more important features for what has been improved from v12… (at least my favorites, your mileage may vary).
Event Throttling
Let’s take Event Throttling for example. In 2007, you had a clunky drop-down menu to managing your throttling, and, you could only manage one at a time, or, all at once.
Now, in 2010, you can manage throttling for multiple services at once
And event see at a glance what each service is throttled to, without needing to select the service from the drop-down menu, to see the event level box values change.
Such a time saver! Definitely makes my life a heck of a lot easier as a developer.
Event Log Flood Protection
Event log flood protection – just as it states above – it suppresses duplicates messages for repeating errors. Just as I am sure some of you have probably seen in the past if you’re search service goes belly up, you get THOUSANDS of messages in short succession. This option, when enabled (default) will suppress those messages, so you do not end up seeing those THOUSANDS of the same message, over and over again.
Trace Log
The trace log configuration has undergone a few upgrades itself. Take a look back at the 2007 configuration…
You could set the where, number of files, and the minutes to use a log file, before moving onto the next one. Wow… that just isn’t all too helpful. Now, let’s have a look at the shiny new 2010 Trace Log configuration.
Ok, so, we didn’t get 50 additional configuration options, but, the ones we do have now are light years ahead of 2007 (in my humble opinion…)
We can now set the number of days to store log files on the server (14 by default), and we can now also restrict the total disk space used by the log files! This is not enabled by default, but, I think this is a best practice, even before the best practices have really be written down, to enable this option immediately, and to something less than the size of the disk available. Full disk = bad.
Also, and this is not a configuration option that you can tweak in Central Admin, but, if you take a look in the logs directory in your 14 Hive (ahem!) sorry, the SharePoint Root folder, you will see that the log files are now being compressed by default! I did this anyways in 2003 and 2007, and eons before with any websites, they just now thought of this? In any event, it saves me a step in server configuration.
Logging to the database!
Check this out. Open up the SQL Management Studio, and expand your databases. You’ll notice a nice new one (among others), named WSS_Logging. Go ahead, check it out…. you will see there are quite a few tables. Most of them are partitioned up, so not too many records are stored within one specific table
However, they were kind enough to create views for us as well
which greatly simplifies hunting for that needle in a haystack. You will also, see, the very last view, ULSTraceLog. Yes, the ULS log is now also contained within the database as well!
This is just absolutely phenomenal. How many times I coped out the ULS logs into an excel sheet (painstakingly, especially since they can be huge files), to sort, filter, and search the data. Or, looking and trying to search the ULS logs within Notepad? UGH! This makes my life so. much. easier. Another awesome thing about this? NETWORK ACCESSIBLE LOGS! Yes! You can now access these from anywhere SQL gives you access to, easily write your own applications to parse the data, use SQL Reporting Services to merge logs from your entire farm, or multiple farms… the possibilities are endless.
Also, you will see that all events that get written back to the server Event Log for all of the servers in your farm? Yep, those can now be accessed in SQL as well, in the NTEventLog table. Awesome.
These are just a few of the many enhancements in SharePoint 2010, more to come soon!
Geoff Varosky's Blog 