Viele Firmen stellen zurzeit ihre monolithischen Architekturen auf Microservice-Architekturen um. Diese steigern die Agilität und Skalierbarkeit von Anwendungen erheblich, erschweren jedoch gleichzeitig das Log-Management. Grund dafür ist, dass Logs nun nicht mehr zentral anfallen, sondern über zahlreiche unabhängige Services verteilt sind. Daher ist es sinnvoll, selbst bei kleineren Anwendungen auf moderne Lösungen wie den Elastic Stack zu setzen. Der Elastic Stack bietet eine leistungsfähige Log-Management-Pipeline, die Logs zentral erfasst, strukturiert und analysierbar macht.
Im Folgenden werden die vier zentralen Herausforderungen beschrieben, mit denen wir bei der Umsetzung des Elastic Stack konfrontiert wurden. Am Ende dieses Blogbeitrags findet sich zudem eine Präsentation, die den Elastic Stack und seine Funktionsweise im Detail erläutert.
Container-Logs ohne IDs: Autodiscover im Elastic Stack
Beim Einsatz des Elastic Stack ist das Einlesen von Logs aus Docker Containern eine besondere Herausforderung. Docker speichert Standardausgabe-Logs (stdout, stderr) auf dem Hostsystem in Verzeichnissen, die nach der Container-ID benannt sind. Da ein Log Shipper diese ID benötigt, um auf die Logdateien zuzugreifen, und sich die IDs bei jedem Neustart eines Containers ändern, wäre eine feste Hinterlegung in der Konfiguration unflexibel. Stattdessen haben wir den Log Shipper so konfiguriert, dass er mittels Autodiscover Containernamen automatisch in die jeweiligen Container-IDs auflöst. Auf diese Weise muss der Log Shipper nur die Containernamen in der Konfiguration enthalten und bezieht die IDs dynamisch zur Laufzeit.
Logs direkt im Elastic Stack Format erzeugen statt aufwendigem Parsing
Eine weitere Herausforderung ist die einheitliche Formatierung der Logs. Da der Elastic Stack mit bestimmten Datentypen arbeitet, müssen Logs entweder bereits bei der Erzeugung korrekt formatiert oder später in der Pipeline geparst werden. Das nachträgliche Parsen von String-Logs ist jedoch aufwendig. Daher bietet es sich an, die Logs direkt im gewünschten Format zu generieren. Elastic stellt hierfür sogar ein fertiges Format bereit, das sich in verschiedenen Programmiersprachen direkt einbinden und verwenden lässt.
Zentraler Exception-Handler für konsistentes ELK Logging in TypeScript
Eine zusätzliche Herausforderung beim Einsatz des Elastic-Formats in TypeScript besteht darin, dass die meisten Logger dieses Format zwar unterstützen, es jedoch standardmäßig nur auf explizit im Code geloggte Exceptions anwenden. Automatisch auftretende Fehler, wie beispielsweise nicht abgefangene Exceptions oder Promise-Rejections, werden hingegen nicht im Elastic-Format ausgegeben. Das führt in der Log-Pipeline zu Problemen beim Parsing dieser Einträge. Um dies zu vermeiden, muss sichergestellt werden, dass alle automatisch generierten Fehler von einem zentralen Exception Handler abgefangen und anschließend im gewünschten Format geloggt werden.
Microservice Herkunft in Logs: Exceptions eindeutig zuordnen
Ein weiteres Hindernis ist die eindeutige Zuordnung von Exceptions zu ihren Ursprungssystemen. Das Elastic-Format stellt diese Information nicht automatisch bereit, sodass in der späteren Pipeline nicht ohne Weiteres nachvollzogen werden kann, welcher Microservice eine bestimmte Exception ausgelöst hat. Diese Angabe ist jedoch essenziell. Sie schafft nicht nur Transparenz über die Herkunft des Fehlers, sondern ermöglicht auch Auswertungen darüber, welche Services welche Anzahl und Art von Exceptions erzeugen. Die Lösung ist vergleichsweise unkompliziert: Sämtliche Logs werden um ein Feld ergänzt, das den Namen des jeweiligen Microservices enthält. Diese Erweiterung lässt sich in den meisten Logger-Konfigurationen mit geringem Aufwand implementieren.
Im Nachfolgenden ist die Präsentation zum Thema „Elastic Stack“ zu finden. Falls Sie mit uns in Kontakt treten möchten, besuchen Sie uns gerne unter www.PowMio.com oder klicken Sie oben auf den Reiter PowMio.
