Optimierung der Leistungsfähigkeit eines Elastic Stacks

1. Einleitung

Ein Elastic Stack ist eine einfache, weit verbreitete Open-Source Lösung, um Software zu überwachen oder fachliche Daten nutzbar zu machen. Die Konfiguration dieses Stacks ist dabei essentiell, da der Betrieb ansonsten langsam, instabil und ressourcenintensiv werden kann. Um Kosten und Leistung in einem akzeptablen Bereich zu halten, muss der Elastic Stack optimiert werden. Dieser Blogeintrag gibt Einblicke in die verschiedenen Optimierungsmöglichkeiten.

2. Elastic Stack

Der Elastic Stack ist ein Oberbegriff für die Softwaremodule Beats, Elasticsearch, Logstash und Kibana [2]. Es handelt sich dabei um eine Open Source Lösung um Daten zu empfangen, speichern, transformieren, suchen und visualisieren. Dieser Artikel richtet seinen Fokus auf die Technologien Elasticsearch und Kibana. Elasticsearch ist eine NoSQL Datenbank um Daten effizient zu speichern und zu durchsuchen. Es ist das zentrale Element des Elastic Stacks welches die Daten speichert und sie effizient bereitstellt. Kibana ermöglicht die Visualisierung der gewonnenen Daten in Dashboards, sowie die Suche, das Filtern und das direkte Anzeigen von Daten.

3. Index und Index Pattern

Der Index beschreibt die Datenrepräsentation in Kibana. Das Index Pattern beschreibt, wie ankommende Daten auf den Index abgebildet werden. Er ist eines der zentralen Elemente, um die Anwendung anzupassen. Die Leistung der Anwendung wird direkt von der Konfiguration des Index beeinflusst. Zwei typische Probleme und deren Lösung werden im Folgenden beschrieben.

3.1. Scripted Fields

Scripted Fields sind eine einfache Möglichkeit, um passendere Daten in Kibana zu verwenden. Dazu werden neue Felder aus bestehenden Daten in Echtzeit berechnet, wenn diese aus Elasticsearch in Kibana eingelesen werden. Leider muss dies für jede Nachricht separat durchgeführt werden. Bei komplizierten Berechnungen oder großen Datenmengen kann die Bereitstellung der Daten in Kibana erheblich verzögert werden. Für komplexe Berechnungen oder Berechnungen mit vielen Variablen sollte es daher vermieden werden. Es verzögert die Prozesskette und kann auch zu Lag führen. Kritische Logs könnten dadurch in einer Warteschlange feststecken und würden dem Nutzer nicht bereitstehen. Es ist daher sinnvoller die benötigten Metriken direkt in der Anwendung zu berechnen und so an Elasticsearch zu senden. Der Index muss die Daten dann nur noch auf das Zielformat abbilden und keine Berechnungen ausführen. Dadurch wird er deutlich schneller.

3.2. Getrennte Indizes

Bei der Verwendung von Zeitreihendaten ist es hilfreich unterschiedliche Zeiträume in getrennten Indizes zu speichern. Meistens werden nur Daten in kleinen Zeiträumen durchsucht. Es handelt sich dabei oft um die neuesten Daten. Kleine, zeitbasierte Indizes beschleunigen daher den Suchprozess, da nur wenige, kleine Dokumente statt einem großen Dokument, welches alle Daten enthält, durchsucht werden müssen. Durch kleine Indizes erhält man außerdem die Möglichkeit, ältere Daten problemlos zu löschen, indem man die älteren Indizes löscht. Dadurch befinden sich weniger ungenutzte Daten in Kibana was auch zu einer besseren Performance und niedrigeren Kosten führt. Um sich automatisch ändernde Indizes einzuführen kann die Rollover API verwendet werden oder ein Datum kann zum Index hinzugefügt werden, welches den Index basierend auf dem Datumsformat ändert. Im folgenden Beispiel wird gezeigt, wie ein zeitbasierter Index über REST angelegt werden kann.

In diesem Beispiel wird der Zeitstempel aus dem Feld “receptionTimestamp” als Datum zum Index mit dem Namen “index” hinzugefügt. Dadurch wird in diesem Fall jeden Tag ein neuer Index erzeugt (z.B. index-2021-05-01), weil sich der Indexname basierend auf diesem REST Aufruf ändert.

Es ist außerdem empfehlenswert verschiedene Indizes für verschiedene Daten zu verwenden, um die Last besser zu verteilen und verschiedene Anwendungsfälle voneinander zu trennen.

4. Datenaufbereitung

Für jede Anwendung ist es wichtig, dass der Cluster richtig aufgesetzt wird. Es ist jedoch mindestens genauso wichtig die Daten richtig aufzubereiten. Dadurch können etwaige Probleme frühzeitig und außerhalb des Elastic Stacks schon behoben werden. Kosten und Speicherplatz können dadurch gespart werden und die Performance wird verbessert.

4.1. Batching

Es kann lange dauern, bis große Datenmengen indiziert sind. Wenn eine Anwendung große Mengen an Daten sendet, die eventuell sehr kritisch sind, werden diese deutlich schneller verarbeitet, wenn sie als Batch gesendet werden. Im Vergleich zu nicht gebatchten Daten entfällt hier viel Overhead.

4.2. Filter

Man sollte nur die Daten von der Anwendung an Elasticsearch senden, die dort auch tatsächlich benötigt werden, um Analysen durchzuführen. Alles Weitere sollte in der Anwendung bereits gefiltert werden. Dadurch wird der Index in Kibana deutlich kleiner, es wird weniger Speicherplatz benötigt und Elasticsearch muss weniger Daten verarbeiten. Außerdem führen zu viele Filterkriterien oder sehr lange Logs in Kibana schnell zu einem Überfluss an Informationen. Dadurch wird es erschwert, schnell die richtigen Daten zu finden.

5. Cluster Anpassungen

Die genaue Anpassung der Parameter eines Elastic Search Clusters kann die Leistung signifikant beeinflussen. Diese Parameter unterscheiden sich deutlich je nach Anwendungsfall und müssen so konfiguriert werden, dass die richtige Balance zwischen Leistung und Kosten gefunden wird.

5.1. Speicherplatz

Ein einfacher, aber wichtiger Parameter. Es muss sichergestellt werden, dass immer genügend Speicherplatz vorhanden ist. Es sollte ein Alarm eingerichtet werden, der rechtzeitig informiert, wenn der Speicherplatz knapp wird. Das Hochskalieren des Clusters dauert sehr lange. Falls es nicht rechtzeitig gestartet wird kann der Speicher volllaufen und es können für Stunden keine neuen Daten verarbeitet werden.

5.2. JVM Memory Pressure

Elasticsearch ist eine Java basierte Anwendung [3]. Es nutzt daher die Java Virtual Machine (JVM). Falls im Vergleich zur Cluster Größe zu viele Anfragen oder zu große Nachrichten ankommen, kann der Arbeitsspeicher knapp werden. Wenn nicht genügend Arbeitsspeicher vorhanden ist kann der Garbage Collector, der nicht mehr benötigte Daten sonst entfernt, nicht mehr korrekt arbeiten. Dadurch erhöht sich der sogenannte Memory Pressure und erreicht im schlimmsten Fall 100% Auslastung. Dadurch hört das ganze Cluster auf weitere Anfragen zu verarbeiten, um einen OutOfMemoryError zu verhindern. Eine intensive Garbage Collection wird dann im Hintergrund durchgeführt. Während dieser Zeit ist die Anwendung nicht mehr erreichbar. Um solche Probleme zu vermeiden sollte dem Cluster immer ausreichend Arbeitsspeicher zur Verfügung stehen. Ein schlankeres Index Pattern mit weniger Scripted Fields und die Vermeidung von komplexen Anfragen über lange Suchzeiträume vermeiden ebenso dieses Problem.

5.3. Heiß-Warm-Kalt Architektur

Anwendungsdaten verbrauchen schnell große Mengen an Speicherplatz. Um diese Daten schnell erreichen zu können müssen sie auf SSDs gespeichert werden. Wenn die Kapazitäten nicht bereits vorhanden sind, müssen dafür Server gebucht werden oder die Anwendung in der Cloud muss entsprechend vergrößert werden, was teuer werden kann. Die neuesten Daten sind meistens sehr wichtig für nachfolgende Analysen. Im Laufe der Zeit verlieren sie jedoch schnell an Relevanz. Nach einigen Tagen ist es unwahrscheinlich, dass die Daten noch häufig benötigt werden. Um hohe Kosten zu vermeiden können die Daten in verschiedene Verfügbarkeitsklassen aufgeteilt werden und auf unterschiedlichen Servern gespeichert werden. Normalerweise unterscheidet man hier zwischen heißen, warmen und kalten Knoten. Heiße Knoten haben eine sehr hohe Verfügbarkeit und werden am häufigsten aufgerufen. Sie verfügen über viel CPU und Arbeitsspeicher und nutzen einen kleinen, aber sehr schnellen Speicher. Warme Knoten werden nicht ganz so häufig aufgerufen. Sie verfügen über weniger Ressourcen, haben aber immer noch einen schnellen SSD Speicher. Kalte Knoten werden selten aufgerufen und benötigen daher geringe Ressourcen. Sie erhalten eine große aber deutlich langsamere HDD. Ältere Daten können dann auf den kalten Knoten gespeichert werden, um Hardwarekosten zu sparen. Im Regelfall benötigt man viele heiße Knoten für schnelle Performance und wenige kalte Knoten, um ältere Daten gelegentlich aufzurufen. Elasticsearch kann ein Rollover durchführen, um automatisch Daten nach einem bestimmten Zeitrahmen zwischen den Knoten zu verschieben und dadurch große Kosteneinsparungen mit sich bringen. Die folgende Grafik veranschaulicht das Konzept. Sie zeigt das Verhältnis zwischen der Anzahl an Knoten (Größe der Rechtecke) und die Menge an gespeicherten Daten.

6. Zusammenfassung

Dieser Blogeintrag hat gezeigt, wie man bessere Ergebnisse mit dem Elastic Stack erhält, indem man die Daten richtig vorbereitet, die Indizes verbessert und die Infrastruktur auf die Bedürfnisse der Anwendung anpasst. Gängige Herangehensweisen für die Optimierung eines solchen Stacks wurden vorgestellt. Dadurch wird die Leistung des Stacks verbessert, Probleme werden vermieden, die Nutzer sind zufriedener und Kosten werden eingespart.