Alerting im Elastic Stack
Alerting ist ein fundamentaler Bestandteil der Anwendungsfälle von Elastic. Seit der Einführung von Watcher (unserem ursprünglichen Paket von Alerting-Features für Elasticsearch) im Jahr 2015 haben wir eine Menge Feedback erhalten, das uns geholfen hat, unser Wissen darüber zu erweitern, wie ein Alerting-System aussehen sollte, was es können muss und was alles zu einem positiven Nutzererlebnis gehört. Mit diesem Blogpost möchten wir einen Überblick über einige der wichtigsten Aspekte geben, die wir dabei gelernt haben, berichten, wie uns das bei unserer Arbeit 2019 beeinflusst hat, und einen Ausblick auf die Zukunft des Alertings im Elastic Stack geben.
Was haben wir gelernt?
In den vier Jahren, in denen es Alerting bei Elastic gibt, konnten wir unser Wissen über Alerting-Systeme massiv ausbauen. Unsere Erkenntnisse lassen sich in drei zukunftsorientierte Beobachtungen einteilen: Alerting ist allgegenwärtig, d. h., Alerts sind in jedem Anwendungsfall anzutreffen; wir müssen sie für alle Anwendungsfälle verstehen lernen; und das Erkennen und entsprechende Agieren wird immer komplexer. Diese Erkenntnisse bilden die Basis für unser Nachdenken über die Zukunft des Alertings.
Allgegenwärtiges Alerting
Alerting betrifft alle unsere Produkte und Anwendungsfälle. Wo es Livedaten gibt, gibt es auch einen Grund für Alerting. Aus diesem Grund haben wir Watcher entwickelt und aus diesem Grund ist Watcher auch so erfolgreich gewesen. Aber wenn wir uns die Anwendungsfälle einmal genauer ansehen, wird klar, dass es für das Alerting keine für alles passende Universallösung gibt.
Ob in Produkten wie Elastic Logs, SIEM, APM, Uptime, Infrastructure und Maps, Features wie Monitoring und Machine Learning oder in der Vielzahl an Kibana-Dashboards – Alerts und Benachrichtigungen spielen eine wichtige Rolle, aber die Anforderungen an das Erkennen von Zuständen, die Art und Weise, wie sie ausgedrückt werden, und die Art und Weise ihrer Darstellung im jeweiligen Kontext sind jeweils speziell. Effektives Alerting und Monitoring erfordert eine tiefe Integration in das jeweilige Produkt. Je weiter sich der Stack und seine Anwendungen entwickelt haben, desto klarer hat sich herauskristallisiert, dass Elasticsearch-Alerting ein Gegenstück benötigt, das eng integrierte Alerts vielfältiger Art und Form in jedem Anwendungsfall ermöglicht.
Verstehen von Alerts
Die Allgegenwart des Alertings geht mit einem Phänomen einher: Je mehr Alerts diese unterschiedlichen Anwendungsfälle generieren, desto mehr werden Alerts zu ihrer eigenen Datenquelle. Daraus ergeben sich wiederum Chancen für ein allgemein tieferes Verständnis von Systemen und ihrem Zustand. Oder um es mit den Worten der SRE(Site Reliability Engineering)-Community auszudrücken: Es eröffnen sich Möglichkeiten, die Observability eines Gesamtsystems zu verbessern.
Bei jedem Anwendungsfall werden Daten verschieden interpretiert und Alerts zeigen die unterschiedlichen Facetten einer Situation. Die richtige Reaktion auf ein Ereignis hängt häufig von Daten aus mehreren Quellen und der Korrelation unterschiedlicher Arten von Alerts und Ereignissen ab, um die Situation verstehen zu können. In einigen Bereichen, wie SIEM, werden Alerts auf höherer Ebene durch Muster in Alerts auf unterer Ebene ausgelöst.
Mit steigender Zahl von Anwendungsfällen für den Elastic Stack sorgt ein richtig implementiertes Alerting-System dafür, dass nicht nur Alerts generiert werden, sondern es hilft auch dabei, die Alerts im Kontext des jeweiligen Anwendungsfalls zu verstehen. So können beispielsweise Uptime-Alerts einen Dienstausfall anzeigen, APM-Alerts Aufschluss darüber geben, welche Transaktion zum Ausfall geführt hat, und Monitoring-Alerts angeben, warum es zum Ausfall gekommen ist. Ein Alerting-System sollte Kontext bereitstellen, Korrelationen ermöglichen und das Bewusstsein für Risiken schärfen – für Nutzer und Maschinen.
Erkennen und Agieren
Je besser wir Alerts verstehen lernen und je beobachtbarer wir das System machen, desto eher sind wir in der Lage, komplexere Zustände zu erkennen und differenzierter zu agieren. Das umfasst mittlerweile weit mehr, als das, was man landläufig unter „Alerting“ versteht.
Im allgemeinen Verständnis wird „Alerting“ mit dem Erkennen eines Zustands und dem anschließenden Benachrichtigen eines Menschen assoziiert – und Schluss. Wenn man jedoch einen Schritt zurücktritt und sich das Gesamtbild ansieht, kann das Alerting-System als Teil einer Kontroll- oder Feedbackschleife verstanden werden, bestehend aus Beobachten, Erkennen eines bestimmten Zustands, Agieren und wieder Beobachten.
Nach heutigem Stand erfordert das „Agieren“ eine Benachrichtigung, d. h., ein Mensch wird herbeigerufen, damit er das System steuert und versucht, es zu korrigieren. Mit immer besseren Erkenntnissen zum System kann das „Agieren“ aber mehr Kontrolle übernehmen, in der Regel unter menschlicher Aufsicht. Denkbar wäre ein halbautomatisches System, das über eine bidirektionale Kommunikation (zum Beispiel über Chatbots) gesteuert wird, oder ein vollautomatisches System, wie wir dies beim Trend zu Anwendungen zur automatischen Skalierung, Selbstheilung und Selbstoptimierung beobachten.
Ein Alerting-System muss differenziertes Erkennen und Agieren unterstützen, wobei klar sein muss, dass „Erkennen“ mehr sein kann als eine Abfrage bei Elasticsearch und „Agieren“ mehr bedeutet, als nur eine E‑Mail zu senden oder einen Webhook aufzurufen.
Anwenden des Gelernten
Im Herbst 2018 haben wir entschieden, dass wir zur Unterstützung der drei oben beschriebenen Beobachtungen Alerting benötigen.
Wir haben auch entschieden, dass die beste Methode dafür ist, Alerts als Entities erster Klasse in Kibana zu haben:
- Allgegenwärtiges Alerting: Alerting-Integrationen in vielfältiger Art und Form für alle unsere Produkte auf Plugin-, API- und UI-Ebene
- Verstehen von Alerts: Bereitstellung einer intuitiven Benutzeroberfläche für alle Arten von Alerting
- Erkennen und Agieren: differenzierte Mechanismen für das Erkennen und Agieren über Kibana-Plugins
Aus unseren Erfahrungen mit Watcher wissen wir auch, dass das Alerting-System sowohl Alert-Lasten in Produktionsumgebungen schultern können als auch hochgradig verfügbar und zuverlässig sein muss. APIs, Benutzeroberflächen und Plugin-/Bibliotheks-Codeverträge zur Unterstützung der drei Beobachtungen müssen eine solide und skalierbare Basis haben. Insgesamt können wir zwischen vier Schichten des Elastic-Alerting-Systems unterscheiden:
2019 haben wir das Fundament für das neue Alerting-System in Kibana gelegt.
Im Januar wurde im Rahmen der Veröffentlichung von Version 6.7 der Task Manager hinzugefügt. Damit hat Kibana eine Funktion zur Einrichtung von persistenten Aufgaben zur automatischen Ausführung im Hintergrund erhalten, die zur Unterstützung von Skalierbarkeit und Verfügbarkeit auf mehrere Kibana-Instanzen verteilt werden können. Alert-Komponenten auf der untersten Schicht, wie Task Manager, können auch für andere Zwecke als das Alerting eingesetzt werden. So ließe sich Task Manager beispielsweise nutzen, um die automatische Berichterstellung in Kibana zu vereinfachen.
Im Juni haben wird dann Kibana zwei neue APIs hinzugefügt: die Alerting-API und die Actions-API.
Mit der Actions-API kann Kibana Aktionen registrieren und auslösen; sie stellt einen einfachen Codevertrag zum Definieren eigener Aktionen zur Verfügung, was eine benutzerfreundliche individuelle Anpassung ermöglicht. In der ersten Version gab es auch ein paar Beispielaktionen für Logging-, Slack- und E‑Mail-Benachrichtigungen.
Über die Alerting-API kann Kibana Erkennungsformen als „Alert-Typen“ registrieren und diese Prüfungen dann mithilfe des Task-Management-Systems automatisch durchführen lassen. Wie bei Aktionen gibt es einen einfachen Alerting-Codevertrag: Wenn man etwas in einer JavaScript-Funktion ausdrücken kann, die auf dem Kibana-Server läuft, kann dieses etwas einen Alert auslösen.
Bei Elastic Stack 7.4 wurde das Hauptaugenmerk darauf gelegt, die unteren Schichten des Alerting-Systems auszufüllen: Wir haben die APIs robuster gemacht, unterstützen jetzt auch security und spaces und haben ein paar weitere integrierte Aktionen wie indexing, webhooks und pager duty hinzugefügt.
Was kommt als Nächstes?
Die Entwicklung des Alerting-Systems von Kibana ist seit ein paar Monaten voll im Gang und das wird auch für den Rest des 7.x-Veröffentlichungszyklus so anhalten. Wir planen ein System-Rollout in drei Phasen.
Die erste Phase – die Fundamentlegung – läuft bereits fast das ganze Jahr 2019. Der Fokus liegt dabei auf skalierbarem Task-Management und der Task-Planung, Codeverträgen für „alerting“ und „action“ und APIs.
Momentan befinden wir uns beim Übergang in die zweite Phase, in der unterschiedliche Anwendungsfälle das Alerting-System auf API- und Bibliotheksebene integrieren können. Dazu gehört auch die Entwicklung und Programmierung einer Benutzeroberfläche in Kibana, um Alerts verstehen und mit spezifischen Anwendungsfällen (wie zum Beispiel Monitoring, Uptime oder SIEM) validieren zu können.
In der dritten Phase werden die Themen „Allgegenwärtiges Alerting“ und „Erkennen und Agieren“ erweitert, indem überall in Kibana benutzerdefinierte Alerts zugelassen werden. Dies kann sowohl über Alerts auf der Basis von Vorlagen als auch über Alerts auf Basis von Ausdrücken, z. B. Canvas-Ausdrücken, geschehen.
Am Ende soll ein System stehen, das unsere Vision des Alertings im Elastic Stack erfüllt:
- Allgegenwärtiges Alerting: Alerts sind eine Entität erster Klasse innerhalb von Kibana, die „space-aware“ ist. Das macht das Segmentieren der Erstellung und Anzeige von Alerts für verschiedene Gruppen möglich und erlaubt eine Integration von Alerting in vielfältiger Art und Form in Produkte wie SIEM, Monitoring und Uptime (um nur einige zu nennen). Alerting ist kein Ersatz für Watcher – es ergänzt Watcher und funktioniert parallel dazu.
- Verstehen von Alerts: Alerting-Integrationen in vielfältiger Art und Form werden von einer Kibana-Benutzeroberfläche begleitet, die umfassende Ansichten für die verschiedenen Alert-Typen sowie Tools für das Korrelieren und das Verstehen der Alert-Historie bereitstellt.
- Erkennen und Agieren: Die APIs und Plugins sind so gestaltet, dass jeder Mechanismus für das Erkennen oder Agieren infrage kommt, solange er in JavaScript für die Ausführung auf dem Kibana-Server ausgedrückt werden kann. Das lässt ausreichend Spielraum für das differenzierte Erkennen und Agieren, das durch Produkte wie SIEM oder unsere Observability-Lösungen in Kibana stattfinden wird.