Seite 2: Zentrales Logging

Inhaltsverzeichnis

Die einfache Antwort: zentrales Logging

Abhilfe für diese Probleme vermag ein zentrales Logging zu schaffen, das durchgängig alle Teile des Anwendungssystems oder – besser noch – die gesamte Anwendungslandschaft nutzen. Die Grundidee ist einfach: Alle Logs fließen an einer Stelle zusammen, werden dort so lange wie nötig gespeichert und lassen sich von den Administratoren, Entwicklern und gegebenenfalls weiteren Beteiligten gleichzeitig strukturiert analysieren. Damit das möglich ist, muss eine zentrale Logging-Software folgende Herausforderungen bewältigen:

• Zusammenstellung: Technische und fachliche Ereignisse werden aus allen Teilen des Anwendungssystems gesammelt, mit Lokalisierungsinformationen angereichert, in ein einheitliches Format gebracht und quasi sofort bereitgestellt. Das "Wegschreiben" der Logs darf nicht den regulären Anwendungsprozess blockieren und muss daher asynchron geschehen.
• Transport: Log-Ereignisse müssen sich auch dann zuverlässig, sicher, zeitnah und ohne Beeinträchtigung des eigentlichen Systems übertragen lassen, wenn sie in hoher Frequenz und mit vielen Daten erzeugt werden.
• Persistierung: Log-Daten sollen in der Regel sofort les- und suchbar sein. Sie können über die Zeit zu beachtlichen Volumina auflaufen, veralten jedoch nach einiger Zeit und sind dann zu löschen. Hinzu kommt, dass sich das Format von Log-Einträgen mit der Entwicklung der Anwendung ändern kann (z. B. neue Felder).
• Analyse: Neben der klassischen Fehleranalyse lassen sich Logs auch zur Analyse weiterer Aspekte verwenden (bspw. Service-Nutzung und Lastaufkommen). Abhängig davon schauen die Leser der Logs auf Einträge der Vergangenheit, der Gegenwart oder eine Kombination daraus. Eine grafische Benutzeroberfläche stellt Operatoren und Entwicklern Werkzeuge zum Suchen, Filtern und Korrelieren bereit.
• Alarmierung: Auf Basis definierbarer Regeln sollte ein zentrales Logging-System automatisch reagieren und zum Beispiel Benachrichtigungen an den Administrator versenden. Alarmereignisse lassen sich ergänzend oder integriert in einem Monitoring-System wie Nagios nutzen.
  

Zentrale Logging-Software lässt sich vor diesem Hintergrund in zwei Kategorien untergliedern: Cloud-basiert sowie selbstverwaltet. Die letzteren Techniken lassen sich weiter unterteilen. Hier existieren einige wenige integrierte Produkte, zum Beispiel Logfaces oder der ELK-Stack (Elasticsearch, Logstash, Kibana) von Elasticsearch.

Daneben gibt es Werkzeuge, die ein oder mehrere dieser Aufgabengebiete abdecken. Sie lassen sich zu vollwertigen zentralen Logging-Techniken kombinieren. Da sich viele Unternehmen strategisch für oder gegen die Nutzung von Cloud-Diensten aussprechen, erleichtert das die Auswahl einer geeigneten Software.

Für Anwendungssysteme in der (öffentlichen) Cloud ist die Geschichte schnell erzählt. Ein Logging auf die lokale Festplatte eines unbekannten Rechners ist wenig hilfreich. Das Bereitstellen eines eigenen Log-Servers in der Cloud widerspricht der Architekturentscheidung des eigentlichen Systems. Daher kann eine sinnige Entscheidung in einem solchen Szenario nur zugunsten einer Cloud-Logging-Technik fallen. Prominente Vertreter sind hier loggly, Papertrail oder logentries.

Für individuell entwickelte, unternehmenskritische Anwendungssysteme stellt sich die Lage oft anders dar. Sie werden überwiegend über eine eigene technische Infrastruktur betrieben. In einem solchen Umfeld bietet es sich an, eine wartungsarme selbstverwaltete Software einzusetzen. Es sei erwähnt, dass auch für diese Anwendungssysteme die Einbindung von Cloud-Techniken möglich ist. Die Lizenzkosten und die Abhängigkeit der Anwendung externer Services ist jedoch aufmerksam zu verfolgen.

Zur Verdeutlichung, wie selbst verwaltetes zentrales Logging in der Praxis eingesetzt und angebunden wird, betrachtet dieser Artikel beispielhaft das kommerzielle Produkt Logfaces. Es ist einfach zu konfigurieren, zu integrieren und schlicht aufgebaut. Der Hersteller dieses Tools bietet eine zeitlich begrenzte Probeversion ohne Registrierung an, die sich zum Ausprobieren der hier beschriebenen Konzepte eignet. Wem der Umfang von Logfaces genügt, kann für den Produktiveinsatz Lizenzen pro Installation oder pro Standort beziehen. Wer mehr will als einfaches Logging operativer Anwendungsdaten oder eine Open-Source-Software sucht, findet möglicherweise mit dem ELK-Stack eine passendes Angebot.

Zentrales Logging: Altbewährtes plus Vernetzung

Logfaces besteht aus drei Komponenten: Ein dedizierter Log-Server nimmt die Log-Ereignisse von den Anwendungskomponenten entgegen, eine Datenbank persistiert sie, und ein grafischer Client unterstützt beim Lesen, Suchen und Analysieren der Log-Einträge. Die folgende Abbildung zeigt anhand einer fiktiven 3-Schichten-Anwendung mit Lastverteilung, wie sich ein zentrales Logging implementieren ließe.

Im Beispielszenario greifen die Anwendungsclients über einen Load Balancer auf die Backend-Server zu. Hier liegt der rechenaufwendige Anwendungskern. Die Datenhaltung ist einfach, sodass die Backend-Server auf eine gemeinsame Datenbank zugreifen können. Darüber hinaus sind die Server zustandslos, und der Load Balancer kann pro Anfrage entscheiden, an welchen Backend-Server er einen Client verweist.

Im gelben Rechteck rechts unten ist der Log-Server abgebildet. Die grünen Linien markieren den Fluss der Log-Einträge. Sowohl die Client- als auch die Server-Komponenten der Anwendung senden ihre Log-Einträge an den Log-Server. In der Regel bildet die eingesetzte Log-Bibliothek die Schnittstelle zwischen den Anwendungsteilen und dem Log-Server. Meist findet sich hier log4j oder ein anderes Mitglied der log4x-Familie (z. B. log4net, slf4j), Logback oder NLog. Für die gängigsten Bibliotheken bietet Logfaces Ausgabe-Plug-ins an. Bei log4x werden diese in Form eines sogenannten Appender bereitgestellt. Die Plug-ins stellen jeweils sicher, dass die Ereignisse gepuffert und asynchron übertragen werden. Bricht die Verbindung zum Log-Server ab, versucht der Appender die erneute Übermittlung der Ereignisse und schreibt sie gegebenenfalls in eine lokale Datei.

Neben diesen Bibliotheken existiert eine Schnittstelle auf Basis des aus Unix bekannten Syslog-Protokolls. Sie lässt sich im Beispielszenario zur Anbindung der Datenbank sowie des Load Balancer verwenden. Im Ergebnis liegen alle Log-Einträge chronologisch sortiert an einem Ort: der Datenbank des Log-Servers.