byte5-CPO Sören Deger kennt als langjähriger Umbraco-Trainer und Projektmanager das CMS wie seine Westentasche. Anlässlich der Erscheinung der Umbraco-Version 8 noch in diesem Quartal teilt Sören in seiner Blogserie „Introducing v8“ sein Wissen, erklärt, was die neue Version an Funktionen mit sich bringt und welche technischen Vorzüge sie gegenüber ihren Vorgängerversionen bietet.

Dabei geht er insbesondere auf Installation, Mehrsprachigkeit und Änderungen bei Dokumententypen, auf nuCache und Log-Viewer sowie auf Content-Apps ein. Außerdem wird Sören klären, was wir von künftigen Minor-Releases erwarten dürfen. Heute geht es um die zwei neuen Features nuCache und Log-Viewer.

DJR 0128 Edit

Am Dienstag dieser Woche ist Umbraco 8 erschienen! Der beste Zeitpunkt also, sich mit den brandneuen Features von v8 zu beschäftigen. Los geht’s!

Nachdem wir uns vergangene Woche die neu eingeführte Mehrsprachigkeit in v8 und Neues in Sachen Dokumententypen näher angesehen haben, betrachten wir im dritten Teil meiner Blogserie den integrierten Log-Viewer und das neue Caching-System nuCache genauer. Es wurde sogar das zu Grunde liegende Logging-Framework komplett ausgetauscht.

Serilog & Log-Viewer

Das Logging von Fehlermeldungen, welches bisher auf dem Framework Log4net basierte, war bei Umbraco schon immer schon so eine Sache. Das Gute war, dass das Logging ausreichend war und man die Möglichkeit hatte, auch Exceptions von eigenem Code ganz einfach in die Umbraco-Logdatei schreiben zu lassen. Der Nachteil jedoch war die fehlende Auswertungsmöglichkeit mit Bordmitteln von Umbraco. Man musste entweder Packages von der Umbraco-Community im Backend installieren oder mittels Texteditors die Tracelog-Datei öffnen und von Hand auswerten. Mit der neuen Umbraco-Version 8 hat sich hier endlich etwas verbessert und es wird statt Log4net nun Serilog verwendet.

Serilog schreibt nun JSON-Log-Dateien, anstatt wie bisher einfache Textdateien wie durch Log4net. Dies ermöglicht nun, dass entsprechende Tools sehr performante Suchabfragen über die Logs durchführen können. Und Umbraco v8 hat deshalb auch bereits einen recht komfortablen Log-Viewer direkt im Core integriert!

Das Standardverzeichnis für diese Logs befindet sich in /App_Data/Logs und beinhaltet auch den Maschinennamen und das Datum, z.B.: /App_Data/Logs/UmbracoTraceLog.DELLBOOK.20192102.json

Der große Vorteil von Serilog ist auch, dass nun viel mehr Informationen strukturiert gespeichert und ausgelesen werden können.

Bisher sah eine klassische Zeile im Log von Umbraco 7 exemplarisch wie folgt aus:

Abbildung 1

Abb. 1: Logeintrag in Umbraco 7

 

In Umbraco 8 ergibt sich für die gleiche Logging-Information folgendes JSON-Objekt:

Abbildung 2

Abb. 2: Log-Eintrag in Umbraco v8

 

Das Hinzufügen von individuellen Log-Einträgen aus eigenem Code ist in v8 sehr leicht möglich. Zunächst muss eine Referenz auf Umbraco.Core.Logging gesetzt werden. Die eigene Klasse sollte idealerweise von einer der folgenden speziellen Umbraco-Klassen erben:

  • RenderMvcController
  • SurfaceController
  • UmbracoApiController
  • UmbracoAuthorizedApiController

Dann kann mit der einfachen Syntax Logger.Info<T> auf die Loggingfunktionalität zugegriffen werden.

Abbildung 3

Abb. 3: Logging in Custom-Code

 

Wenn man nicht von diesen Umbraco-Klassen erbt, muss man zusätzlich eine Referenz auf Umbraco.Core.Composing setzen und in der betreffenden Methode die Current.Logger-Instanz verwenden.

Im Log wird durch das obige Beispiel bei Aufruf der API-Methode Folgendes angezeigt:

Abbildung 4

Abb. 4: JSON-Objekt in Log-Datei nach Aufruf des vorherigen ApiControllers

 

Serilog lässt sich über die Datei /config/serilog.config individuell und einfach konfigurieren. Man kann beispielsweise den entsprechenden Log-Level, ab welchem Informationen und Fehler erfasst werden sollen, mit dem folgenden Schlüssel konfigurieren:

Abbildung 5

Abb. 5: Änderung des Log-Levels in Serilog-Konfigurationsdatei

 

Es gibt folgende, fast sich selbsterklärende Level, welche im Detail auf der offiziellen Dokumentationsseite von Umbraco aber auch noch näher erläutert werden:

  • Verbose
  • Debug
  • Information
  • Warning
  • Error
  • Fatal

In dieser recht umfangreichen Dokumentation findet man auch bereits konkrete Beispiele wie man beispielsweise:

  • den Log-Level nur für bestimmte Namespaces ändert,
  • Log-Einträge in eigenen Dateien und anderen Pfaden speichert,
  • Log-Events schreibt, um die Log-Einträge auf verschiedenen Storage-Typen zu speichern
  • eigene Log-Properties zu allen Logeinträgen hinzufügt

…und noch einiges mehr. Serilog ist somit sehr umfangreich, mächtig und dennoch einfach anzupassen.

Werfen wir nun aber mal einen Blick auf den built-in Log-Viewer von Umbraco 8. Dieser befindet sich im Settings-Bereich und ist über den linken Verzeichnisbaum zu öffnen.

Abbildung 6

Abb. 6: Integrierter Log-Viewer in Umbraco 8

 

Man erhält hier einen Überblick aller Logeinträge des aktuellen Tags. Im linken Bereich kann man gespeicherte Suchen aufrufen und ausführen. Darunter befindet sich eine Zusammenfassung aller Nachrichtentypen und der Anzahl dieser Nachrichten im aktuellen Log. Auf der rechten Seite findet man die Anzahl der aktuellen Fehler im Log und ein Diagramm mit der Verteilung des Log-Typs.

Wenn man nun auf die rote Fehlerzahl oben rechts klickt werden sofort alle Fehlermeldung in einer Liste angezeigt:

Abbildung 7

Abb. 7: Listendarstellung von Fehlern im integrierten Log-Viewer von Umbraco 8

 

Die einzelnen Fehlermeldungen kann man nun auch wieder öffnen und sich die Details übersichtlich ansehen. Das Besondere hierbei sind zwei Dinge: Die Werte bei SourceContext und MachineName sind verlinkt und je nach Logeintrag eventuell auch noch weitere (Andeutung durch das Lupensymbol hinter dem Wert). Wenn man nun auf diesen Link klickt, werden in einer neuen Liste alle Fehlermeldungen angezeigt, welche exakt den gleichen SourceContext oder den gleichen MachineName haben.

Weiterhin gibt es am Ende einen Such-Button, mit welchem man direkt eine Google- oder Bing-Suche nach dieser Fehlermeldung starten kann.

Abbildung 8

Abb. 8: Detailansicht eines Log-Eintrags mit erweiterten Suchfunktionen

 

Werfen wir nun einen Blick auf die weiteren Funktionalitäten des Log-Viewers. Die gespeicherten Suchen können einfach per Klick geöffnet werden. Zum Beispiel können wir uns mit der gespeicherten Suche „Find all logs that have the property ‚Duration‘ and the duration is greater than 1000ms“ alle Logeinträge anzeigen lassen, welche mit einer Dauer größer als 1000ms vorhanden sind.

Abbildung 9

Abb. 9: Log-Einträge mit Dauer größer 1000ms

 

Wir können diese Such-Query nun natürlich auch individuell anpassen und diese ebenfalls als Suche speichern. Nach dem Anpassen der Such-Query erscheint zusätzlich ein gelbes Sternsymbol in der Such-Query-Leiste.

Abbildung 10

Abb. 10: Möglichkeit zum Speichern eigener Such-Querys über Sternsymbol

 

Daraufhin öffnet sich ein Overlay, in welchem nochmals die aktuelle Query angezeigt wird und ein Anzeigename für die gespeicherte Suche eingetragen werden muss.

Abbildung 11

Abb. 11: Speichern einer Suche im Log-Viewer für spätere Verwendung

 

Nun können wir jederzeit bei den gespeicherten Suchen unsere neue Suche aufrufen und zur Auswertung verwenden.

Abbildung 12

Abb. 12: Gespeicherte Suchen mit neu hinzugefügter Suche „Logs with duration > 100ms“ am Ende der Liste

 

Die gespeicherten Suchen werden in einer eigenen Konfigurationsdatei von Umbraco v8 gespeichert und können grundsätzlich auch dort bearbeitet werden. Sofern gespeicherte Suchen bei einem Deployment beinhaltet sein sollen, muss natürlich auch diese Datei mit ins Deployment-Paket.

Abbildung 13

Abb. 13: Konfigurationsdatei für gespeicherte Suchen des Log-Viewers in /config/logviewer.searches.confg.js

 

Möchte man nun eine gespeicherte Suche wieder löschen, kann man diese entweder in der Konfigurationsdatei wieder entfernen oder man kann im Such-Query-Feld über „Example Searches“ die gespeicherten Suchen entfernen.

Abbildung 14

Abb. 14: Gespeicherte Suchen in Log-Viewer löschen

 

Weiterführende Informationen zu den Such-Query-Expressions findet man hier.

Es besteht übrigens auch die Möglichkeit, einen eigenen Log-Viewer zu implementieren, beispielsweise um Logs aus einem Azure Table-Storage zu durchsuchen. Ein Beispiel findet man in der offiziellen Dokumentation von Umbraco 8.

Caching mit nuCache

Das zweite Thema des heutigen Blogposts ist das neue Caching-System von Umbraco 8: nuCache.

Bisher wurde der Content aus der Umbraco-Datenbank in einer XML-Datei /App_Data/umbraco.config gespeichert, um bei lesenden Operationen nicht auf die Datenbank zugreifen zu müssen.

In Umbraco v8 wurde das Caching nun komplett auf nuCache umgestellt. nuCache ist ein „Multiversion concurrency control“ (MVCC)-orientierter Objekt-Cache und basiert im Hintergrund auf einem BTree Key-Value-Storage.

Dies bedeutet, dass durch den Zugriff auf einzelne Objekte die Performance deutlich besser ist, als zuvor bei Verwendung einer teils recht sehr großen XML-Datei. Der Cache wird zwar noch immer auf Datei-Ebene gespeichert, wie zuvor die umbraco.config, aber nun in Form einer binären Datenbank. Außerdem sind nun auch die Medien-Objekte im Cache enthalten und die Content-Objekte enthalten auch den Entwurf beziehungsweise die zuletzt gespeicherte und nicht veröffentlichte Version eines Content-Knotens.

Beim Startup von Umbraco wird der gesamte Cache nun direkt aus der Datei geladen, ohne die eigentliche Umbraco-Datenbank abzufragen. Das beschleunigt auch die Startup-Zeit. Wenn nun Content- oder Media-Knoten aktualisiert werden, so wird direkt in den Cache geschrieben und nur dieses eine Objekt im Cache aktualisiert. In Umbraco 7 war es bis dato hingegen so, dass zunächst der Content in der Umbraco-Datenbank und erst danach die XML-Datei im Gesamten aktualisiert wurde.

Durch nuCache haben wir somit nun in Umbraco 8 neben der bereits genannten extremen Performance-Verbesserung auch eine zuverlässige sofortige Vorschau von lediglich gespeicherten und nicht veröffentlichten Knoten, ein Media-Caching und einen deutlich geringeren Arbeisspeicherverbrauch auf der Ressourcenseite.

Nun stellt sich natürlich die Frage, wie wir uns die gecachten Objekte ansehen können. Die ursprüngliche umbraco.config konnten wir mit jedem beliebigen Texteditor öffnen und uns das beinhaltete XML ansehen. Mit nuCache ist dies mit einem gewöhnlichen Texteditor nicht möglich, da die Dateien eine binäre Datenbank sind.

Hierfür hat Waren Buckley bereits einen sogenannten nuCache-Explorer als kleine Desktopapplikation entwickelt, welcher hier heruntergeladen werden kann. 

Mit Hilfe von Warrens nuCache-Explorers kann nach der Installation ganz einfach auf die einzelnen Objekte im Cache zugegriffen werden und die JSON-Repräsentation angesehen werden.

Abbildung 15

Abb. 15: nuCache-Dateien im Verzeichnis „/App_Data/TEMP/NuCache

 

Es gibt je eine binäre Datenbankdatei für den Content-Cache und für den Media-Cache. Im nuCache-Explorer können diese Datei nun beispielsweise per Drag & Drop einfach geöffnet werden. Wenn wir den Content-Cache öffnen, wird uns zunächst das erste Objekt daraus angezeigt.

Abbildung 16

Abb. 16: Darstellung eines Content-Objekts aus nuCache im nuCache-Explorer

 

Wir sehen hier nun alle Informationen und Daten zu diesem Content-Objekt. Zunächst bekommen wir die Dokumententypen-ID angezeigt und danach bei „Draft Data“ alle Daten der aktuell gespeicherten, nicht veröffentlichen Version des Content-Knotens. Hier sind nun auch alle Werte der Propertys in den unterschiedlichen Sprachen aufgeführt, sofern wir die neue Funktionalität der Mehrsprachigkeit von Umbraco 8 verwenden. Die „Draft Data“ hat zum einen den großen Vorteil, dass wir nicht mehr – wie bisher in Umbraco 7 – auf die Umbraco-Datenbank zugreifen müssen, um an diese Daten zu gelangen. Zum anderen ermöglicht dies auch die sofortige Verfügbarkeit der Daten in der Vorschaufunktion des Umbraco-Backends für Content-Knoten, worin der große Performance-Gewinn bei der Vorschaufunktion begründet ist.

Als nächstes werden bei „Node“ die wichtigsten Werte der System-Propertys angezeigt und bei „PublishedData“ alle Werte der Propertys unseres veröffentlichten Content-Knotens. Auch hier haben wir wieder alle Daten für alle verwendete Sprachen verfügbar.

„Published Status“-Dashboard

Beim Thema Caching stellt sich nun abschließend noch die Frage, was man tun kann, wenn es beim neuen nuCache mal Probleme mit dem Caching geben sollte. Für diesen Zweck gibt es nun im Settings-Bereich ein neues Dashboard: „Published Status“.

In diesem Dashboard wird zunächst der allgemeine nuCache-Status angezeigt.

 Abbildung 17

Abb. 17: „Published Status“ Dashboard im Settings-Bereich

 

Darunter hat man nun verschiedene Möglichkeiten:

  • Refresh: Der Status wird aktualisiert
  • Collect: Es werden Momentaufnahmen gesammelt (nachdem ein Garbage-Collector ausgeführt wurde)
  • Rebuild: Neuerstellung des Datenbank-Caches (Inhalt der Tabelle cmsContentNu in der Umbraco-Datenbank). Dies kann sehr aufwendig sein und lange dauern.
  • Reload: Der Cache im Arbeitsspeicher und in den lokalen Dateien wird aus der Tabelle cmsContentNu komplett neu geladen. Jedoch wird die Tabelle nicht neu erstellt. Dies funktioniert sehr schnell und löst auch das Neuladen auf allen Servern in einer Load-Balancing Umgebung aus.

 

Heute in einer Woche (8. März) geht es schon weiter mit dem nächsten Teil meiner Serie. Darin werden wir uns dem Thema „Content-Apps“ in Umbraco 8 widmen.

Du möchtest noch mehr über Umbraco 8 erfahren? Dann lies doch unseren Blogpost v8 Is Here – Alles, was du über die neue Umbraco-Version wissen musst“ !

 

Unser erster Hackathon zu Umbraco v8 findet am Donnerstag, den 4. April, statt! Sei dabei, wenn wir uns im Rahmen des deutschen Umbraco-Festivals ein paar Issues vorknöpfen und gemeinsam mit Poornima vom offiziellen Pull-Request-Team gemeinsam an Umbraco 8 feilen. Die Teilnahme kostet nichts außer einer Anmeldung bei Laura ! Los geht’s um 14 Uhr.

Zurück