Elastic Stack 6.6.0 veröffentlicht

6.6.0 ist da!

Diese Version bietet neue Features, die unter anderem die Verwaltung und Skalierung Ihres Clusters vereinfachen, das Indexieren und Abfragen von Geo-Shapes beschleunigen und die Speicherung der Daten effizienter gestalten. Zudem gibt es wichtige Verbesserungen bei Elasticsearch SQL, Machine Learning, Auditbeat und mehr.

Stellen Sie ein Cluster auf unserem Elasticsearch Service bereit oder laden Sie den Stack herunter und machen Sie sich selbst ein Bild von den neuesten Features.

Index-Lifecycle-Management mit umfangreichen Verwaltungsfunktionen für den Lebenszyklus von Daten

Benutzer mit Zeitreihen-Anwendungsfällen, wie Logging, Metriken und APM, speichern Daten in der Regel in zeitbasierten Indizes. Während der unterschiedlichen Phasen des Lebenszyklus dieser Daten lässt sich auf verschiedene Weise dafür sorgen, dass die Daten so kostengünstig wie möglich gespeichert werden. So könnte der Benutzer mit zunehmendem Indexalter die Zahl der Shards oder die der Kopien reduzieren möchten, die zur Speicherung des Index genutzt werden, oder er könnte die Daten auf Knoten verschieben wollen, die sich auf günstigerer Hardware befinden. Denkbar wäre auch, Indizes, die ein bestimmtes Alter überschritten haben, zu löschen. Bisher gab es nur begrenzte Möglichkeiten, Richtlinien zur Verwaltung des Indexlebens außerhalb des Clusters zu definieren (z. B. Curator oder benutzerdefinierte Automatisierungsskripts), und das, was es gab, war mit zusätzlichem Konfigurations- und Überwachungsaufwand verbunden. Mit dem neuen Feature „Index-Lifecycle-Management“ steht eine integrierte und optimierte Möglichkeit zur Verwaltung dieser Daten zur Verfügung, die die Umsetzung von Best Practices vereinfacht.

Das Index-Lifecycle-Management teilt den Lebenszyklus eines Index in vier Phasen auf: „heiß“, „warm“, „kalt“ und „löschen“. Sie können eine Index-Lifecycle-Richtlinie definieren, die folgende Möglichkeiten bietet:

– Einrichtung einer Primär-Shard pro heißem Knoten für einen höheren Durchsatz beim Indexieren – Ersetzen des heißen Index durch einen neuen, leeren Index, sobald der bestehende Index „voll“ ist oder nachdem ein bestimmter Zeitraum vergangen ist – Verlagern des alten Index auf warme Knoten, wo die Shard-Zahl auf eins reduziert und eine Zusammenführung zu einem einzelnen Segment erzwungen werden kann, um den benötigten Speicherplatz und die Abfragezeiten zu optimieren – Anschließendes Verlagern des Index auf kalte Knoten zur Reduzierung der Speicherkosten

Zukünftig werden Sie auch die Möglichkeit haben, den Index „einzufrieren“. Eingefrorene Indizes benötigen weniger Speicherplatz, lassen sich aber nicht ganz so schnell abfragen. Und wenn Sie den Index nicht mehr benötigen, können Sie ihn löschen lassen.

Mit Index-Lifecycle-Management wird all dies automatisch für Sie abgewickelt.

Besseres Massenspeicher-Hauptspeicher-Verhältnis durch Einfrieren von Indizes

Elasticsearch ist in hohem Maße für schnelle und effiziente Suchen optimiert. Früher hat jeder offene (also durchsuchbare) Index ein wenig Hauptspeicherplatz belegt, um sicherzustellen, dass jede Abfrage, in der nach diesem Index gesucht wird, schnell ausgeführt werden kann. Je größer und zahlreicher die Indizes auf einem bestimmten Knoten wurden, desto mehr Hauptspeicher war nötig, damit die Indizes offen bleiben konnten. Das heißt im Endeffekt, dass ein Knoten mit einer einzelnen JVM nur eine bestimmte Menge an Massenspeicherplatz adressieren kann. Für die meisten Benutzer und Anwendungsfälle ist das kein Problem. Es gibt jedoch Fälle, z. B. bei der gesetzlich vorgeschriebenen Langzeitarchivierung von Daten über mehrere Jahre, in denen die Daten online bleiben und durchsuchbar gehalten werden sollen, ohne dass sie ab einem bestimmten Alter noch besonders schnell bereitstehen müssen.

Eingefrorene Indizes ermöglichen ein wesentlich höheres Massenspeicher-Heap-Verhältnis, wenn auch auf Kosten der Suchgeschwindigkeit. Ein eingefrorener Index belegt keinen Heap-Platz, sodass auf einem einzelnen Knoten ohne viel Aufwand problemlos Tausende von Indizes verwaltet werden können. Wird bei einer Suche nach Indizes gesucht, die eingefroren sind, öffnet die Abfrage jeden Index nacheinander, durchsucht ihn und schließt ihn anschließend wieder. Anders als geschlossene Indizes werden eingefrorene Indizes repliziert. Mit der Option, Indizes einzufrieren, steht eine weitere Möglichkeit zur individuellen Optimierung Ihrer Cluster-Kosten und Performance-Anforderungen zur Verfügung.

Schnellere und kleinere Geo-Shapes auf Bkd-Baum-Basis

Die Bkd-Baum-Datenstruktur hat einmal mehr ihre Leistungsfähigkeit unter Beweis gestellt. Schon die Einführung von Geo-Punkten auf Bkd-Basis in Version 5.0 hat bei der Abfrage von Geo-Punkten zu deutlichen Verbesserungen hinsichtlich Massen- und Hauptspeichernutzung sowie Performance geführt. In Version 6.6.0 erweitern wir die Vorteile der Bkd-Basis auf Geo-Shapes. Damit haben wir so etwas wie einen Suche-Hattrick geschafft: Das Indexieren wird schneller, es wird weniger Massenspeicherplatz benötigt, und der Hauptspeicher wird auch weniger beansprucht.

Elasticsearch SQL mit Unterstützung für Datumshistogramme

Elasticsearch SQL schreitet mit zahlreichen Verbesserungen bei Zeitreihen weiter in Richtung allgemeine Verfügbarkeit voran – einschließlich nativer Unterstützung für Datumshistogramme mit SQL-Syntax. Dies sind gute Neuigkeiten für alle Benutzer von Elasticsearch SQL, aber wir denken, dass die Unterstützung für Datenhistogramme am ehesten den Benutzern von Canvas zugutekommen wird, vereinfacht sie doch das Erstellen von Zeitreihendiagrammen in Kibana.

Machine Learning jetzt mit Anmerkungsfunktion

Wer ein potenzielles System- oder Sicherheitsproblem untersucht, möchte in der Regel seine Erkenntnisse und Fortschritte – Angaben zur Ursache, zu den Lösungsschritten usw. – irgendwo festhalten. Die Machine-Learning-Benutzeroberfläche bietet jetzt die Möglichkeit, Anmerkungen hinzuzufügen, die von allen Benutzern eingesehen werden können. Das erleichtert die Zusammenarbeit mit anderen und gibt Ihnen die Chance, die durchgeführten Maßnahmen zu protokollieren, ohne Kibana dazu verlassen zu müssen.

Neue Agent-Metriken in Elastic APM

APM führt mit Version 6.6 Agent-Metriken ein. Die neueste Version unserer Agents meldet jetzt automatisch Metriken für das System, die CPU (auf Prozessebene) und den Hauptspeicher sowie Traces und Fehler.

Anders gesagt: Das verteilte Tracing ist nun allgemein verfügbar und alle Agents sind OpenTracing-konform. Im Übrigen ist es in der APM-Benutzeroberfläche problemlos möglich, von APM zur entsprechenden Logging- oder Infrastructure-Ansicht zu springen, und auch der Java-Agent trumpft mit zwei tollen neuen Features auf. Näheres dazu erfahren Sie im Blog-Post zu APM.

Zusätzlich zu den genannten Änderungen freut es uns, bekanntgeben zu können, dass Elastic APM jetzt auch für Deployments auf Elasticsearch Service (siehe Blog) und Elastic Cloud Enterprise (siehe Blog) bereitsteht.

Und das ist noch nicht alles …

Zu all dem, was wir bereits beschrieben haben, kommen noch etliche neue Features und Verbesserungen in Beats, Logstash und Kibana hinzu.

In Auditbeat gibt es ein neues Systemmodul zur Erfassung verschiedener sicherheitsrelevanter Informationen aus dem System. Dazu gehören Daten über das Betriebssystem, die Prozesse, die Sockets und die Benutzer auf einem bestimmten Host. Wenn Sie mehr über das Auditbeat-Systemmodul erfahren möchten, lesen Sie unseren Auditbeat-Blog-Post.

Machine-Learning enthält ab sofort standardmäßig Machine-Learning-Jobs für Auditbeat-Daten und ermöglicht es Benutzern so, ohne weiteren Konfigurationsaufwand häufige Anomalien in ihren Audit-Daten zu erkennen.

Filebeat bietet einen neuen NetFlow-Input, mit dessen Hilfe Sie diese Netflow- und IPFIX-Datensätze über UDP empfangen können. Er unterstützt NetFlow v1, v5, v6, v7, v8, v9 und IPFIX.

Benutzer von Beats Central Management haben jetzt die Möglichkeit, Metricbeat und Filebeat so zu konfigurieren, dass Änderungen an einzelnen Teilen der Konfiguration zurückgewiesen werden. Dies erlaubt die effektive Durchsetzung der Vorgaben dafür, was von der Remote-Konfiguration geändert werden darf, auf der Ebene des gerade ausgeführten Beats. Zur Verbesserung der Sicherheit werden Änderungen an den Abschnitten zum Konsolen-Output und zum Datei-Output jetzt standardmäßig blockiert.

Was Logstash anbetrifft, ist die in 6.1 als Beta eingeführte performantere Java-Ausführungsmaschine jetzt allgemein verfügbar.

Kibana bietet auf vielfachen Wunsch ab sofort die Möglichkeit, mehreren Elasticsearch-Knoten eine einzelne Kibana-Instanz zuzuordnen. Damit dürften die bisherigen Schwierigkeiten beseitigt sein, die mit der Existenz nur eines „Point of Failure“ in der Verbindung zwischen Kibana und Elasticsearch verbunden waren. Von der Visualisierungsfront ist zu vermelden, dass Kibana-Dashboards jetzt als PNG-Dateien exportiert werden können. Alles Wichtige zu diesen und anderen Änderungen finden Sie in „Versions-Highlights in Kibana 6.6“.

Jetzt ausprobieren

Stellen Sie ein Cluster auf unserem Elasticsearch Service bereit oder laden Sie den Stack herunter und machen Sie sich selbst ein Bild von den neuesten Features.