{"id":272,"date":"2025-08-14T09:20:26","date_gmt":"2025-08-14T09:20:26","guid":{"rendered":"http:\/\/localhost:8083\/?p=272"},"modified":"2026-02-24T11:25:59","modified_gmt":"2026-02-24T11:25:59","slug":"elastic-stack-herausforderungen-und-unsere-losungsansatze","status":"publish","type":"post","link":"https:\/\/powmio-experts.com\/blogs\/272\/","title":{"rendered":"Elastic Stack – Herausforderungen und unsere L\u00f6sungsans\u00e4tze"},"content":{"rendered":"\n

<\/p>\n\n\n\n

\"Logo
Elastic, Elasticsearch, Logstash, Kibana und das ELK-Logo sind Marken von Elasticsearch B.V., registriert in den USA und anderen L\u00e4ndern. Dieses Bild wird ausschlie\u00dflich zu illustrativen Zwecken im Kontext dieses Artikels verwendet.<\/figcaption><\/figure>\n\n\n\n
\n\n\n\n

Viele Firmen stellen zurzeit ihre monolithischen Architekturen auf Microservice-Architekturen um. Diese steigern die Agilit\u00e4t und Skalierbarkeit von Anwendungen erheblich, erschweren jedoch gleichzeitig das Log-Management. Grund daf\u00fcr ist, dass Logs nun nicht mehr zentral anfallen, sondern \u00fcber zahlreiche unabh\u00e4ngige Services verteilt sind. Daher ist es sinnvoll, selbst bei kleineren Anwendungen auf moderne L\u00f6sungen wie den Elastic Stack zu setzen. Der Elastic Stack bietet eine leistungsf\u00e4hige Log-Management-Pipeline, die Logs zentral erfasst, strukturiert und analysierbar macht.<\/p>\n\n\n\n

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\u00e4sentation, die den Elastic Stack und seine Funktionsweise im Detail erl\u00e4utert.<\/p>\n\n\n\n

Container-Logs ohne IDs: Autodiscover im Elastic Stack<\/h3>\n\n\n\n

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\u00f6tigt, um auf die Logdateien zuzugreifen, und sich die IDs bei jedem Neustart eines Containers \u00e4ndern, w\u00e4re 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\u00f6st. Auf diese Weise muss der Log Shipper nur die Containernamen in der Konfiguration enthalten und bezieht die IDs dynamisch zur Laufzeit.<\/p>\n\n\n\n

Logs direkt im Elastic Stack Format erzeugen statt aufwendigem Parsing<\/h3>\n\n\n\n

Eine weitere Herausforderung ist die einheitliche Formatierung der Logs. Da der Elastic Stack mit bestimmten Datentypen arbeitet, m\u00fcssen Logs entweder bereits bei der Erzeugung korrekt formatiert oder sp\u00e4ter in der Pipeline geparst werden. Das nachtr\u00e4gliche Parsen von String-Logs ist jedoch aufwendig. Daher bietet es sich an, die Logs direkt im gew\u00fcnschten Format zu generieren. Elastic stellt hierf\u00fcr sogar ein fertiges Format bereit, das sich in verschiedenen Programmiersprachen direkt einbinden und verwenden l\u00e4sst.<\/p>\n\n\n\n

Zentraler Exception-Handler f\u00fcr konsistentes ELK Logging in TypeScript<\/h3>\n\n\n\n

Eine zus\u00e4tzliche Herausforderung beim Einsatz des Elastic-Formats in TypeScript besteht darin, dass die meisten Logger dieses Format zwar unterst\u00fctzen, es jedoch standardm\u00e4\u00dfig 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\u00fchrt in der Log-Pipeline zu Problemen beim Parsing dieser Eintr\u00e4ge. Um dies zu vermeiden, muss sichergestellt werden, dass alle automatisch generierten Fehler von einem zentralen Exception Handler abgefangen und anschlie\u00dfend im gew\u00fcnschten Format geloggt werden.<\/p>\n\n\n\n

Microservice Herkunft in Logs: Exceptions eindeutig zuordnen<\/h3>\n\n\n\n

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\u00e4teren Pipeline nicht ohne Weiteres nachvollzogen werden kann, welcher Microservice eine bestimmte Exception ausgel\u00f6st hat. Diese Angabe ist jedoch essenziell. Sie schafft nicht nur Transparenz \u00fcber die Herkunft des Fehlers, sondern erm\u00f6glicht auch Auswertungen dar\u00fcber, welche Services welche Anzahl und Art von Exceptions erzeugen. Die L\u00f6sung ist vergleichsweise unkompliziert: S\u00e4mtliche Logs werden um ein Feld erg\u00e4nzt, das den Namen des jeweiligen Microservices enth\u00e4lt. Diese Erweiterung l\u00e4sst sich in den meisten Logger-Konfigurationen mit geringem Aufwand implementieren.<\/p>\n\n\n\n

Im Nachfolgenden ist die Pr\u00e4sentation zum Thema \u201eElastic Stack\u201c zu finden. Falls Sie mit uns in Kontakt treten m\u00f6chten, besuchen Sie uns gerne unter www.PowMio.com<\/a> oder klicken Sie oben auf den Reiter PowMio.<\/p>\n\n\n\n