Elastic kündigt GA der projektübergreifenden Suche auf Serverless an: Teams können alle verknüpften Projekte abfragen, ohne ein Byte zu verschieben

Elastic hat heute die allgemeine Verfügbarkeit der projektübergreifenden Suche (CPS) für Elastic Cloud Serverless bekannt gegeben, sodass Unternehmen eine einzelne Abfrage über mehrere serverlose Projekte hinweg ausführen können. Mit CPS können Kunden über alle Regionen, Projekttypen und Cloudanbieter hinweg suchen – bei einfacher Einrichtung, versionsloser Kompatibilität und vollständigem Sicherheitsbereich. Daten werden direkt am Speicherort abgefragt, was das Risiko von Datenbewegungen eliminiert und die Egress-Kosten minimal hält. Es unterstützt alle Solutions, einschließlich Observability-, Security-, Search- und Vektordatenbank-Workloads, und bietet Teams zentrale Transparenz ohne den betrieblichen Mehraufwand einer Zentralisierung von Daten. 

Unternehmen verwalten ihre Daten aus legitimen Gründen projektübergreifend: zur Einhaltung von Vorgaben zur Datenresidenz, zur Isolierung von Mandantendaten oder aufgrund organisatorischer Anforderungen. Doch dies kann eine schmerzhafte Nebenwirkung haben: keine einheitliche Transparenz. SOC-Teams wechseln zwischen regionalen Projekten hin und her, um eine Bedrohung zu verfolgen. Site Reliability Engineers (SREs) können Produktions- und Staging-Signale nicht an einem Ort sehen. Die Behelfslösung, Daten zu zentralisieren, bedeutet, dieselben Bytes zweimal zu speichern und zu verschieben und dabei Verstöße gegen die Datensouveränität zu riskieren. Bestehende Lösungen helfen ebenfalls nicht weiter; einige sind an einen einzigen Cloud-Anbieter gebunden, während andere Versionskoordination und Servereinrichtung erfordern, nur um eine föderierte Abfrage auszuführen.

CPS baut Datensilos über verteilte Architekturen hinweg tatsächlich ab, ohne die Datenisolation, Datenresidenz oder die Grenzen zu beeinträchtigen, auf die Systeme angewiesen sind. Durch die transparente Zusammenführung von Ergebnissen in einer einzigen Abfrage ermöglicht CPS Teams, abteilungsübergreifende Sicherheitssignale nebeneinander zu analysieren, Produktions- und Staging-Logs nahtlos zu korrelieren oder Such-Apps mit Kontext aus mehreren verknüpften Projekten zu entwickeln – und das alles, ohne separate Deployments in eine einzige Umgebung zwingen zu müssen.

Cluster-übergreifende Suche (CCS), ein ähnliches Feature in Elastic Cloud Hosted (ECH), einem vollständig verwalteten Cloud-Service für den Betrieb des Elastic Stack, wird bereits von mehr als 80 % der großen ECH-Kunden mit komplexen Architekturen genutzt. Einige davon verwalten über 50 Remote-Cluster-Verbindungen in einem einzigen Deployment. CPS bietet dieselbe Funktionalität in Serverless, ohne dass Kenntnisse über die Deployment-Topologie, die Konfiguration von Zertifikaten oder die Authentifizierung pro Verbindung erforderlich sind. Die CPS-Infrastruktur ist bewusst abstrahiert: drei Klicks in der Cloud-Konsole zum Verknüpfen von Projekten, wobei die Authentifizierung auf Organisationsebene durch die Steuerungsebene von Elastic verwaltet wird. 

Das ist die gesamte erforderliche Einrichtung, Punkt.

Sobald sie verknüpft sind, werden Suchen in Discover, ES|QL, Dashboards und Alerting-Regeln automatisch über alle verknüpften Projekte hinweg ausgeführt, wobei Sie mit dem Kibana CPS Scope Picker den Bereich stets fest unter Ihrer Kontrolle behalten.

Daten verknüpfter Projekte werden standardmäßig in Discover abgefragt.

Mit der CPS-Bereichsauswahl in Kibana können Analysten und Entwickler den Abfragebereich wechseln, ohne die Abfragesyntax zu ändern – gefiltert nach Projekt-Tags oder nur nach dem aktuellen.

Administratoren legen die Standardeinstellung pro Kibana-Space fest. Ein Space, der für die Untersuchung lokaler Vorfälle verwendet wird, beschränkt den Standardbereich auf ein einzelnes Projekt; ein Space für globale Abläufe verwendet standardmäßig das gesamte verknüpfte Set. Nutzer können die Standardeinstellung für jede einzelne Abfrage oder Sitzung über die Projektauswahl überschreiben, ohne die Space-Konfiguration zu ändern.

CPS startete als Tech-Preview am 16. April 2026. Dieses GA-Release wird mit sinnvollen Ergänzungen versendet. 

Skalierung: Die Unterstützung von bis zu 100 verknüpften Projekten ist standardmäßig inbegriffen. Enterprise-Teams und MSSPs, die Projekte pro Kunde oder Region verknüpfen, können nun mit dem Umfang arbeiten, den ihre Architekturen erfordern. Höhere Grenzwerte sind auf Anfrage verfügbar. 

Serverloses Projekt als Ursprungsprojekt: Bei GA können bestehende Projekte mit bis zu 100 verknüpften Projekten verknüpft werden und diese abfragen, ohne dass eine Migration oder Neuerstellung erforderlich ist. 

ML- und KI-Funktionen: Mit CPS erkennen Elastic-ML-Jobs unbeaufsichtigt Anomalien in Zeitreihendaten und können bei GA in einem einzigen Job projektübergreifend über mehrere verknüpfte Projekte hinweg abfragen. Die Anomalieerkennung für das Monitoring der Anwendungsleistung (APM) in Elastic Observability kann ebenfalls mehrere verknüpfte Projekte umfassen und bietet SRE-Teams eine einheitliche Ansicht von Anomalien. Darüber hinaus ermöglicht Elastic Agent Builder KI-Agenten über alle solutions hinweg, Kontext aus mehreren verknüpften serverlosen Projekten abzurufen, wodurch CPS zu einem grundlegenden Baustein für Produktionsagenten wird, die mit verteilten Daten arbeiten.

Versionsunabhängig und cloud-agnostisch: Teams sind weder an einen einzigen Cloud-Anbieter gebunden noch gezwungen, Versionen über Deployments hinweg abzustimmen, nur um eine Suche durchzuführen. Und dies funktioniert lösungsübergreifend: bei Observability-, Security-, Search- und Vektordatenbank-Workloads.

• Observability: Anwendungs- und Infrastruktur-Monitoring, Alerting, SLOs und APM-Anomalieerkennung arbeiten über verknüpfte Projekte hinweg und ermöglichen eine flexible Datenlokalität und -analyse. 

• Security: CPS versorgt das zentrale SOC-Modell mit Energie: Erkennungsregeln werden einmal auf einem zentralen Projekt ausgeführt und fragen alle verknüpften Projekte ab, sodass SOC-Teams eine Warnmeldung priorisieren können, ohne Daten manuell zusammenzuführen oder Warnmeldungsregeln zu duplizieren. Entitätsinformationen und Elastic Defend-Telemetriedaten aus verknüpften Projekten speisen dieselbe zentrale Ansicht. 

• Search: ES|QL-Abfragen und Discover-Sitzungen erstrecken sich standardmäßig über verknüpfte Projekte. Bei allgemeiner Verfügbarkeit kann ein KI-Agent in allen solutions Kontext aus mehreren verknüpften Projekten mit einer einzigen Abfrage abrufen, wodurch CPS zu einem grundlegenden Baustein für Produktionsagenten wird, die über verteilte Daten hinweg arbeiten.

Vollständige Zugriffssteuerung: Der Zugriff eines Nutzers auf Daten über verknüpfte Projekte hinweg wird durch seine individuellen Berechtigungen für jedes Projekt bestimmt, nicht dadurch, von wo aus er die Abfrage ausführt.  Was dieser Nutzer sehen kann, ist stets vollständig und konsistent mit dem, was er sehen darf.

Reduzierte Kosten: Da Daten dort bleiben, wo sie sind, zahlen Sie für die Abfragen, die Sie ausführen, und nicht für das Speichern und Verschieben derselben Bytes zweimal.

Vollständiges Projektrouting: Es gibt Teams präzise Kontrolle darüber, auf welche Projekte eine Abfrage abzielt. Mithilfe vordefinierter Tags wie Region, Cloudanbieter und Projektalias – oder benutzerdefinierter Tags, die Sie selbst definieren – können Sie jede Abfrage an eine bestimmte Teilmenge verknüpfter Projekte weiterleiten. Benannte Ausdrücke und boolesche Logik (AND, OR, NOT) ermöglichen es Ihnen, wiederverwendbare Routing-Regeln für gängige Muster zu erstellen, wie z. B. „alle EU-Projekte“ oder „alle MSSP-Tenant-Umgebungen außer Staging“.

Programmatischer CPS-Zugriff: CPS hat eine neue Nutzerrolle eingeführt, die es allen ermöglicht, nicht nur Organisationsinhabern, Cloud-API-Schlüssel für CPS-Abfragen zu erstellen, wodurch Reibungsverluste für Teams beseitigt werden, die Pipelines und Anwendungen auf CPS aufbauen.

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.