Elastic baut Suchmaschine für Metriken um und beansprucht 30-fachen Geschwindigkeitsvorteil gegenüber Prometheus, während KI-Workloads Observability-Budgets verändern
Eine Sonderkonferenz am 22. September 2026 beleuchtete das neue Metrik-Angebot des Unternehmens und die Go-to-Market-Strategie zur Konsolidierung der Observability-Ausgaben
Elastic nutzte eine Sonderkonferenz für Investoren am 22. September, um die technischen Grundlagen und die kommerzielle Logik hinter seinem zu Beginn des Geschäftsjahres im Juni eingeführten Metrik-Angebot darzulegen. Im Zentrum steht eine neu architektonierte Version von Elasticsearch, die Metriken in einem spaltenorientierten Format speichert anstelle des Dokumentenspeichers, den das Unternehmen historisch für Logs genutzt hat. Dies sei laut Management ein notwendiger Schritt gewesen, um direkt mit dedizierten Metrik-Plattformen wie Prometheus, Mimir und ClickHouse zu konkurrieren.
Santosh Krishnan, Senior Vice President of Security and Observability Solutions, gab bekannt, dass das Projekt vor seiner Markteinführung im Juni eine 12- bis 18-monatige Forschungs- und Entwicklungsphase durchlaufen hat – ein Datenpunkt, der den technischen Aufwand hinter dem quantifiziert, was das Unternehmen als mehrjährigen Burggraben positioniert. „Wir erzielen stets einen asymmetrischen Vorteil, wenn wir der Plattform Innovationen hinzufügen“, sagte Krishnan und argumentierte, dass ELASTICs bestehende Stärke bei unstrukturierten Log-Daten nun auf eine speziell dafür entwickelte Metrik-Engine ausgeweitet werde.
Benchmark-Behauptungen leiten direkte Konfrontation mit Platzhirschen ein
Der konkreteste neue Datenpunkt der Telefonkonferenz betraf die Leistungsbenchmarks: Bahaaldine Azarmi, General Manager of Observability, erklärte, dass ELASTICs neuer spaltenorientierter Speicher 30-mal schneller ist als Prometheus und Mimir sowie 8-mal schneller als ClickHouse. Die Benchmarks seien veröffentlicht und über Open-Source-Code reproduzierbar. Die Architektur nutzt Techniken wie „Dim Filter“, um hochkardinalitätsspezifische Daten im Arbeitsspeicher zu verwalten, sowie optimierte Codecs für die Speichereffizienz. Damit wird eine zentrale technische Herausforderung bei Metriken adressiert, die Azarmi wie folgt beschrieb: Im Gegensatz zu Logs gehen Metriken mit zahlreichen Dimensionen und Labels ein, die selektiv abgefragt werden müssen, ohne irrelevante Daten zu parsen. Das Management framt Kardinalität – also die Anzahl der Dimensionen, die ein System verarbeiten kann, ohne Kunden bei Kosten oder Leistung zu benachteiligen – als das primäre Schlachtfeld gegen konkurrierende Metrik-Plattformen, von denen laut Unternehmensangaben einige Kunden zu Kompromissen bei der Datenspeicherung zwingen, die während Vorfällen zu blinden Flecken führen.
PromQL-Kompatibilität steht kurz vor dem Abschluss
Azarmi gab bekannt, dass Elastic eine Kompatibilität von 90 % mit PromQL – dem Standard-Abfragesprache unter Prometheus-Nutzern – erreicht hat und „auf Kurs ist, 100 % zu erreichen“. Dies ist ein aussagekräftiger Datenpunkt, da er die Wechselkosten für die große bestehende Basis von Prometheus-Nutzern senkt. Dies ist eine Kohorte, die das Management explizit als eines von drei Go-to-Market-Zielen identifizierte, neben dem bestehenden Kundenstamm für Logs und solchen Kunden, die derzeit von anderen Metriken-Anbietern bei der Preisgestaltung für höhere Datenaufbewahrung oder Kardinalität „bestraft“ werden.
KI-Workloads gelten als Nachfragetreiber, nicht nur als Feature
Das Management brachte die Einführung des Metrik-Produkts wiederholt mit der operativen Belastung durch agentische KI in Verbindung. Azarmi argumentierte, dass agentenbasierte Workloads sich strukturell von der traditionellen Anwendungsverwachung unterscheiden, da Schritte zur Entscheidungsfindung, Tool-Aufrufe und Abfragezyklen im Gegensatz zu den klar definierten Transaktionspfaden von Altanwendungen unvorhersehbar sind. „KI führt regelrecht zu einer Explosion von Metriken“, sagte er und verwies auf GPU-Zyklen, LLM-Aufrufe und Agenten-Harnesses als neue Signal-Kategorien, die überwacht werden müssen. Krishnan bekräftigte dies in der Analysten-Fragerunde und wies darauf hin, dass die Ausgaben für Observability durch KI auf zwei verschiedene Arten angetrieben werden: Infrastruktur-Monitoring für den eigentlichen Rechenleistungsaufbau und eine neuere Kategorie des Monitoring auf Agentenebene, die sich auf Sicherheit und Verhalten konzentriert und nicht nur auf die Betriebszeit.
Adoption verläuft schrittweise, nicht sprunghaft
Zur kommerziellen Entwicklung äußerte sich Krishnan bemerkenswert offen und erklärte, dass die kurzfristige Einführung kein steiles Wachstum („Hockey Stick“) aufweisen wird. Er teilte Analysten mit, dass das frühe Engagement von Design-Partnern „äußerst positiv“ gewesen sei, warnte jedoch, dass Unternehmenskaufzyklen bedeuten, dass die Annahme eher einem schrittweisen Aufbau („Ramp-Style“) als einem sofortigen Wendepunkt folgen wird. Etwa zwei Drittel des heutigen Bestandsgeschäfts von Elastic entfallen auf Logs und SIEM, und Krishnan bestätigte, dass die kurzfristige Chance des Metrik-Produkts vor allem darin liegt, einen Neuverkauf an diesen bestehenden SRE-fokussierten Kundenstamm zu binden, bei dem Infrastruktur-Monitoring-Tools von Drittanbietern oft bereits einen höheren wirtschaftlichen Wert als ELASTICs Log-Analytics-Verträge besitzen. Das Management lehnte es ab, einen spezifischen Umsatzzuwachs pro Kunde zu quantifizieren; Krishnan sagte lediglich: „Es ist noch früh... bleiben Sie dran.“
Ausgabenkonsolidierung plus eine neue Ebene zusätzlicher Nachfrage
Als Reaktion auf eine Frage von Thomas Blakey von Cantor Fitzgerald, ob der Vorstoß bei Metriken eine Verschiebung von Marktanteilen zulasten von Mitbewerbern oder rein zusätzliches Ausgabenvolumen darstellt, charakterisierte Krishnan es als beides. „Es gibt definitiv einen Aspekt der Ausgabenkonsolidierung“, sagte er, fügte jedoch hinzu, dass das KI-getriebene Infrastrukturwachstum Kunden dazu veranlasse, bestehende Tools insgesamt neu zu bewerten. Dies schaffe das, was er als „das gewissermaßen Sahnehäubchen oben drauf“ jenseits der reinen Anbieterkonsolidierung bezeichnete. Die in das System einströmenden Metrik-Datenvolumina seien von einer Größenordnung, die mit den Log-Volumina vergleichbar sei, obwohl die Aufbewahrungsfristen für Metriken tendenziell kürzer ausfallen.
Übernahme von Deductive AI und Oktober-Produkt-Event klingen als Katalysatoren an
Azarmi verwies auf die jüngste Übernahme von Deductive AI – einem auf agentengestützte Ursachenanalyse spezialisierten Unternehmen –, die in eine größere Observability-Ankündigung einfließt, die für das Event von Elastic am 8. Oktober in New York in New York geplant ist. Er beschrieb den Ehrgeiz des Unternehmens, KI-Agenten eine Ursachenanalyse (Root-Cause-Analysis) über Metriken, Traces, Logs und vektorisierte Wissensdatenbanken hinweg innerhalb einer einzigen integrierten Plattform zu ermöglichen. Diese Fähigkeit sei, so Azarmi, nur deshalb möglich, weil alle vier Datentypen nun in derselben Architektur liegen. Investoren sollten das Oktober-Event als den nächsten Prüfstein betrachten, um Belege dafür zu erhalten, dass sich die Metrik-Einführung in Buchungen niederschlägt, angesichts des Eingeständnisses des Managements, dass quantifizierbare Adoptionsmetriken noch nicht vorliegen.
Kundenbeleg von Norion Bank
In einem Kundenvideo wurde die Norion Bank vorgestellt, ein achtjähriger Elastic-Nutzer, dessen Observability-Ingenieure berichteten, dass frühe Tests der neuen Zeitreihen-Datenströme innerhalb eines Monats nach der Implementierung „erhebliche“ Speichereinsparungen brachten. Ein Ingenieur bot eine treffende Formulierung des Nutzenversprechens der Kategorie unter Budgetdruck: „Die Frage lautet oft, wie wir das billiger machen können, anstatt wie uns das schneller aus Störfällen herausholt.“ Genau dieses Spannungsverhältnis zwischen Kosteneinsparung und Erkennungsgeschwindigkeit ist der Kompromiss, den Elastic mit seinem konsolidierten Metrikspeicher zu lösen versucht, obwohl die Kommentare der Bank auch unterstrichen, dass Compliance-Vorgaben wie DORA und GDPR Aufbewahrungs- und Prüfungsanforderungen mit sich bringen, die einfache Kostensenkungsnarrative rund um Telemetriedaten verkomplizieren.