Besser zentral: Professionelles Logging

Inhaltsverzeichnis

Logging hilft über alle Phasen von der Entwicklung bis in den Betrieb bei der Identifikation und Rückverfolgung von Fehlern; und auch für das Monitoring lässt es sich verwenden. Noch besser ist ein zentrales Logging: Es bringt Daten- und Kontrollflüsse über mehrere Schichten, Knoten und Systemkomponenten hinweg in einen Zusammenhang und eine homogene Struktur. Damit steht es wider die üblichen verstreuten Log-Dateien und für mehr Professionalität.

Logging beschreibt laut deutscher Wikipedia "generell das (automatische) Speichern von Prozessen oder Datenänderungen [...] in Logdateien". Diese eng gefasste Definition ist exemplarisch und verrät viel über dieses stiefmütterlich behandelte Thema.

Dabei schauen sich Entwickler täglich Logs an, und es ist gute Praxis, Anwendungssysteme von der Implementierung bis in den Abnahmetest über Logs kritisch zu betrachten. Mit der Übertragung der Verantwortung an den Produktivbetrieb passiert oft etwas Bemerkenswertes. Plötzlich werden Logs nicht mehr ohne Verdachtsmoment geprüft. Operatoren wissen möglicherweise noch nicht einmal, ob Logs überhaupt geschrieben wurden und wo sie liegen. Sofern die Operatoren nicht Teil eines DevOps-Teams waren, haben sie vermutlich nicht von den Entwicklern gelernt, was in den Log-Dateien steht und wie sie zu lesen sind. Die Entwickler wiederum haben womöglich nie geprüft, ob in den Logs auch die benötigten Informationen zu finden sind.

Melden Nutzer Probleme im Produktionssystem, sind Logs häufig das einzige Mittel, um Fehler nachzuvollziehen und ihren Ursachen auf den Grund zu gehen. Am Anfang der Analyse steht der Zugriff auf die Logs. Falls der Systemadministrator mit ihnen jedoch nicht vertraut ist, kann er seiner Verantwortung nicht nachkommen. Er ist gezwungen, die Entwickler zu kontaktieren, die eigentlich Second- oder Third-Level-Support leisten sollen. Die Entwickler haben (hoffentlich) keinen Zugriff auf die Produktionssysteme. Aus diesem Grund muss der Administrator sich führen lassen und Log-Datei für Log-Datei einsammeln. Schließlich stellt er noch die Frage, wie er die gesammelten Dateien verschlüsselt an die Entwickler senden kann.

Liegen die Dateien endlich lokal vor, kann die Analyse beginnen. Zum Data Mining in den Log-Dateien gehört, ihre Einträge in einen zeitlichen Zusammenhang zu bringen. In der Regel interessiert sich der Leser der Logs nicht für alle Einträge, sondern nur für bestimmte, zum Beispiel die einer Komponente, eines Nutzers oder eines Request. Er muss diese Einträge herausarbeiten, wobei das Finden, Korrelieren und Filtern schwierig ist, wenn Log-Einträge aus einfachen Textdateien mit Kommandozeilen-Werkzeugen gelesen werden.

Als Herausforderung kommt hinzu, dass viele Anwendungssysteme eine Mehrschichtenarchitektur aufweisen und jede Schicht dabei ein eigenes Log erstellt. Zur Nachverfolgung des Daten- und Kontrollflusses durch die Schichten sind Einträge aus verschiedenen Log-Dateien zunächst in die richtige zeitliche Abfolge zu bringen. Ein typisches Beispiel sind hier die Anfragen von Clients, deren Abarbeitung auf dem Server weitergeht, sodass sich ein Request-Response-Zyklus in den Logs von Client und Server niederschlägt.

Gängige Log-Bibliotheken lassen die Log-Einträge aller Komponenten üblicherweise in einer Log-Datei pro Anwendungsinstanz auflaufen. Bei horizontaler Skalierung des Anwendungssystems über Lastverteilung multipliziert sich so der Aufwand zur Bereitstellung und Analyse mit der Anzahl der Instanzen.