Die wesentliche Zusammenfassung zu Elastic 2026 für Microsoft Build-Teilnehmer und Azure-Entwickler

KI-Agenten, die sich erinnern. 30-mal schneller als Prometheus. Ein Index für alle Medien. Das hat Elastic im Jahr 2026 geliefert.

MS-Build.jpg

Bislang hat Elastic im Jahr 2026 vier Neuerungen auf den Markt gebracht, die Ihre Suche und die Möglichkeiten unserer KI-Plattform verändern. 

  • Elastic Inference Service (EIS) hostet jetzt jina-embeddings-v5-omni, das Text, Bilder, Videos und Audio in einem einzigen Elasticsearch-Index für fast 100 Sprachen zusammenfasst. 
  • Elastic Agent Builder lieferte Kontextmanagement, Fähigkeiten und Enterprise-Connectors, damit KI-Agenten in langen Gesprächen in großem Maßstab präzise bleiben.
  • Die neu aufgebaute Metrik-Engine speichert OpenTelemetry (OTel)-Daten mit 3,75 Bytes pro Datenpunkt und fragt sie 160-mal schneller ab als das frühere Elasticsearch-TSDS.
  • Elastic Security Labs hat einen CI/CD-Pipeline-Detektor als Open Source veröffentlicht, der Angreifer in GitHub Actions und Azure DevOps abfängt, bevor sie in die Produktionsumgebung gelangen.

In diesem Blog erfahren Sie, welche Produkte wir im Jahr 2026 auf den Markt gebracht haben.

4 Gründe, warum Elastic die Plattform für Azure-Entwickler im Jahr 2026 ist

1. Elasticsearch ist jetzt die Abfrageebene für Agenten, die auf Azure KI Foundry aufgebaut sind

Der häufigste Produktionsfehler von KI-Agenten ist der Kontext – falsche, veraltete oder gar keine Daten erreichen den Agenten zum Zeitpunkt der Inferenz. Elastic 9.4 behebt dieses Problem mit drei produktionsreifen Verbesserungen am Agent Builder, die jetzt allgemein verfügbar sind:

  1. Fähigkeiten: Anleitungspakete werden vom Agenten bedarfsgesteuert geladen, wodurch er über Fachwissen verfügt, ohne jedes Kontextfenster zu überladen. Fünf speziell entwickelte Fähigkeiten wurden für den Sicherheitsbetrieb und fünf für SRE-Workflows (Site Reliability Engineering) bereitgestellt; weitere befinden sich in der Entwicklung. 

  2. Native Microsoft 365-Connectors: SharePoint- und Drive-Inhalte werden über eine semantische Metadatenebene direkt in den Agentenkontext integriert. Ihr Unternehmenskorpus bildet das Rückgrat der Datenabfrage; Elasticsearch dient als Index.

  3. Kontextmanagement im großen Maßstab: Auslagerung, Komprimierung und Zusammenfassung von Abfrageergebnissen sorgen für präzise und kosteneffiziente, lange Agentengespräche mit mehreren Gesprächsrunden im Produktionsbetrieb.

GPU-beschleunigtes Indexieren über NVIDIA cuVS – allgemein verfügbar in Elastic 9.4 – liefert eine 12-fache Verbesserung des Indizierungsdurchsatzes. DiskBBQ, der Vektor-Indizierungsalgorithmus von Elastic, hat die Abfragelatenz bei Abfragen mit restriktiven Filtern um mindestens das Dreifache verbessert. Für KI-Workloads, die auf Azure mit hochkardinalen Einbettungen ausgeführt werden, ist dies der Infrastrukturvorteil, der sich bei Latenz und Kosten im großen Maßstab bemerkbar macht.

Die Microsoft Azure AI-Integration ist ein integraler Bestandteil des Elasticsearch Labs-Ökosystems. Wenn Sie Azure OpenAI Service- oder Azure AI Foundry-Modelle verwenden, steht Ihnen Elasticsearch als zentrale Datenbank für die Datenabfrage mit integrierter Hybridsuche (BM25 + Vektor), Reranking und Kontextoptimierung zur Verfügung.

Für TypeScript- und JavaScript-Entwickler im Azure-Ökosystem hat Elastic im April 2026 außerdem einen eleganten, typsicheren Elasticsearch Query Language (ES|QL) Query Builder eingeführt. Die Interpolation von Rohzeichenfolgen für Abfragen entfällt. Laufzeitfehler durch Tippfehler in Feldnamen gehören der Vergangenheit an.

const query = esql
  .from('logs-*')
  .where('event.category', '==', 'authentication')
  .stats('count(*)', { by: ['user.name', 'host.name'] })
  .sort('count(*)', 'desc')
  .limit(10);

Ein Index für jeden Medientyp, mit dem Ihr Agent arbeitet
Microsoft 365-Inhalte bestehen nicht nur aus Text. SharePoint-Bibliotheken enthalten PDFs, Präsentationen und gescannte Bilder. Teams zeichnet Meeting-Aufzeichnungen auf. Azure Blob Storage speichert Produktfotos, Schulungsvideos und Audiodateien aus Kundengesprächen. Bisher erforderte die Indizierung jedes Typs ein separates Modell und eine separate Pipeline.

jina-embeddings-v5-omni wird auf dem Elastic Inference Service gehostet und speichert Text, Bilder, Videos und Audio in einem einzigen Elasticsearch-Index. Eine einzige Abfrage liefert semantisch relevante Inhalte aller Medientypen gleichzeitig und deckt dabei fast 100 Sprachen ab. Das Modell ist in zwei Größen verfügbar: small und nano. Beide sind für Standard-GPU-Hardware optimiert.

Für Entwickler mit bereits vorhandenen Textindizes erzeugt jina-embeddings-v5-omni Texteinbettungen, die mit jina-embeddings-v5-text identisch sind. Man kann einen Textindex erweitern, um Bilder, Audio und Video zu verarbeiten, ohne ihn neu aufbauen zu müssen. Mit aktivierter Elasticsearch BBQ-Quantisierung verliert das Modell weniger als 3 % Leistung, während die Einbettungen 93 % weniger Speicherplatz benötigen.

Hinweis: jina-embeddings-v5-omni steht für nicht-kommerzielle Evaluation unter einer CC-BY-NC-4.0 Lizenz zur Verfügung. Kontaktieren Sie Elastic Sales für das kommerzielle Deployment.

2. Elastic ist jetzt in VS Code, Cursor und GitHub Copilot integriert.

Im April 2026 veröffentlichte Elastic MCP Apps – interaktive Benutzeroberflächen, die innerhalb einer KI-Konversation gerendert werden und auf dem MCP App-Standard basieren, der von Anthropic und OpenAI mitentwickelt wurde. Drei MCP Apps starteten gleichzeitig: Sicherheit, Beobachtbarkeit und Suche. Alle drei funktionieren nativ in VS Code Copilot, Cursor und Claude Desktop.

Die Elastic Security MCP App liefert sechs interaktive Security Operations Center (SOC)-Dashboards, die im Chat direkt angezeigt werden, ohne die Programmierumgebung zu verlassen:

  1. Interaktive Benutzeroberfläche: Alarm-Triage: Sicherheitswarnungen abrufen, filtern und klassifizieren. Schweregradgruppierung, KI-basierte Bewertungskarten, Prozessbaum und Netzwerkereignisse.

  2. Angriffserkennung: KI-gestützte Analyse von Angriffsketten mit bedarfsgerechter Generierung. Angriffsbeschreibungen mit Konfidenzbewertung, Entitätsrisiko und MITRE-Mapping.

  3. Ticketmanagement: Ermittlungsfälle erstellen, suchen und verwalten. Ticketliste mit Benachrichtigungen, Beobachtungsfunktionen, Kommentarfeldern und KI-Aktionen.

  4. Erkennungsregeln: Erkennungsregeln durchsuchen, anpassen und verwalten. Regelbrowser mit KQL-Suche, Abfragevalidierung und Analyse fehlerhafter Regeln.

  5. Bedrohungssuche: ES|QL-Workbench mit Entitätsuntersuchung. Abfrageeditor, anklickbare Entitäten und Untersuchungsgraph.

  6. Beispieldaten: ECS-Sicherheitsereignisse für häufige Angriffsszenarien generieren. Szenarioauswahl mit vier vorgefertigten Angriffsketten.

Jede Aktion wird über dieselben APIs, die das Produkt verwendet, an Elasticsearch und Kibana zurückgeschrieben. Rollenbasierte Zugriffssteuerung wird über den bestehenden Elasticsearch-API-Schlüssel durchgesetzt. Die Einrichtung erfolgt durch Doppelklicken auf das .mcpb-Bundle. Es ist keine neue Infrastruktur und kein neues Governance-Modell erforderlich.

Die Kubernetes Observability MCP App bringt AKS-Untersuchungsfähigkeiten direkt in VS Code. Wenn ein Pod abstürzt, kann der KI-Codieragent die Ursache abfragen, strukturierte Beweise aufzeigen und weitere Schritte empfehlen, ohne ein Dashboard zu öffnen.

Installieren Sie beide Bundles aus dem neuesten GitHub-Release.

3. Elasticsearch ist jetzt eine produktionsreife Engine für spaltenbasierte Metriken

Azure setzt voll auf OpenTelemetry. Azure Monitor, AKS, Azure Functions und Azure AI Foundry senden alle nativ OpenTelemetry-Protokoll-Daten (OTLP). Wenn Sie bereits OTel-Telemetrie von Ihren Azure-Workloads erfassen, ist die Frage, wo sie landet und wie schnell Sie sie abfragen können, wenn um 2:00 Uhr nachts etwas ausfällt.

Elastic hat die Metrik-Engine von Elasticsearch im Jahr 2026 von Grund auf neu entwickelt, und die Ergebnisse sind beachtlich. Die neue spaltenorientierte Metrik-Engine speichert OTel-Metriken mit 3,75 Byte pro Datenpunkt – im Vergleich zu 25 Byte vor einem Jahr, was einer 6,6-fachen Verbesserung der Speichereffizienz entspricht. Die Abfrageleistung wurde im Vergleich zu früheren Versionen von Elasticsearch TSDS um bis zu 160-mal verbessert. Der Indexierungsdurchsatz für OTel-Daten wurde um bis zu 50 % gesteigert.

Die architektonische Arbeit hinter diesen Zahlen umfasste drei Ebenen:

  1. Vollständig spaltenorientierte Speicherung: Elastic ersetzte invertierte Indizes und BKD-Bäume auf Dimensionsfeldern durch Doc-Value-Skipper, eine Lucene-native Struktur, die das spaltenorientierte Layout verstärkt und doppelten Index-Overhead eliminiert. Jedes Feld wird in einer eigenen Datei gespeichert. Keine zeilenbasierte Nachverfolgung. Kein unnötiger Speicherplatzverbrauch.

  2. Vektorisierte ES|QL-Rechen-Engine: Der neue TS- Quellbefehl, allgemein verfügbar ab Elastic 9.4, führt Zeitreihenaggregationen mithilfe eines zweistufigen Modells durch: einer inneren Aggregation pro Zeitreihe, z. B.RATE() oder AVG_OVER_TIME(), und anschließend einer äußeren Aggregation der Ergebnisse. Die Rechen-Engine verarbeitet die Daten in der Reihenfolge der Zeitreihen und dekodiert sie ohne Kopieren direkt in die verwendeten primitiven Arrays. Zähler-, Mittelwert- und Fensterabfragen werden parallel vektorisiert ausgeführt.

  3. Native OTLP-Ingestion: Ein dedizierter OTLP-Protobuf-Endpoint, der in Elastic 9.3 allgemein verfügbar ist, akzeptiert Daten direkt von OpenTelemetry-Kollektoren ohne JSON-Übersetzungsebene. Das Hashing über Dimensionen zur Berechnung von Zeitreihen-IDs wird auf die Datenpunkte in einer einzigen Protobuf-Nachricht verteilt, wodurch der Indizierungsaufwand um 20 % reduziert wird.

Für Azure AKS-Teams, die bereits PromQL-basierte Dashboards und Alarmregeln verwenden, bietet Elastic 9.4 native PromQL-Unterstützung (technische Vorschau) in Kibana. Bestehende Abfragen funktionieren ohne Änderung. Derselbe TSDS-Speicher und dieselbe vektorisierte Rechen-Engine ermöglichen die gleichzeitige Ausführung von PromQL- und ES|QL-Abfragen.

Das Ergebnis ist eine zentrale Plattform für Protokolle, Metriken, Traces und Sicherheitsdaten – ohne separate Backends, ohne Kardinalitätsbeschränkungen und ohne Abrechnung pro Metrik. Für Azure-Entwickler, die bereits OTel-Daten erzeugen, ist die Speicherung in Elasticsearch kostengünstiger und die Abfragen sind schneller als mit einem dedizierten Metrik-Stack neben der bestehenden Protokollinfrastruktur.

Ein Beispiel für eine ES|QL-Zeitreihenabfrage für Azure AKS-Workloads:

TS metrics-hostmetricsreceiver.otel-default
| WHERE TRANGE(4h)
| STATS AVG(RATE(system.cpu.time)) BY host.name, TBUCKET(5m)

4. Elastic sichert jetzt die von Ihnen entwickelten Apps, einschließlich der Pipeline, die sie bereitstellt.

CI/CD-Pipelines zählen 2026 zu den Hauptangriffszielen und zielen direkt auf Azure- und GitHub-Entwickler ab.

Elastic Security Labs veröffentlichte im April 2026 eine Studie über ein Muster, das sich in der gesamten Branche zeigte: Die Angreifer richteten sich nicht mehr gegen die Produktionsserver, sondern gegen die Automatisierung, die diese bereitstellt. Im September 2025 stahl die GhostAction-Kampagne 3.325 Geheimnisse aus 817 GitHub-Repositories, indem sie bösartige Workflow-Dateien einschleuste. Im Februar 2026 kompromittierte HackerBot-Claw das Trivy-Repository von Aqua Security und enthüllte 33.000 Geheimnisse auf 7.000 Rechnern durch eine Fehlkonfiguration von GitHub Actions, die das Sicherheitsteam von Microsoft anschließend dokumentierte.

Elastic Security Labs hat cicd-abuse-detector als Open Source veröffentlicht – eine sofort einsatzbereite CI-Vorlage, die über 50 Signalerkennungsmuster und ein großes Sprachmodell (LLM) nutzt, um verdächtige Änderungen an GitHub Actions-, GitLab CI- und Azure DevOps-Pipelines zu erkennen. Sie läuft auf einem Standard-Runner ubuntu-latest ohne Python-Abhängigkeiten. Die Ergebnisse werden zur plattformübergreifenden Korrelation an Elasticsearch gesendet.

FROM logs-cicd.abuse-* 
WHERE verdict.verdict IN ("malicious", "suspicious") AND @timestamp > NOW() - 7 days
| EVAL platform = cicd.platform, repo = cicd.repository, actor = cicd.actor
| SORT @timestamp DESC

Eine Abfrage. Jede Plattform. Historisch abfragbar.

Für Entra ID- und Active Directory-Umgebungenbietet Elastic Security 9.4 vier neue Entity Analytics-Funktionen, die Identitätsstörungen auf Datenmodellebene auflösen:

  1. Entitätsauflösung: Vereinheitlicht Okta, Microsoft Entra ID und Active Directory zu einem einzigen verifizierten Identitätsdatensatz pro Mitarbeiter (Wenn sich ein Bedrohungsakteur mithilfe derselben Identität lateral über drei Systeme bewegt, betrachtet Elastic dies als eine Entität und nicht als drei separate Warnmeldungen.)

  2. Dynamische Überwachungslisten: Einführungen von Risikomultiplikatoren für privilegierte Azure-Administratoren, Führungskräfte und besonders wichtige Dienstkonten.

  3. Entitätsbasierte Suchansätze: Liefert proaktive, umgebungsspezifische Hinweise zur Bedrohungssuche anstelle einer leeren Suchanfrage.

  4. Präzise Entitätsidentifikation: Regelt die Identitätsvereinigung automatisch auf Plattformebene

Für Azure AI Foundry- und LLM-Anwendungen zentralisiert die Azure AI Foundry-Integration, die in Elastic 9.1 enthalten ist, die Beobachtbarkeit, indem Protokolle und Metriken von jedem auf Azure AI Foundry gehosteten KI-Modell automatisch in Elasticsearch gezogen werden. Von dort aus liefert Elastic Observability ein vollständiges, verteiltes Tracing über Agentenketten, die Verfolgung von Token-Kosten, die Überwachung von Latenzzeiten und die Sicherheitsbewertung, so dass Sie genau sehen können, was Ihr Agent getan hat, was er gekostet hat und wo er versagt hat.

Für GitHub Actions- und Azure DevOps-Nutzer, die Kibana verwalten, bietet Elastic 9.4 Dashboards als Code – versionskontrollierte Kibana-Dashboards, die über CI/CD-Pipelines bereitgestellt werden. Die Dashboards befinden sich in der Quellcodeverwaltung zusammen mit Ihrem Anwendungscode. Pull Requests, Review Gates und automatisierte Rollouts gelten für Ihre Beobachtbarkeit- und Sicherheitsansichten genauso wie für die Dienste, die diese Ansichten überwachen.

Compliance: FIPS 140-3-Compliance für Elasticsearch und Kibana ist in Elastic 9.4 allgemein verfügbar, noch vor der Deadline im September 2026. Elastic Cloud Serverless ist in neun Azure-Regionen weltweit verfügbar und wird in den kommenden Monaten die regionale Azure-Expansion fortsetzen.

Fangen Sie hier an: 4 Aktionen für Microsoft Build-Teilnehmer

  1. Integrieren Sie Elasticsearch noch heute in Ihren Azure AI Foundry-Agenten. Starten Sie eine kostenlose Testversion von Elastic Cloud. Navigieren Sie zur Microsoft Azure AI-Integration. Verbinden Sie Ihren ersten Azure OpenAI-basierten Agenten mit Elasticsearch als Datenabfrageebene. Ein funktionsfähiger Prototyp ist in weniger als einer Stunde verfügbar.
  2. Installieren Sie die Elastic MCP Apps in VS Code. Laden Sie das .mcpb-Bundle der neuesten Version herunter. Verbinden Sie es in VS Code Copilot mit Ihrer Elasticsearch-URL und Ihrem API-Schlüssel. Ihre erste Sicherheitsanalyse oder Kubernetes-Untersuchung wird innerhalb von fünf Minuten im Chat ausgeführt.
  3. Integrieren Sie Ihre Azure OTel-Metriken in Elasticsearch. Aktivieren Sie den verwalteten OTLP-Endpoint in Elastic Cloud. Richten Sie Ihren Azure Monitor OTel-Collector darauf aus. Fragen Sie Ihre AKS-Metriken, Host-Telemetriedaten und Anwendungstraces in einer einzigen ES|QL-Pipeline ab – ein separates Metrik-Backend ist nicht erforderlich.
  4. Härten Sie Ihre GitHub Actions- und Azure DevOps-Pipelines ab. Klonen Sie das Repository „cicd-abuse-detector“. Fügen Sie es Ihrem nächsten Pull-Request-Check hinzu. Überprüfen Sie das vollständige Bedrohungsmodell anhand Ihrer Pipeline-Konfiguration. Die gesamte Einrichtung läuft auf Ihrem bestehenden Runner ohne weitere Abhängigkeiten außer der Claude Code CLI.

Die Elasticsearch Platform in 2026 wurde für Entwickler konzipiert, die im Microsoft- und Azure-Ökosystem arbeiten. Agenten, Metriken, Pipelines und Identität laufen hier zusammen. Bauen Sie mit uns.

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.