Store Item „Published date“ and „Published by“ information on each Sitecore item

Sitecore Publish Statistics for Published by and Published date - Teaser

Did you ever miss that Sitecore doesn’t keep track of who published which item(s) at what date? Well, be not sad no longer! In this blog post you’ll find a neat solution to store the „Published date“ and „Published by [user]“ information on all Sitecore items – so it’s finally possible to blame the right person who published too many items once again 😉 Weiterlesen

Audit-Logging in separater Datei

Sitecore protokolliert standardmässig Logins, Publishing-Vorgänge sowie das Hinzufügen/Entfernen von Versionen im Backend mit AUDIT Einträgen im Sitecore-Log. Im Betrieb, wenn mehrere Autoren auf dem System arbeiten, kann das Analysieren dieser AUDIT Events schwierig sein, da sie zusammen mit allen anderen Sitecore-Log-Einträgen in eine einzelne Datei geloggt werden.
(mehr …)

Splunk for Sitecore Logs

Was ist Splunk?

Splunk ist ein Log-, Monitoring- und Reporting-Tool. Es kann verschiedenste Textdateien, wie Log-Dateien oder andere Daten von Applikationen oder Servern, einlesen und in einem durchsuchbaren Speicher ablegen. Splunk bietet ein komfortables Web-Interface, mit dem die indexierten Daten durchsucht werden können sowie Warnmeldungen und grafisch ansprechende Diagramme generiert werden können.

Sitecore Log Source Type

Splunk liest die einzelnen Files nach einem vordefinierten Muster ein und versucht so, die einzelnen Events zu erkennen. Diese Muster werden Source Types genannt und sind essentiell wichtig, damit die Analyse von Log-Files überhaupt funktionieren kann. Leider existiert für Sitecore bzw. log4net kein Source Type. So haben wir selber einen solchen erstellt und können nun die Sitecore Logs sauber indexieren. In der Datei etc/system/local/props.conf des Splunk-Programm-Verzeichnisses muss dazu folgender Eintrag gemacht werden:

[Sitecore Log]
BREAK_ONLY_BEFORE = \S+\s\d{2}:\d{2}:\d{2}
NO_BINARY_CHECK = 1
SHOULD_LINEMERGE = true
pulldown_type = 1

Sobald die Konfigurationsdatei angepasst und Splunk neu gestartet wurde, kann beim Hinzufügen von neuen Datenquellen der Source Type „Sitecore Log“ ausgewählt werden:

Splunk ist ein nützliches Tool, um viele Log-Files komfortabel zu durchsuchen und zu analysieren. Die zusätzlichen Funktionen wie beispielweise das automatische Alarmieren bei gewissen Events, machen den Einsatz in einer Produktivumgebung mit grossem Datenvolumen interessant. Zu erwähnen ist ausserdem Splunk Storm, welches die cloud-basierte Version von Splunk darstellt.

Sitecore-Logging auf High-Traffic-Sites

Jeder Sitecore-Entwickler weiss mit Sicherheit, wie man Log-Einträge schreibt. Z.B.

Log.Error("Some error occurred!", typeof(MyClass));

Mit der standard-Sitecore-Konfiguration würde das einen Eintrag im Log des aktuellen Tages machen. Dieser Standardansatz funktioniert gut, solange nicht allzu viel Traffic auf der Site herrscht. Auf hoch frequentierten Sites hingegen, wird die Analyse von Logs sehr schwierig.

Hauptprobleme sind:

  1. Sitecore erzeugt selbst Log-Einträge, die mit applikations-spezifischen Einträgen vermischt werden –> viele Log-Einträge
  2. Die Logging-Konfiguration (z.B.  Ausgabemedien oder Log-Level) können nicht geändert werden ohne Zugang zu den Config-Dateien
  3. Es ist nur schwer möglich, Log-Einträge einem bestimmten Request oder einer bestimmten Session zuzuordnen.

Bestehende Lösungen

In diversen Blog Posts sind bereits verschiedene Wege beschrieben worden, wie die Standard-Sitecore-Logging-Konfiguration verbessert werden kann. Zum Beispiel kann mit einem eigenen log4net Appender und logger ein eigenes Log-File als Ausgabemedium genutzt werden.

Ein weiterer Weg, eigene Log-Einträge von den Sitecore-eigenen Einträgen zu unterscheiden ist, eigene Log-Einträge mit einem Präfix zu versehen. Log4net kann dann mittels Regex-Pattern diese Einträge gesondert in ein eigenes Log schreiben.

Ferner kann die Ausgabe auf andere Medien z.B. in eine SQL-Tabelle die Analyse einfacher machen. John West beschreibt in seinem Post verschiedene Möglichkeiten, dies umzusetzen.

Eigene Log-Einträge von den Sitecore-eigenen Einträgen gesondert zu behandeln ist also möglich. Dies löst aber noch nicht unsere anderen beiden Probleme.

  1. Ist es auch mit eigenem Log-File immer noch schwierig, Log-Einträge einem bestimmten Request zuzuordnen und
  2. Für Anpassungen von Log-Level und Ausgabemedien ist eine Änderung der web.config nötig, was Server-Zugriff voraussetzt.

Dies sind die Gründe, wieso wir uns dafür entschieden haben, einen anderen Ansatz zu wählen.

Unser Ansatz

Die Grundidee ist, die Sitecore-Logging-Funktionen über eine eigene Logger-Klasse von unsrem Code zu entkoppeln. Das heisst konkret, dass wir eigene .Warn(), .Error(), usw. -Methoden implementieren.

 

Logger.Error("Some error occurred!");

Wird eine dieser Methoden aufgerufen, startet unser Logger dynamisch Processors für spezifische Ausgabemedien (ähnlich wie log4net appenders), die zur Laufzeit ein/ausgeschaltet und konfiguriert werden können.

Auf diese Weise können wir die ursprünglichen drei Probleme lösen:

  1. Unsere eigenen Log-Einträge können von denen des Sitecore-Systems getrennt werden, da wir eigene Log-Einträge über unsren eigenen Logger schreiben.
  2. Die Konfiguration von Log-Levels und Ausgabemedien kann zur Laufzeit über das Sitecore-Backend vorgenommen werden.
  3. Durch Implementieren eines Browser-Console-Log, können wir Log Events eines spezifischen Requests direkt zur Browser-Konsole ausgeben via HTTP- Headers. Dazu haben wir das FirePHP  Protokoll in .NET umgesetzt.

Mit diesem Ansatz gewinnen wir viel Flexibilität punkto Logging. Speziell in komplexen Infrastrukturen mit mehreren Servern und ohne direkten Zugang zu Config-Dateien kann dies eine grosse Hilfe beim Analysieren von Problemen sein.