Zentrales Logging in Verteilten Systemen mit ELK

Die Architektur von Software Services hat sich in den letzten Jahren oder Jahrzehnten von Monolithen hin zu Microservices entwickelt. Mircoservices sind leicht skalierbar und können dadurch sehr flexibel eingesetzt werden. Für den Betrieb in Produktion eröffnet diese Entwicklung sehr viele Möglichkeiten um die Services der benötigten Last anzupassen.

Ein wichtiger Bestandteil von Systemen in Produktion ist das Monitoring insbesondere das Finden von Fehlern in Logfiles. Während das Durchsuchen der Logfiles in einem Single-System-Service, in denen es nur ein oder eventuell mehrere chronologisch aufgeteilte Logfiles gibt, noch recht leicht von der Hand geht, sieht die Sache bei verteilen Microservices ganz anders aus. Ein eingehender Request wird von einem Service zum nächsten weitergeleitet, so kann sich die Fehlersuche schon als schwierig gestalten und sehr viel Zeit verschlingen.

Die Lösung für dieses Problem liegt in einem zentralen Logging, d.h. die Logfiles werden an einer zentralen Stelle gesammelt und verarbeitet. Es gibt unzählige Frameworks die genau dieses Problem adressieren. Splunk, Loggy, Graylog oder der ELK-Stack sind nur einige Beispiele. Wir wollen uns hier den ELK-Stack genauer ansehen, da dieser sich immer größerer Beliebtheit erfreut und die Technologien kostenlos genutzt werden können.

Der ELK-Stack Grundaufbau

ELK steht für die Technologien auf denen das Logging Framework basiert: Elasticsearch, Logstash und Kibana. Logstash sammelt die Logfiles von verschiedensten Quellen, kann diese Filtern, verändern und an mehrere Datenbanken weitergeben. Eine Möglichkeit ist das Logstash, das Logeinträge via TCP oder UDP entgegennimmt. Im ELK-Stack werden die Log Einträge von Logstash an Elasticsearch weitergegeben und gespeichert. Bei Elasticsearch handelt es sich um eine Document-Based-NoSql Datenbank.

Elasticsearch basiert auf Apache Lucene und ist extrem performant, wenn es um das Suchen von Texten geht und ist daher perfekt für Logfileeinträge geeignet. Kibana ist eine grafische Benutzeroberfläche, welche die Logeinträge aus Elasticsearch ausliest und darstellt. Die aggregierten Logdaten können graphisch mit Diagrammen visualisiert und zu einem Dashboard zusammengefasst werden

Abb. 1 ELK-Stack Grundaufbau: jedes Service sendet die Logeinträge per TCP oder UDP an Logstash

Der ELK Stack kann aber auch etwas anders aufgebaut werden. Logstash kann nicht nur auf TCP oder UPD Aufrufe reagieren und die Logeinträge auf diese Weise entgegennehmen, sondern auch direkt aus einem Logfile lesen. In diesem Setup muss Logstash bei jedem Service installiert werden und als Input werden ein oder mehrere Files definiert. Logstash überwacht die angegebenen Logfiles, reagiert auf Änderungen in dem File und schickt neue Einträge an Elasticsearch.

Ein Logstash per Service

Dieses Setup hat den Nachteil, dass Logstash auf jedem Hostsystem deployed werden muss, es bringt aber auch einige Vorteile mit sich. Wenn die Netzwerkverbindung abricht sind die Logeinträge nicht verloren, sondern weiterhin auf dem Service gespeichert. Um dies im ersten Setup zu erreichen müssen die Logeinträge zusätzlich noch in ein File geschrieben werden. Weiters wird die Applikation entlastet, weil diese sich nur mehr in ein File loggen muss und sich nicht mehr um das Senden der Logeinträge kümmern muss. Zu guter Letzt können auch applikationsabhängige Logfiles in das zentrale Logging eingespielt werden, wie etwa IIS oder Systemlogs des Betriebssystems.

Abb. 2 Ein Logstash per Service welches die Logfile direkt überwacht und Änderungen an Elasticsearch sendet

Beats statt Logstash

Nachdem Logstash doch eher schwergewichtig ist wurde die Beats-Familie entwickelt. Filebeat, Metricbeat oder Heartbeat sind nur ein paar Mitglieder dieser Familie. Metricbeat zum Beispiel sammelt Metriken über das Hostsystem oder Heartbeat kann feststellen, ob eine Applikation auf dem Hostsystem noch einwandfrei funktioniert. Filebeat macht das gleiche wie Logstash mit Inputtype: File, ist dabei aber deutlich leichtgewichtiger als Logstash und benötigt weniger Ressourcen auf dem Hostsystem. Dafür stehen Filebeat nicht so viele Filter wie Logstash zur Verfügung. Ein übliches Setup wäre deshalb das Filebeat an eine Zentrale Logstash Installation sendet und dort die Filterung vorgenommen wird.

Abb. 3 Beats statt Logstash, Filebeats kann auch verwendet werden um die Logeinträge aus dem Logfile zu lesen und an Logstash zu senden

Jedes dieser Setups hat gewisse Vor- und Nachteile. Welches eingesetzt werden soll ist je nach Anwendungsfall zu entscheiden.

The post Zentrales Logging in Verteilten Systemen mit ELK appeared first on ANECON Blog.