In diesem Blogbeitrag erläutern wir die neue Log-Protokollierung von DeltaMaster Web und beschreiben weitere Möglichkeiten zur Fehleranalyse. Zudem geben wir Tipps zur Konfiguration.

Fehleranalyse und Protokollierungsmöglichkeiten in DeltaMaster

DeltaMaster bietet seit der Version 6.1.8 ein neues Feature für eine umfangreichere Fehleranalyse. Die Entwicklung an diesem Feature ist zwar noch nicht beendet, trotzdem kann es bereits eine große Hilfe bei der Fehleranalyse sein.
DeltaMaster bietet schon seit langem umfangreiche Logdateien:

• DeltaMaster Full-Client, DeltaMaster Service:
  • Mdx.log
  • Sql.log
  • Sync.log
  • Trace-Dateien
  • Service.trace
• DeltaMaster Web-Client: WebClient.trace

Alle Logdateien wurden bisher als Textdateien erstellt. Konfiguration und Aktivierung erfolgen im Desktop-Client über die Diagnose, im DeltaMaster Service und im DeltaMaster Web-Client über die Konfigurationsdateien.

Mit dem neuen Feature können alle Protokolle in eine Datenbank geschrieben und somit auch darüber ausgewertet werden. Für die Konfiguration gibt es eine neue Konfigurationsdatei Namens NLog.config.

Hinweis: Für den Betrieb von DeltaMaster ist eine aktive Protokollierung nicht erforderlich. Diese kann sogar Geschwindigkeitsnachteile verursachen. Deswegen empfehlen wir, die Protokollierung nur im Bedarfsfall zu aktivieren und nach abgeschlossener Fehleranalyse zu deaktivieren.

Logging Framework „NLog“

NLog ist ein .NET Logging-Framework, dass es ermöglicht Logs in unterschiedliche Ziele (u.a. Textdatei, Datenbank) zu schreiben und Konfigurationen auch während des Betriebs zu ändern. In diesem Blogbeitrag wird nicht auf die Details von NLog oder der Implementierung des Logging-Frameworks in DeltaMaster eingegangen. Hier werden nur die Vorteile benannt und die grundsätzliche Aktivierung beschrieben. Weitere Informationen, u.a. zur Implementierung von NLog in DeltaMaster, befinden sich in der Dokumentation der Entwicklung.

DeltaMaster liefert bereits vorkonfigurierte NLog.config-Dateien für den DeltaMaster Full-Client, DeltaMaster Service und DeltaMaster Web-Client mit. Einzig das Log-Level kann bei Bedarf geändert werden. Grundsätzlich gibt es die in Tabelle 1 genannten Log-Level. Im Standard wird das Log-Level „Info“ genutzt. Für eine detaillierte Analyse kann „Debug“ oder „Trace“ verwendet werden.

Tabelle 1: NLog Log-Level

Am Ende der Konfigurationsdatei gibt es einen Abschnitt . Dort sind alle „Logger“ aufgelistet, und über das Attribut „minlevel“ wird das Log-Level gesteuert.

Mdx.log, Sql.log und Sync.log sind DeltaMaster-eigene „Logger“. Das bedeutet, dass die Protokollierung hierfür separat in der DeltaMaster.Service.exe.config aktiviert werden muss.

Für diese „Logger“ sollte das Log-Level auch nicht geändert werden, da nicht alle Level möglich sind. Der Logger „*“ protokolliert alles Weitere, und dort kann das Log-Level auch verändert werden.

Log Datenbank

Spannend wird es, wenn nun alle Protokolle in eine Datenbank geschrieben werden. Es empfiehlt sich, eine eigene Datenbank für das „Logging“ anzulegen, da Log-Tabellen schnell sehr groß werden können. Für den Full-Client ist die Protokollierung in eine Datenbank in Vorbereitung.

Installation

1) Neue MSSQL-Datenbank anlegen (derzeit keine bestimmte Version notwendig)

2) Scripte ausführen (auf Anfrage verfügbar)

• Create.sql
• LogSetting.sql

Konfiguration DeltaMaster Service

1) Verbindung zur Logging-Datenbank in DeltaMaster.Service.exe.config hinzufügen

2) Logging-Endpoint in DeltaMaster.Service.exe.config auskommentieren und anpassen. Es muss der gleiche Server und der gleiche Port wie beim Service-Endpoint verwendet werden.

3) NLog.config vom DeltaMaster Service kann unverändert bleiben. Bei Bedarf Log-Level anpassen.

Nach einem Neustart des Dienstes „DeltaMaster Service“ sollten bereits Einträge in die Tabellen auf der Datenbank geschrieben werden.

Konfiguration DeltaMaster Web-Client

1) Logging-Endpoint in web.config auskommentieren und anpassen. Auch hier muss der gleiche Server und der gleiche Port wie beim Service-Endpoint verwendet werden.

2) NLog.config vom DeltaMaster Web-Client anpassen. Logger mit dem Ziel (writeTo) „LogService“ auskommentieren. Der Logger mit dem Ziel „TraceFile“ kann anschließend durch einkommentieren deaktiviert werden.

Achtung Namenskonvention: Falls die BissantzServiceUrl angepasst wurde, so muss diese auch in der NLog.config angepasst werden!

Verwendung

Nach der Aktivierung können Auswertungen der Logs in der Datenbank oder über eine vorbereitete DeltaMaster Analysesitzung durchgeführt werden.

Weitere Hinweise
DeltaMaster-Service

Die Konfiguration der Pfade für Log- und Trace-Dateien erfolgen wie bekannt über die beiden Einträge in der DeltaMaster.Service.exe.confi:

Webclient

Die Konfiguration des Pfads für die Trace-Datei erfolgt wie bekannt über den Eintrag in der web.config:

Die Konfiguration des Log-Levels (Error, Verbose) in der web.config ist durch die Konfiguration in der Nlog.config ersetzt worden.

Wenig bekannt ist die Möglichkeit eines Full-Response-Loggings im Web-Client. Dieses kann weiterhin in der web.config aktiviert werden, sollte jedoch nur im absoluten Ausnahmefall notwendig sein.

Fehlercodes im Webbrowser

Wird im Browser ein Fehlercode angezeigt, dann sollte unbedingt als erstes Abschnitt 6.2 aus dem Handbuch „DeltaMaster Weboption – Installation und Einrichtung“ geprüft werden, da hier bereits Hinweise zur Fehlerbehebung stehen.

IIS

Insbesondere in einer Webumgebung können auch Fehler außerhalb von DeltaMaster auftreten. Der IIS bietet hierzu zwei Protokolle.
Hinweis: Änderungen im IIS können auch in der web.config stehen, die ggf. bei einem Update des Webclients beibehalten werden sollen.

Protokollierung

Der IIS protokolliert im Standard alle Aufrufe mit. Über den Menüpunkt Protokollierung (engl. Log-ging) können Format, Verzeichnis, Zeitplan und Protokollfelder angepasst werden. Es können u. a. hilfreiche Cookie-Informationen mit protokolliert werden, die im Standard nicht mit enthalten sind.

Ablaufverfolgung (ab IIS 7)

Eine weitere und sehr hilfreiche Möglichkeit zur Fehleranalyse ist die Ablaufverfolgung (Failed Request Tracing). Hiermit können insbesondere Fehler mit dem http-Statuscode 500 analysiert werden. Es kann aber auch jeder Request unabhängig vom Statuscode im Detail mitprotokolliert werden, z.B. zur Performanceanalyse.

Installation:
1) Dieses Feature wird im Standard nicht mitinstalliert und muss daher über die Rollendienste bzw. Windows-Features nachinstalliert werden (s. Abbildung 1).

Abbildung 1: Beispiel Windows 10: Systemsteuerung / Programme / Windows-Features aktivieren

2) Nach der Installation steht im IIS-Manager die Ablaufverfolgung zur Verfügung. Falls der IIS-Manager schon geöffnet war, muss dieser geschlossen und wieder geöffnet werden. Als nächstes muss auf der Webseite unter Aktionen (rechte Seite) die Ablaufverfolgung aktiviert und das Verzeichnis konfiguriert werden.

3) Schließlich muss noch eine Regel erstellt werden, welche Ereignisse protokolliert werden sollen.

Bei jedem Aufruf wird dann im angegebenen Ordner eine XML-Datei erzeugt. Diese Datei kann über den Internet Explorer im Detail betrachtet werden. In kürzester Zeit werden dann sehr viele Dateien erstellt. Diese sind ohne weitere Hilfsmittel kaum auswertbar, deswegen hat unsere Entwicklung ein kleines Tool dafür erstellt: RequestTraceViewer (s. Abbildung 2).

Der RequestTraceViewer durchsucht alle XML-Dateien eines Ordners. Über Filter können Zeiträume, Status Codes oder User eingegrenzt werden. Darüber hinaus besteht die Möglichkeit, nach einem Cookie zu suchen und sich alle Dateien einer Session anzuzeigen.

Abbildung 2: RequestTraceViewer

Browser

Für Fehler- und Performanceanalysen im Web sind die Entwicklertools in den Browsern ebenfalls sehr hilfreich. Diese sind in allen gängigen Browsern über F12 aufrufbar. Interessant für weitergehende Analysen ist die Registerkarte Netzwerk (Network). Wenn man einen Eintrag auswählt, werden weitere Informationen zur Anfrage dargestellt (s. Abbildung 3).

Abbildung 3: Google Chrome – Header Informationen

Kann eine Fehlerseite im Browser provoziert werden, dann sollten auch die Logs der vorgehenden Seiten behalten werden (Chrome: „Preserve log“), damit das Fehlverhalten nachvollzogen werden kann (s. Abbildung 4). Diese Funktion ist ebenfalls in allen Browsern (IE erst ab einem Patch in Version 11) verfügbar.

Abbildung 4: Google Chrome – Entwicklertools

Tipps

Performance DeltaMaster Service

Wir haben in Projekten sehr gute Erfahrungen mit aktiviertem „Garbage-Collector“ gemacht. Tests mit über 300 gleichzeitig agierenden Nutzern auf einem DeltaMaster Service sowie einem Server mit 4 CPU-Kernen und 16GB RAM waren mit dieser Einstellung kein Problem und die Performance sehr gut. Insbesondere die Speicherverwaltung auf Mehrprozessorsystemen wird mit der Verwendung des „Garbage-Collectors“ optimiert. Wer sich für Details interessiert, kann sich die Quelle 4) näher ansehen.

Garbage-Collector in der DeltaMaster.service.exe.config aktivieren:

Timeouts

Soll eine Abmeldung vom DeltaMaster Web nicht bereits nach 15 Minuten erfolgen, dann müssen einige Einstellungen angepasst werden. Beispiel für einen Timeout nach 60 Minuten:
1) Web.config:

2) DeltaMaster.Service.exe.config

3) IIS Anwendungspool – Leerlauftimeout (Idle-Timeout): 60 Minuten (s. Abbildung 5)

Abbildung 5: IIS – Erweiterte Einstellungen Application Pool

Trotzdem kann es vorkommen, dass ein Timeout vor Ablauf der 60 Minuten auftritt.

Denn wenn noch weitere Server oder Dienste auf der „Strecke“ zwischen Browser-Anfrage und DeltaMaster Service „mitreden“, dann müssen auch dort die Timeouts angepasst werden. Beispielsweise bei einem Reverse-Proxy.

Load-Balancer

Soll ein Load-Balancer eingesetzt werden, dann ist eine gewisse Vorsicht geboten. In den Projekten war bei einem Einsatz eines Load-Balancers die Mehrzahl der Fehler auf den Load-Balancer zurückzuführen.

Ein Load-Balancer muss zwingend „Session Stickiness“ gewährleisten. Das bedeutet, dass eine einmal hergestellte Session zwischen Client und Server immer die gleiche Route, also über die gleichen Server, gehen muss. Ein anderer Server würde die Session nicht kennen und somit einen Fehler werfen. Diese Fehlermeldungen können mitunter sehr irreführend sein. DeltaMaster erfordert zwingend, dass eine Session vom gleichen Service bearbeitet wird.

Quellen

1) https://github.com/NLog/NLog/wiki/Configuration-file#log-levels
2) https://de.wikipedia.org/wiki/HTTP-Statuscode
3) https://blogs.msdn.microsoft.com/benjaminperkins/2012/01/02/enable-and-activate-failed-request-tracing-rules/
4) https://docs.microsoft.com/de-de/dotnet/standard/garbage-collection/fundamentals