© DrHitch/Shutterstock.com
Logging

1 Auswirkungen moderner Architekturansätze auf den Betrieb von Anwendungen


Reactive Programming, Microservices, Message-oriented Middleware und andere moderne Architekturansätze fordern von Entwicklern heutzutage bei der Auswahl ihrer Tools mehr Weitblick, mehr (Ein-)Blick in die Produktion und deren Anforderungen, als noch vor einigen Jahren. Alle diese Ansätze bringen üblicherweise die Möglichkeit einer besseren Verteilung der gesamten Anwendung mit sich. Dies hat aber beträchtliche Auswirkungen auf den Betrieb von Anwendungen dieser Art.

Innerhalb dieses Kapitels wollen wir die hierdurch entstehenden Anforderungen an Entwickler, als auch an die eingesetzten Tools selbst genauer unter die Lupe nehmen. Zum Ende des Kapitels versuchen wir uns an einer möglichst objektiven Bewertung der Werkzeuge im jeweiligen Einsatzszenario.

Da aber viele miteinander interagierende Tools vorgestellt werden, müssen wir uns auf eine Beschreibung und eine Bewertung beschränken und wollen das Zusammenspiel und die Funktionsweise beschreiben (Abb. 1.1). Für konkretere Einblicke in die Tools wollen wir gern auf speziellere Beiträge verweisen, vielleicht können wir ja die Neugier wecken. Einige Leser werden nun denken „Warte, dafür haben wir doch DevOps, was interessiert mich das“, aber warten wir es ab. Und wer hier den nächsten Vergleich schwergewichtiger Application Server und deren Leistungsvermögen erwartet, den müssen wir leider enttäuschen.

arrasz_abb1.png

Abbildung 1.1: Reise durch die Entstehung (das Development), über die Stabilisierungsphase der Preproduktion, bis hin zur Produktion

Beginnen wir nun im ersten Kapitel mit den Werkzeugen zum Logging aus Anwendungen, der Konfiguration von Logging sowie der Kumulierung von Logs über verschiedene Dienste, (Micro-)Services oder auch Server hinweg. Warum beginnen wir ausgerechnet mit Logging?

Logging ist wohl derjenige Teil der Implementierung, bei dem am offensichtlichsten eine Verbindung zwischen Entwicklern und Betreibern besteht. Üblicherweise versuchen Teamplaner dies heute mit dem Buzzword „DevOps“ zu erschlagen. DevOps in Cross-functional Teams sollen die Verbindung zwischen Entwicklung und Betrieb stabilisieren. Sie sollen den Gedanken des Betriebs und der betriebsvorbereitenden Maßnahmen, auf die wir später detailliert eingehen werden, in die Entwicklerteams tragen, dort mitarbeiten und Betriebsgrundlagen manifestieren.

Leider ist es aber heutzutage immer noch so, dass ausgerechnet die uralte Disziplin des Loggings den Betrieb oft am wenigsten unterstützt. Folgende Probleme haben wir in den letzten Jahren immer und immer wieder aus verschiedensten Softwareteams gehört:

  • Keine aussagekräftigen Inhalte in den Logs
  • Viel zu groß, man findet die Information im Grundrauschen nicht
  • Nicht sortierbar
  • Nicht effizient indizierbar und somit
  • Nicht effizient durchsuchbar
  • Nicht oder kaum statistisch verwertbar

Aus unserer Erfahrung heraus ist es daher besonders wichtig, dass bereits in der Phase des Ramp-ups einer Anwendung abgeklärt ist, welche Anforderungen der Betrieb an Anwendungslogfiles stellt. Schließlich müssen gerade die Kollegen vom Betrieb wissen, was die Anwendung so anstellt. Wichtiger ist aber, dass Logfiles schnell und effizient auswertbar sind. Welche Voraussetzungen Entwickler hierfür einhalten müssen, werden wir im weiteren Verlauf des Kapitels noch detaillierter besprechen.

Aber was ist eigentlich an klassischem Logging so schwer? Das machen wir Entwickler doch schon von Beginn des Softwarezeitalters an? Nun ja, fragt man dies einen althergebrachten Systemadministrator, wird er wohl so oder so ähnlich antworten: „Gute Logfiles konnten Entwickler noch nie. WIR sorgen immer im Nachgang dafür, dass die Logfiles wenigstens ein klein wenig Aussage und so etwas wie einen vollständigen Timestamp haben. Oft bekommen wir Anwendungsarchive über den Zaun geworfen, in denen das Logging noch auf Debug-Level steht. 3 Megabyte Logeinträge pro Sekunde sind keine Seltenheit.

Was also macht ein gutes, produktionsunterstützendes Anwendung-Logging aus?

  • Loglevel im Betrieb anpassbar (darauf gehen wir an anderer Stelle detaillierter ein).
  • Trennung technischer Logeinträge (z. B. gefangene Exceptions) von fachlichen Informationen (z. B. fehlende Möglichkeit, ein Dokument zu drucken, da noch Informationen im Dokument fehlen). Weiterhin sollte...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang