• Elasticsearch ist ein Prometheus-kompatibles Metrik-Backend – Prometheus Remote Write und PromQL funktioniert jetzt nativ in Kibana, keine Übersetzungsschicht erforderlich.

• Metriken landen in der spaltenorientierten TSDS-Architektur von Elasticsearch und speichern Daten bis zu 2,5 × effizienter als Prometheus sowie 2 × effizienter als ClickHouse.

• ES|QL-Zeitreihenabfragen werden bis zu 30 × schneller ausgeführt als bei Prometheus bei Gauge-Durchschnittswerten und Counter-Raten, einschließlich Workloads mit hoher Kardinalität.

• Elastic kostet ungefähr 50 % weniger als Datadog – ohne Klassifizierung benutzerdefinierter Metriken und ohne kardinalitätsbasierte Abrechnung.

• Grafana kann Elasticsearch direkt über die native Prometheus-API abfragen, wobei Sie Ihre Visualisierungsebene beibehalten, während das Backend ersetzt wird.

• Kubernetes- und AWS-Überwachung werden mit vorab erstellten Dashboards, Alert-Vorlagen, ML-Anomaliejobs und Inhalten für agentische Untersuchungen bereitgestellt, die direkt beim Ingest bereitstehen. Zusätzlich sind Skills und MCP-Apps verfügbar.

• Einheitliches Backend für Metriken, Logs und Traces, das agentische Untersuchungen ermöglicht, ohne Kontext über Tools hinweg zusammenzusetzen.

• Die Erkundung von Metriken in Discover ermöglicht es jedem, sofort mit dem Abfragen und Analysieren von Metriken zu beginnen, ohne dass Abfragesprache-Kenntnisse erforderlich sind.

• Individuell anpassbare Dashboards lassen sich schnell und flexibel erstellen – Dashboards-as-Code, KI-gestützte Dashboard-Erstellung, Steuerelemente für Variablen und einklappbare Bereiche bedeuten weniger Zeitaufwand für die Erstellung und mehr Zeit für die Untersuchung.

• Migrationstools zur einfachen Migration von Dashboards und Alerting-Regeln/Monitoren aus Datadog und Grafana.

Elasticsearch-Metriken konkurrieren jetzt in jeder für SREs wichtigen Dimension: Sie können es sich leisten, jede Metrik in voller Auflösung aufzubewahren, sie bis zu 30 x schneller als Prometheus abzufragen, 50 % weniger als bei Datadog zu zahlen, Dashboards und Alerting-Regeln einfach von Grafana oder Datadog zu migrieren und von einem Alert zur Grundursache zu gelangen, ohne Kontext zwischen nicht verbundenen Tools zusammenführen zu müssen. Im weiteren Verlauf dieses Blogposts werden die einzelnen dieser Punkte ausführlich erläutert.

Elasticsearch-Metrik-Performance: 30 × schneller als Prometheus und Mimir

Datadog und Prometheus erzwingen denselben Kompromiss: Daten mit hoher Kardinalität verwerfen oder zusehen, wie die Kosten in die Höhe schnellen. SREs, die Kubernetes, AWS oder eine beliebige Infrastruktur mit hoher Kardinalität verwalten, kennen die genaue Ausprägung dieses Problems. Die Kubernetes-Labels, ephemeren Pod-Daten und feingranularen OTel-Dimensionen, die bei einem Vorfall am wichtigsten sind, müssen als Erstes weichen, wenn die Budgets knapper werden.

Elastic hat den Zeitreihendaten-Speicher und die ES|QL-Compute-Engine zu einer vollständig spaltenorientierten Metriken-Engine umgebaut. Das Hinzufügen eines neuen Kubernetes-Labels, eines neuen AWS-Instanz-Tags oder einer neuen Anwendungsdimension belastet das System nicht; es verursacht weit geringere Kosten als Systeme, die jedes Label indexieren. OTel-, Prometheus- und anwendungsdefinierte Metriken landen alle in voller Auflösung im selben spaltenorientierten Backend – mit Logs, Traces und Metriken in einem einzigen Speicher. Keine Daten verworfen, keine Aufbewahrungsdauer verkürzt.

Elasticsearch speichert Metriken bis zu 2,5-mal effizienter als Prometheus (Ergebnisse können aufgrund von Faktoren wie Kompaktierung abweichen) und 2-mal effizienter als ClickHouse. Die Abfrageleistung über ES|QL ist bis zu 30-mal schneller als Prometheus bei Gauge-Durchschnittswerten und Counter-Raten, einschließlich Workloads mit hoher Kardinalität, bei denen Mitbewerber ins Stocken geraten. Der Architekturbeitrag beschreibt, wie TSDS aufgebaut ist und warum das spaltenbasierte Layout diese Ergebnisse liefert.

| | | | | | :------------------------: | :----------------: | :--------------: | :----------------: | | Dimension | vs. Prometheus | vs. Mimir | vs. ClickHouse | | Abfrageleistung (ES|QL) | Bis zu 30 × schneller | Bis zu 30 × schneller | Bis zu 8 × schneller | | Speichereffizienz | Bis zu 2,5-mal besser | Gleichauf | 2-mal besser |

Der wesentliche architektonische Unterschied besteht darin, dass Elasticsearch-Metriken keinen In-Memory-Zustand pro Zeitreihe pflegen, der mit der Kardinalität skaliert, sodass das Hinzufügen von Tausenden neuer Kubernetes-Pod-Labels oder OTel-Dimensionen den Arbeitsspeicherdruck nicht in die Höhe treibt.

OTel-, Prometheus-native und anwendungsdefinierte Metriken werden alle auf dieselbe Weise in voller Auflösung gespeichert und schnell abgefragt – zur Hälfte der Kosten von Datadog.

Preise für Elastic Observability-Metriken ohne die Gebühren für benutzerdefinierte Metriken von Datadog

Die Kosten für Beobachtbarkeit sind der Grund Nr. 1, warum Teams die Plattform wechseln. Für Datadog-Kunden lässt sich das Problem auf einen einzigen Preismechanismus zurückführen: benutzerdefinierte Metriken. Jeder benutzerdefinierte Wert außerhalb der integrierten Integrationen von Datadog wird als benutzerdefinierte Metrik eingestuft und zu einem höheren Tarif abgerechnet. Dazu gehören auch die Daten mit hoher Kardinalität, die von Kubernetes-, OpenTelemetry- und cloudnativen Workloads standardmäßig generiert werden. Je granularer Ihre Instrumentierung ist, desto schneller summieren sich die Kosten. Teams, die moderne Infrastruktur betreiben, stoßen schnell an diese Grenze, und die Reaktion ist vorhersehbar: Daten verwerfen, Aufbewahrungsfristen verkürzen, den Kontext verlieren, der bei einem Vorfall am wichtigsten ist.

Elasticsearch-Metriken heben diese Klassifizierung auf. Jede Metrik kostet gleich viel – ganz ohne Aufschläge pro Metrik, ohne kardinalitätsbasierte Abrechnung und ohne erzwungene Rollups. Sie behalten jede Metrik in voller Auflösung – ohne Überraschungsrechnung am Monatsende. Und da Elastic nur 50 % der Kosten von Datadog ausmacht, ändert sich das Gespräch mit der Finanzabteilung: Es geht nicht mehr darum, welche Daten Sie verwerfen mussten, um das Budget einzuhalten, sondern darum, was Sie herausgefunden haben, weil Sie alles behalten haben. Das ist auch der Grund, warum die KI-Untersuchung funktioniert. Im Gegensatz zum fragmentierten LGTM-Stack von Grafana ist der Kontext bereits vereinheitlicht, wenn der Alert ausgelöst wird, und muss nicht manuell über voneinander getrennte Tools hinweg zusammengestellt werden.

Native Unterstützung von Prometheus und PromQL in Elasticsearch

Die meisten SRE-Teams betreiben keine saubere Telemetrie-Pipeline mit einheitlichem Format. Prometheus ist tief in Anwendungen, Services, Plattformen und Automatisierungen eingebettet. Die Migration von Metrik-Backends bedeutete in der Vergangenheit das Neuschreiben von Abfragen, das Neuerstellen von Dashboards und die Umschulung von Engineers – Reibungsverluste, die so groß sind, dass Teams lieber auf Plattformen bleiben, aus denen sie herausgewachsen sind, anstatt diesen Prozess zu durchlaufen.

Elasticsearch-Metriken haben den Großteil dieser Reibungspunkte beseitigt. Prometheus-Metriken treffen über Prometheus Remote Write ein und landen ohne semantische Änderungen im selben spaltenorientierten Speicher, wodurch die vollständige Metrikgenauigkeit durchgängig erhalten bleibt. Richten Sie sie auf Elasticsearch statt auf Mimir aus, und die Daten fließen. Keine Übersetzungsebene, keine Änderungen an bestehenden Scrape Configs.

PromQL funktioniert jetzt nativ in Kibana, sodass Entwickler, die mit PromQL arbeiten, ihre Arbeitsweise nicht ändern müssen. Bestehende PromQL-Abfragen, Dashboards und Alert-Regeln werden direkt in Kibana migriert. 

PromQL-Abfragen funktionieren unverändert auf Elasticsearch

Wenn Ihr Team bereits PromQL schreibt, muss sich nichts ändern. Diese Abfragen werden unverändert für Elasticsearch als Ihr Backend ausgeführt – einfach kopieren, einfügen und loslegen.

CPU-Auslastungsrate (auf Container-Ebene) Die CPU-Rate pro Sekunde über alle Container hinweg, gruppiert nach Pod. Nützlich, um zu erkennen, welche Pods während eines Vorfalls CPU verbrauchen.

PROMQL sum by (pod) (rate(container_cpu_usage_seconds_total[5m]))

Arbeitsspeicher-Arbeitssatz (Container-Ebene) Derzeit aktiv genutzter Arbeitsspeicher pro Container – der entscheidende Wert für das OOM-Risiko, nicht der gesamte zugewiesene Arbeitsspeicher.

PROMQL sum by (container) (avg_over_time(container_memory_working_set_bytes[5m]))

HTTP-Anforderungsrate (auf Anwendungsebene) Anfragendurchsatz pro Sekunde, gruppiert nach Instanz. Ein standardmäßiges erstes Signal bei der Untersuchung von Latenz- oder Fehlerspitzen.

PROMQL sum by (instance) (rate(http_requests_total[5m]))

Alle drei folgen der standardmäßigen PromQL-Syntax. Wenn Sie Elasticsearch als Ihr Backend verwenden, werden sie ohne Änderungen ausgeführt. Die vollständige Syntaxreferenz und Informationen über den abgedeckten Umfang finden Sie in der PromQL-Support-Dokumentation.

Die native Prometheus-API macht Elasticsearch zu einem vollständig Prometheus-kompatiblen Backend. Jedes Prometheus-kompatible Frontend (einschließlich Grafana) kann Elasticsearch direkt abfragen, sodass Teams, die Grafana als ihre Visualisierungsebene beibehalten und gleichzeitig auf Elasticsearch konsolidieren möchten, genau das tun können, ohne bestehende Dashboards oder Alert-Regeln zu ändern.

Wenn SREs tiefer einsteigen müssen, als PromQL erlaubt, funktioniert ES|QL über Metriken, Logs und Traces hinweg in einer einzigen Schnittstelle. Der Befehl „TS“ übernimmt die Besonderheiten von Zeitreihen: Counter-Raten, Gauge-Durchschnittswerte, Zeitfensterfunktionen und mehrstufige Aggregationen über hochkardinale Dimensionen hinweg. Dieselbe Abfrage, die eine CPU-Counter-Rate abruft, kann mit Logs desselben Hosts verknüpft werden und das Deployment-Ereignis anzeigen, das der Spitze vorausging. Kein Wechsel des Tools, keine neue Abfragesprache. Die Abfragesprache, die Dashboards, die Alert-Regeln, die Visualisierungsebene – all das wird übernommen. Das Einzige, was sich ändert, ist, dass Elasticsearch das einzige Backend ist, das alles antreibt.

Elastic Observability: Dashboards, Alerts und Infrastrukturinhalte out of the box

Bei den meisten Beobachtbarkeit-Anbietern müssen Sie alles von Grund auf neu erstellen. Elastic Observability hat diesen Bedarf in drei Bereichen reduziert:

Erkundung von Metriken in Discover. Die neue Erfahrung bei der Erkundung von Metriken in Elasticsearch ermöglicht es SREs, Metriken auf derselben Schnittstelle zu erkunden, die auch für Logs verwendet wird – kein Tab-Wechsel, keine doppelten Abfragen. Verbinden Sie eine OTel-Pipeline oder Prometheus Scrape Config, öffnen Sie Streams, und jede Metrik im Datenstrom wird sofort als Zeitreihendiagramm dargestellt. Kein Dashboard zu erstellen, keine Abfrage zu schreiben. Hier können Teams Daten validieren, Muster erkennen, anhand einer Live-Ansicht der fließenden Daten Alerts und SLOs erstellen und diese mit Logs, Traces und anderen indexierten Daten in Elasticsearch querverknüpfen.

Dashboards. Kibana-Dashboards verfügen jetzt über einklappbare Panels mit verzögertem Laden, sodass nicht unmittelbar sichtbare Panels erst bei Bedarf Abfragen generieren, sowie über ES|QL-Steuervariablen, mit denen SREs Visualisierungen über Dropdown-Menüs manipulieren können, ohne neue Abfragen zu schreiben. Dashboards-as-code wird ebenfalls bereitgestellt und ermöglicht versionskontrollierte Dashboard-Definitionen, die als Vorlagen verwendet, geteilt und programmatisch umgebungsübergreifend bereitgestellt werden können.

Vorkonfigurierte Infrastrukturinhalte.  Elastic wird mit zwei neuen Infrastruktur-OOTB-Erlebnissen bereitgestellt:

• Die neue Kubernetes-Integration wird mit hierarchischen Dashboards, Vorlagen für Alert-Regeln, Jobs zur ML-Anomalieerkennung sowie dem Kontext und den Prompts bereitgestellt, die für eine KI-gestützte Ursachenanalyse erforderlich sind – alles vorkonfiguriert und einsatzbereit, sobald Daten fließen. 

• Das AWS-Infrastruktur-Monitoring folgt demselben Muster: OOTB-Inhalte für Kern-AWS-Services werden beim Ingest aktiviert, sodass Teams nicht jedes Mal bei null anfangen müssen, wenn ein neuer Service oder Account online geht. Derselbe Ansatz gilt auch für Datenbanken und andere Kerninfrastruktur – die Plattform wird vorkonfiguriert und nicht als leere Leinwand geliefert.

Agentische Untersuchungen über Ihre Infrastruktur hinweg mit Elastic Observability

Elasticsearch korreliert Metriken, Logs und Traces in einem einzigen Backend, sodass der Untersuchungskontext zusammengestellt ist, bevor ein Engineer benachrichtigt wird.

Der schwierige Teil ist 2 Uhr morgens. Eine RDS-Instanz, die an Verbindungslimits stößt und vorgelagerte Dienste aushungert. Eine Auto-Scaling-Gruppe, die Health-Checks aus einem Grund nicht besteht, der tief in den Anwendungs-Logs verborgen ist. Ein Pod-Neustart, der sich kaskadierend über einen Namespace ausbreitet.

In einem Grafana-LGTM-Stack öffnen Sie drei Tabs, bevor Sie genügend Kontext haben, um eine Hypothese aufzustellen.

In Datadog ist der Kontext einheitlich, aber die KI ist eine Blackbox: kein BYO-LLM, keine Optionen für Datenresidenz.

In Elastic teilen sich Metriken, Logs und Traces ein einziges Backend und ein gemeinsames Schema, sodass der Untersuchungskontext bereits zusammengestellt ist, wenn der Alert ausgelöst wird – keine manuelle Korrelation über Tools hinweg, kein Kontextverlust bei der Übersetzung zwischen Abfragesprachen. Die ML-Anomalieerkennung wird automatisch für Infrastrukturmetriken (Kubernetes, AWS, Datenbanken) ausgeführt, sodass die Untersuchung von einer bewerteten Anomalie mit Kontext dazu ausgeht, was typisch ist, was sich geändert hat und wie schwerwiegend die Abweichung ist, und nicht nur von einer einfachen Schwellenwertüberschreitung.

Wenn ein Alert ausgelöst wird, korreliert der Untersuchungs-Workflow von Elastic Signale, stellt den Kontext zur Ursache zusammen und zeigt empfohlene nächste Schritte an, bevor jemand alarmiert wird. Der Beitrag zur agentischen Kubernetes-Beobachtbarkeit führt durch ein vollständiges End-to-End-Beispiel. Der Leitfaden zur EKS-Fehlerbehebung zeigt, wie Agent Builder und MCP für eine vollständige Ursachenanalyse über EC2, EKS und zugehörige AWS-Services hinweg zusammenarbeiten.

Zusätzlich zur Untersuchung von Problemen in Elastic Observability können Sie Claude, Cursor, VS Code oder Ihr bevorzugtes Tool verwenden, um Probleme mithilfe von MCP-Apps und Agent-Skills von Elastic zu analysieren. Die Observability MCP-App erweitert die Analyse dorthin, wo Ihr Team bereits arbeitet. Wenn Ihr Team Untersuchungen in Claude, Cursor oder VS Code durchführt, werden dieselben Untersuchungsfunktionen (Infrastruktur-Zustands-Rollup, Dienstabhängigkeitsgraph, Anomaliedetails, Schadensradius-Analyse) als interaktive Ansichten direkt in der Konversation gerendert. Weder Grafana noch Datadog bieten dies.

• Observability MCP App – Verbindet Claude, Cursor, VS Code oder jedes MCP-kompatible Tool direkt mit Ihren Elasticsearch-Daten, sodass Infrastrukturzustand, Serviceabhängigkeiten und Anomaliekontext als interaktive Ansichten in der Konversation erscheinen, ohne dass Sie das Tool Ihrer Wahl verlassen müssen. Erfahren Sie, wie es mit Kubernetes funktioniert.

• Agent-Skills – Vorgefertigte Skills für Kubernetes, AWS und andere Kerninfrastruktur ermöglichen jedem Agenten – in Elastic oder Ihrem eigenen –, strukturierte Untersuchungen Ihrer Beobachtbarkeitsdaten ohne individuelles Prompt-Engineering. Fügen Sie sie in Claude, Cursor oder Ihre eigene Agenten-Pipeline ein, und sie funktionieren out of the box. Entdecken Sie die Beobachtbarkeit-Skills oder durchsuchen Sie die Skills-Bibliothek auf GitHub.

Migration von Datadog oder Grafana zu Elastic Observability

Der häufigste Grund, warum SRE-Teams die Beobachtbarkeitsplattform nicht wechseln, ist die Migration. Die Migration von Alert-Regeln aus mehreren Jahren, Hunderten von Dashboards und in Runbooks eingebetteten PromQL-Abfragen ist eine gewaltige operative Aufgabe, und die Kosten für die Pflege paralleler Stacks währenddessen summieren sich von Tag zu Tag.

Die Observability Migration Platform übernimmt die Übersetzung automatisch. Verweisen Sie die CLI oder Claude/Cursor (mit den Agent-Skills von Elastic) auf Ihre Datadog-Organisation oder Grafana-Instanz und das Tool konvertiert unterstützte Dashboards, Alert-Regeln und PromQL-Abfragen in Kibana-native Ausgaben. Mit dem Tool können Sie sehen, was vollständig migriert wurde, was Anpassungen erforderte und was Ihrerseits erforderlich ist, um alles zu migrieren. Sie übertragen das, was Sie bereits erstellt haben.

Auf der Ingest-Seite sorgt Prometheus Remote Write dafür, dass die Pipeline keine Änderungen erfordert. Scrape Configs verweisen auf Elasticsearch anstelle eines anderen Prometheus-kompatiblen Backends, und die Daten landen im selben spaltenorientierten Speicher. Workflows, Abfragen und Alert-Konfigurationen werden ohne Änderungen übernommen. Für Teams, die Grafana während oder nach der Migration als Visualisierungsebene beibehalten möchten, bedeuten die native Prometheus-API und die PromQL-Unterstützung in Kibana, dass der Übergang schrittweise erfolgen kann, anstatt alles auf einmal umzustellen.

Elasticsearch als Backend für Grafana

Für Teams, die noch nicht bereit sind, Grafana zu verlassen, ist das Ersetzen des Backends ein eigenständiger Migrationspfad, und abhängig von Ihrem Workflow gibt es zwei Möglichkeiten, dies zu tun.

Wenn Ihr Team heute Prometheus ausführt, ist die Prometheus-Datenquelle von Grafana der Weg des geringsten Widerstands. Elasticsearch bietet jetzt eine native Prometheus-kompatible API, sodass Sie das vorhandene Prometheus-Plugin von Grafana direkt auf Elasticsearch verweisen können. Keine Sidecars, keine Adapter, keine Pipeline-Änderungen erforderlich. Bestehende PromQL-Dashboards, Alert-Regeln und Variablen-Dropdowns funktionieren ohne Anpassung, einschließlich des Metrics Drilldown-Explorers von Grafana. Fügen Sie Elasticsearch als „remote_write“-Ziel in Ihrer Prometheus-Konfiguration hinzu und tauschen Sie die Datenquellen-URL aus. Das ist für die meisten Teams bereits die gesamte Migration. Sehen Sie sich die End-to-End-Einrichtungsanleitung an.

Für Teams, die noch weiter gehen und Protokolle, Metriken und Traces gemeinsam über einen einzigen Grafana-Abfrage-Editor abfragen möchten, wird das offizielle Grafana-Elasticsearch-Plugin jetzt mit ES|QL-Support bereitgestellt. Dies ermöglicht signalübergreifende Korrelationen direkt in Grafana, wobei Elasticsearch alle drei Datentypen in einem einheitlichen spaltenbasierten Backend verarbeitet. Erfahren Sie, wie Sie es einrichten.

So oder so behalten Sie Grafana bei, ersetzen Mimir und Loki und profitieren darunter vollständig von dem spaltenbasierten Speicher und der Abfrageleistung von Elasticsearch. Jahre operativer Arbeit – bewahrt. Die Migration, die die Teams bisher aufgeschoben haben, wird zu einem Backend-Wechsel.

Was ist GA und was befindet sich in der technischen Vorschau

| Funktionalität | Status | | ----------------------------------------- | ------------ | | Engine für spaltenorientierte Metriken (TSDS) | GA | | ES|QL-Zeitreihenunterstützung | GA | | PromQL-Support in Kibana | GA | | Prometheus Remote Write-Ingest | GA | | OOTB-Erlebnis für Kubernetes-Infrastruktur | GA | | OOTB-Erlebnis für AWS-Infrastruktur | Technische Vorschau | | Observability MCP-App | Technische Vorschau | | Agent-Skills | Technische Vorschau | | Observability Migration Platform | Technische Vorschau |

Die einzelnen im Text verlinkten Beiträge behandeln die Besonderheiten von GA im Vergleich zur Vorschau sowie bekannte Einschränkungen.

All das (die Columnar-Metrics-Engine, natives PromQL, agentische Untersuchungen und Migrationstools) läuft über die drei Deployment-Modi von Elastic: serverless, Elastic Cloud und selbstverwaltet. Datadog bietet keine On-Prem-Option; Grafana Cloud beschränkt seine wertvollsten Features auf gehostete Deployments. Mit Elastic entscheiden Sie, wo Ihre Daten gespeichert sind.

Elastic Observability: geringere Kosten ohne Datenverlust

Moderne Cloud-Infrastruktur hat das Beobachtbarkeitsmodell, das auf separaten Tools für separate Signale basiert, zunichtegemacht. Die Kosten sind beträchtlich: doppelte Tool-Rechnungen, manuelle Korrelation während Vorfällen und verworfene Daten, nur um im Budget zu bleiben.

Ein einziges Backend, das jedes Signal effizient speichert, bedeutet, dass Sie alles behalten, was Sie benötigen, ohne die damit üblicherweise verbundenen Kosten. Das ist eine andere Art von Gespräch mit der Finanzabteilung: nicht „Wir mussten Daten verwerfen, um im Budget zu bleiben“, sondern „Das haben wir herausgefunden.“ Die KI bekommt das Gesamtbild, weil es nur ein einziges Bild gibt, und die Plattform bietet genügend vorgefertigte Inhalte, um vom ersten Tag an nützlich zu sein – nicht erst nach wochenlanger Dashboard-Arbeit.

Das ist möglich, weil Elasticsearch anders aufgebaut ist als die Plattformen, die Sie wahrscheinlich ersetzen:

• Spaltenorientierter Metrikspeicher speichert Metrikdaten hocheffizient im TSDS-Indexmodus. 

• Native Prometheus-Kompatibilität bedeutet, dass bestehende Scrape Configs, PromQL-Abfragen und Dashboards ohne Umschreiben funktionieren.

• Vereinheitlichte Metriken, Logs und Traces in einem einzigen Backend bedeuten, dass der Untersuchungskontext zum Abfragezeitpunkt zusammengestellt wird und nicht manuell über mehrere Tabs hinweg.

• Suche und Analytik in derselben Engine — ein invertierter Index für Logs, ein spaltenbasierter Index für Metriken, gemeinsam abgefragt mit ES|QL.

• Agentische Untersuchungen, die Signale korrelieren, Anomalien aufdecken und Abhilfemaßnahmen vorschlagen, bevor jemand alarmiert wird.

• Serverlos, Elastic Cloud oder selbstverwaltet – Sie entscheiden, wo Ihre Daten liegen, was Datadog nicht bieten kann.

Das Kostengespräch mit der Finanzabteilung dreht sich um das, was Sie gefunden haben, nicht um das, was Sie ausgegeben haben.

Erste Schritte

• Kostenlose Testversion starten

• Dokumentation zu Elastic Observability

• Elastic Observability Labs

Häufig gestellte Fragen

Ist Elasticsearch jetzt eine produktionsreife Metrikplattform?

Ja. Seit Juni 2026 bietet Elasticsearch eine neu entwickelte spaltenorientierte Speicher-Engine, die speziell für Zeitreihendaten konzipiert wurde, nativen Prometheus Remote Write-Ingest, PromQL-Unterstützung in Kibana, ES|QL-Zeitreihenabfragen sowie sofort einsatzbereite Infrastruktur-Dashboards für Kubernetes und AWS. Die spaltenorientierte Metrik-Engine, die ES|QL-Zeitreihenunterstützung, PromQL und der Prometheus-Ingest sind in Elastic Serverless allgemein verfügbar und bald GA in Elastic Cloud Hosted.

Wie schneidet Elasticsearch im Vergleich zu Datadog hinsichtlich der Metrikkosten ab?

Bei vergleichbaren Metrik-Workloads kostet Elastic Observability Serverless deutlich weniger als Datadog – in anschaulichen Beispielen auf Basis veröffentlichter Listenpreise mehr als 50 % weniger und oft fast zwei Drittel weniger. Der Unterschied ist strukturell bedingt: Datadog rechnet primär pro Host ab und berechnet mit zunehmender Instrumentierung zusätzliche Gebühren für benutzerdefinierte Metriken und Container. Der Kostenunterschied ist genau bei den Workloads am größten, bei denen Datadog am meisten abrechnet: Umgebungen mit hoher Kardinalität und dichter Instrumentierung wie Kubernetes und OTel.

Wie schneidet die Metrik-Performance von Elasticsearch im Vergleich zu Prometheus und Grafana Mimir ab?

ES|QL-Abfragen auf Elasticsearch werden bei Gauge-Durchschnitten und Counter-Raten, einschließlich Workloads mit hoher Kardinalität, bis zu 30 × schneller ausgeführt als auf Prometheus und Mimir. Elasticsearch speichert OTel-Metriken mit 3,75 Bytes pro Datenpunkt; bis zu 2,5 × effizienter als Prometheus und 2 × effizienter als ClickHouse.

Können Teams von Datadog oder Grafana zu Elasticsearch migrieren, ohne alles neu aufzubauen?

Ja. Die Observability Migration Platform von Elastic konvertiert Dashboards und Alert-Regeln von Datadog und Grafana und migriert PromQL-Abfragen unverändert nach Kibana. Teams können Grafana auch als Visualisierungsebene beibehalten und gleichzeitig das Backend durch Elasticsearch ersetzen, indem sie die native Prometheus-API und den PromQL-Support in Kibana nutzen.

Was unterscheidet Elasticsearch von Grafana bei der Metrik-Beobachtbarkeit?

Elasticsearch speichert Metriken, Logs und Traces in einem einzigen einheitlichen Backend mit einer Abfragesprache (ES|QL), während der LGTM-Stack von Grafana Metriken (Mimir/Prometheus) und Logs (Loki) auf separate Backends verteilt, die separate Abfragesprachen erfordern. Elasticsearch stellt zudem agentische Untersuchungsfunktionen bereit, darunter KI-Agent, Workflows, MCP-App und Agent-Skills – ein umfassenderes Funktionspaket als Grafana. 

Unterstützt Elasticsearch Prometheus und PromQL nativ?

Ja, auf zwei unterschiedliche Arten. Erstens akzeptiert Elasticsearch Prometheus-Metriken über Prometheus Remote Write und macht eine native Prometheus-kompatible API verfügbar, sodass es als Backend für jedes Prometheus-kompatible Frontend – einschließlich Grafana – dienen kann. Zweitens unterstützt Kibana PromQL nativ, sodass bestehende Abfragen, Dashboards und Alert-Regeln direkt in Kibana ohne Übersetzungsschicht oder Anpassungen ausgeführt werden können.

Welche Inhalte für das Infrastruktur-Monitoring werden out of the box mit Elastic Observability bereitgestellt?

Elastic stellt vordefinierte Dashboards, Alert-Vorlagen und ML-Anomalieerkennungsjobs für Hunderte von Infrastrukturintegrationen bereit, die Hosts, Container, Cloud-Dienste, Datenbanken, Netzwerkgeräte und mehr abdecken. Speziell für Kubernetes und AWS umfasst die Plattform zudem Inhalte für agentische Untersuchungen wie Agent-Skills und eine Observability MCP-App, mit der Teams Untersuchungen direkt über Claude, Cursor oder VS Code ausführen können. All dies ist beim Ingest verfügbar, ohne dass eine Konfiguration erforderlich ist.

In Teil 1 haben wir behandelt, wie die Kubernetes-Integration von Elastic Telemetriedaten über den EDOT Collector in Elasticsearch versendet. In diesem Beitrag gehen wir noch einen Schritt weiter mit einem MCP-App-Server (Model Context Protocol), der diese Telemetriedaten als von KI aufrufbare Tools bereitstellt – komplett mit interaktiven React-Benutzeroberflächen, die inline gerendert werden. Wir behandeln außerdem, wie Sie mit Elastic Workflows noch weiter gehen können: automatisierte Runbooks, die den gesamten Ursachenanalyse-Ablauf vom Alert bis zum Behebungsvorschlag übernehmen.

Observability MCP-App, die dort rendert, wo Sie arbeiten

Die Elastic Observability MCP-App (technische Vorschau) liefert sechs Ansichten, jeweils eine pro Tool. Jede wird inline gerendert, wenn das Tool eine Antwort zurückgibt, und jede stellt konkrete Prompts für die nächsten Schritte als anklickbare Schaltflächen bereit, sodass Sie nicht raten müssen, wie Sie richtig fortfahren. MCP-Apps gehen über eigenständige Agenten-Workflows hinaus – sie rendern interaktive Live-Ansichten direkt in Ihrem Chat oder Ihrer IDE, inline im Gespräch, ohne einen Kontextwechsel zu Kibana.

Cluster-Health-Rollup

Fragen Sie „Was ist defekt?“ oder „Gib mir einen Statusbericht“ und erhalten Sie eine Übersicht auf einen Blick: allgemeiner Zustand, beeinträchtigte Dienste mit Begründungen, die größten Pod-Speicher-Verbraucher, Aufschlüsselung des Schweregrads der Anomalien und der Service-Durchsatz – alles in einer einzigen Inline-Ansicht.

Die Ansicht passt sich an die Gegebenheiten Ihres Deployments an. APM liefert Ihnen Service-Health-Informationen. Kubernetes-Metriken fügen Pod- und Knoten-Kontext hinzu. ML-Jobs integrieren Anomalien. Wenn ein Signal nicht vorhanden ist, teilt Ihnen die Ansicht mit, was fehlt, anstatt fehlzuschlagen. Wir beginnen mit einem Statusbericht des Kubernetes-Clusters:

Kombinierte Berichte wie die Statusübersicht bieten eine kompakte Datendarstellung mit Detailerweiterung, sodass Sie selbst bestimmen können, wie viele Informationen Sie auf einmal anzeigen lassen möchten. Vorgeschlagene Untersuchungsaktionen bieten sowohl Hilfestellung zu spezifischen zurückgegebenen Informationen als auch eine Orientierung für Nutzer bezüglich weiterer auszuführender Tools.

Dienstabhängigkeitsgraph

Fragen Sie „Welche Services kommunizieren mit Checkout?“ oder „Zeig mir die Topologie“ und Sie erhalten einen geschichteten Abhängigkeitsgraphen – vorgelagerte Aufrufer, nachgelagerte Abhängigkeiten, Protokolle, Anrufvolumen und Latenz pro Edge. Fahren Sie mit dem Mauszeiger über einen Edge, um den vollständigen Aufrufpfad hervorzuheben. Bitten wir Claude, uns die Serviceabhängigkeiten des Frontends zu zeigen („Zeig mir die Serviceabhängigkeiten des Frontends“):

Zoomen Sie, schwenken Sie und bewegen Sie den Mauszeiger, um alle Details zu sehen, die Sie zum Verständnis der komplexen Servicebeziehungen benötigen:

Anomaliedetails

Fragen Sie „Was ist anomal?“ oder „Gibt es in Checkout etwas Ungewöhnliches?“ und erhalten Sie automatisch eine von zwei Ansichten. Wenn mehrere Entitäten betroffen sind, zeigt der Überblicksmodus Anzahlen nach Schweregrad, betroffene Entitäten und eine Aufschlüsselung nach Jobs. Wenn eine einzelne Entität im Fokus steht, zeigt der Detailmodus den Score, Ist- und typische Werte mit einem Vergleichsbalkendiagramm, die prozentuale Abweichung und, sofern verfügbar, eine Zeitreihe. Sehen wir uns den Frontend-Service an:

Dies ist keine ESQL-Abfrage, sondern eine Erläuterung der Ergebnisse eines zuvor definierten Anomalieerkennungsjobs. Wie in Teil 1 dieser Blogreihe erläutert, bringt die Kubernetes-Integration einige davon mit, die Sie aktivieren können. Dieses Tool hilft Ihnen, das Beste aus ihnen herauszuholen.

Observe

Observe ist das primäre Zugriffsprimitiv des Agenten für Elastic – ein Tool mit zwei Modi für drei verschiedene Bedürfnisse. Fragt man „Wie hoch ist der Netzwerkdurchsatz jedes meiner Kubernetes-Cluster?“, erhält man eine Tabelle oder ein Diagramm mit den Ergebnissen. Sagt man „Sag mir, wenn der Speicher unter 80 MB fällt“ oder „Achte für die nächsten 10 Minuten auf alles Ungewöhnliche beim Frontend-Speicher“, blockiert es, bis die Bedingung erfüllt ist oder das Zeitfenster abläuft.

Die Ansicht passt sich an den jeweiligen Modus an: eine Ergebnistabelle für einmalige Abfragen, ein Live-Trenddiagramm mit aktuellen, Spitzen- und Baseline-Statistiken für Stichproben- und Schwellenwertbedingungen sowie eine Triggerkarte mit Schweregradbewertung für den Anomalienmodus. Wir nutzen sie hier, um den am stärksten ausgelasteten Kubernetes-Knoten zu ermitteln:

Risiko mit einem Schadensradius bewerten

Fragen Sie „Was passiert, wenn dieser Knoten ausfällt?“ und erhalten Sie ein radiales Auswirkungsdiagramm: der Ziel-Knoten in der Mitte, vollständig ausgefallene Deployments in Rot, beeinträchtigte in Gelb und unbeeinflusste in Grau. Eine schwebende Übersichtskarte zeigt gefährdete Pods und die Machbarkeit der Neuplanung an. Single-Replica-Deployments werden als Single Points of Failure markiert. Was würde passieren, wenn unser stark ausgelasteter Knoten ausfiele:

Alert-Verwaltung

Mit dem Tool zur Alert-Verwaltung können Sie Alerts erstellen, auflisten, Informationen abrufen und Alerts löschen. Als Nächstes erstellen wir einen Alert. Verwenden Sie zuvor jedoch noch einmal Observe, um schnell eine Baseline zu ermitteln, damit wir wissen, dass der Alert Sinn machen wird:

Sagen Sie „Benachrichtige mich, wenn der Frontend-Speicher 75 MB überschreitet“ und der Agent erstellt eine persistente Kibana-Alerting-Regel – ein gespeichertes Objekt, das auch nach Beendigung der Unterhaltung weiter ausgeführt wird. Die Ansicht rendert eine Live-Regelkarte: Regelname, Bedingung, Zeitfenster, Prüfintervall, KQL-Filter und Tags. Schaltflächen für nächste Schritte bieten die Möglichkeit, die Regel zu überprüfen, die Stabilisierung der Metrik zu beobachten oder den aktuellen Cluster-Zustand zu prüfen. Der Agent bestätigt, was erstellt wurde und wo es in Kibana zu finden ist:

MCP-App-Architektur

Die App besteht aus einem Node.js-Server, sechs modellorientierten Tools, die mit sechs Einzeldatei-Ansichtsressourcen verbunden sind, reinen App-Tools für erneute Abfragen und vite-plugin-singlefile-Bundling. Die Tools sind nach Deployment-Backend gruppiert (Universal, APM-abhängig, K8s-abhängig, ML-abhängig), sodass sowohl der Agent als auch der Nutzer im Voraus wissen, welche Tools für ein bestimmtes Deployment relevant sind, anstatt beim Aufruf Fähigkeitslücken zu entdecken. Das Repo enthält sechs Skills als separate .zip- Artefakte, die dem Agenten beibringen, wann und wie jedes Tool aufgerufen werden soll.

Das folgende Diagramm zeigt die drei Komponenten, aus denen die App besteht: den MCP-Host (Claude Desktop, VS Code oder ähnlich), der das LLM und die Claude-Skills enthält, die ihm beibringen, wie die Tools verwendet werden; den MCP-App-Server, einen einzelnen Node.js-Prozess, der die Tool-Registry bereitstellt, die React-UI-Ansichten bündelt und die gesamte Kommunikation mit Elastic abwickelt; und den Elastic Stack selbst, in dem Elasticsearch und Kibana als Live-Daten- und Alerting-Backends dienen.

Das folgende Diagramm veranschaulicht den Ablauf einer Nutzeranfrage: Claude liest die entsprechende Skill-Datei, um zu verstehen, welches Tool aufgerufen werden soll und wie dessen Parameter auszufüllen sind, ruft das Tool auf, das serverseitige Abfragen an Elasticsearch und Kibana auslöst, und erhält eine kompakte Textzusammenfassung zusammen mit einer React-UI-Ressource zurück, die inline als interaktives Widget gerendert wird.

Vom Alert zur Ursache: Untersuchungs-Workflows

Alert-Regeln teilen Ihnen mit, dass etwas nicht stimmt. ML-Module zeigen Ihnen das Muster. Elastic Workflows führen die Diagnose aus – automatisch, sobald ein Alert ausgelöst wird.

Wir stellen einen Kubernetes-Untersuchungs-Workflow (technische Vorschau) bereit, der bei einem Kubernetes-Alert ausgelöst wird und eine strukturierte Ursachenzusammenfassung zurückgibt, bevor Sie ein einziges Dashboard geöffnet haben. Der SRE, der per Pager benachrichtigt wird, öffnet den Alert und stellt fest, dass die Untersuchung bereits abgeschlossen ist.

Der Workflow ist ein gerichteter Graph von Schritten, der mehrere Datenquellen abfragt – primär über die Elasticsearch Query Language (ES|QL), mit einer Elasticsearch-Suche für das Nachschlagen von ML-Anomalien. „if“-Schritte verzweigen sich anhand von Abfrageergebnissen und entscheiden, welcher Abgleich ausgeführt werden soll (ML-Speicheranomalie vs. Log-Klassifizierung) und ob der Upstream-Zustand überprüft werden soll (nur bei bestehenden APM-Abhängigkeiten). KI-Schritte kommen an drei Stellen vor: bei der Klassifizierung von Log-Mustern auf dem Nicht-OOM-Pfad, bei der Einstufung von Upstream-Komponenten als beeinträchtigt vs. fehlerfrei und bei einem abschließenden „ai.summarize“, das alle strukturierten Belege zu einer Ursachenanalyse zusammenfasst.

Wie der Untersuchungs-Workflow in der Praxis aussieht

Die folgende Beispielausführung basiert auf dem OpenTelemetry Astronomy Shop, der mit Elastic ausgeführt wird – 16 Dienste, Kafka, PostgreSQL, alle über OTLP vorinstrumentiert. Neben der echten Telemetrie des Shops haben wir eine synthetische OOMKill-Kaskade eingespeist, die über die EDOT-Datenströme synthetische K8s- und APM-Signale in denselben Namespace schreibt. Der Workflow kann unsere Signale nicht von echten unterscheiden – er untersucht lediglich den Alert.

Alert ausgelöst: CrashLoopBackOff – app-deployment in oteldemo-esyox-default. Anzahl der Neustarts: 6.

Workflow-Schritt 1 – Pod- und Container-Kontext charakterisieren

Der Workflow fragt K8s-Metriken für die Neustartanzahl, den letzten Beendigungsgrund und die Auslastung im Vergleich zu deklarierten Limits ab.

Ergebnis: Letzter Beendigungsgrund OOMKilled, Anzahl der Neustarts 6. (Hinweis: Die kubeletstats-Auslastung war für diesen Pod/dieses Zeitfenster nicht verfügbar – der Workflow wird ordnungsgemäß fortgesetzt.)

Workflow-Verzweigungen: Der Beendigungsgrund ist OOMKilled, daher nimmt der Workflow den Pfad zur Speicheruntersuchung, nicht den Pfad zur Log-Untersuchung.

Workflow-Schritt 2a – ML-Anomalieergebnisse einsehen

Anstatt Speichertrends neu zu berechnen, fragt der Workflow den ML-Anomalieindex nach einer aktiven „k8s_pod_memory_growth“-Anomalie ab.

Ergebnis: Keine Anomalie – die Spitze wird als lastbedingt gekennzeichnet, nicht als mutmaßliches Leck.

Workflow-Schritt 3 – Upstream-Service-Integrität prüfen

Der Workflow listet Upstream-Abhängigkeiten aus den APM-„service_destination.1m“-Aggregaten auf und vergleicht dann die aktuelle Fehlerrate und mittlere Latenz mit derselben Stunde vor 7 Tagen. Ein KI-Klassifizierungsschritt entscheidet, ob dem Alert eine Upstream-Verschlechterung vorausgegangen ist. Ergebnis: Ein Upstream – api-gateway. Aktuelle mittlere Latenz 15,13 ms, Fehlerrate 41,26 %. Baseline (vor 168 Std.): identisch. Klassifizierung: upstream_healthy – innerhalb der Schwellenwerte von 5 × Fehler / 3 × Latenz. Upstream ist ausgeschlossen.

Workflow-Schritt 4 — Mit kürzlichen K8s-Änderungen korrelieren

Das Event-Log für den Namespace zeigt einen engen Zyklus von Pulled → Created → Started → Killing → BackOff, der sich etwa alle 60–90 Sekunden wiederholt. Keine Deployments oder Skalierungsereignisse in den vergangenen zwei Stunden.

Workflow-Ausgabe:

URSACHENHYPOTHESE (Konfidenz: hoch)

app-deployment führt unter Speicherdruck OOMKilling durch. Der Pod hat
6 Neustarts mit dem Beendigungsgrund OOMKilled durchgeführt. ML hat die Speicherspitze als
lastbedingt markiert (kein Leck). Upstream-api-gateway ist fehlerfrei entsprechend der aktuellen 7-Tage-
Baseline. Dies ist ein Ressourcenzuweisungsproblem – das Speicherlimit des Containers
ist für seinen tatsächlichen Arbeitssatz zu niedrig.

Beweis:
- 6 Neustarts, letzter Beendigungsgrund OOMKilled
- Keine ML-memory-growth-Anomalie → leak_suspected=false (lastbedingt)
- Upstream-api-gateway unverändert im Vergleich zur 7-Tage-Baseline (15,13 ms, 41,26 %) → fehlerfrei
- K8s-Ereignisse zeigen enge Pulled/Created/Started/Killing/BackOff-Zyklen;
  keine Deployments in den letzten 2 Std.

Wahrscheinliche Ursache: Speicherlimit für den tatsächlichen Arbeitssatz unter Last unzureichend.

Empfohlene nächste Schritte:
1. Erhöhen Sie das Arbeitsspeicherlimit für app-deployment basierend auf der beobachteten Nutzung
2. Überprüfen Sie den Anwendungscode auf Speicheroptimierungsmöglichkeiten
3. Ziehen Sie eine Graceful degradation auf Pfaden mit hoher Last in Betracht

Nachgelagerte Auswirkungen: anhand von APM-Zielmetriken keine identifiziert.

Die obige Ausgabe zeigt, wie der Alert aussieht, wenn Sie ihn öffnen – kein Link zu einer Reihe von Logs oder einem Dashboard, sondern eine Antwort.

Derselbe Workflow ist als MCP-Tool über Claude Desktop, VS Code oder jeden MCP-kompatiblen Client zugänglich. Wenn ein Entwickler über seine IDE fragt: „Warum gibt Checkout einen Fehler aus?“, ruft der Agent den Workflow auf und gibt dieselbe strukturierte Ausgabe inline zurück – dieselben Belege, dieselbe Grundursache –, ohne den Editor zu verlassen.

Hier ist eine animierte Schritt-für-Schritt-Anleitung zur Workflow-Ausführung:

Beobachtbarkeit-Skill für Kubernetes-Untersuchungen

Wir stellen außerdem einen einzelnen, umfassenden Untersuchungs-Skill („observability-k8s-investigation“) bereit, der das vollständige Diagnoseprotokoll für Probleme mit Kubernetes-Workloads, -Knoten und der control-plane enthält. Es handelt sich um eine zielgerichtete Untersuchungsmethodik, die die Gedankengänge enthält, die ein erfahrener SRE instinktiv anwendet, aber selten aufschreibt. Sie erhalten dies, indem Sie Kibana auf dem neuesten Stand halten, da es in unsere KI-Agenten-Skills integriert ist. Es beginnt mit Leitprinzipien, die die häufigsten Fehldiagnosen verhindern:

• Das Fehlen von Beweisen ist kein Beweis. Wenn Log-Abfragen null Zeilen zurückgeben, melden Sie „no_logs_available“ – leiten Sie aus leeren Ergebnissen keinen Fehlermodus ab.
• OOMKilled deutet nicht standardmäßig auf ein Speicherleck hin. Vergleichen Sie die aktuelle Nutzung mit einer 7-Tage-Baseline, bevor Sie von einem Leck ausgehen. Das Limit ist möglicherweise einfach zu knapp bemessen.
• Durchschnittliche CPU-Metriken verbergen Drosselung. Ein Pod kann bei 40–60 % durchschnittlicher Auslastung unauffällig wirken, während er bei p99 stark gedrosselt wird. Betrachten Sie Max und p95, nicht nur den Durchschnitt.
• Begleitsymptome sind keine Ursachen. Zwei Dienste, die sich gleichzeitig verschlechtern, haben gewöhnlich eine gemeinsame vorgelagerte Ursache. Gehen Sie nur dann von einem Kausalzusammenhang aus, wenn die Beeinträchtigung eines Dienstes der des anderen eindeutig vorausgeht und das Delta groß ist.

Von dort aus bildet der Skill eine Fehlermodus-Taxonomie ab, die 16 verschiedene K8s-Fehlermuster über Workload-, Knoten-, control-plane-, Autoscaling- und Netzwerkebenen hinweg abdeckt – von OOMKilled und CFS-Drosselung über Admission-Webhook-Blockaden bis hin zu StatefulSet-Split-Brain. Jeder Modus verfügt über ein ausschlaggebendes Signal, das ihn identifiziert, und eine Prüfliste zur Bestätigung, die ihn verifiziert.

Der Untersuchungsablauf folgt einem strukturierten Bogen: Orientieren (Ziel-Pod, Namespace, Deployment ermitteln), Charakterisieren (Anzahl der Neustarts, Beendigungsgründe, Auslastung abrufen), Klassifizieren (mit der Taxonomie abgleichen), Untermauern (Ereignisse, Logs, APM, Baseline-Vergleiche heranziehen) und Synthetisieren (eine Hypothese zur Grundursache mit kalibriertem Konfidenzniveau – hoch, mittel oder niedrig – mit expliziten Belegen und empfohlenen nächsten Schritten erstellen).

Wenn zwei Fehlermodi zu den Belegen passen, nennt der Skill beide und gibt an, welcher seiner Ansicht nach ursächlich ist und warum. Wenn die Beweislage uneindeutig ist, wird dies angegeben. „Konkurrierende Hypothesen sind eine gültige Ausgabe“ ist ein ausdrückliches Designprinzip – das Erzeugen falscher Gewissheit wird als Fehlermodus der Untersuchung selbst behandelt.

Erste Schritte

Diese Funktionen bauen auf der in Teil 1 beschriebenen Kubernetes-Integration auf. Sobald Dashboards und die Datenerfassung laufen:

Schritt 1 – Untersuchungs-Workflows aktivieren (technische Vorschau). Importieren Sie den Kubernetes Crashloop Investigation Workflow von der Workflows-Seite in Kibana und konfigurieren Sie ihn optional so, dass er bei einer Alert-Regel ausgelöst wird.

Schritt 2 – Installieren Sie die MCP-App auf einem MCP-kompatiblen Client (technische Vorschau). Das Repository der MCP-App für Observability finden Sie auf GitHub. (Downloads finden Sie auf der Seite „Versionen“.) Vergessen Sie bei der Installation der App nicht, auch die enthaltenen Skills zu installieren und zu aktivieren. Greifen Sie über Ihren bevorzugten agentischen Client auf die Tools der Beispiel-MCP-App zu – Anweisungen finden Sie in der README unter dem obigen GitHub-Link.

Schritt 3 – Nutzen Sie den K8s-Investigation-Skill (technische Vorschau). Dieser ist praktisch inklusive, wenn Sie Agent Builder verwenden, da er bereits in KI-Agent-Skills integriert ist. Der Skill bringt dem Agenten bei, wann und wie die zugrunde liegenden Tools und Workflows aufgerufen werden sollen, und stellt so konsistente Diagnosen in Konversationskontexten sicher.

Was kommt als Nächstes?

Untersuchungs-Workflows diagnostizieren, was in den von Ihnen überwachten Diensten fehlerhaft ist. Die nächste Frage ist schwieriger: was ist mit den Diensten, die Sie nicht überwachen?

Wir denken über eine topologiebewusste Coverage Intelligence nach – das automatische Erkennen jedes in Ihrem Cluster bereitgestellten Workloads über die Kubernetes-API, der Abgleich mit in Elastic einfließenden Telemetriedaten und das Aufdecken von Lücken. „Sie haben 47 Services. 11 verfügen über keine verteilten Traces. Hier ist Ihr riskantester toter Winkel.“ Diese Funktion wird derzeit geprüft und wird voraussichtlich Gegenstand eines zukünftigen Blogbeitrags sein.

Parallel dazu erweitern wir Workflows in Richtung Problembehebung – nicht nur Diagnose, sondern Handeln: Erstellen eines Tickets mit angehängter Untersuchungszusammenfassung, Vorschlagen eines Rollbacks zur menschlichen Freigabe oder Skalieren eines Workloads, um Zeit zu gewinnen, während die Ursache behoben wird.

Wenn Sie Kubernetes aktuell auf Elastic ausführen, teilen Sie uns mit, welche Untersuchungsschritte Sie bei jedem Vorfall manuell wiederholen, bei welchen Behebungsmaßnahmen Sie einem Workflow zutrauen würden, dass er sie vorschlägt, und welche MCP-Tools wir als Nächstes entwickeln sollten. Sie können hier an der Elastic-Community-Diskussion teilnehmen.