Dieser Post ist Teil 2 der Logging Reihe, in der ich alte und neue Möglichkeiten der Ablaufverfolgung in SharePoint 2010 vorstelle. In Teil 1 wurden die Techniken vorgestellt um selbst in die sogenannten ULS Logs von SharePoint zu schreiben und so die Abläufe und Fehler in eigenen SharePoint Applikationen (Composites) nachzuvollziehen, wenn keine Debugging Möglichkeiten gegeben sind (so wie es auf Staging und natürlich Produktionssystemen der Fall ist).
In diesem Teil soll die neue Logging Datenbank von SharePoint 2010 vorgestellt werden. Das Durchsuchen der ULS Logs kann mitunter eine mühsame Arbeit sein, je nachdem wie “verbos” die jeweilige SharePoint Farm ihre Aktivitäten mit-logged. Was und besonders wie viel (also welcher Log-Level) jede einzelne Komponenten protokolliert wird seit jeher in der Zentraladministration eingestellt (in SP 2010 unter Monitoring > Diagnostic Logging).
Trotzdem, die ULS Logs sind gross und unübersichtlich. Tools wie der bekannte SharePoint ULS Log Viewer helfen zwar dabei, die Protokolle sinvoll durchsuchbar zu machen, aber es muss einen besseren Weg geben in Zeiten hochperformanter relationaler DBMS diese Information zu inidzieren und zu durchsuchen. In SharePoint 2010 gibt es das – Die neuen Logging Datenbanken, direkt im, der Farm zugewiesenen, SQL Server abgelegt.
Standardmässig werden von SharePoint 2010 keine Logging Datenbanken angelegt. Um dies zu erreichen müssen einige Timer Jobs, welche für das Logging zuständig sind gestartet werden.
- Diagnostic Data Provider: Event Log
- Diagnostic Data Provider: Performance Counters - Database Servers
- Diagnostic Data Provider: Performance Counters - Web Front Ends
- Diagnostic Data Provider: SQL Blocking Queries
- Diagnostic Data Provider: SQL DMV
- Diagnostic Data Provider: SQL Memory DMV
- Diagnostic Data Provider: Trace Log
Je nachdem was benötigt wird, startet man den entsprechenden Timer Dienst und bekommt sofort eine schöne Logging Datenbank erstellt mit den entsprechenden Protokollen. Diese Informationen zu durchsuchen und zu visualisieren ist ein Leichtes – ein bisschen Programmiererfahrung genügt um auf einen SQL Server zuzugreifen. Hier mit LINQ2SQL
1: public IEnumerable<TraceLog> GetTraceLogEntries()
2: {
3: var ctx = new LoggingDbDataContext(ConnectionFactory.GetTraceLogConnection());
4: return from logEntry in ctx.TraceLogs
5: select logEntry;
6: }
Es ginge noch kürzer, aber wir Entwickler, die in der echten Welt, ausserhalb von “Hello World”, auch schon mal für einen echten Kunden entwickeln, wissen warum Datenbindung nicht in die UI gehört, genauso wie zum Glück mein Baumeister weiss, dass die Wände meines Hauses schichtenweise aufgebaut gehören und nicht alles pragmatisch ineinander vermischt, wie es die Bauarbeiter am liebsten gemacht hätten – das Haus steht in beiden Fällen, aber irgendwie hab ich so das Gefühl dass es auch standhält und sein Geld wert ist.
Zurück zum Thema: Diesen kleinen Datenzugriffsblock kann man natürlich wunderbar in ein eigenes WebPart einbauen und hat so sehr komfortabel Zugriff auf die relevanten Logging Daten. Noch besser wäre die entsprechende Datenbank via Business Connectivity Services anzusprechen und als Externen Inhaltstyp verfügbar zu machen. Solange sinnvoll möglich sollte man immer SharePoint OOB Funktionalität verwenden um einfach wartbare und besonders einfach migrierbare Composites zu entwicklen. Das folgende Snippet zeigt die einfachst implementierten Methoden der BDC Entität. Die zwei Methoden reichen um Kompletten Lesezugriff für den externen Inhaltstyp herzustellen
1: public static TraceLog ReadItem(string id)
2: {
3: return GetTraceLogEntries().Where(t => t.CorrelationId == new Guid(id)).Single();
4: }
5:
6: public static IEnumerable<TraceLog> ReadList()
7: {
8: return GetTraceLogEntries();
9: }
Dieser kurze Überblick versteht sich als Denkanstoss wie man als Entwickler einfach und effizient die SharePoint Logging Daten verarbeiten kann. Eine ausührlichere Demo zu den Business Data Connectivity Services folgt.
UPDATE: Da fehlten wohl die Code Snippets – fixed.
Subscribe