
Die Elastic Platform ist schon lange ein anerkanntes Analysesystem für Suchanwendungsfälle und maschinengenerierte Daten. Im Mittelpunkt von Analytics steht die Verarbeitung von Ingestionsdaten. Dabei spielt die optimale Strukturierung der Daten beim Indexieren in Elasticsearch eine wichtige Rolle. Kibana legt Elasticsearch-Aggregationen offen und verwendet sie zur Erstellung von interaktiven Dashboards, Visualisierungen und Warnmeldungen.
Aber da die Elastic Platform immer häufiger als Plattform für Search, Security, Observability und allgemeine Analytics eingesetzt wird, benötigen Analysten die Möglichkeit, Daten nach der Ingestion so umzuwandeln, dass sie ihren Untersuchungsanforderungen entsprechen, und Einblicke aus den zugrunde liegenden Elasticsearch-Indexdaten zu gewinnen. Dazu bedarf es eines prägnanten, integrierten und effizienten Workflows, der durch reichhaltige und aussagekräftige Abfragen ermöglicht wird, bei denen Suche, Filter, Aggregation und Transformation über einen einzigen Abfrageausdruck mit minimalem Kontextwechsel der Benutzeroberfläche erfolgen.
Zur Bewältigung dieser Herausforderungen entwickelt das Elastic-Team derzeit die Elasticsearch Query Language (ESQL). ESQL bietet Elastic-Benutzern eine flexible, leistungsstarke und zuverlässige Abfragesprache für Daten. ESQL ermöglicht außerdem eine hervorragende Abfrage-UX mit Verarbeitungsfunktionen nach der Ingestion, die die Analytics- und Datenverarbeitungsfunktionen von Elasticsearch grundlegend verändern und erweitern.
Neue Rechenarchitektur für Abfragen und Aggregationen
ESQL ist mehr als nur eine Sprache. Es handelt sich dabei um eine wichtige Investition in neue Rechenfunktionen innerhalb von Elasticsearch. Zur Erfüllung der Funktions- und Leistungsanforderungen von ESQL muss eine völlig neue Rechenarchitektur aufgebaut werden. Die Such-, Aggregations- und Transformationsfunktionen von ESQL werden direkt in Elasticsearch selbst ausgeführt. Abfrageausdrücke werden zur Ausführung nicht in QueryDSL transpiliert. Stattdessen haben wir native Unterstützung für ESQL-Funktionen in Elasticsearch integriert.
ESQL bietet verteilte Rechenfunktionen für Nutzer in unterschiedlichen Rollen und mit unterschiedlichen Kenntnissen. Dank dieser Rechenfunktionen vereinfacht ESQL die Workflows von Nutzern in mehrfacher Hinsicht.
ESQL ermöglicht Folgendes:
- Nutzung einer herausragenden Abfrage-UX: ESQL-Abfrageausdrücke unterstützen komplexe Analytics und Datenverarbeitung. Sie lassen sich leicht erlernen, lesen und austauschen.
- Nutzung der Filter-, Aggregations- und Transformationsfunktionen von Elasticsearch mit Unterabfragen und Lookups, ermöglicht durch neue Rechen- und Datenverarbeitungsfunktionen von Elasticsearch.
- Nutzung von ESQL in Kibana in Discover, Kibana Lens und Elastic Solutions für reibungslose Workflows. Sie können ESQL-Abfragen visualisieren, sie über Dashboards oder als Abfragen an Teams weitergeben und Abfragen zur Erstellung benutzerdefinierter Warnmeldungen verwenden.

So können Sie ESQL nutzen
ESQL ist eine Abfragesprache mit Pipes, bei der Nutzer Elasticsearch-Daten über eine Abfolge von Befehlen verarbeiten, die durch Pipes voneinander getrennt sind. Die Ausgabe eines Befehls wird zur Eingabe für den nächsten, sodass eine logische Datenpipeline definiert wird. ESQL-Ausdrücke sind linear, logisch und leicht lesbar. Sie sind so simpel, dass sie von Analysten aller Kenntnisstufen verfasst, verwendet und verändert werden können. Ein einfaches Beispiel:
search index_name
| eval field_c = (field_a + field_b)
| sort field_c desc
Mit dem oben dargestellten Ausdruck werden alle Daten aus dem Index abgerufen, und für jeden Datensatz wird ein neues Feld C erstellt, das die Summe von Feld A und Feld B bildet. Anschließend werden die Ergebnisse nach Feld C sortiert.
Nutzung von ESQL für Security
ESQL eignet sich insbesondere für die Ad-hoc-Bedrohungssuche durch Sicherheitsanalysten. Beispielsweise kann ein Analyst zunächst die Protokolldaten abfragen, um die einzelnen Prozesse zu ermitteln, die von „powershell.exe“ generiert wurden, und diese nach der Zeichenfolge der Befehlszeilenargumente sortieren.
from winlog
| where host.os.family == ‘windows’
| where process.name == "powershell.exe"
| unique process.command_line
| sort len(process.command_lin) desc
| limit 3
host.os.family | process.name | process.command_line |
windows | powershell.exe | (get-acl \\smb_file\share).access | ft IdentityReference,FileSystemRights,AccessControlType,IsInherited,InheritanceFlags -auto |
windows | powershell.exe | Get-ADComputer -property * -filter { ipv4address -eq ‘172.16.0.3’} |
windows | powershell.exe | Get-ADGroupMember -identity Helpdesk |
Aus den Ergebnissen geht hervor, dass PowerShell zum Abrufen von Dateisysteminformationen und auch von Informationen über Active Directory verwendet wird. Dies kann entweder normales Systemverhalten sein oder aber auf bösartige Aktivitäten hinweisen.
Zur weiteren Untersuchung wird die Abfrage so geändert, dass sie nach Active Directory-spezifischen und dateisystembezogenen Befehlszeilenargumenten filtert. Dann werden die eindeutigen Werte von process.command_line gezählt und nach hostname gruppiert.
from winlog
| where host.os.family == ‘windows’
| where process.name == "powershell.exe"
| where process.command_line in (‘*get-acl*’, ‘*Get-AD*’)
| stats count(unique process.command_line) as cl_count by hostname
| sort cl_count desc
| limit 3
cl_count | hostname |
155 | host2 |
74 | host1 |
67 | host3 |
Aus den Ergebnissen geht hervor, dass Host 2 deutlich mehr Powershell-Prozesse aufweist, die datei- und AD-bezogene Befehlszeilenargumente aufrufen, als andere Hosts. Ein Analyst kann den ESQL-Abfrageausdruck weiter anpassen und ergänzen, um zu ermitteln, ob bei Host 2 eine bösartige Aktivität vorliegt. Diese Untersuchung führt letztlich zu einem Verständnis des Bedrohungsvektors, sodass Abhilfemaßnahmen ergriffen werden können und ermittelt werden kann, wie sich diese Bedrohung in Zukunft verhindert lässt.
Nutzung von ESQL für Search
Schlussendlich ist und bleibt Elasticsearch zur Suche gedacht. Daher unterstützt ESQL die Such-, Relevanz- und Rankingfunktionen, die schon lange Bestandteil von Elasticsearch sind. Mit ESQL lässt sich die volle Leistungsfähigkeit dieser Suchfunktionen auf unkomplizierte Weise nutzen.
Hier ein Beispiel für eine einfache Begriff-Aggregation, bei der wir Buckets mit den drei häufigsten Begriffen im Genrefeld sortiert nach der Anzahl der Dokumente erstellen möchten.
from music
| stats terms((genre), 3, doc_count, unwind)
| sort doc_count desc
doc_count | term |
6 | electronic |
3 | rock |
2 | jazz |
Bucketing-Aggregationen wie das Datumshistogramm werden ebenfalls unterstützt. In dieser Abfrage erstellen wir ein Histogramm aus dem Verkaufsindex mit Intervallen von 50 basierend auf dem Preisfeld.
from sales
| stats histogram(price, 50)
| sort bucket desc
doc_count | bucket |
3 | 200 |
2 | 150 |
0 | 100 |
1 | 50 |
1 | 0 |
Mit ESQL ist es außerdem ausgesprochen einfach, Daten auf eine Weise zu verarbeiten, die den heutigen Pipeline-Aggregationen ähnelt. Nehmen wir zum Beispiel an, Sie möchten die Ableitung einer Ableitung berechnen, und zwar in der einfachsten Form:
from sales
| eval (stats derivative(sales)) as fist_der
| eval (stats derivative(first_der)) as second_der
Nutzung von ESQL für Observability
Site Reliability Engineers (SREs) müssen riesige Mengen an Daten verarbeiten können. Sie sind dafür verantwortlich, anhand dieser Daten Systemausfälle und andere damit verbundene Probleme zu verhindern und zu beheben. Sie überwachen Tausende von Systemen, die wichtige Trace-, Protokoll- und Metrikdaten generieren. Mithilfe dieser Daten können SREs Probleme erkennen und Maßnahmen ergreifen, um System- oder Anwendungsausfälle künftig zu vermeiden. Für ein SRE ist daher die Fähigkeit, das Systemverhalten mit einem kombinierten Verständnis aus mehreren Datensätzen zu analysieren, unerlässlich.
Die Observability ingestierter Daten ist grundsätzlich unvorhersehbar. Mit ESQL können SREs Daten korrelieren und umformen, um tiefere Einblicke in das System- und Anwendungsverhalten zu erhalten. Dadurch erhalten sie mehr Möglichkeiten für Post-hoc-Analysen, nachdem ein Problem festgestellt wurde. Diese wertvollen Erkenntnisse werden direkt dazu genutzt, ähnliche Probleme in Zukunft zu vermeiden.
Der folgende Abschnitt über Datenverarbeitung enthält Beispiele für die Observability.
Eine völlig neue Art der Datenverarbeitung mit den Rechenfunktionen von Elasticsearch
ESQL-Ausdrücke sind bei der Gewinnung von Erkenntnissen aus Indexdaten sowohl flexibel als auch leistungsstark. Die Hauptarbeit hinter diesen Ausdrücken geschieht jedoch in Elasticsearch selbst. Wir haben eine neue Compute Engine entwickelt, um die Datenverarbeitungsfunktionen von ESQL zu unterstützen. Vor allem haben wir die Verarbeitung von Daten nach der Ingestion, Zwischenstände von Daten, Lookup-Funktionen und Unterabfragen verbessert.
ESQL beruht vollständig auf den neuen Rechen- und Verarbeitungsfunktionen in Elasticsearch. Bei ESQL finden Interpreting und Ausführung nicht mittels Transpilierung statt. Vielmehr werden ESQL-Ausdrücke komplett und direkt in Elasticsearch verarbeitet.
Verarbeitung nach der Ingestion
Dank der Integration von ESQL in Kibana können Sie schnell und einfach auf die gängigsten und nützlichsten Aggregationen und Projektionen zugreifen. Angenommen, Sie arbeiten mit einem Index von Metrikdaten. Ein Analyst will womöglich Verhältniswerte berechnen oder Aggregationen der ingestierten Daten vornehmen. Mit ESQL lassen sich diese problemlos aus einem zugrundeliegenden Index ableiten.
from network_flow
| stats count(*) filter (where transport == ‘udp’) as udp_count
| stats count(*) filter (where transport == ‘tcp’) as tcp_count
| eval total_transport_events = udp_count + tcp_count
| eval udp_per_total = udp_count / total_transport_events
ESQL ermöglicht die schnelle und einfache Aggregation und Transformation zugrundeliegender Indizes und eröffnet Analysten somit neue Einblicke bei der Strukturierung und Analyse der Daten. Auf diese Weise wird die Dateneingabe vereinfacht, da Analysten mit ESQL neue Strukturen und Einblicke aus einer breiten Palette zugrundeliegender Indizes ableiten können.
Datenpipelines und Zwischenstände von Daten
Ein weiterer wichtiger Bestandteil der Unterstützung von ESQL-Ausdrücken ist der Umgang mit Zwischenständen von Daten. Die Verarbeitung und Änderung von Daten im Verlauf der verschiedenen Pipelinephasen sind wesentliche Aspekte der Möglichkeiten von ESQL.
In der folgenden Abfrage durchsuchen wir den Metrikenindex nach den fünf Hostnamen mit der höchsten CPU-Spitzenauslastung.
from metrics
| stats max(system.process.cpu.total.pct) as max_cpu by hostname
| where max_cpu > .800 and hostname == '*web*'
| sort max_cpu desc
| limit 5
Für jede Phase dieser Datenpipeline wird eine Tabelle ausgegeben. Mit dem ersten Befehl from metrics werden alle Indexdaten abgerufen. Diese Tabelle wird dann nach system.process.cpu.total.pct aggregiert und nach hostnamegruppiert, wodurch eine eindeutige Tabelle entsteht. Diese tabellarischen Ergebnisse werden dann so gefiltert und sortiert, dass die gewünschte Ausgabe entsteht.
max_cpu | hostname |
.989 | 1webapache |
.978 | 1websftp |
.964 | nfsweb |
.955 | 2webredis |
.943 | web_staging_primary |
Diese Ausgabe kann dann als Grundlage für Visualisierungen oder Alerts verwendet werden.
Lookups und Unterabfragen
Mit ESQL werden außerdem Lookup- und Unterabfragefunktionen in Elasticsearch eingeführt.
ESQL kann in einem separaten Lookup-Index Werte nachschlagen. Auf diese Weise werden die Ergebnisse bei der Abfrage am häufigsten angereichert. Lookups ähneln SQL Left Joins darin, dass sie Felder aus einem fremden Index unter Verwendung eines bestimmten Schlüssels zurückgeben.
Ein Lookup-Index enthält beispielsweise Informationen über Systembenutzer, die durch einen eindeutigen Schlüssel identifiziert werden. Mit einem ESQL-Ausdruck lassen sich Daten in diesen Indizes nachschlagen, sodass diese Fremddaten in den Ergebnissen zurückgegeben werden. Mit dieser Abfrage werden die Ergebnisse aus dem Index „access_logs“ mit Benutzerdaten aus dem Index „user_info_lookup“ angereichert. Konkret sollen die Felder für E-Mail und Status aus dem Lookup-Index zurückgegeben werden.
from access_logs where user != 'root'
| lookup user_info_lookup['email', 'state'] on userid
userid | [ … access_logs … ] | state | userid | |
3455 | … | bob | NY | 3455 |
Mithilfe von Unterabfragen lassen sich bestimmte Abfragen als Argumente in andere Abfragen einbetten. Beispiel: Ein SRE möchte eine Aggregation als Argument in einer Abfrage desselben Index verwenden. Hier berechnet ein SRE anhand der Gesamtzahl der Anmeldungen den Prozentsatz der Anmeldungen eines bestimmten Benutzers.
from user_login where userid = 1234
| eval stats count(*) as 1234_logins
| eval total_logins = [from logs where userid = *| stats count(*) as total_logins]
| eval round((1234_logins / total_logins), 2) as 1234_pct
Mithilfe von Lookups und Unterabfragen können Analysten und SREs Elasticsearch in vollem Umfang nutzen und so äußerst reichhaltige Datenstrukturen erzeugen und neue Einblicke in die Daten in Elasticsearch gewinnen.
ESQL verändert und verbessert die Interaktion mit Daten in der Elastic Search Platform grundlegend. ESQL erschließt den Wert Ihrer Daten mit leistungsstarken Funktionen zur schnellen Transformation und Zusammenführung großer Datensätze, zum Durchsuchen, Filtern und Verarbeiten riesiger Datenmengen und schließlich zur Reduzierung der Antwort- und Bearbeitungszeit. Wir sind gespannt darauf, wie Sie ESQL einsetzen werden!
Begleiten Sie uns auf dieser analytischen Reise
Sind Sie interessiert an ESQL, Transformationen und Joins und der Verwendung mehrstufiger Abfragen? Wir auch! Bleiben Sie über Neuigkeiten auf dem Laufenden, denn das Team von Elastic arbeitet weiter an der Entwicklung, Vorbereitung und Veröffentlichung dieser Funktionen.
Sie möchten diese Lösung vor allen anderen testen? Sie erreichen uns in den Diskussionsforen oder im Slack-Kanal unserer Elastic-Community. Wir freuen uns über Ihr Feedback – gestalten Sie unsere neue Abfragesprache, die Compute Engine und die abfragebasierten Ermittlungsabläufe mit.
Die Entscheidung über die Veröffentlichung der in diesem Blogpost beschriebenen Features und Funktionen oder deren Zeitpunkt liegt allein bei Elastic. Möglicherweise werden aktuell nicht verfügbare Features oder Funktionen nicht rechtzeitig oder gar nicht bereitgestellt.