- Thomas Pollinger
- 03.10.2016
- DE
Gewusst wie! "Anbindung an das Logging (Log4Net) des Management Server (RedDot CMS)"
log4j ist ein Framework zum Loggen von Anwendungsmeldungen in Java. Innerhalb vieler Open-Source- und kommerzieller Softwareprodukte hat es sich über die Jahre zu einem De-facto-Standard entwickelt. log4j gilt als Vorreiter für andere Logging-Frameworks, auch in anderen Programmiersprachen.
Das Projekt wurde von Ceki Gülcü 1996 während seiner Arbeit am IBM-Entwicklungslabor in Zürich gegründet. Heute ist es ein Teil des Logging-Projekts der Apache Software Foundation und steht unter der Apache-Lizenz 2.0. Es entstand zu einer Zeit, als es in den Java-Standardbibliotheken noch keine Logging-Mechanismen gab. Heutzutage ist es durch seine Ausgereiftheit und Konfigurierbarkeit für viele Softwareentwickler das Log-System der ersten Wahl.
Die Ausstrahlung der log4j-Konzepte auf andere Programmiersprachen bzw. Plattformen ist so groß, dass es mittlerweile etliche Adaptionen gibt. Einige werden vom Apache Logging Projekt selbst gepflegt. Zum Beispiel:
- log4cxx für C++ mit zu Log4J kompatiblen Konfigurationsdateien
- log4Net für .Net
- log4php für PHP
...
Quelle: Wikipedia
Zurück zum OpenText Web Site Management Server und dessen log4Net Implementierung. Diese folgt dem Logging-Projekt der Apache Software Foundation bis auf das Logging-Pattern, welche SAP’s Logging Framework entspricht.
- Warum sollte man denn log4Net in den Erweiterungen des Management Servers verwenden?
- Welche Vorteile hat man dadruch?
- Was sollte beachtet werden, damit die integration einfach funktioniert?
Der Management-Server hat ein sehr ausgefeiltes Logging integriert, welches man über die Datei "OpenText\WS\MS\Configuration\logging.config" steuern kann.
Dort kann man die s.g. Log-Level anpassen und auch, sofern gewünscht, das Logging an andere Ziele zur Auswertung senden lassen (Windows EventLog etc.). Dazu kann man mehr im Logging-Projekt Manual der Apache Software Foundation finden.
Warum sollte man denn log4Net in den Erweiterungen des Management Servers verwenden?
Der Management Server hat einen integrierten Log-Filer-Viewer, welcher sich einfach im Server Manager aufrufen lässt:
Dieser integrierte Log-File-Viewer eignet sich perfekt um auch die s.g. Eigenentwicklungen bzw. des Log-Files zu überwachen. Denn der Funktionsumfang ist vollkommen ausreichend für Plug-Ins oder Web-Applikationen, welche z.B. mit dem Management Server (RedDot) zusammenarbeiten.
Welche Vorteile hat man dadruch?
Die Vorteile bei der Nutzung des im Management-Server integrierten Log-File-Viewers sind einfach erläutert:
- dieser ist "Out-of-the-Box" (OotB) dabei
- es ist ein zentraler Punkt zur Kontrolle von Log-Files
- man hat die Möglichkeit, durch öffnen von mehreren Log-Files-Viewer Fenstern, Zusammenhänge schnell zu erkennen
- man kann diese Log-Files, bei möglichen Fehlverhalten in der Software, direkt an den OpenText Customer Service schicken, wenn die Erweiterungen zusammen mit dem Management Server z.B. Fehlverhalten auslösen
Bei einer korrekten Integraton von weiteren Log-Files an eine zentrale Stelle, kann man im täglichen Betrieb seine Arbeitsabläufe schnell optimieren. ;)
Tipp: Um mehrere Log-File-Viewer zeitgleich und dauerhaft offen zu haben, gibt es eine "undokumentierte" Funktion im Server Manager:
- das gewünschte Log-File im Verzeichnisbaum des Server Managers auswählen
- im Aktionsmenü unterhalb des letzten Befehls auf die "weiße Fläche" klicken
- nun [SHIFT] gedrückt halten und zeitgleich den Befehl "Log-Datei einsehen" anklicken
Wenn man diese Reihenfolge für jedes Log-File einhält, kann man mehrere Fenster zeitgleich offen halten. Sogar ein Wechsel in andere Module wie z.B. SmartTree oder SmartEdit schließt nun diese Log-Viewer Fenster nicht mehr automatisch. ;)
Was sollte beachtet werden, damit die integration einfach funktioniert?
Es gibt nicht wirklich viele Dinge, welche man zur Nutzung des integrierten Log-File-Viewers, beachten sollte. Die folgenden Punkte sind auf jedenfall hilfreich, wenn man diese direkt von Anfang an beachtet:
- die Zugriffsrechtes für das Verzeichnis \OpenText\WS\MS\ASP\Log\{Verzeichnisname} müssen korrekt sein
- das Logging-Pattern des SAP’s Logging Framework muss zwingend beachtet werden (z.B. Log-Level: WARN → WARNING oder Timestamp: Anzahl der Millisekunden seit 1.1.1970 0:00 in UTC)
- das Logging-Pattern bzw. die Wertezuordnung für den Log-File-Viewer des Management Servers muss zwingend beachtet werden
- man sollte sich dann im klaren sein: Was, Warum und Wie soll in einem Log-File dokumentiert werden? (Log-Level: ALL → TRACE → DEBUG → INFO → WARN → ERROR → FATAL → OFF)
Alles andere folgt dem Logging-Projekt Manual der Apache Software Foundation. ;)
Zuordnung der Werte innerhalb der Logging-Pattern für den Log-File-Viewer
Die Zuordnung ist recht einfach. Jedoch muss man beachten, dass man das Pattern nicht ändern darf. Da sonst der Log-File-Viewer bei der Darstellung der Inhalte durcheinander kommt. Entweder wird nicht alles angezeigt oder einfach nur ein Fehler ausgegeben.
Daher gibt es hier eine visuelle Zuordnung zwischen Pattern und dem Log-File-Viewer:
Wie man sehr gut erkennen kann, ist die Zuordnung zwischen dem Pattern und der Anzeige sehr einfach. ;)
Hier mal ein Beispiel einer log4net.config für eine Powershell-Integration:
Hier noch ein Beispiel, wie die passende Anzeige im Management Server Log-File-Viewer dann aussieht:
Knoff-Hoff: Jetzt gibt es eine Sache in der log4Net.config Datei, welche nicht ganz unwichtig ist:
Eine Standard log4Net Integration, schreibt für den Log-Level "Warnung" ein "WARN" in das Log-File. Da der Log-File-Viewer wegen dem SAP-Standard jedoch ein "WARNING" statt einem "WARN" erwartet, ist ein kleiner Workaround nötig.
Dieser "{SAPFIX}" dient nur dazu, dass der von log4Net (OotB) geschriebe Log-Level "WARN" für das SAP-Format "WARNING" ergänzt wird. Diese Log4Net-Variable wird, innerhalb der Powershell-Funktion, nur für den Log-Level "WARN" gesetzt und enthält den ergänzenden Wert "ING". ;)
Fazit
Egal in welcher marktüblichen Programmiersprache man entwickelt, Log4Net erleichtert die Überwachung von z.B. Erweiterungen des Management Servers (RedDot) ungemein. Solange man sich an die Log-Pattern des Log-File-Viewers hält. Kann man sehr einfach und schnell eine Integration an den Log-File-Viewer des Management Server vornehmen.
Somit erhält man eine kostengünstige Überwachung. Mit der man in der Lage ist für den Fall einer Störung bzw. einer Fehlersuche, sich schnell und einfach einen ersten Überblick zu verschaffen.
Ebenso erleichtert es die Kommunikation mit dem OpenText Customer Service, wenn z.B. ein Plug-In eine Funktion im Management Server aufruft und es zu einem Fehlverhalten kommt. Damit ist man dann in der Lage, sein eigenes Log-File zusammen mit dem wsms.log zur Verfügung stellen.
Der Aufwand, welcher sehr überschaubar ist, lohnt sich auf jeden Fall und man betreibt aktiv eine Fehlerkultur.
Weitere ergänzende Informationen dazu findet man auch in der Online-Hilfe unter:
- Handbuch: Server Manager / Kapitel: 3.5 – Log files
- Handbuch: Server Manager / Kapitel: 3.5.1 – Viewing log files
- Handbuch: Server Manager / Kapitel: 7.1.8 – Viewing log files
- Handbuch: Server Manager / Kapitel: 10.2.1 – Logging Options
- und in den reweiligen Release Notes von 11.2.x und 16.0.x
Über den Autor:
... ist Senior Site Reliability Engineer bei der Vodafone GmbH in Düsseldorf. Seit dem Jahr 2007 betreut er zusammen mit seinen Kollegen die OpenText- (vormals RedDot-) Plattform Web Site Management für die deutsche Konzernzentrale.
Er entwickelt Erweiterungen in Form von Plug-Ins und PowerShell Skripten. Seit den Anfängen in 2001 (RedDot CMS 4.0) kennt er sich speziell mit der Arbeitweise und den Funktionen des Management Server aus.