Categories: Sharepoint 2010

KOmfortable Logfile Analyse für Sharepoint–Teil 2

Wie im  Teil 1 schon beschrieben, können wir per Auftrag alle Einträge des ULS Logfiles in die Datenbank schreiben lassen. Die Abfrage per T-SQL läßt deutlich mehr Spielraum die Suche nach Problemen, KorrelationsID usw. zu vereinfachen. Aber ehrlich gesagt: das muss noch besser gehen. Wie wäre es ,das Logile in der Zentraladministration anzuzeigen? Inklusive Filterfunktion, Hervorhebung von kritischen bzw unerwarteten Ereignissen? Hört sich gut, läßt sich gut machen!

Zwei Dinge braucht der Mann dazu: Den Zugriff zur Datenbank und den Sharepoint Designer 2010.

Datenbankzugriff

Die Daten stecken in der WSS_Logging Datenbank und können sehr komfortabel per Sicht (ULSTraceLog) ausgelesen werden. Für den Zugriff könnten wir einerseits das Konto derFarm verwenden oder ein spezielle dediziertes Konto für die Logfileanlayse, das nur Leserechte auf die Datenbank erhält.

Dazu legen wir einen Benutzer (bspw. SQLULSUSer) an und geben bei der Benutzerzuordnung die Rechte  in der WSS_Logging Datenbank lesen zu dürfen. (hier: per Datenbankrolle db_datareader, mit der in jeder Tabelle lesen dürfte)

Sharepoint Designer 2010

Im Sharepoint Designer öffnen wir die Zentraladministration und legen per Menu eine Datenquelle an:

An dieser Stelle gilt es aufzupassen, denn die Anmeldedaten werden im Sharepoint Designer im Klartext gespeichert.!

Sofern die Anmeldung geklappt hat, sollte die WSS_Loggingdatenbank auswählbar sein und wählt als Datenbasis für die späteren Abfragen die Sicht ULSTraceLog.

Da vermutlich nicht jede Information beobachtet werden muss, lassen sich Felder aus er Ansicht entfernen.  Sharepoint Designer liebt es es eh nicht besonders, wenn zu viele Felder anzeigt werden und unterdrückt oft genug einige Felder, obwohl diese angezeigt werden sollten.

Nun kann man noch die Ergebnisse der Abfrage nach Logtime absteigen sortieren, so dass auf jeden Fall aktuellste Ereignisse ganz oben zu finden sein werden.

Ebenso ließe sich ein Filter einbauen, der nur bestimmte Ereignisseinträge anzeigt.  Da es später sehr viele Logeinträge sein könnten,  würde ich den Filter eher auf die TOP 1000 EInträge oder per Datum (max. der letzten 24 Stunden) eingrenzen. Das kann man aber per T-SQL deutlich leichter bewerkstelligen  als im Sharepoint Designer irgendein  Rumgefummle zu starten. Dazu schließen wir zunächst die eben erstelle Sortierung und klicken auf Datenquelle. Dort ändern wir im weiteren Dialog die Einstellung so, dass an statt der Sicht ein T-SQL Befehl eintragen werden kann, wie zum Beispiel folgender:

Neue Seite für Logfileanzeige

Um die Logfileeinträge in der Zentraladministration komfortabel lesen zu können, werden nun im folgenden

  • eine neue Seite anlegen: Logfile.aspx
  • Die Datenquelle einbinden und die anzuzeigenden Felder festlegen
  • Die Masterpage anhängen
  • Das Layout auf ein besser lesbares ändern
  • bedingte Formatierungen für den Level  (warning oder unexpected bspw) einführen.

So nun der Reihe: Zuerst die Seite (ich nenne sie Logfile.aspx)

Wenn die Datei angelegt ist, diese doppelklicken und zum Bearbeiten öffnen. Den Hinweis, dass die Datei im erweiterten Modus geöffnet werden muss, bejahen wir.

Nun sehen wir eine leere Seite mit einem Form Feld, in das wir die Datenquelle per Klick einfügen.

Im Ergebnis sehen wir, dass nicht alle Spalten angezeigt werden. Daher fügen wir die relevanten Spalten hinzu, andere lassen wir weg. So macht zum Beispiel die RowID hier wohl keinen Sinn, sehr wohl der Level oder die Message.

Damit das ganze auch irgendwie nach Sharepoint aussieht und vor allem das Menu der Zentraladministration vorhanden sein sollte, fügen wir der Logfile.aspx die Masterpage v4 an.

Das Ergebnis hat nun schon mehr mit Sharepoint Ähnlichkeit:

Allerdings hasse ich es wenn ich horizontal und vertikal scrollen muss! Das kann man allerdings dadurch beheben, wenn man irgendwo in die Tabelle klickt und dann per Menü “Entwurf” den Wiederholenden Abschnitt wählt:

Letzter Schliff

Optimal wäre nun noch die Ladezeiten zu verbessern und Fehler hervorzuheben. Bitte schön:

Markieren Sie dazu das Feld Level, in dem sich Warning, Unexpected usw befinden, und wählen im kontextmenü “bedingte Formatierung. Nun können Sie via “Erstellen”.. Formatierung übernehmen unserer Regeln für die Formatierung anlegen.

          

Nachdem wir die Regeln festgelegt haben, definieren wir die Formatvorlage. Hintergrund “rot” etwa.

Fast geschafft. Nur noch per Seitenverwaltung das Paging aktivieren und die Anzeigen auf eine gewünschte Anzahl der Datensätze einschränken.. und schon wird die Anzeige schon deutlich flüssiger.

Und zuletzt noch eine Gruppierungs- und Filtermöglichkeit aktivieren:

Und so könnte das Endergebnis aussehen.

Mit Filterfunktion:

Fumus

Share
Published by
Fumus

Recent Posts

SQL Server 2019 – static data masking – Du Opfer!

In SQL Server 2016 wurde das sog. dynamic data masking eingeführt. Eine Möglichkeit Daten bei…

5 Jahren ago

MinRole – Oder wie alles etwas einfacher wird

Seit Sharepoint Server 2007 präsentiert sich die Installation immer auf die gleiche Weise. Gerade mal,…

8 Jahren ago

Schritt für Schritt: SQL 2016 – Dynamic Data Masking

Es weihnachtet! Gerade bekam ich von einer Kollegin Plätzchen angeboten mit der Größe eines Diskus…

8 Jahren ago

Schritt für Schritt: SQL Server 2016 – temporal tables

Nein, bitte nicht verwechseln: temporal tables haben nichts zu tun mit temporary tables table variables…

9 Jahren ago

SQL Server 2016 Schritt für Schritt–Installation und First Look

SQL Server 2016.. habe ich schon erwähnt, dass ich den ziemlich cool finde? Wollen wir…

9 Jahren ago

SQL Server 2016 – CTP2

Nach langer Zeit wieder mal eine Artikel von mir.. der mich besonders erfreut. SQL Server…

9 Jahren ago