Chatbot, Grafana & Co. - Projekt dampf Teil 3

Wie bereits im letzten Teil angekündigt, wird es in diesem Teil der Reihe zum Projekt dampf darum gehen, wie die Benachrichtigungen durch den Chatbot aussehen und funktionieren, sowie um weitere visuelle Unterstützung für den Nutzer in Form von Grafana-Dashboards. Falls ihr den letzten oder gar beide Teile verpasst habt, könnt ihr diese hier nachholen: Anomalie-Erkennung in Zeitserien – Projekt dampf Teil 1, Korrelation von Anomalien – Projekt dampf Teil 2.

Chatbot

Unser Chatbot hat im Grunde zwei Aufgaben zu erfüllen:

• Bei erkannten Problemen soll er schnellstmöglich Benachrichtigungen an einen Broadcast-Channel senden.
• In Direktnachrichten oder einem Gruppen-Channel soll der Nutzer mit ihm kommunizieren können, um sich bei der Fehlersuche unterstützen zu lassen.

Chatbot-Architektur

In Bezug auf das zweite Aufgabengebiet des Chatbots gilt die Maxime: „Einen guten Chatbot erkennt man daran, dass man ihn nicht erkennt“. Es sollte einem möglichst nicht auffallen, dass man es nicht mit einem echten Menschen zu tun hat. Wer schon den ein oder anderen Chatbot verwendet hat, weiß, dass wir diesbezüglich noch lange nicht am Ziel angekommen, aber durchaus schon auf dem richtigen Weg sind.

Um statt strikter Befehle auch geschriebene, menschliche Sprache für den Chatbot verständlich zu machen, muss sie in maschinell verwertbare Codierungen übersetzt werden, auch bekannt als Natural Language Processing oder kurz NLP. Da es sehr aufwendig wäre, solche Übersetzungen selbst zu entwickeln, gibt es bei vielen Anbietern Services, die das für einen übernehmen. Da unser gesamtes Projekt in Amazon Web Services (AWS) aufgesetzt ist, insbesondere in Form von Lambdas sowie EC2 Instanzen, verwenden wir auch deren Service für NLP für Chatbots, Amazon Lex.

Amazon Lex bietet uns vor allem für zwei Probleme Lösungen. Zum einen interpretiert es die Anfragen des Benutzers bis zu einem gewissen Grade und erkennt bei ausführlichen Anfragen, indem es Füllwörter herausfiltert und die Semantik der Anfrage analysiert, welche Absicht dahintersteckt. Fragt der Benutzer beispielsweise „Was kann ich hier eigentlich machen?“ wird Amazon Lex diese Anfrage als andere, ausführlichere Form von „help me“ erkennen und der Chatbot kann somit entsprechend reagieren. Zum anderen verarbeitet es konkrete Informationen in Textform zu maschinell verwertbaren Daten. In unserem Projekt macht sich das insbesondere bei Zeitangaben bemerkbar. Statt ein genaues Datum und Uhrzeit eingeben zu müssen, kann man dadurch auch natürlichere Angaben wie „in den letzten 20 Minuten“ oder „gestern morgen gegen 6“ machen und Lex übersetzt diese Worte für das Programm im Hintergrund.

Damit schöpfen wir bei Weitem nicht alle Möglichkeiten aus, aber die weiteren boten uns zumindest bisher keinen Mehrwert. Beispielsweise bietet Amazon Lex auch an, es direkt mit einer Slack-Application, der Schnittstelle zwischen Slack und der tatsächlichen Bot-Logik, zu verknüpfen. Aber uns wurde schnell klar, dass die vorgegebenen Antwort-Formate und die insgesamt eingeschränkte Flexibilität uns nicht ausreicht. Stattdessen läuft unser Chatbot mit Hilfe eines API Gateways über eine selbst geschriebene AWS Lambda und ruft nur bei Bedarf Amazon Lex im Hintergrund auf. Die Architektur mit Amazon-Lex im Hintergrund sieht dann folgendermaßen aus:

Diagramm der Chatbot-Architektur

Der Chatbot kann entsprechend seiner zwei Aufgaben auf zwei Arten getriggert werden. Zum einen kann eine Lambda, wenn ein neues Problem gefunden wird, die Benachrichtigung in den Broadcast-Channel auslösen (rot-gestrichelter Pfad). Zum anderen kann natürlich der Benutzer eine Reaktion auslösen, wenn dieser den Chatbot irgendetwas fragt (goldener Pfad).
Im ersten Fall bekommt der Chatbot Informationen nur in vordefinierten, maschinell verarbeitbaren Formaten, z.B. als json-Objekte, vorgelegt. Im zweiten Fall kommen allerdings NLP und somit Amazon Lex ins Spiel. Die Slack-Application ruft über das API-Gateway die Slack-Lambda auf, welche dann wiederum Amazon Lex anspricht. Amazon Lex verifiziert die Anfrage, kann je nach Bedarf weitere Funktionen in einer eigenen Amazon Lex Lambda aufrufen und schickt die benötigten Informationen wieder an die Slack-Lambda zurück. Diese bereitet dann die Antwort auf und sendet sie an Slack.

Der Chatbot aus der Sicht des Nutzers

Sobald ein Problem erkannt wird, erscheint, auch wenn noch nicht alle Informationen bekannt sind, so schnell wie möglich eine Nachricht mit der Startzeit des Problems und einem Link zu einem dazugehörigen Grafana-Dashboard (hierzu mehr im Abschnitt Grafana) im Broadcast-Channel. Weitere Informationen schreibt der Chatbot, sobald sie ihm bekannt werden, entweder direkt als Updates in die ursprüngliche Nachricht oder in den Sub-Thread der Nachricht, sodass man alle Informationen zu einem Problem an einem Ort hat. Das kann zum Beispiel eine zusammenfassende Abbildung aus dem dazugehörigen Dashboard sein, damit man direkt in Slack eine Übersicht bekommt, welche Services betroffen sind. Oder auch die Angabe, wie viele Metriken insgesamt betroffen sind.

Screenshot aus dem Broadcast-Channel

Die Kommunikation zwischen Nutzer und Chatbot beginnt für einen neuen Nutzer vermutlich meist mit einem simplen „help me“, das einem die vorhandenen Möglichkeiten erklärt. Falls trotzdem mal eine Anfrage ins Leere laufen sollte, hilft der Chatbot mit Vorschlägen für fehlerhafte oder überhaupt nicht angegebene Informationen weiter, um den Benutzer zu seiner eigentlichen Absicht hinzuführen. Somit kann man diverse Informationen und mit Hilfe von Grafana auch Visualisierungen über aktuelle oder in der Vergangenheit liegende Probleme abfragen. Beispielsweise kann der Benutzer nach einem Link zu einem bestimmten Dashboard unter Auswahl von Datum und Uhrzeit fragen oder sich direkt das gesuchte Panel als png zuschicken lassen.

Screenshot einer Interaktion mit dem Chatbot

Grafana

Anfangs wollten wir die Nutzer-Interaktion mit Hilfe des Chatbots nur innerhalb von Slack gestalten. Allerdings merkten wir mit der Zeit, dass man manche Dinge sowieso immer haben möchte und es deutlich übersichtlicher ist, diese in Grafana auf einem Dashboard zusammenzufassen, als den Chatbot nach allem fragen zu müssen. Deshalb führten wir zwei Arten von Dashboards ein, die in Grafana gefunden werden können.

Zum einen gibt es das sogenannte Overview-Dashboard, das Informationen zur gesamten Anwendung bietet. Hier kann man beispielsweise ein Flowchart der kompletten Anwendung sehen, in dem aktuell von Problemen betroffene Metriken und Services rot eingefärbt sind. Oder welche Services jeweils wie viel Prozent der Zeit verfügbar waren. Oder auch eine Übersicht in Form einer Heatmap, zu welchen Uhrzeiten in den letzten Tagen wie häufig Probleme aufgetreten sind:

Zum anderen gibt es für jedes gefundene Problem ein eigenes, dynamisch erstelltes, sogenanntes Incident-Dashboard. In diesem findet sich ein Flowchart, das die betroffenen Services und deren Abhängigkeiten zeigt, sowie die Entwicklung der betroffenen Metriken von einigen Minuten vor der Anomalie bis jetzt:

Wenn man das Dashboard erst zu einem späteren Zeitpunkt öffnet und das Problem bis dahin schon wieder vorbei ist, gehen die Graphen statt bis jetzt nur bis einige Minuten nach dem Endzeitpunkt des Problems. In den Metrik-Graphen werden außer der Werte der Metrik selbst auch der Anomalie-Score sowie die Vorhersage für jeden Wert gezeigt, sodass man direkt sehen kann, was die Anomalie ausgelöst hat. Ob der Wert nun niedriger oder höher als vorhergesagt war oder auch ob der Anomalie-Score langsam aber stetig oder sehr plötzlich angestiegen ist.

Mit diesen letzten beiden Puzzlestücken ist unsere Anwendung schließlich komplett:

Diagramm des Aufbaus der dampf-Anwendung

Wir hoffen, die dampf-Reihe hat euch die Themen Machine Learning und Monitoring und die Möglichkeiten, diese beiden Themen zu kombinieren, etwas näher bringen können.
Auf Wiederlesen, euer Team dampf