Elasticsearch Watcher – Automatische Überwachung, Alarmierung und vieles mehr!
Mehr Überblick im Elasticsearch-Cluster durch intelligentes Monitoring

Augsburg, 20.06.2025 (PresseBox) - In der dynamischen Welt der Daten ist es wichtig, Tools an der Hand zu haben, die bei der automatisierten Überwachung dieser Daten behilflich sind.ElasticsearchsPlatinum und Enterprise Lizenzen bieten mit dem Feature Watcher genau das. Watcher ist eine Komponente, die Ihnen die automatische Überwachung und Alarmierung auf der Basis von Änderungen in Ihren Daten ermöglicht. Im folgenden Blogbeitrag werde ich Ihnen zunächst die Grundlagen von Watcher näherbringen und dann einen etwas außergewöhnlichen Use Case vorstellen. Denn Watcher bietet tatsächlich noch viel mehr als „nur“ Unterstützung bei Überwachung und Alarmierung!

Inhaltsverzeichnis

1. Was steckt hinter Elasticsearch Watcher?
2. Elasticsearch Watcher Use Cases
3. Beispiel Use Case: Watches zur Berechnung aggregierter Statuswerte
   • Umsetzung mit Elasticsearch Watcher
   • Ausbaustufen

Was steckt hinter Elasticsearch Watcher?

Mit Watcher können Sie sogenannte „Watches“ definieren. Diese Watches werden automatisch in regelmäßigen Abständen ausgeführt und führen in der Regel eine Abfrage an einen oder mehrere Elasticsearch Indizes aus. Wenn die Bedingung eines Watches erfüllt ist, werden Aktionen ausgelöst. Dabei kann es sich beispielsweise um das Versenden einer E-Mail handeln, die Erstellung eines Jira Tickets oder das Indexieren von Daten in einen Elasticsearch Index.

Ein Watch besteht aus den folgenden Komponenten:

• Schedule: Der Zeitplan zum Ausführen des Watches. Dieser kann auf ein regelmäßiges Intervall gesetzt werden, etwa alle 30 Sekunden oder alle 5 Stunden, durch einen Cron-Ausdruck festgelegt werden oder auf einen festen Zeitpunkt gesetzt werden (z.B. jeden Tag um 15 Uhr).
• Input: Durch den Input werden Daten in den Ausführungskontext des Watches geladen. Dieser Payload ist in den darauffolgenden Watcher-Phasen zugänglich. Es gibt verschiedene Input Typen, etwa den Search Input, mit dem eine Elasticsearch Query ausgeführt werden kann, oder der HTTP Input, mit dem beliebige APIs oder Web Services angesprochen werden können. Durch einen sogenannten Chain Input können auch mehrere Inputs verkettet werden.
• Condition: Eine Bedingung, die bestimmt, ob die Aktion(en) ausgeführt werden sollen. Bedingungen können global oder pro Aktion gesetzt werden.
• Payload Transform(optional): Manipuliert den Payload (z.B. die Response der Input Query) vor dem Ausführen der Aktionen, etwa durch ein Skript.
• Action: Eine oder mehrere Aktionen, die ausgeführt werden, falls die Bedingung erfüllt ist. Diese können z.B. das Senden einer E-Mail, die Indexierung von Dokumenten oder das Senden von Daten an einen Webservice umfassen.

Elasticsearch Watcher Use Cases

Durch ihre vielfältigen Konfigurationsoptionen sind Watches äußerst flexibel und können eine große Bandbreite an Use Cases abdecken. Naheliegende Use Cases sind zum Beispiel die folgenden:

• Versenden Sie täglich per E-Mail einen Report, der die Verkaufszahlen des Vortages Ihres Onlineshops beinhaltet.
• Überwachen Sie den Status Ihres Elasticsearch Clusters durch regelmäßiges Aufrufen der Cluster-Health-API. Bei Problemen wird eine Nachricht in einen Slack Channel gepostet.
• Überwachen Sie die Festplattennutzung Ihrer Server. Wenn ein gewisser Schwellwert überschritten wird, wird automatisch ein Helpdesk-Ticket eröffnet.

Beispiel Use Case: Watches zur Berechnung aggregierter Statuswerte

Tatsächlich decken Watches aber noch viel mehr ab als die eben erwähnten Anwendungsfälle. Um Ihre Vorstellungskraft anzuregen, möchte ich Ihnen nun einen etwas exotischeren Use Case vorstellen. Und zwar soll es darum gehen, den Gesundheitszustand von Systemen zu berechnen (nicht nur zu überwachen). Dieser Status kann dann genutzt werden, um ihn mittels Kibana Dashboards für Nutzer zu visualisieren oder darauf basierend ein Alerting einzurichten.

Ausgangslage und Ziel: Es geht um ein System, welches sich in zwei Komponenten A und B untergliedert. Die Komponenten beinhalten jeweils verschiedene Applikationen, die auf verschiedenen Servern betrieben werden. Der Gesundheitszustand des Systems soll anhand der CPU-Auslastung dieser Server in die Kategorien „grün“, „gelb“ und „rot“ eingeteilt werden.

Berechnungslogik: Der Gesundheitszustand wird durch folgende Logik ermittelt:

1. Status pro Komponente: Pro Komponente wird die Durchschnitts-CPU aller Server berechnet.
   • Überschreitet dieser Wert einen bestimmten Schwellwert, etwa 80%, lautet der Status der Komponente „gelb“.
   • Überschreitet dieser Wert sogar einen höheren Schwellwert, etwa 90%, lautet der Status der Komponente „rot“.
   • Ansonsten lautet der Status der Komponente „grün“.
2. Gesamtstatus für das System:
   • Ist der Status beider Komponenten „grün“, dann ist auch der Gesamtstatus des Systems „grün“.
   • Ist der Status mindestens einer Komponente „gelb“, dann ist auch der Gesamtstatus „gelb“.
   • Ist der Status mindestens einer Komponente sogar „rot“, dann ist auch der Gesamtstatus „rot“.

Umsetzung mit Elasticsearch Watcher:

1. Die CPU-Werte aller Server der Komponenten A und B werden in Elasticsearch Indizes indexiert (im Bild unten grün und blau dargestellt).
2. Für die beiden Komponenten existiert jeweils ein Watch (Watch 1-A und 1–B, orange dargestellt). Dieser fragt mittels eines Search Inputs die relevanten CPU-Werte aus dem jeweiligen Index ab. Im Payload Transform können wir mittels eines Skripts unsere Logik umsetzen und den Durchschnitt der CPU-Werte mit den Schwellwerten abgleichen. So können wir den Status berechnen und diesen dann mittels einer Index-Aktion in einen weiteren Index indexieren.
3. Im letzten Schritt kommt erneut ein Watch zum Zug (Watch 2, gelb dargestellt). Dieser fragt mittels eines Search Inputs die im vorangegangenen Schritt indexierten Statuswerte der Komponenten ab. Wieder setzen wir die Berechnungslogik im Payload Transform um, und erhalten so den Gesamtstatus als „Maximum“ der Komponentenstatus. Dieser Gesamtstatus kann mittels einer Index-Aktion in einen weiteren Index (gelb) indexiert werden.

Ausbaustufen

Es sind diverse Ausbaustufen denkbar.

• Auslagerung der Schwellwerte: Wir könnten die Schwellwerte für die Watches in Schritt 2 in einem Index hinterlegen, anstatt sie fix in das Payload-Transform-Skript einzubauen. Wir könnten die indexierten Schwellwerte dann im Watch abfragen, indem wir einen Chain Input zusammen mit Search Inputs nutzen.
• Alerting: Anstatt „nur“ Statuswerte zu berechnen und zu indexieren, wäre es möglich direkt ein Alerting in die Watches zu integrieren. Beispielsweise könnten wir zusätzlich zur Index-Aktion eine E-Mail-Aktion einbauen. Die Index-Aktion würde stets ausgelöst, aber die E-Mail-Aktion nur unter der Bedingung, dass der berechnete Status „rot“ lautet.
• Ausbau der Statuslogik: Wir könnten die Berechnungslogik zum Gesamtstatus zu erweitern. Möglich wäre etwa das Abprüfen einer Vielzahl an Komponenten, das Einbauen von mehr als zwei Berechnungsstufen oder das Abprüfen weiterer Metriken neben der CPU-Auslastung.