Für neue Nutzer ist dies der schnellste Weg, eine hochwertige Vektorsuche in Betrieb zu nehmen. Wenn Sie Elasticsearch bereits nutzen, bietet das neue Angebot eine Vektorsuche auf der Plattform, auf der Ihre Daten bereits gespeichert sind – ganz ohne die Einführung eines neuen Systems. Die Elasticsearch-Vektordatenbank unterstützt verschiedene Szenarien – vom Grounding eines großen Sprachmodells (LLM) über die Bereitstellung von Abruf- und Speicherfunktionen für KI-Agenten bis hin zur Bereitstellung von Hunderten Milliarden Vektoren. Starten Sie ein neues Projekt und legen Sie in wenigen Minuten los.

Eine Engine für alle Vektor-Anwendungsfälle

Die Elasticsearch-Vektordatenbank wurde für alle entwickelt, die Anwendungen mit Vektoren erstellen:

• RAG: Rufen Sie mit dem Abruf dichter und dünnbesetzter Vektoren den passenden Kontext für Ihr LLM ab oder entscheiden Sie sich für die Hybridsuche, die sowohl den Vektor- als auch den lexikalischen Abruf kombiniert. Die Qualität Ihrer Generierung verbessert sich mit der Qualität Ihres Abrufs.

• KI-Agenten: Geben Sie Agenten schnellen, gefilterten Zugriff auf Dokumente und Konversationsgedächtnis – mit den niedrigen Latenzen, die mehrstufige Agentenschleifen erfordern.

• Semantische Suche: Gleichen Sie nach Bedeutung statt nach Schlagwörtern ab – mit einem einzigen Feldtyp und ganz ohne Pipeline-Code.

• Empfehlungen und Ähnlichkeit: Finden Sie die nächsten Nachbarn über Produkte, Bilder oder beliebige andere Inhalte hinweg – und das in großem Maßstab.

Alles, was Ihre Vektor-Workloads benötigen – standardmäßig optimiert

Eine vektorbasierte Anwendung zu erstellen bedeutet, mehrere separate Komponenten miteinander zu verbinden: Einbettungsmodelle einzurichten und zu hosten, Ihre Dokumente damit zu indexieren, die Vektoren effizient zu speichern, das Einbettungsmodell auf jede Abfrage anzuwenden, mit dem Vektorspeicher abzugleichen und schließlich die Dokumente hinter den Treffern abzurufen. Die Elasticsearch-Vektordatenbank übernimmt all das für Sie – ohne zusätzliche Konfiguration oder Einrichtung.

Vektorindexierung mit vectordb_document-Indexmodus

Der vectordb_document-Indexmodus, eine neue Indexkonfiguration, die speziell für vektororientierte Workloads entwickelt wurde, ist standardmäßig aktiviert, sodass Sie die Einstellungen erhalten, die Experten wählen würden. Folgendes wird dadurch aktiviert:

• Standardmäßig bfloat16: Vektoren werden mit der halben Größe von float32 bei vernachlässigbaren Auswirkungen auf den Recall gespeichert, wodurch sich Ihr Festplattenbedarf um etwa die Hälfte reduziert, noch bevor Quantisierung überhaupt ins Spiel kommt.

• Quellvektoren sind ausgeschlossen: In Elasticsearch befinden sich Ihre Einbettungen bereits in den Indexstrukturen, die für die Suche verwendet werden; eine zweite Rohkopie in _source würde lediglich den Speicher aufblähen und das Abrufen von Ergebnissen verlangsamen. Wir schließen das Duplikat aus, damit Antworten schneller zurückgegeben werden und Sie weniger speichern müssen.

• Die richtigen Dateien werden vorab in den Cache geladen: Die Datenstrukturen, auf die Vektorabfragen zuerst zugreifen, werden vorab in den Arbeitsspeicher geladen, sodass Ihre erste (und auch noch Ihre tausendste) Abfrage blitzschnell ist.

• Parallele Zusammenführung: Durch die Zusammenführung werden Segmente zu besser organisierten Vektorstrukturen konsolidiert, was sowohl den Recall als auch die Latenz verbessert, und durch die Multithread-Ausführung dieser Zusammenführungen erreichen Sie Ihr Ziel schneller.

Vektorspeicherung, Komprimierung und Auto-Tuning

• Ihre Vektoren werden automatisch komprimiert. Better Binary Quantization (BBQ) reduziert den Vektorspeicherbedarf um das bis zu 32-Fache bei Beibehaltung der Trefferquote, und DiskBBQ verringert den Speicherbedarf für Workloads in großem Maßstab noch weiter. 

• Entscheiden Sie sich für die automatische Kalibrierung, die die Quantisierung jedes Segments auf Ihre Daten abstimmt und bei jeder Zusammenführung neu abstimmt, wenn sich die Daten verändern. Bei Tests mit 18 Datensätzen verbesserten sich die Abfragen pro Sekunde (QPS) durchschnittlich um 16,7 %, wobei sich der Recall bei den meisten von ihnen erhöhte.

Einbettungen mit vollständig verwalteter GPU-Inferenz

• Generieren Sie Einbettungen mit nativen Embedding- und Reranking-Modellen von Jina AI oder binden Sie Drittanbieter-Modelle ein – alles auf verwalteten GPUs über den Elastic Inference Service (EIS) und ganz ohne eigene Modellserver. Oder hosten Sie selbst, wenn Sie eine eigene Lösung bevorzugen.

• Der Feldtyp semantic_text verarbeitet Chunking und Einbettung sowie Abfragen automatisch – der einfachste Weg zur semantischen Suche auf dem Markt. 

Hybridsuche und gefilterte Vektorsuche

• Die Hybridsuche ist integriert und kombiniert Volltext- und Vektor-Retrieval in einer einzigen Abfrage. Kombinieren Sie die Ergebnisse mit Reciprocal Rank Fusion (RRF) oder einem beliebigen anderen Mischmechanismus nach Ihren Wünschen. Die Vektorsuche ist meist der Teil der Hybridsuche, der sich am schwersten optimal konfigurieren lässt. Mit der Elasticsearch-Vektordatenbank haben Sie alles im Griff und Ihr gesamter Hybrid-Stack wird besser. 

• Mit der gefilterten Vektorsuche wenden Sie Metadatenfilter als Teil des Vektorabrufs selbst an und nicht erst im Nachhinein, was den Recall beeinträchtigt.

Enterprise von Anfang an

Sie erhalten außerdem rollenbasierte Zugriffssteuerung (RBAC), Audit Logging und die Compliance-Zertifizierungen, die reinen Vektordatenbanken in der Regel fehlen.

Erschwinglich in großem Maßstab und vorhersehbar

Die Elasticsearch-Vektordatenbank ist so konzipiert, dass sie auch bei wachsendem Bedarf erschwinglich bleibt: Durch BBQ- und DiskBBQ-Komprimierung, die das Speicherwachstum linear und den Arbeitsspeicherbedarf gering hält, führt die Skalierung auf Hunderte von Milliarden Vektoren nicht zu explodierenden Kosten. Und was Sie tatsächlich bezahlen, basiert auf Zahlen, die Sie bereits kennen: der Zahl der von Ihnen gespeicherten Daten, der Zahl der indexierten Daten und der von Ihnen benötigten Suchkapazität. Schätzen Sie Ihre Dokumentenzahl und die Vektordimensionen sowie Ihre Abfragelast ab, und Sie können bereits vor der Erstellung des Projekts ermitteln, was Sie zahlen werden. Außerdem können Sie Ihre Rechnung am Monatsende Zeile für Zeile nachvollziehen. Es gibt keine undurchsichtigen Recheneinheiten und keine überraschenden Gebühren für Hintergrundoperationen.

Erste Schritte mit der Elasticsearch-Vektordatenbank

Ein Serverless-Vektordatenbank-Projekt erstellen

Erstellen Sie ein neues serverloses Vektordatenbank-Projekt in Elastic Cloud. Leiten Sie Ihre Daten an den Endpoint weiter, und schon können Sie mit dem Indexieren beginnen.

Einen Index mit semantic_text erstellen

Der Vektorindex-Modus übernimmt die Vektorkonfiguration. Die Verwendung von semantic_text bedeutet, dass die Einrichtung von Einbettungen und Chunking sowie die Indexeinrichtung bei verwalteter GPU-Inferenz für Sie verwaltet werden, ohne dass Sie eine Einbettungs-Pipeline erstellen müssen.

Dokumente ingestieren

Indexieren Sie Text, und die Einbettungen werden für Sie generiert.

Eine semantische Suchabfrage ausführen

Fragen Sie dasselbe semantische Feld ab, das Sie gerade erstellt haben:

Und Sie erhalten Ergebnisse zurück:

Die semantische Suche ist erst der Anfang. Führen Sie rein textbasierte Abfragen aus oder kombinieren Sie beides zu hybriden Abfragen. Sie können für die volle Kontrolle sogar Ihre eigenen Vektorabfragen erstellen. Folgen Sie dem Schnellstart für die semantische Suche in der Dokumentation zur vollständigen Anleitung.

Was kommt als Nächstes für die Vektorsuche in Elasticsearch?

Wir arbeiten bereits an den nächsten Verbesserungen:

• Bessere Multi-Mandanten-Verwaltung: Wenn Ihre Daten pro Mandant getrennt bleiben müssen, bieten wir Ihnen eine Möglichkeit, dies schneller und mit weniger Code umzusetzen.

• Automatische Indexoptimierung: Vom „brandneuen Index“ bis zu „vollständig optimiert“, mit möglichst wenig Feinabstimmung.

• Kontinuierliche Infrastrukturverbesserungen: Eine laufende Optimierung der Einstellungen und Infrastruktur der Vektordatenbank, damit Sie stets den besten Durchsatz und die schnellsten Reaktionen erhalten.

Testen Sie die Elasticsearch-Vektordatenbank auf Elastic Cloud Serverless

Gelangen Sie in wenigen Minuten von einem leeren Projekt zu einer hybriden, gefilterten Vektorabfrage – mit produktionsreifen Standardeinstellungen, die das Tuning für Sie übernehmen. Erstellen Sie schnelle, skalierbare KI-Apps, keine Infrastruktur.

Starten Sie auf Elastic Cloud Serverless oder tauchen Sie ein in die vollständige Dokumentation und die API-Referenz.

Elastic Cloud Serverless beseitigt bereits jetzt den Aufwand für die Verwaltung der Infrastruktur und Versionsaktualisierungen. CPS geht noch einen Schritt weiter. Wir haben komplexes Netzwerk-Peering und manuelle Zertifikatsverwaltung durch ein einfaches Verknüpfungsmodell ersetzt. Jetzt können Sie Ihre Elastic Cloud Serverless-Projekte einfach als einfache Namespaces für Ihre Daten behandeln. Ob Sie nun mit strengen Gesetzen zur Datenresidenz zu tun haben, Mandantendaten isolieren müssen oder einfach nur die massiven Netzwerk-Ausgangskosten vermeiden wollen, die durch die Duplizierung von Protokollen entstehen – mit CPS können Sie Ihre Daten genau dort suchen, wo sie sich befinden, und zwar mit einer einzigen Abfrage.

In diesem Beitrag erklären wir, wie CPS funktioniert, wie Sie Ihre Suchanfragen mit Projekt-Tags steuern können und wie sich dieses neue Modell von der herkömmlichen Cross-Cluster Search (CCS) unterscheidet.

So verknüpfen Sie Projekte für die projektübergreifende Suche

Um mit der projektübergreifenden Suche zu beginnen, verknüpfen Sie Projekte in der Elastic Cloud-Konsole oder API. Die Verknüpfung ist einfach und unidirektional: Sie wählen ein Ursprungsprojekt aus und verbinden dann die Projekte, in denen es suchen soll. Diese Verknüpfungen können sich über Regionen, Cloud-Anbieter und Projekttypen erstrecken, sodass Ihre Daten dort bleiben, wo sie hingehören, ohne dass Sie auf ein einheitliches Sucherlebnis verzichten müssen.

Sobald der Link hergestellt ist, tritt er normalerweise innerhalb von etwa einer Minute in Kraft. Wenn Sie Kibana bereits geöffnet haben, aktualisieren Sie die Seite, um die neuen projektübergreifenden Suchfunktionen zu sehen.

Wie die projektübergreifende Suche standardmäßig alle verknüpften Projekte abfragt

Sobald Projekte verknüpft sind, verwandelt die projektübergreifende Suche separate Projekte in eine einzige logische Suchoberfläche. Wenn Ihre Logs über mehrere Projekte verteilt sind, sucht eine Abfrage wie FROM logs* das Ursprungsprojekt und jedes verknüpfte Projekt, das passende Daten enthält. Sie müssen die einzelnen Remote-Ziele nicht im Voraus benennen.

Das ist eine deutliche Verbesserung gegenüber der clusterübergreifenden Suche (CCS). In CCS bedeutet das Erreichen sowohl lokaler als auch entfernter Daten oft, etwas wie FROM logs*,*:logs* zu schreiben. Für Nutzer bedeutet das weniger Abfragekomplexität. Für Teams bringt uns das einem echten zentralen Überblick über verteilte Daten näher.

Weitere Informationen dazu finden Sie in den CPS-Suchmodelldokumenten .

Wenn Sie daran interessiert sind, technische Details zu erfahren, wie wir das gebaut haben, sehen Sie sich So funktioniert die projektübergreifende Suche (CPS) in Elasticsearch Serverless an.

Steuerung von Suchvorgängen über Projekt-Routing

Die standardmäßige Suche in jedem verknüpften Projekt ist praktisch und nützlich für viele Workflows, aber nicht jede Suche sollte überall durchgeführt werden. Die projektübergreifende Suche führt Projektrouting ein, eine Möglichkeit, eine Abfrage auf eine bestimmte Teilmenge von Projekten zu beschränken.

Es funktioniert über die in Elastic Cloud definierten Projekt-Tags. Jedes Projekt hat integrierte Attribute wie seinen Alias, Cloudanbieter und Region. Sie können auch Ihre eigenen Tags hinzufügen, um zu zeigen, wie Ihr Unternehmen über seinen Bestand denkt, wie environment:prod, environment:test, eine Geschäftseinheit oder einen Kundennamen. Elasticsearch kann diese Metadaten dann verwenden, um zu entscheiden, welche verknüpften Projekte an einer Suche teilnehmen sollen.

Alle Elasticsearch Endpoints, die projektübergreifende Suche unterstützen, akzeptieren einen project_routing Parameter. In der technischen Vorschau ist das Routing auf die Verwendung von Projektalias beschränkt. Wenn Sie beispielsweise project_routing auf _alias:my-linked-project setzen, wird die Anfrage nur an das verknüpfte Projekt gesendet, während _alias:_origin die Anfrage im Ursprungsprojekt belässt. Im Laufe der Zeit eröffnet dieses Modell die Möglichkeit zu einer viel umfangreicheren Routing-Struktur, bei der der Suchbereich der logischen Struktur Ihrer Organisation folgen kann, anstatt dem physischen Layout Ihrer Infrastruktur.

Beispiele und weitere Details zu ihrer Funktionsweise finden Sie in den Dokumenten zum Projektrouting.

Standard-Projektrouting auf der Kibana-Space-Ebene

Ein Beispiel dafür, wo eine höhere Präzision beim Suchrouting erforderlich ist: Die Suche in allen verknüpften Projekten könnte eine Flut von Fehlalarmen in Ihren Kibana-Regeln oder verwirrende Ergebnisse in Ihren bestehenden Dashboards auslösen. Um dieses Problem zu beheben, können Sie in Kibana einen Standardprojektbereich auf Space-Ebene festlegen. Dies dient als sichere Voreinstellung für diesen spezifischen Space – das heißt, alle Dashboards, Discover-Sitzungen und Alerting-Regeln berücksichtigen diese automatisch. Analysten können den Umfang während einer Untersuchung immer noch manuell überschreiben, wenn sie eine breitere Sicht benötigen.

Dies ist wichtig für Teams, die an einem zentralen Projekt arbeiten, wie z. B. MSPs, MSSPs und Kompetenzzentren: Sie können jedem Team einen eigenen Kibana Space zuweisen und diesen so einschränken, dass nur die jeweiligen Kundenprojekte abgefragt werden können, wodurch mandantenspezifische Erfahrungen gewährleistet werden. Analysten können den Umfang während einer Untersuchung immer noch manuell überschreiben, wenn sie eine breitere Sicht benötigen.

Sie können diese Space-Voreinstellung konfigurieren, bevor oder nachdem Sie Ihre Projekte in der Cloud-Benutzeroberfläche verknüpfen. Da CPS jedoch sofort die Funktion „Alle durchsuchen“ aktiviert, sobald ein Link erstellt wird, stellt das vorherige Festlegen Ihrer Kibana-Standardeinstellungen sicher, dass Ihre bestehenden Erkennungsregeln nicht plötzlich auf einen riesigen globalen Datensatz angewendet werden und Ihr Team überfordern.

Verwendung von Tags in Suchanfragen

Zusätzlich zur Verwendung von Tags für das Projekt-Routing können Sie Tags auch in Ihren ES|QL- und _search-Abfragen verwenden. Dies kann nützlich sein, um festzustellen, woher jeder Datensatz oder jede Zeile in einem Ergebnissatz stammt, oder um nach diesen Tags zu sortieren, zu filtern oder zu aggregieren.

Wenn Sie zum Beispiel sehen möchten, von welchem Projekt jede Zeile in einer ES|QL-Antwort stammt, können Sie der ES|QL-Abfrage das Tag _project._alias hinzufügen:

und dies ermöglicht Ihnen die Verwendung von _project._alias in anderen Teilen der Abfrage einschließlich KEEP-Klauseln, um sie im Endergebnis zu sehen:

Weitere Beispiele für die Verwendung von Tags in Abfragen finden Sie in diesem Dokument, das beschreibt, wie Sie sie sowohl in Such-APIs als auch in ES|QL verwenden können.

Wenn Sie mehr über technische Details darüber erfahren möchten, wie wir Tags zu Such- und ES|QL-Abfragen hinzugefügt haben, lesen Sie Schnellere projektübergreifende Suche in Elasticsearch Serverless mit Projekt-Tags und Routing.

Wie die projektübergreifende Suche Ursprungs- und verknüpfte Projekte gleichermaßen behandelt

Wenn Sie CCS verwendet haben, sind Sie sich möglicherweise bewusst, dass der lokale Cluster in einigen Punkten anders behandelt wird als Remote-Cluster.

• Fehler aus dem lokalen Cluster werden anders behandelt als Fehler aus Remote-Clustern. Insbesondere verwendet CCS die skip_unavailable-Einstellung, um zu steuern, wie sich Fehler von entfernten Clustern verhalten, aber diese Einstellung existiert nicht für den lokalen Cluster.

• Der lokale Cluster hat keinen „Cluster-Alias“, sodass der Indexausdruck *:logs* alle Remote-Projekte sucht, aber den lokalen Cluster überspringt. Um beides zu durchsuchen, müssen Sie den Indexausdruck logs*,*:logs* verwenden.

In CPS haben wir diese beiden Verhaltensweisen geändert, um das Ursprungsprojekt und verknüpfte Projekte auf eine gleichmäßigere Grundlage zu stellen.

Erstens wird die skip_unavailable -Einstellung in Elastic Cloud Serverless nicht verwendet. Stattdessen steuern Sie, ob Sie Teilergebnisse einer Suche über den Parameter allow_partial_search_results in _search oder _async_search oder den Parameter allow_partial_results in ES|QL wünschen.

Zweitens verfügt in Elastic Cloud Serverless das Ursprungsprojekt über einen Projektalias. Es ist in Elastic Cloud wie alle Projekt-Tags definiert. Daher sind in CPS alle folgenden Abfragen gleichwertig – sie zielen auf alle Projekte mit einem „logs“-Index ab:

Hinweis: Es gibt einen wichtigen Unterschied zwischen dem qualifizierten Indexausdruck *:logs und dem unqualifizierten Ausdruck logs hinsichtlich der Fehlerbehandlung bei fehlenden Indizes. Für Details siehe Unqualifizierte und qualifizierte Suchausdrücke in der öffentlichen Dokumentation.

Zugriffskontroll- und Sicherheitsmodell für projektübergreifende Suche

Elastic hat ein neues cloudbasiertes Sicherheitsmodell entwickelt, Universal Identity and Access Management (UIAM), das ein zentrales Prinzip für projektübergreifende Suche ermöglicht: Die Projekte und Daten, auf die Sie zugreifen können, hängen nicht davon ab, von wo aus Sie darauf zugreifen.

Egal, ob Sie eine Suche von Ihrem primären Beobachtbarkeitsprojekt oder einem Ad-hoc-Analyseprojekt aus initiieren, bleibt Ihr Zugriff auf die verknüpften Daten konsistent, da die Zugriffsrechte an einem zentralen Ort definiert wurden. Das cloudbasierte Authentifizierungs- und Autorisierungsmodell nutzt den Cloud-UIAM-Dienst, um sicherzustellen, dass Ihre Zugriffsberechtigungen unabhängig vom Ursprungsprojekt einheitlich sind.

Projektübergreifende Suche ausprobieren

Letztlich verringern Elastic Cloud Serverless und CPS zusammen die operative Reibung und bieten Ihnen zusätzliche Möglichkeiten, Daten auf Basis logischer Überlegungen statt physischer oder betrieblicher Überlegungen zu organisieren. Die projektübergreifende Suche ermöglicht es Ihren Nutzern, sich rein auf die logische Organisation ihrer Daten zu konzentrieren und bietet ein einheitliches Sucherlebnis ohne die physischen Komplexitäten der Vergangenheit.

Heute ist dies viel einfacher. Elastic Cloud API-Schlüssel können nun direkt zur Authentifizierung bei den Elasticsearch- und Kibana-APIs auf Elastic Cloud Serverless verwendet werden. Sie können nun eine einzige Zugangsberechtigung verwenden, um die Ressourcen Ihrer Organisation zu verwalten und Datenoperationen auszuführen, wie z. B. Elasticsearch Abfragesprache (ES|QL)-Abfragen, Daten-Ingestion und Alerting.

Schauen wir uns an, warum wir das entwickelt haben, wie wir eine global verteilte Identitätsschicht konstruiert haben, um dies zu ermöglichen, und wie sie die Grundlage für die projektübergreifende Suche bildet.

Die Last der geheimen Verwaltung

Der Aufbau zuverlässiger CI/CD-Pipelines, GitOps-Workflows oder Terraform-Automatisierung rund um Datenplattformen geht mit einem versteckten Kostenfaktor einher: der Geheimnisverbreitung.

Im vorherigen Modell hatten Entwickler ein uneinheitliches Authentifizierungskonzept:

• Steuerebene (Elastic Cloud API-Schlüssel): Organisationsbezogene Schlüssel, die zum Erstellen von Projekten, zur Einladung von Nutzern und zur Verwaltung der Abrechnung über die Elastic Cloud API verwendet werden.

• Datenebene (Elasticsearch-API-Schlüssel): Projektbezogene Schlüssel, die innerhalb eines bestimmten Serverless-Projekts erstellt werden, um mit Elasticsearch und Kibana-APIs zu interagieren.

Das bedeutete, dass Ihr Deployment-Skript sich bei Elastic Cloud authentifizieren, ein Serverless-Projekt bereitstellen, einen neu erstellten Elasticsearch-API-Schlüssel aus diesem speziellen Projekt extrahieren und diesen zweiten Schlüssel dann in die Downstream-Anwendung oder das Automatisierungstool einfügen musste, was zu komplexen Pipelines, fragmentierten Audit-Logs und einem höheren Risiko von Credential-Lecks führte.

Vereinheitlichte Authentifizierung in Elastic Cloud Serverless

Mit dieser Version entfällt die Trennung bei Serverless-Projekten. Sie können jetzt einen Elastic Cloud API-Schlüssel erstellen, der explizit für Cloud-, Elasticsearch- und Kibana-APIs autorisiert ist.

• Vorher: Ein Elastic Cloud-API-Schlüssel war ausschließlich ein Token für die Steuerungsebene. Er konnte Projekte erstellen, die Abrechnung verwalten und Benutzer einladen. Es gab jedoch eine klare Grenze: Es konnte nicht verwendet werden, um die Elasticsearch- oder Kibana-APIs innerhalb dieser Projekte aufzurufen. Sie benötigten immer einen zweiten, projektspezifischen Schlüssel für Datenoperationen.

• Jetzt: Durch die Aktivierung des Zugriffs auf Cloud, Elasticsearch und Kibana-APIs bei der Erstellung eines Elastic-Cloud-API-Schlüssels wird die harte Grenze für Serverless entfernt. Dieser API-Schlüssel wird zu einem wirklich einheitlichen Berechtigungsnachweis. Er behält seine Fähigkeit bei, die Infrastruktur Ihrer Organisation zu verwalten und gleichzeitig nativen Zugriff auf das Abfragen, Ingestieren und Analysieren von Daten in jedem autorisierten Serverless-Projekt zu ermöglichen.

Indem Sie dies unter einem einzigen Elastic Cloud API-Schlüssel vereinen, erhalten Sie eine einzige Identität, die als eine Einheit festgelegt, geprüft, rotiert und widerrufen werden kann. Jeder API-Aufruf, egal ob er ein neues Projekt bereitstellt oder eine ES|QL-Abfrage ausführt, erscheint unter denselben Anmeldedaten in Ihren Auditprotokollen, was Ihnen eine einzige Spur bei Vorfalluntersuchungen oder Compliance-Überprüfungen bietet. Die Rotation von Anmeldeinformationen wird zu einem einstufigen Vorgang, anstatt einer koordinierten Aktualisierung über separate Steuerungs- und Datenebenen-Geheimnisse. Und da Rollenzuweisungen pro Projekt erfolgen, kann ein einzelner Schlüssel mehrere Projekte umfassen, die Ingestion in Ihrem Beobachtbarkeit-Projekt verwalten und Abfragen in Ihrem Sicherheitsprojekt ausführen, ohne dass für jedes einzelne Zugangsdaten getrennt werden müssen.

Wichtig ist, dass vereint nicht allmächtig bedeutet. Durch die Verwendung der role_assignments Nutzdaten können Sie einen einheitlichen Schlüssel strikt auf ein einzelnes Projekt und eine bestimmte Rolle (z. B. schreibgeschützt) beschränken und so sicherstellen, dass der Explosionsradius vollständig eingegrenzt bleibt, falls ein Berechtigungsnachweis jemals offengelegt wird. Wenn ein Entwickler ausscheidet oder eine Anwendung eingestellt wird, können Sie einen einzelnen Schlüssel aus der Elastic Cloud-Konsole widerrufen und somit den Zugriff sowohl auf der Kontrollebene als auch auf allen zugehörigen Elasticsearch-Projekten sofort beenden.

(Hinweis: Für Elastic Cloud Hosted/verwaltete Elastic Cloud-Deployments verwalten API-Schlüssel weiterhin nur die Steuerungsebene.) Die Unterstützung für die Erweiterung auf gehostete Stack-APIs ist für eine zukünftige Version geplant.

Automatisieren Sie Ihre Workflows

Der Einstieg ist einfach. Sie können dies komplett über die Elastic Cloud-Konsole konfigurieren oder mit der Elastic Cloud API automatisieren.

Der Benutzeroberflächenprozess bleibt derselbe, aber jetzt können Sie Cloud-, Elasticsearch- und Kibana-API-Zugriff unter der Projektrollenzuweisung auswählen.

Hier erfahren Sie, wie Sie einen einheitlichen Schlüssel programmatisch mit der Elastic Cloud API erstellen. Beachten Sie das application_roles-Array, da dieses dem Schlüssel nativen Zugriff auf die Elasticsearch-Datenebene gewährt:

Nach der Erstellung übergeben Sie einfach genau denselben Schlüssel im Header Authorization: ApiKey sowohl an api.elastic-cloud.com als auch an Ihre spezifischen Serverless Elasticsearch-Endpunkte.

Hinter den Kulissen: Aufbau einer verteilten Identitätsebene

Die Verwendung eines Cloud-API-Schlüssels sowohl auf der Steuerungsebene als auch auf der Datenebene ist nicht so einfach wie die Übergabe eines Tokens. Es erfordert das Lösen einer grundlegenden Herausforderung in verteilten Systemen.

Historisch gesehen befanden sich Cloud-API-Schlüssel in einem zentralisierten globalen Sicherheitscluster. Das funktioniert gut für Operationen auf der Steuerungsebene, bei denen eine höhere Latenz akzeptabel ist. Allerdings erfordern Elasticsearch-Datenanfragen eine äußerst niedrige Latenz. Wir können uns keine Reise um den Globus zu einer zentralen Steuerungsebene leisten, um jede einzelne Suchanfrage oder jeden einzelnen Ingest-Anfrage zu validieren.

Um dies zu lösen, haben wir eine neue Authentifizierungsarchitektur eingeführt, die von einem global verteilten Datenspeicher unterstützt wird. Das folgende Sequenzdiagramm zeigt einen Client, der eine Elasticsearch-Abfrage mit einem Elastic Cloud API-Schlüssel sendet, und veranschaulicht, wie die Authentifizierung vollständig innerhalb der lokalen Region stattfindet, ohne eine Rundreise zur globalen Kontrollebene. Elasticsearch delegiert die Authentifizierung an den Regional IAM Service, der den Schlüssel validiert und seine Rollenzuweisungen anhand eines lokalen Replikats der global verteilten Datenbank auflöst. Nach der Autorisierung führt Elasticsearch die Abfrage aus und liefert dem Client die Ergebnisse.

Weltweit verteilte Persistenz

Anstatt sich ausschließlich auf einen zentralisierten Sicherheitscluster zu verlassen, werden die Elastic Cloud API-Schlüssel und die zugehörigen Rollendefinitionen jetzt in einer global verteilten, hochverfügbaren Datenbank gespeichert. Diese Datenbank synchronisiert Identitäts- und Zugriffsmanagementdaten (IAM) über die globale Kontrollebene und die regionalen Datenebenen, in denen Ihre Serverless-Projekte tatsächlich laufen.

Lokale Validierung mit regionalem IAM

Wenn Ihr Client eine Anfrage an Elasticsearch mit einem Elastic Cloud API-Schlüssel sendet, wird die Anfrage nicht an die globale Steuerungsebene zurückgesendet. Stattdessen wird er an den neuen regionalen IAM-Dienst weitergeleitet. Der Schlüssel wird mit der lokalen Datenbankreplik abgeglichen, wodurch sichergestellt wird, dass die Authentifizierung mit einer Latenzzeit von nahezu Null erfolgt und vollständig von Ausfällen der globalen Kontrollebene abgeschirmt ist.

Dynamisches Rollen-Mapping

Die Authentifizierung ist nur die halbe Miete; das System muss die Anfrage ebenfalls autorisieren. Der regionale IAM-Dienst übersetzt Ihre Cloud-Rollenzuweisungen, z. B. application_roles, sofort in native Elasticsearch-Privilegien. Elasticsearch kann die Anfrage dann lokal autorisieren und ausführen, ohne jemals einen lokalen .security-Index zu benötigen.

Die Grundlage für Cross-Project Search

Diese verteilte Identitätsarchitektur ist ein grundlegender Baustein für die Zukunft der Elastic-Plattform.

Da Identität und Zugriff nun einheitlich und global synchronisiert sind, verfügen wir über das notwendige Framework, um Ihre Identität sicher zwischen verschiedenen Projekten weiterzugeben. Dies ermöglicht die kommenden Cross-Project Search (CPS)-Funktionen für Serverless.

Mit CPS können Sie Daten aus mehreren entfernten Serverless-Projekten abfragen – beispielsweise durch die Kombination von Security- und Observability-Workloads. Und das so einfach, als wären es ein einziger Datensatz. Durch die Verwendung einheitlicher API-Schlüssel kann das System Ihre Berechtigungen in allen Projekten automatisch und gleichzeitig auswerten, ohne dass Sie komplexe Vertrauensbeziehungen, Zertifikate oder doppelte Zugangsdaten für jedes Zielprojekt konfigurieren müssen.

Weitere Informationen

Sind Sie bereit, Ihren Stack zu vereinfachen?

• Lesen Sie die Dokumentation zu Elastic Cloud API-Schlüsseln, um zu erfahren, wie Sie Stack-Zugriff zuweisen.

• Schauen Sie sich API-Schlüssel erstellen (Elastic Cloud API) an, um die Schlüsselgenerierung zu automatisieren.

• Überprüfen Sie die Elastic API-Schlüssel, um einen vollständigen Vergleich der Schlüsseltypen auf der gesamten Elastic-Plattform zu erhalten.

Beginnen Sie noch heute mit dem Aufbau in Elastic Cloud oder setzen Sie Ihre Arbeit fort.

Verzichtserklärung

Die Entscheidung über die Veröffentlichung der in diesem Blogeintrag beschriebenen Leistungsmerkmale und Features sowie deren Zeitpunkt liegt allein bei Elastic. Es ist möglich, dass noch nicht verfügbare Leistungsmerkmale oder Features nicht rechtzeitig oder überhaupt nicht veröffentlicht werden.

Es ist zu voll auf der Party

Sie veranstalten eine Pizza-Party. Sie haben ein paar Freunde, die Ihnen beim Servieren helfen, jeder an verschiedenen Stellen im Raum stationiert. Sie geben jedem Freund eine Pizza und verteilen die Stücke an die hungrigen Gäste, sobald diese eintreffen.

Zunächst läuft alles reibungslos. Nach und nach treffen ein paar Gäste ein, Ihre Freunde servieren Snacks, alle sind zufrieden. Aber dann spricht sich herum, wie gut Ihre Sauerteigpizzen sind. Es klingelt ständig an der Tür. Die Gäste strömen herein. Bald formiert sich eine Menschenmenge um einen Ihrer Freunde, der eine Salamipizza in der Hand hält, die anscheinend jeder will.

Ihr Freund mit der Salamipizza ist überfordert. Die Gäste warten, werden ungeduldig und es hat sich eine lange Warteschlange gebildet. Währenddessen steht Ihr Freund mit einer Margherita-Pizza herum, und kaum jemand fragt nach einem Stück.

Und was nun?

Sie bestellen ein paar mehr Salamipizzen und geben sie an andere Freunde weiter. Jetzt haben drei Freunde Salamipizzen parat, nicht nur einer. Die Menge verteilt sich und plötzlich können dreimal so viele Gäste gleichzeitig bedient werden.

Ein paar Dinge werden deutlich, wenn Sie mehr Partys veranstalten:

• Nicht alle Pizzen sind gleich beliebt. Einige sind sehr gefragt, andere finden weniger Abnehmer. Sie benötigen keine zusätzlichen „Kopien“ unbeliebter Pizzen. Sie benötigen noch weitere der stark gefragten.

• Bestellen Sie mehr Pizzen, bevor die Warteschlange zu lang wird. Wenn Sie warten, bis Ihr Freund völlig überfordert ist und die Gäste verärgert abreisen, haben Sie zu lange gewartet. Es ist besser, eine zusätzliche Pizza zu holen, wenn Sie sehen, wie sich eine Menschenmenge bildet.

• Werfen Sie die Pizzen nicht zu schnell weg. Nur weil der Andrang am Salamistand für fünf Minuten zurückgegangen ist, heißt das nicht, dass der Ansturm vorbei ist. Vielleicht füllen die Leute nur ihre Getränke nach oder unterhalten sich miteinander (gibt es sowas heutzutage überhaupt noch?). Halten Sie die zusätzlichen Pizzen bereit. Wenn die Flaute eine Weile anhält, können Sie sie wegräumen.

• Sie können nur so viele Pizzen verteilen, wie Sie Freunde haben, die mithelfen. Wenn Ihnen nur vier Freunde helfen, ändern zehn Pizzen nichts am Ergebnis. Es können nur vier Menschen gleichzeitig bedient werden. Passen Sie die Anzahl der Pizzen an Ihre verfügbaren Helfer an.

• Wenn ein Freund geht, räumen Sie seine Pizza weg. Wenn einer Ihrer Freunde gehen muss, räumen Sie sofort seine Pizza weg. Sie können keine Pizzen unbeaufsichtigt stehen lassen. Geben Sie sie jemand anderem oder räumen Sie sie weg.

Von Pizzen bis zu Repliken

Ordnen wir dies wieder Elasticsearch zu.

In unserer Analogie sind Pizzen die Replikate (Kopien Ihrer Index-Shards), Ihre Freunde, die sie servieren, sind die Suchknoten, die hungrigen Gäste sind die Suchabfragen, und die beliebte Pizza, um die sich alle reißen, ist ein heißer Index mit hoher Suchlast.

Wenn der Suchverkehr auf einem bestimmten Index zunimmt, erstellen wir zusätzliche Replikate und verteilen diese auf Ihre Suchknoten. Jedes Replikat kann jede Abfrage für diesen Index beantworten, genau wie jeder Freund, der eine Salamipizza in der Hand hält, Pizzastücke verteilen kann. Mehr Replikate bedeuten einen höheren Durchsatz: Drei Replikate können dreimal so viele Abfragen pro Sekunde wie ein einzelnes Replikat verarbeiten.

Den Hunger messen

Bevor wir entscheiden, wie viele Pizzen wir bestellen, müssen wir wissen, wie hungrig das Publikum ist.

Elasticsearch verfolgt die Suchlast für jeden Shard. Es ist eine Metrik, die erfasst, wie viel Suchaktivität ein Shard verarbeitet. Wir aggregieren dies über alle Shards eines Indexes, um die gesamte Suchnachfrage zu verstehen.

Am wichtigsten ist die relative Suchlast: Welcher Anteil des gesamten Suchverkehrs Ihres Projekts trifft jeden Index? Wenn ein Index 60 % aller Suchanfragen erhält, während ein anderer 5 % bekommt, wissen wir, wo wir Kapazität hinzufügen müssen.

Die Berechnung hinter den Pizzen

Wir berechnen die optimale Anzahl der Replikate nach folgender Formel:

Wo:

• L = die relative Suchlast des Index (zwischen 0 und 1).

• N = die Anzahl der gewünschten Suchknoten in Ihrem Projekt.

• S = die Anzahl der Shards im Index.

• X = eine Schwelle, um Hotspots zu vermeiden (Standard: 0,5).

Ein Beispiel: vier Suchknoten, ein Index mit zwei primären Shards, die 80 % des Suchverkehrs erhalten:

Dieser Hot-Index erhält vier Replikate, die auf die Suchknoten verteilt werden.

Der Schwellenwert X (standardmäßig 0,5) ist wichtig. Wir warten nicht, bis ein Replikat völlig überlastet ist, sondern skalieren, wenn es die halbe Kapazität erreicht hat. Teilen Sie die zusätzliche Pizza aus, wenn Sie sehen, dass sich eine Menschenmenge bildet, nicht wenn die Gäste bereits gehen.

Schnell hochskalieren, langsam herunterskalieren

Wenn die Suchlast steigt, fügen wir sofort Repliken hinzu. Es gibt keinen Grund, die Nutzer warten zu lassen.

Wenn die Suchlast abfällt, warten wir eine Weile, bevor wir etwas unternehmen. Wir müssen eine konstant niedrige Nachfrage über einen Zeitraum von etwa 30 Minuten beobachten, bevor wir die Anzahl der Replikate reduzieren. (Dies dient dazu, mit Spitzenverkehr umzugehen, wobei ein ruhiger Moment nicht bedeutet, dass die Party vorbei ist.)

Das ist wichtig, weil das Hinzufügen eines Replikats Kosten verursacht. Das neue Replikat kopiert Daten und wärmt seine Caches auf, bevor es Abfragen effizient verarbeitet. Replikate zu voreilig zu entfernen bedeutet, dass Sie diese Anlaufkosten ständig erneut zahlen, weil der Traffic naturgemäß schwankt.

Berücksichtigung der Topologiegrenzen

Replikate können niemals die Anzahl der Suchknoten überschreiten. Mehr Replikate als Knoten zu haben, bringt keinen Vorteil (Sie können nur so viele Pizzen servieren, wie Sie Freunde haben, die beim Servieren der Pizzastücke helfen).

Wenn Knoten aus Ihrem Projekt entfernt werden, reduzieren wir die Anzahl der Replikate sofort entsprechend. Es wird nicht erst aufs Abkühlen gewartet, da es keine nicht zugewiesenen Replikate geben kann. Sobald ein Freund geht, räumen wir seine Pizza weg.

Das größere Serverless-Bild

Replikate für den Suchlastausgleich arbeiten mit anderen Systemen zur automatischen Skalierung zusammen:

• Automatische Suchskalierung passt die Anzahl der Suchknoten an (Anzahl der helfenden Freunde).

• Replikate für die Suchlastverteilung verteilen den Traffic durch Anpassung der Replikatzahlen pro Index (wie viele Pizzen jeder Sorte benötigt werden).

• Datenstrom-Autosharding optimiert die Shard-Anzahl für Schreibvorgänge (wie man jede Pizza aufteilt, beschrieben im vorherigen Beitrag).

Ein wichtiges Gestaltungsprinzip: Replikate für den Lastausgleich lösen nicht direkt die automatische Skalierung der Suche aus. Durch die Verteilung von Suchanfragen auf mehrere Replikate können Sie stattdessen die Ressourcenauslastung Ihrer Suchknoten erhöhen. Diese höhere Auslastung löst dann unsere vorhandene automatische Skalierungslogik aus, um bei Bedarf für zusätzliche Kapazitäten zu sorgen. Replikate für den Lastausgleich ermöglichen die automatische Skalierung und stellen sicher, dass Ihre Suchknoten tatsächlich genutzt werden, anstatt dass der gesamte Datenverkehr auf einem einzigen Replikat blockiert wird, während andere Knoten untätig bleiben.

Was das für Sie bedeutet

Sie müssen nicht vorhersagen, welche Indizes beliebt sein werden. Sie müssen die Replikate nicht manuell anpassen, wenn sich die Verkehrsmuster ändern. Sie müssen nicht um 3 Uhr morgens aufwachen, weil ein Ansturm Ihren am stärksten belasteten Index überfordert hat.

Das System überwacht, wo sich Warteschlangen bilden, und bestellt für diese Stellen mehr Pizzen. Kalte Indizes verschwenden keine Ressourcen für unnötige Replikate. Heiße Indizes erhalten die benötigte Kapazität. Ihr Budget fließt dort hin, wo es wichtig ist.

Fazit

Im Autosharding-Beitrag haben wir dafür gesorgt, dass Ihre Pizzen richtig aufgeteilt werden. Jetzt sorgen wir mit Replikaten für die Suchlastverteilung dafür, dass Sie genug Pizzen bereit haben, wenn die hungrigen Massen eintreffen.

Probieren Sie Elastic Cloud Serverless aus und lassen Sie uns die Pizza-Logistik übernehmen.

Agenten gewinnen an Bedeutung, getrieben durch ihr Potenzial, Effizienzsteigerungen und bessere Kundenerlebnisse zu liefern. Aber in der Praxis ist es schwierig, Agenten den richtigen Kontext zu bieten, insbesondere wenn sie mit unübersichtlichen, unstrukturierten Unternehmensdaten arbeiten. Entwickler müssen Tools, Prompts, Zustand, Schlussfolgerungslogik, Modelle und vor allem den relevanten Kontext aus Geschäftsquellen abrufen, um genaue Ergebnisse und Aktionen zu liefern. Elastic Agent Builder bietet diese Kernkomponenten für die Entwicklung sicherer, zuverlässiger, kontextgesteuerter Agenten.

Kernfunktionen von Agent Builder

Agent Builder nutzt die langfristigen Investitionen von Elastic in die Suchrelevanz und die Retrieval-Augmented Generation und arbeitet daran, Elasticsearch zur besten Vektordatenbank zu machen, um die Entwicklung kontextbezogener, datenorientierter KI-Agenten zu vereinfachen.

Mit Agent Builder können Sie:

• Starten Sie sofort mit einem integrierten Dialogagenten, der Fragen beantworten, Analysen durchführen und Untersuchungen über alle Daten in Elasticsearch anstoßen kann.

• Wechseln Sie schnell von komplexen unstrukturierten Daten zu einem benutzerdefinierten Agenten mit konfigurationsbasierter Entwicklungserfahrung.

• Nutzen Sie die erstklassige, hybride Suchrelevanz durch integriertes ES|QL oder benutzerdefinierte Tools, um die Kontextqualität und Agentenzuverlässigkeit zu verbessern.

• Komplexe Workflows (Vorschau) als wiederverwendbare Werkzeuge ausführen, um Daten anzureichern, Einträge zu aktualisieren, Nachrichten zu senden und vieles mehr für eine regelbasierte Automatisierung.

• Verbinden Sie sich mit Datenquellen außerhalb von Elasticsearch über Workflows und MCP, um den Kontext für Agenten zu korrelieren und zu kombinieren.

• Integrieren Sie beliebige Agenten- oder Anwendungsframeworks mithilfe von integrierten und benutzerdefinierten Tools, die über MCP bereitgestellt werden, sowie mit der Möglichkeit zur Verbindung mit externen MCPs (Vorschau), Unterstützung für A2A und vollständige API-Unterstützung.

• Erweitern Sie die Fähigkeiten von Agent Builder durch Integration mit Drittanbieterlösungen wie LlamaIndex für komplexe Dokumentenverarbeitung oder Arcade.dev für sicheren, strukturierten Toolzugriff.

Um die Funktionen von Agent Builder weiter zu erweitern, führen wir Elastic Workflows ein, unsere neuen regelbasierten Automatisierungsfunktionen, jetzt in der technischen Vorschau. Für organisatorische Aufgaben benötigen Agenten manchmal Sicherheit und Zuverlässigkeit von regelbasierten Aktionen, die oft notwendig sind, um eine bestimmte Geschäftslogik umzusetzen. Elastic Workflows bietet Agenten eine einfache, deklarative Möglichkeit, interne und externe Systeme zu orchestrieren, um Aktionen durchzuführen, Daten und Kontext zu erfassen und zu transformieren. Workflows sind vollständig zusammensetzbar, ereignisgesteuert und flexibel und können einem Agenten über MCP als Werkzeuge zur Verfügung gestellt werden.

In wenigen Minuten vom Daten zum Agenten

Die Entwicklung von Agenten kann wochenlange Vorarbeit erfordern, um separate Datenspeicher zu konsolidieren, manuelle Pipelines zu erstellen, Abfragen zu optimieren und komplexe Orchestrierungen zu verwalten. Agent Builder verkürzt die Entwicklungszeit für Agenten, indem es die Notwendigkeit für separate Datenspeicher, Vektordatenbanken, RAG-Pipelines, Suchschichten, Abfrageübersetzer und Tool-Orchestratoren beseitigt, sodass Sie sich auf die Agentenlogik und die Anwendungsbereitstellung konzentrieren können.

Agent Builder integriert nativ die Primitiven der Elasticsearch-Plattform, um die Agentenentwicklung zu beschleunigen.

• Beginnen Sie mit einem integrierten Dialogsystem, das sofort mit Ihren indexierten Daten chatten und argumentieren kann.

• Integrieren Sie Agenten in Anwendungen, Dashboards oder CI/CD-Systeme mit interaktivem Zugriff über Kibana, APIs oder MCP und A2A.

• Nutzen Sie die Standardwerkzeuge, um Ihre Datenstruktur zu verstehen, den passenden Index auszuwählen, optimierte hybride, semantische und strukturierte Abfragen zu generieren und konfigurierbare Visualisierungen mit ES|QL auf Basis von natürlichsprachlichen Eingabeaufforderungen zu erstellen.

Um tiefer einzutauchen, probieren Sie eine vollständige praktische Anleitung.

Bauen Sie auf Elasticsearch auf, einer vollständigen Datenplattform für Kontext-Engineering

Für KI-Agenten ist die Qualität des Kontexts entscheidend, um effektives Denken zu ermöglichen und die Gefahr von Halluzinationen zu verringern. Für viele Enterprise-KI-Agenten sind die Geschäftsdaten, die für die Ausführung einer Aufgabe erforderlich sind, der wichtigste Kontext. Als massiv skalierbarer Datenspeicher, Vektordatenbank und führender Anbieter relevanter Daten bietet Elasticsearch bereits viele leistungsstarke Kontext-Engineering-Primitive. Context Engineering geht über die einfache retrieval-augmented generation hinaus, indem es Ihnen ermöglicht, die Art und Weise, wie Daten abgerufen, sortiert, gefiltert und Agenten präsentiert werden, individuell anzupassen und zu skalieren, wodurch Rauschen und Mehrdeutigkeiten reduziert werden.

Elasticsearch liefert eine Kontext-Engine, die lexikalische Suche, Vektorsuche und strukturierte Filterung für den Abruf kombiniert und die Leistung von LLMs erheblich verbessert, indem sichergestellt wird, dass das Modell auf relevantem und präzisem Kontext arbeitet. Diese Funktion wird durch agentische Abrufe unterstützt, zusammen mit integrierten Werkzeugen und einer Suchlogik, die automatisch die richtigen Indizes auswählt und natürliche Sprache in optimierte Kontextanfragen umwandelt.

Mit Agent Builder können Sie sicherstellen, dass Agenten zuerst den relevantesten Kontext erhalten, indem Sie die Relevanz und das Ranking steuern. So können Sie die Logik für Bewertung, Ranking und Filterung feinabstimmen. Mit Elasticsearch können Sie kontrollieren, was wichtig ist, warum es wichtig ist und wie es priorisiert wird, anstatt sich auf ein undurchsichtiges Abrufverhalten zu verlassen. Grundlage hierfür ist Elasticsearch als Skalierbarkeits-Datenplattform, mit der sich alle Ihre Daten – von Texten über Vektoren und Metadaten bis hin zu Logs und mehr – auf einer Plattform speichern und skalieren lassen, was die Kontextverwaltung für Agenten vereinfacht.

Führen Sie komplexe Workflows als wiederverwendbare Tools aus

Während KI-Agenten das Denken für komplexe Aufgaben ermöglichen, hängt ein Großteil der Automatisierung davon ab, regelbasierte Aktionen zuverlässig auszuführen, die eine spezifische Geschäftslogik durchsetzen. Elastic Workflows bietet eine einfache, deklarative Möglichkeit, interne und externe Systeme zu orchestrieren, um Aktionen auszuführen, Kontext oder Daten zu sammeln und diese als Teil der Agenten zu integrieren. Die in YAML definierten Workflows sind vollständig zusammensetzbar, so dass sie so einfach oder so komplex sein können, wie es die Aufgabe erfordert. Dies gibt Agenten eine effiziente Möglichkeit, über die Elasticsearch-Platform und solutions hinweg sowie mit Anwendungen von Drittanbietern zu agieren.

Die Integration eines Workflows mit Agent Builder kann in drei Schritten erfolgen (Voraussetzung: Workflows mit den hier angegebenen Details aktivieren)

1. Erstellen und speichern Sie einen neuen Workflow mit dem einfachen YAML-basierten Editor mit integrierter Autovervollständigung und Testfunktion.

2. Erstellen Sie ein neues Tool in Agent Builder mit dem Typ „Workflow“ und geben Sie eine Beschreibung an, die dem Agenten hilft zu bestimmen, wann das Workflow-Tool verwendet werden soll.

3. Fügen Sie das Workflow-Tool zu Ihrem benutzerdefinierten Agenten hinzu.

4. Das ist es! Jetzt kann der Agent den Workflow innerhalb eines Gesprächs aufrufen.

Ihr Agent, Ihre Regeln

Agent Builder bindet Sie nicht an ein einzelnes Entwicklungsparadigma. Stattdessen ist es darauf ausgelegt, offene, flexible Entwicklungsansätze für Agenten mit vollständiger Kontrolle über Daten, Relevanz, Modelle, Interoperabilität, Sicherheit und Agentendesign zu ermöglichen.

Mithilfe benutzerdefinierter Agentendefinitionen können Sie genau auswählen, auf welche Tools ein Agent zugreifen darf, benutzerdefinierte Systemaufforderungen einbetten, die Anweisungen des Agenten anpassen und Sicherheitsgrenzen definieren. Die Agenten bleiben modellunabhängig, sodass Sie flexibel ein bevorzugtes LLM konfigurieren können, sowohl nativ als auch im gesamten Ökosystem, ohne an einen einzigen Anbieter gebunden zu sein.

Entwickeln Sie erweiterbare Tools, die domänenspezifische Logik kapseln (z. B. spezifische Indexfilter, ES|QL-Joins, analytische Pipelines) und schränken Sie diese für einen sicheren Einsatz in der Produktion ein. Vollständige API-Unterstützung ermöglicht die Interoperabilität mit anderen agentischen Frameworks, mit nativer Unterstützung für das Model Context Protocol (MCP). Die A2A-Integration bedeutet, dass Sie Ihre Elastic-Agenten anderen Frameworks, Diensten und Client-Apps zugänglich machen können, indem Sie dieselben Daten und dieselbe Context-Engineering-Logik für alle Integrationen wiederverwenden.

Agent Builder unterstützt eine flexible, offene Entwicklung und ist so konzipiert, dass er sich problemlos in gängige Agenten-Frameworks und -Plattformen integrieren lässt. Diese Integrationen können für die Bereitstellung effektiver Agenten von entscheidender Bedeutung sein. Wie Sam Partee, Mitbegründer von Arcade.dev , beschreibt:

„Agentische Systeme scheitern heute, weil die Verbindung von KI mit Werkzeugen und Daten komplex ist.“ Elastic Agent Builder mit Arcade.dev bietet Entwicklern eine strukturierte und sichere Möglichkeit, die Art und Weise zu steuern, wie Agenten Kontext abrufen, Argumente liefern und handeln, und ermöglicht so die Weiterentwicklung von Demo- zu Produktionsversionen.

Agent Builder nutzt außerdem die Erweiterbarkeit von Elasticsearch zur Verarbeitung komplexer Daten. Wie Jerry Liu, CEO von LlamaIndex beschreibt:

„Das Erschließen des Unternehmenskontextes aus unstrukturierten Datenquellen ist der Schlüssel zum Aufbau effektiver Agenten. Elastic Agent Builder in Kombination mit der komplexen Dokumentenverarbeitung von LlamaIndex stärkt die kritische Kontextschicht und hilft Teams dabei, Daten abzurufen, zu verarbeiten und aufzubereiten, damit Agenten genauer argumentieren und bessere Ergebnisse erzielen können.“

Was können Sie erstellen?

Agent Builder wird bereits für eine Vielzahl von Anwendungsfällen eingesetzt. Nachfolgend finden Sie einige Beispiele und Referenzarchitekturen für den Einstieg in die Agentenarbeit:

• Infrastruktur automatisieren: In Support-Szenarien wurden Agenten zum Lesen, Nachdenken und Chatten eingesetzt, aber bisher können sie nicht die Infrastruktur berühren, die sie möglicherweise verwalten müssen. Das Ingenieurteam von Elastic hat im Rahmen eines Hackathons einen Agenten für die automatische Verwaltung der Infrastruktur entwickelt. Der Agent untersucht aktiv Probleme mit der Anwendungsinfrastruktur und ergreift automatisierte Maßnahmen. Es verwendet Workflows, um Konfigurationen zu optimieren, auf Probleme zu reagieren und Ressourcen zu skalieren, alles auf der Grundlage eines intelligenten Verständnisses der Infrastrukturprotokolle.

• Sicherheitsbedrohungsanalyse: Ein Sicherheitsschwachstellen-Agent wurde mit Elastic Agent Builder, MCP und Elasticsearch entwickelt. Es automatisiert die Bedrohungsanalyse durch die Korrelation interner Sicherheitsdaten mit externen Bedrohungsinformationen. Der Agent führt semantische Suche über historische Vorfälle und Konfigurationen durch, erweitert die Ergebnisse mit Live-Internetdaten und wendet LLM-Argumentation an, um Umweltrelevanz zu bewerten, Risiken zu priorisieren und umsetzbare Sanierungen zu erstellen. Sehen Sie sich die Referenzarchitekturan.

• Technischer Kundensupport: Agenten können mehrere Unterstützungsaufgaben ausführen, darunter Ticketzusammenfassungen, Issue-Deduplizierung und -Erstellung sowie tiefgehende technische Untersuchungen. Agent Builder ermöglicht dies mit mehrstufigen, hybriden Suchen, um nur die relevantesten verwandten Probleme, Lösungen und Verfahren zu finden und Hypothesen zu Grundursachen sowie Behebungspläne zu formulieren. Agent Builder kann die Architektur komplexer Unterstützungssysteme vereinfachen und die Zeit bis zur Bereitstellung beschleunigen.

• Produkt- und Inhaltserkennung: Agent Builder vereinfacht den Prozess der Bereitstellung komplexer Produktkataloge für Konversationserlebnisse und bietet Unternehmen gleichzeitig die Flexibilität, ihre eigene Geschäftslogik und ihre eigenen Anforderungen zu pflegen.

• Selbst erstellen: Nehmen Sie am Agent Builder Hackathon teil, der vom 22. Januar bis 27. Februar 2026 stattfindet. Arbeiten Sie mit der Community zusammen, um kontextgesteuerte, mehrstufige KI-Agenten zu entwickeln, die Suche, Workflows, Tools und Argumentation kombinieren, um reale Aufgaben zu automatisieren*

Beginnen Sie jetzt mit der Erstellung benutzerdefinierter Agenten

Starten Sie mit einer Elastic Cloud-Testversion und sehen Sie sich hier die Dokumentation an. Für bestehende Kunden ist Agent Builder in Cloud Serverless und auf dem Enterprise Tier in Elastic Cloud Hosted und selbstverwaltet verfügbar.

* Klicken Sie hier für die vollständigen Bedingungen und Teilnahmevoraussetzungen für den Hackathon

Wir haben ein umfassendes Infrastruktur-Upgrade für alle Elastic Cloud Serverless-Projekte abgeschlossen, die auf AWS laufen und auf neuere, schnellere Hardware migriert wurden. Diese Änderung wurde automatisch auf alle Serverless-Projekte ausgerollt. Es bietet einen höheren Durchsatz und geringere Latenz für Serverless-Projekte mit Elasticsearch, Elastic Observability und Elastic Security auf AWS.

Wichtigste Leistungsvorteile für Entwickler:innen

Die neue AWS-Hardwareinfrastruktur bildet die Grundlage für alles, was Sie mit Elastic Cloud Serverless tun, und führt zu spürbaren Vorteilen hinsichtlich der Geschwindigkeit und Reaktionsfähigkeit Ihrer Anwendungen.

Reduzierte Abfragelatenz … erhöhter Durchsatz

Die verbesserte Hardware steigert die Geschwindigkeit der Rechenressourcen erheblich, sodass Ihre Suchanfragen schneller als je zuvor verarbeitet werden.

• Suchen und Vektorsuche: Egal, ob Sie traditionelle Volltextabfragen durchführen oder modernste Vektorsuche für Ihre generative KI- und Retrieval-Augmented-Generation (RAG)-Anwendungen verwenden – Sie werden eine deutliche Verringerung der Latenzzeit feststellen. Interne Benchmarkings zeigten einen durchschnittlichen Rückgang der Suchlatenz um 35 %.

• Schnellere Indexierung: Die Ingestion-Raten sind optimiert, sodass Sie riesige Datenmengen und komplexe Dokumente mit erhöhtem Durchsatz indexieren können. Das ist besonders wichtig für Anwendungen, die Daten nahezu in Echtzeit anzeigen müssen. Interne Benchmarkings zeigten einen durchschnittlichen Anstieg des Indexierungsdurchsatzes um 26 %.

Konstante Leistung unter Last

Elastic Cloud Serverless ist so konzipiert, dass es sich dynamisch in Echtzeit an die Nachfrage anpasst und die Latenz minimiert, unabhängig von Ihrer Arbeitslast. Mit diesem Hardware-Upgrade ist das Skalieren nun leistungsfähiger und reaktionsschneller.

• Problemloser Umgang mit Spitzen: Egal, ob Sie mit einem plötzlichen Anstieg des Nutzerverkehrs oder einem massiven Batch-Ingest konfrontiert sind – die neue Infrastruktur stellt sicher, dass Ihre Such- und Indexierungsressourcen effizienter skaliert werden, um eine gleichbleibend niedrige Latenz zu gewährleisten.

• Optimierte Entkopplung von Rechenleistung und Speicher: Die Serverless-Architektur trennt Rechenleistung und Speicher, wodurch Workloads unabhängig voneinander skaliert werden können, um optimale Leistung und Kosteneffizienz zu gewährleisten. Die schnellere Hardware verbessert die Computerschicht und maximiert die Effizienz dieses entkoppelten Designs.

Hinter den Kulissen: Ergebnisse interner Benchmarks

Um die Auswirkungen unseres AWS-Infrastruktur-Upgrades zu quantifizieren, führte das Elastic-Engineering-Team ein umfassendes internes Benchmarking mit einer Reihe von Serverless-Workloads durch. Diese Workloads lieferten empirische Beweise für Leistungsverbesserungen, die Sie in Ihren Anwendungen erwarten können, unabhängig von Ihrem Anwendungsfall.

Der Benchmarking-Ansatz

Wir konzentrierten unsere Tests auf die wichtigsten Kennzahlen, die das Entwicklererlebnis und die Anwendungsreaktionsfähigkeit direkt beeinflussen: Reaktionszeit (also Latenz) und Durchsatz bei Such- und Indexierungsoperationen.

• Getestete Arbeitslasten: Die Tests umfassten Suchvorgänge mit hoher Parallelität, wie sie typisch für benutzerorientierte Anwendungen sind, komplexe Vektorsuchanfragen sowie die Erfassung/Indexierung großer Datenmengen für Anwendungsfälle im Bereich Beobachtbarkeit und Sicherheit. Insbesondere nutzte unsere Testmethodik öffentlich verfügbare Datensätze für Rally, das Benchmarking-Tool von Elastic.

  • wikipediaEin Datensatz, der aus einem Snapshot des Wikipedia-Textinhalts abgeleitet wurde, um die allgemeine Textsuchleistung zu messen.

  • MSMARCO-Passage-RankingEin Datensatz, abgeleitet von Microsofts Machine Reading Comprehension (MS MARCO), um die Suchleistung auf spärlichen Vektorfeldern zu messen.

  • OpenAI_Vector: Ein Datensatz, der aus BEIRs NQ abgeleitet und mit Einbettungen angereichert wurde, die vom text-embedding-ada-002-Modell von OpenAI generiert wurden, um die Suchleistung auf dichten Vektorfeldern zu messen.

• Messung: Wir verglichen die Leistung der alten und neuen Infrastruktur und maßen die Latenz im 99. Perzentil (P99), um den Worst-Case, die Tail-Latenz-Performance und die Operationen pro Sekunde zu erfassen. Jeder Track wurde für jedes Hardware-Profil fünfmal ausgeführt, um die Konsistenz der Ergebnisse zu gewährleisten.

• Das Ziel: Unser Ziel war es, die Fähigkeit der Infrastruktur zu validieren, um eine konstant schnellere und vorhersehbarere Leistung zu liefern, selbst in Phasen schneller automatischer Skalierung.

Zusammenfassung der Leistungsdaten

Die Ergebnisse bestätigen deutliche Verbesserungen in Effizienz und Geschwindigkeit. Diese Vorteile schlagen sich direkt in kürzeren Reaktionszeiten für Ihre Benutzer:innen und niedrigeren Betriebskosten nieder, da Sie die gleiche Menge an Arbeit mit weniger Rechenressourcen erledigen können.

Die folgenden Tabellen zeigen die quantitativen Verbesserungen. Höhere Werte sind besser für den Durchsatz; niedrigere Werte sind besser für die Latenz.

Suche nach Benchmark-Ergebnissen:

Benchmark

Vergleich

Alte Infrastruktur

Neue Infrastruktur

Differential

„Wikipedia“ (Klartext)

Durchsatz der Suchvorgänge (Operationen/s)

729

1.107

+52 %

„Wikipedia“ (Klartext)

Latenz der Suchoperation (p99, ms)

56

35

-37 %

„MSMARCO-Passage-Ranking“ (dünnbesetzte Vektoren)

Durchsatz der Suchvorgänge (Operationen/s)

22

31

+40 %

„MSMARCO-Passage-Ranking“ (dünnbesetzte Vektoren)

Latenz der Suchoperation (p99, ms)

108

67

-38 %

`OpenAI_Vector` (dichte Vektoren)

Durchsatz der Suchvorgänge (Operationen/s)

475

624

+31 %

`OpenAI_Vector` (dichte Vektoren)

Latenz der Suchoperation (p99, ms)

35

22

-37 %

Indexieren der Benchmark-Ergebnisse:

Benchmark

Vergleich

Alte Infrastruktur

Neue Infrastruktur

Differential

„Wikipedia“ (Klartext)

Durchsatz der Suchvorgänge (Operationen/s)

2.845

3220

+13 %

„Wikipedia“ (Klartext)

Latenz der Suchoperation (p99, ms)

1769

1120

-37 %

„MSMARCO-Passage-Ranking“ (dünnbesetzte Vektoren)

Durchsatz der Suchvorgänge (Operationen/s)

7.087

8900

+26 %

„MSMARCO-Passage-Ranking“ (dünnbesetzte Vektoren)

Latenz der Suchoperation (p99, ms)

824

677

-18 %

`OpenAI_Vector` (dichte Vektoren)

Durchsatz der Suchvorgänge (Operationen/s)

2.972

3187

+7 %

`OpenAI_Vector` (dichte Vektoren)

Latenz der Suchoperation (p99, ms)

2946

2944

0 %

Der zusätzliche Bonus: Kostenreduzierung

Unser Fokus liegt zwar auf der Bereitstellung einer Performance mit geringer Latenz, aber die Effizienz der neuen Hardware hat auch einen direkten, positiven Einfluss auf die Kosten von Elasticsearch-Projekten.

Die Preisgestaltung von Elasticsearch Serverless basiert auf der Nutzung, das heißt, Sie zahlen nur für die Ingest- und Suchressourcen, die Sie verbrauchen. Da die neuere, schnellere Hardware effizienter ist, werden Ihre Arbeitslasten oft mit weniger Ressourcen erledigt, was bei den meisten Projekten zu einer erheblichen Kostenreduzierung führt. Sie erhalten eine Premium-Leistungssteigerung ohne den Premium-Preis – die Definition von optimierter Effizienz.

Was bedeutet das für Sie als Entwickler:in?

Dieses Infrastruktur-Upgrade wird vollständig von Elastic verwaltet, sodass Sie keinen Finger rühren müssen – keine Migrationen und keine Konfigurationsänderungen. Die Verbesserung erfolgt sofort und automatisch bei all Ihren AWS-basierten Serverless-Projekten.

Dieses Upgrade ermöglicht Ihnen Folgendes:

• Erstellen Sie schnellere Anwendungen: Konzentrieren Sie sich auf die Geschwindigkeit der Features, da Sie wissen, dass Ihre zugrundeliegende Such-Platform die Geschwindigkeit bietet, die Ihre Benutzer:innen erwarten.

• Innovation mit Zuversicht: Stellen Sie neue Such-, Beobachtbarkeits- und Sicherheitsfeatures – einschließlich komplexer KI-Features wie Vektorsuche und Relevanzranking – mit der Gewissheit bereit, dass die Platform die Last mit maximaler Leistung bewältigen kann.

• Vereinfachen Sie Ihren Stack: Nutzen Sie einen vollständig verwalteten Service, der Infrastrukturmanagement, Kapazitätsplanung und Skalierung übernimmt, damit Sie sich auf Ihren Code und Ihre Daten konzentrieren können.

1. Klonen Sie das Repository: Laden Sie den Code des Tools von GitHub mit git clone https://github.com/elastic/elasticsearch-labs/supporting-blog-content/serverless-ai-agent aherunter und navigieren Sie mit cd serverless-ai-agent in das Verzeichnis.

2. Umgebung einrichten: Erstellen Sie eine virtuelle Umgebung (optional) mit python -m venv venv und aktivieren Sie diese (source venv/bin/activate oder venv\Scripts\activate unter Windows). Installieren Sie anschließend die benötigten Python-Pakete mit pip install -r requirements.txt.

3. Zugangsdaten konfigurieren: Erstellen Sie eine .env -Datei im Projektstammverzeichnis und füllen Sie diese mit Ihrer Elasticsearch API-URL (ES_URL), Ihrem API-Schlüssel (API_KEY), Ihrer Region (REGION) und Ihrem OpenAI API-Schlüssel (OPENAI_API_KEY).

4. Tool ausführen: Führen Sie das Tool aus, indem Sie python main.py in Ihrem Terminal eingeben. Dadurch wird der KI-Agent gestartet und Sie werden zur Eingabe Ihrer Befehle aufgefordert.

5. Projekte mit natürlicher Sprache verwalten: Interagieren Sie mit dem Tool mithilfe von Befehlen in einfachem Englisch wie „Erstelle ein serverloses Projekt mit dem Namen my\_project“, „Rufe den Status des serverlosen Projekts mit dem Namen my\_project ab“ oder „Lösche das serverlose Projekt mit dem Namen my\_project“. Die KI interpretiert Ihre Befehle und führt die entsprechenden Funktionen aus.

Hintergrund

Mit diesem kleinen Kommandozeilen-Tool können Sie Ihre Serverless Elasticsearch-Projekte in einfacher Sprache verwalten. Es kommuniziert mit einer KI (in diesem Fall OpenAI), um herauszufinden, was Sie meinen, und ruft mithilfe von LlamaIndex die richtigen Funktionen auf!

Was kann der Elasticsearch Serverless AI-Agent leisten?

• Projekt erstellen: Ein neues Serverless Elasticsearch-Projekt starten.

• Projekt löschen: Ein bestehendes Projekt entfernen (ja, es wird nach dem Löschen aufgeräumt).

• Projektstatus abrufen: Prüfen Sie, wie es um Ihr Projekt steht.

• Projektdetails abrufen: Erhalten Sie alle wichtigen Details zu Ihrem Projekt.

Den Code finden Sie auf GitHub.

Funktionsweise des Elasticsearch Serverless AI-Agenten

Wenn Sie beispielsweise Folgendes eingeben:

"Erstelle ein serverloses Projekt mit dem Namen my_project"

…und so läuft es hinter den Kulissen ab:

• Benutzereingabe & Kontext: Ihr Befehl in natürlicher Sprache wird an den KI-Agenten gesendet.

• Funktionsbeschreibungen: Der KI-Agent kennt bereits einige Funktionen – wie create_ess_project, delete_ess_project, get_ess_project_status und get_ess_project_details –, weil wir ihm detaillierte Beschreibungen gegeben haben. Diese Beschreibungen erklären der KI, was jede Funktion bewirkt und welche Parameter sie benötigt.

• LLM-Verarbeitung: Ihre Anfrage plus die Funktionsinformationen werden an das LLM gesendet. Das bedeutet, die KI sieht Folgendes:

  • Die Benutzeranfrage: Ihre Anweisung in einfacher Sprache.

  • Verfügbare Funktionen & Beschreibungen: Details zu den Funktionen der einzelnen Werkzeuge, damit das richtige ausgewählt werden kann.

  • Kontext-/Verlaufsinformationen zum Chat: Da es sich um eine Konversation handelt, wird gespeichert, was zuvor gesagt wurde.

• Funktionsaufruf & -antwort: Die KI ermittelt, welche Funktion aufgerufen werden soll, übergibt die richtigen Parameter (wie Ihren Projektnamen) und führt dann die Funktion aus. Die Antwort wird Ihnen in einem freundlichen Format zugesandt.

Kurz gesagt, senden wir sowohl Ihre Anfrage in natürlicher Sprache als auch eine Liste detaillierter Werkzeugbeschreibungen an das LLM, damit es Ihre Anfrage „verstehen“ und die richtige Aktion auswählen kann.

KI-Agenten einrichten

Voraussetzungen:

Bevor Sie den KI-Agenten ausführen, stellen Sie sicher, dass Sie Folgendes eingerichtet haben:

1. Python (Version 3.7 oder höher) ist installiert.

2. Elasticsearch-Serverless-Konto auf Elastic Cloud eingerichtet.

3. OpenAI-Konto zur Interaktion mit dem Sprachmodell.

Schritte:

1. Klonen Sie das Repository:

2. Erstellen einer virtuellen Umgebung (optional, aber empfohlen): Wenn Sie mit umgebungsbezogenen Problemen konfrontiert sind, können Sie zur Isolation eine virtuelle Umgebung einrichten:

3. Abhängigkeiten installieren: Stellen Sie sicher, dass alle erforderlichen Abhängigkeiten installiert sind, indem Sie Folgendes ausführen:

4. Konfigurieren Sie Ihre Umgebung: Erstellen Sie eine .env-Datei. Datei im Projektverzeichnis mit den folgenden Variablen. Hier ist eine Beispieldatei .env.example , die Ihnen weiterhelfen soll:

Stellen Sie sicher, dass Sie die korrekten Werte für ES_URL, API_KEY, und OPENAI_API_KEY haben. Ihre API-Schlüssel finden Sie in den jeweiligen Service-Dashboards.

5. Projektdatei: Das Tool verwendet eine projects.json -Datei, um Ihre Projektzuordnungen (Projektnamen zu ihren Details) zu speichern. Diese Datei wird automatisch erstellt, falls sie noch nicht existiert.

Ausführen des KI-Agenten

Sie sehen dann eine Eingabeaufforderung wie diese:

Geben Sie Ihren Befehl ein, und der KI-Agent wird seine Magie wirken! Wenn Sie fertig sind, geben Sie exit oder quit ein, um das Fenster zu verlassen.

Ein paar weitere Details

• LLM-Integration: Dem LLM werden sowohl Ihre Anfrage als auch detaillierte Beschreibungen jeder verfügbaren Funktion übermittelt. Dies hilft dem System, den Kontext zu verstehen und beispielsweise zu entscheiden, ob es create_ess_project oder delete_ess_project aufrufen soll.

• Werkzeugbeschreibungen: Jedes Funktionswerkzeug (erstellt mit FunctionTool.from_defaults) hat eine freundliche Beschreibung. Diese Beschreibung ist in der an das LLM gesendeten Aufforderung enthalten, damit es „weiß“, welche Aktionen zur Verfügung stehen und was von jeder Aktion erwartet wird.

• Persistenz: Ihre Projekte und deren Details werden in projects.json gespeichert. So müssen Sie die Informationen nicht jedes Mal erneut eingeben.

• Ausführliche Protokollierung: Der Agent ist auf ausführlichen Modus eingestellt, was sich hervorragend zum Debuggen eignet und um zu sehen, wie Ihre Anweisungen in Funktionsaufrufe übersetzt werden.

Beispiel für die Nutzung des Elasticsearch AI-Agenten

Wo wir angefangen haben

Die erste Version von Elasticsearch wurde 2010 als verteilte, skalierbare Suchmaschine veröffentlicht, die es Benutzern ermöglicht, schnell nach wichtigen Erkenntnissen zu suchen und diese anzuzeigen. Zwölf Jahre und über 65.000 Commits später bietet Elasticsearch seinen Nutzern weiterhin praxiserprobte Lösungen für eine Vielzahl von Suchproblemen. Dank des Engagements von über 1.500 Mitwirkenden, darunter Hunderte von festangestellten Elastic-Mitarbeitern, hat sich Elasticsearch ständig weiterentwickelt, um den neuen Herausforderungen im Bereich der Suche gerecht zu werden.

In der Frühphase von Elasticsearch, als Bedenken hinsichtlich Datenverlusten aufkamen, unternahm das Elastic-Team über mehrere Jahre hinweg Anstrengungen , das Cluster-Koordinationssystem neu zu schreiben, um zu gewährleisten, dass bestätigte Daten sicher gespeichert werden. Als deutlich wurde, dass die Verwaltung von Indizes in großen Clustern mühsam ist, arbeitete das Team an der Implementierung einer umfassenden ILM-Lösung , um diese Arbeit zu automatisieren, indem es den Benutzern ermöglicht, Indexmuster und Lebenszyklusaktionen vorzudefinieren. Da die Nutzer den Bedarf erkannten, große Mengen an Metrik- und Zeitreihendaten zu speichern, wurden verschiedene Funktionen wie eine bessere Komprimierung hinzugefügt, um die Datengröße zu reduzieren. Da die Speicherkosten für die Suche in großen Mengen kalter Daten stiegen, investierten wir in die Entwicklung von durchsuchbaren Snapshots , um Benutzerdaten direkt in kostengünstigen Objektspeichern durchsuchen zu können.

Diese Investitionen legen den Grundstein für die nächste Entwicklungsstufe von Elasticsearch. Angesichts des Wachstums cloudnativer Dienste und neuer Orchestrierungssysteme haben wir beschlossen, Elasticsearch weiterzuentwickeln, um die Benutzerfreundlichkeit bei der Arbeit mit cloudnativen Systemen zu verbessern. Wir sind überzeugt, dass diese Änderungen Möglichkeiten zur Verbesserung des Betriebsablaufs, der Leistung und der Kosten beim Betrieb von Elasticsearch auf Elastic Cloud bieten.

Wohin wir gehen – Die Einführung einer staatenlosen Architektur

Eine der größten Herausforderungen beim Betrieb oder der Orchestrierung von Elasticsearch besteht darin, dass es von zahlreichen persistenten Zuständen abhängt und daher ein zustandsbehaftetes System ist. Die drei Hauptbestandteile sind das Translog, der Indexspeicher und die Cluster-Metadaten. Dieser Zustand bedeutet, dass die Daten persistent sein müssen und bei einem Neustart oder Austausch eines Knotens nicht verloren gehen dürfen.

Die bestehende Elasticsearch-Architektur auf Elastic Cloud muss die Indizierung über mehrere Verfügbarkeitszonen hinweg duplizieren, um im Falle von Ausfällen Redundanz zu gewährleisten. Wir beabsichtigen, die Speicherung dieser Daten von lokalen Festplatten in einen Objektspeicher wie AWS S3 zu verlagern. Durch die Nutzung externer Dienste zur Speicherung dieser Daten entfällt die Notwendigkeit der Indexierungsreplikation, wodurch der mit der Datenerfassung verbundene Hardwareaufwand erheblich reduziert wird. Diese Architektur bietet zudem sehr hohe Garantien für die Datenbeständigkeit, da Cloud-Objektspeicher wie AWS S3, GCP Cloud Storage und Azure Blob Storage Daten über Verfügbarkeitszonen hinweg replizieren.

Durch die Auslagerung der Indexspeicherung in einen externen Dienst können wir Elasticsearch auch neu strukturieren, indem wir die Verantwortlichkeiten für Indizierung und Suche trennen. Anstatt primäre und Replikatinstanzen für beide Arbeitslasten zu verwenden, planen wir eine Indexierungsebene und eine Suchebene. Durch die Trennung dieser Arbeitslasten können diese unabhängig voneinander skaliert werden, und die Hardwareauswahl kann gezielter auf die jeweiligen Anwendungsfälle abgestimmt werden. Es hilft auch dabei, eine seit langem bestehende Herausforderung zu lösen, bei der sich die Such- und Indexierungslast gegenseitig beeinflussen kann.

Nach einer mehrmonatigen Machbarkeits- und Versuchsphase sind wir davon überzeugt, dass diese Objektspeicherdienste die Anforderungen erfüllen, die wir an die Speicherung von Indizes und Cluster-Metadaten stellen. Unsere Tests und Benchmarks zeigen, dass diese Speicherdienste die hohen Indexierungsanforderungen der größten Cluster, die wir in Elastic Cloud gesehen haben, erfüllen können. Darüber hinaus reduziert die Speicherung der Daten im Objektspeicher die Indizierungskosten und ermöglicht eine einfache Optimierung der Suchleistung. Zur Datensuche nutzt Elasticsearch das bewährte Searchable Snapshots-Modell, bei dem die Daten dauerhaft im Cloud-nativen Objektspeicher abgelegt werden und lokale Festplatten als Cache für häufig abgerufene Daten dienen.

Um die Unterschiede zu verdeutlichen, bezeichnen wir unser bestehendes Modell als „Knoten-zu-Knoten“-Replikation. In der Hot-Tier-Ebene dieses Modells übernehmen sowohl der primäre als auch der Replikat-Shard die gleiche rechenintensive Aufgabe bei der Verarbeitung und Beantwortung von Suchanfragen. Diese Knoten sind „zustandsbehaftet“, da sie sich auf ihre lokalen Festplatten verlassen, um die Daten für die von ihnen gehosteten Shards sicher zu speichern. Darüber hinaus kommunizieren primäre und Replikat-Shards ständig miteinander, um synchron zu bleiben. Dies geschieht, indem die auf dem primären Shard durchgeführten Operationen auf den Replikat-Shard repliziert werden, was bedeutet, dass die Kosten dieser Operationen (hauptsächlich CPU) für jedes angegebene Replikat anfallen. Die gleichen Shards und Nodes, die für die Datenaufnahme zuständig sind, bedienen auch Suchanfragen, daher müssen Bereitstellung und Skalierung beide Arbeitslasten berücksichtigen.

Neben der Suche und dem Datenimport übernehmen Shards im Node-to-Node-Replikationsmodell weitere rechenintensive Aufgaben, wie beispielsweise das Zusammenführen von Lucene-Segmenten. Dieses Design hat zwar seine Vorzüge, aber wir sahen viele Möglichkeiten, die sich aus unseren Erfahrungen mit Kunden im Laufe der Jahre und der Entwicklung des gesamten Cloud-Ökosystems ergaben.

Die neue Architektur ermöglicht zahlreiche sofortige und zukünftige Verbesserungen, darunter:

1. Sie können den Datendurchsatz auf derselben Hardware deutlich erhöhen, oder anders ausgedrückt, die Effizienz bei gleicher Datenerfassungslast deutlich verbessern. Diese Steigerung resultiert aus der Beseitigung der Duplizierung von Indexierungsvorgängen für jede Replik. Die rechenintensiven Indexierungsvorgänge müssen nur einmal auf der Indexierungsebene durchgeführt werden, die anschließend die resultierenden Segmente an einen Objektspeicher sendet. Von dort aus können die Daten direkt von der Suchschicht verwendet werden.

2. Sie können Rechenleistung und Speicher trennen, um Ihre Clustertopologie zu vereinfachen. Elasticsearch verfügt heute über mehrere Datenebenen (Content, Hot, Warm, Cold und Frozen), um Daten mit Hardwareprofilen abzugleichen. Die Hot-Tier-Kategorie dient der Suche in nahezu Echtzeit, die Frozen-Tier-Kategorie der Suche nach weniger häufig gesuchten Daten. Diese Ebenen bieten zwar einen Mehrwert, erhöhen aber auch die Komplexität. In der neuen Architektur werden Datenebenen nicht mehr benötigt, was die Konfiguration und den Betrieb von Elasticsearch vereinfacht. Wir trennen außerdem die Indizierung von der Suche, was die Komplexität weiter reduziert und es uns ermöglicht, beide Arbeitslasten unabhängig voneinander zu skalieren.

3. Sie können die Speicherkosten auf der Indexierungsebene senken, indem Sie die Menge der Daten reduzieren, die auf einer lokalen Festplatte gespeichert werden müssen. Aktuell muss Elasticsearch für Indexierungszwecke eine vollständige Shard-Kopie auf den Hot Nodes (sowohl primären als auch Replikaten) speichern. Bei dem zustandslosen Ansatz, direkt auf den Objektspeicher zuzugreifen, wird nur ein Teil dieser lokalen Daten benötigt. Bei reinen Anfüge-Anwendungsfällen müssen nur bestimmte Metadaten zur Indizierung gespeichert werden. Dadurch wird der für die Indizierung benötigte lokale Speicherplatz erheblich reduziert.

4. Sie können die mit Suchanfragen verbundenen Speicherkosten senken. Indem das Searchable Snapshots-Modell zum nativen Modus der Datensuche gemacht wird, werden die mit Suchanfragen verbundenen Speicherkosten deutlich reduziert. Je nach den Anforderungen der Benutzer an die Suchlatenz ermöglicht Elasticsearch Anpassungen, um das lokale Caching häufig angeforderter Daten zu erhöhen.

Benchmarking – 75 % Verbesserung des Indexierungsdurchsatzes

Um diesen Ansatz zu validieren, haben wir einen umfangreichen Machbarkeitsnachweis erbracht, bei dem die Daten nur auf einem einzigen Knoten indiziert und die Replikation über Cloud-Objektspeicher realisiert wurde. Wir stellten fest, dass wir eine Verbesserung des Indexierungsdurchsatzes um 75 % erreichen konnten, indem wir die Notwendigkeit beseitigten, Hardware für die Indexierungsreplikation zu dedizieren. Darüber hinaus waren die CPU-Kosten für das einfache Abrufen von Daten aus dem Objektspeicher wesentlich geringer als für das Indizieren der Daten und das lokale Schreiben, wie es heutzutage für die Hot-Tier-Ebene erforderlich ist. Dies bedeutet, dass die Suchknoten ihre gesamte CPU-Leistung der Suche widmen können.

Diese Leistungstests wurden auf einem Zwei-Knoten-Cluster gegen alle drei großen Public-Cloud-Anbieter (AWS, GCP und Azure) durchgeführt. Wir beabsichtigen, im Zuge unserer Bemühungen um eine zustandslose Produktionsimplementierung weiterhin größere Benchmarks zu entwickeln.

Indexierungsdurchsatz

CPU-Auslastung

Staatenlos für uns, Ersparnisse für Sie

Die zustandslose Architektur von Elastic Cloud ermöglicht es Ihnen, den Indexierungsaufwand zu reduzieren, die Datenerfassung und -suche unabhängig voneinander zu skalieren, die Verwaltung der Datenebenen zu vereinfachen und Vorgänge wie Skalierung oder Upgrade zu beschleunigen. Dies ist der erste Meilenstein hin zu einer umfassenden Modernisierung der Elastic Cloud-Plattform.

Werden Sie Teil unserer Vision für zustandsloses Elasticsearch.

Haben Sie Interesse, diese Lösung vor allen anderen auszuprobieren? Sie können uns über die Diskussionsseite oder unseren Community-Slack-Kanal erreichen. Wir würden uns über Ihr Feedback freuen, um die Ausrichtung unserer neuen Architektur mitzugestalten.