Entwickeln Sie eine Anwendung, in der zeitbasierte Daten gespeichert werden? Bestellungen, Ratings, Kommentare, Terminvereinbarungen, Zeitbuchungen, Reparaturen oder Kundenkontakte? Haben Sie detaillierte Logdateien über die Anzahl und Dauer der Zugriffe? Hand aufs Herz: Wie schnell würde Ihnen auffallen, wenn sich Ihre Systeme (oder Ihre Benutzer) anders verhalten als gedacht? Vielleicht versucht einer Ihrer Mandanten die Software gerade mit viel zu vielen Daten zu fluten, oder ein Produkt in Ihrem Webshop geht „durch die Decke“? Vielleicht gibt es Performanceprobleme in bestimmten Browsern oder unnatürliche CPU-Spitzen, die eine nähere Betrachtung verdienen? Der Metrics Advisor aus den Azure Cognitive Services stellt einen KI-unterstützten Service zur Verfügung, der Ihre Daten überwacht und bei Anomalieverdacht Alarm schlägt.

Was ist normal?

Die große Herausforderung dabei ist, zu definieren, was überhaupt eine Anomalie darstellt. Stellen Sie sich ein ganzes Regal voller Entwicklerzeitschriften vor, nur eine Sportzeitschrift ist darunter. Mit Recht könnte man also behaupten, die Sportzeitschrift sei eine Anomalie. Vielleicht sind zufällig aber auch alle Zeitschriften im A4-Format, nur zwei in A5 – eine weitere Anomalie. Für eine automatisierte Erkennung von Anomalien ist es somit wichtig, aus Erfahrungen zu lernen und zu verstehen, welche Anomalien tatsächlich Relevanz besitzen – und wo ein Fehlalarm vorliegt, der zukünftig vermieden werden soll.

Im Fall von zeitbasierten Daten – und darum geht es beim Metrics Advisor ausschließlich – gibt es mehrere Ansätze zur Erkennung von Anomalien. Der einfachste Weg ist die Definition von harten Grenzen: Alles unter oder über einem gewissen Schwellwert wird als Anomalie betrachtet. Dafür braucht es kein Machine Learning und keine künstliche Intelligenz, die Regeln sind schnell implementiert und klar nachvollziehbar. Bei Monitoringdaten wird das vielleicht genügen: Sind 70 Prozent des Speicherplatzes belegt, will man reagieren. Oft verläuft die (Daten-)Welt aber nicht in starren Bahnen, manchmal ist die relative Veränderung entscheidender als der tatsächliche Wert: Wenn innerhalb der letzten drei Stunden ein signifikanter Anstieg oder eine Abnahme von mehr als 10 Prozent erfolgt ist, soll eine Anomalie erkannt werden. Ein Beispiel könnte man aus dem Finanzbereich nehmen. Ändert sich Ihr privater Kontostand von 20 000 € auf 30 000 €, so ist das vermutlich als Anomalie zu werten. Ändert sich ein Firmenkonto von 200 000 € auf 210 000 €, ist das nicht der Rede wert. Gut an diesem Beispiel erkennbar: Die Einordnung, was eine Anomalie ist, ändert sich möglicherweise über die Zeit. Bei der Gründung eines Start-ups sind 100 000 € viel Geld, bei einem Großkonzern eine Randnotiz. Was aber, wenn Ihre Daten saisonalen Schwankungen unterliegen oder einzelne Tage wie Wochenenden oder Feiertage sich deutlich anders verhalten? Auch hier ist die Einordnung gar nicht so trivial. Ist eine Grippewelle in den Wintermonaten erwartbar und nur im Sommer eine Anomalie oder soll jeder Anstieg der Infektionszahlen erkannt werden? Sie sehen, die Frage der Anomalieerkennung ist unabhängig vom Tooling eine zum Teil sehr subjektive – und nicht alle Entscheidungen können von der Technik übernommen werden. Machine Learning kann allerdings helfen, aus historischen Daten zu lernen und normale Schwankungen von Anomalien zu unterscheiden.

Metrics Advisor

Der Metrics Advisor ist ein neuer Service aus der Reihe der Azure Cognitive Services und vorerst nur in einer Preview-Version verfügbar. Intern wird ein weiterer Service verwendet, nämlich der Anomaly Detector (ebenfalls aus den Cognitive Services). Der Metrics Advisor ergänzt diesen um zahlreiche API-Methoden, ein Web-Frontend zur Verwaltung und Ansicht der Data Feeds, Root-Cause-Analysen und Alert-Konfigurationen. Um experimentieren zu können, benötigen Sie eine Azure Subscription. Dort können Sie eine Metrics-Advisor-Ressource erstellen; die Verwendung ist in der Preview-Phase komplett kostenlos.

Das Beispiel, mit dem ich Ihnen die grundsätzliche Vorgehensweise demonstrieren möchte, verwendet Daten von Google Trends. Ich habe für zwei Suchbegriffe („Impfstoff“ und „Influenza“) die wöchentlichen Google-Trends-Scores der letzten fünf Jahre für vier Länder (USA, China, Deutschland, Österreich) ausgewertet und heruntergeladen und möchte versuchen, etwaige Anomalien in diesen Daten zu erkennen. Die gesamte Administration des Metrics Advisors kann über das zur Verfügung gestellte REST API durchgeführt werden, ein schnellerer Einstieg gelingt über das bereitgestellte Web-Frontend, den sogenannten Workspace.

Data Feeds

Zu Beginn erzeugen wir einen neuen Data Feed, der die Basisdaten für die Auswertung bereitstellt. Als Datenquellen stehen out of the box verschiedenste Azure Services und Datenbanken zur Verfügung: Application Insights, Blob Storage, Cosmos DB, Data Lake, Table Storage, SQL Database, Elastic Search, Mongo DB, PostgreSQL – und einige mehr. In unserem Beispiel habe ich die Google-Trends-Daten in eine SQL-Server-Datenbank geladen. Die Tabelle hat neben dem Primärschlüssel noch vier weitere Spalten: das Datum, das Land und die Scores für Impfstoff und Influenza. Im Metrics Advisor muss nun (neben dem Connection String) ein SQL-Statement angegeben werden, mit dem alle Werte für ein bestimmtes Datum abgefragt werden können. Der Service wird nämlich auch in Zukunft regelmäßig unsere Datenbank aufsuchen, um die neuen Daten abzuholen und zu analysieren. Die Häufigkeit, in der diese Aktualisierung passieren soll, wird über die Granularität eingestellt: Die Daten können jährlich, monatlich, wöchentlich, täglich, stündlich oder in noch kürzeren Zeiträumen (die kleinste Einheit sind 300 Sekunden) ausgewertet werden. Abhängig von der gewählten Granularität gibt Microsoft auch Empfehlungen, wie viele historische Daten bereitgestellt werden sollen. Wählen wir einen 5-Minuten-Takt, dann reichen Daten der letzten vier Tage. In unserem Fall, einer wöchentlichen Analyse, werden bereits vier Jahre empfohlen. Nach dem Klick auf Verify and get schema wird das SQL-Statement abgesetzt und die Struktur unserer Datenquelle ermittelt. Wir sehen die in Abbildung 1 gezeigten Spalten und müssen die Bedeutung zuordnen: Welche Spalte beinhaltet den Timestamp? Welche Spalten sollen als Metrik analysiert werden – und wo befinden sich zusätzliche Fakten (Dimensionen), die mögliche Ursachen für Anomalien sein könnten?

Bevor die Daten nun tatsächlich importiert werden, gilt es noch, eine Einstellung zu betrachten: die roll up settings. Für eine spätere Ursachenanalyse (Root Cause Analysis) ist es notwendig, einen mehrdimensionalen Cube zu bauen, der je Dimension aggregierte Werte berechnet (also in unserem Fall pro Woche auch eine Aggregation über alle Länder). So kann später bei Anomalien untersucht werden, welche Dimensionen bzw. Ausprägungen ursächlich für die Wertveränderung zu sein scheinen. Sollten sich die Aggregationen nicht ohnehin bereits in unserer Datenquelle befinden, kann der Metrics Advisor zur Berechnung der Daten aufgefordert werden. Die einzige Entscheidung, die wir dabei treffen müssen, ist die Art der Aggregation (Summe, Durchschnitt, Min, Max, Anzahl). Hier hinkt unser Beispiel etwas: Wir wählen Durchschnitt aus, der Wert der USA fließt aber somit mit dem gleichen Faktor ein wie der Wert des kleinen Österreich. Sie sehen: oft scheitert man an der Datenqualität oder muss aufpassen, dass Aussagen nicht auf falschen Berechnungen beruhen.

Abschließend starten wir den Import, der je nach Datenmenge durchaus mehrere Stunden in Anspruch nehmen kann. Der Status des Imports kann auch im Workspace nachverfolgt werden, einzelne Zeiträume können jederzeit neu geladen werden.

Analyse und Feintuning

Sobald der Datenimport abgeschlossen ist, können wir einen ersten Blick auf unsere Ergebnisse werfen. Das wesentliche Ziel des Metrics Advisors ist die Analyse und Erkennung neuer Anomalien – also die Untersuchung, ob der jeweils neueste Datenpunkt eine Anomalie darstellt oder nicht. Dennoch werden auch die historischen Daten betrachtet. Abhängig von der Granularität blickt der Service einige Stunden bis Jahre in die Vergangenheit und versucht auch dort, Anomalien zu kennzeichnen. In unserem Fall (Daten aus fünf Jahren, wöchentliche Aggregation) liefert die sogenannte Smart Detection Ergebnisse für die vergangenen sechs Monate und markiert einzelne Zeitpunkte als Anomalie (Abb. 2).

Nun gilt es, einen Blick auf die Vorschläge zu werfen: Sind die identifizierten Anomalien tatsächlich relevant? Ist die Erkennung zu sensibel oder zu tolerant? Es gibt einige Möglichkeiten, um die Erkennungsrate zu verbessern. Erinnern wir uns an den Beginn dieses Artikels: Die große Herausforderung besteht darin, zu definieren, was überhaupt eine Anomalie darstellt.

Vermutlich fällt Ihnen im Workspace sehr rasch ein prominent platzierter Schieberegler auf. Damit können wir die Sensitivität steuern. Je höher der Wert, desto kleiner wird der Bereich, der normale Punkte enthält. Wir bekommen diese Grenzen auch innerhalb der Charts als hellblaue Fläche visualisiert. Manchmal ist es sinnvoll, nicht gleich beim ersten Auftreten einer Anomalie zu warnen, sondern erst, wenn über einen gewissen Zeitraum mehrere Anomalien erkannt wurden. Wir können den Metrics Advisor so konfigurieren, dass eine bestimmte Anzahl von Punkten rückwirkend betrachtet wird und eine Anomalie erst als solche gilt, wenn von diesen Punkten ein bestimmter Prozentsatz als Anomalie erkannt wurde. Zum Beispiel soll ein kurzes Performanceproblem toleriert werden, aber wenn in den letzten 15 Minuten 70 Prozent der Messwerte als Anomalie erkannt wurden, ist insgesamt von einem Problem zu sprechen.

Je nach Anwendungsfall kann es sinnvoll sein, die Smart Detection durch manuelle Regeln zu ergänzen. Mit Hilfe eines Hard Threshold können eine Unter- oder Obergrenze sowie ein Wertebereich festgelegt werden, der als Anomalie gelten soll. Der Change Threshold bietet die erwähnte Möglichkeit, eine prozentuelle Veränderung zu einem oder mehreren Vorgängerpunkten als Anomalie zu werten. Durch die Art der Verknüpfung (or/and) der verschiedenen Regeln beeinflussen wir die Erkennung: Eine Anomalie soll beispielsweise nur dann als solche erkannt werden, wenn die Smart Detection zuschlägt und der Wert über 30 liegt. Wir können mehrere dieser Konfigurationen zusammenstellen und benennen. Zusätzlich ist es möglich, für einzelne Dimensionen besondere Regeln zu hinterlegen.

Abhängig von unseren Einstellungen werden nun also mehr oder weniger Anomalien in den Daten entdeckt, der Metrics Advisor versucht anschließend, diese in sogenannte Incidents zu überführen. Ein Incident kann aus einer einzigen Anomalie bestehen, oft werden aber auch zusammenhängende Anomalien und damit ganze Zeitbereiche unter einem gemeinsamen Incident angeführt. Im Incident Hub stehen Tools zur näheren Betrachtung zur Verfügung: Wir können die gefundenen Incidents filtern (nach Zeit, Kritikalität und Dimension), eine erste automatische Ursachenanalyse starten (siehe „Root cause“ in Abb. 3) und durch mehrere Dimensionen einen Drill-down durchführen, um Erkenntnisse zu sammeln.

Feedback

Der vielleicht größte Vorteil beim Einsatz von künstlicher Intelligenz für die Anomalieerkennung liegt in der Möglichkeit, durch Feedback zu lernen. Selbst wenn Sensitivität und Schwellwerte gut eingestellt wurden, wird der Service manchmal falsch liegen. Genau für diese Datenpunkte kann dann aber über das API oder das Portal Feedback gegeben werden: Wo wurde fälschlicherweise eine Anomalie erkannt? Wo wurde eine Anomalie übersehen? Der Service nimmt dieses Feedback entgegen und versucht, zukünftig ähnlich gelagerte Fälle korrekter zuzuordnen. Auch zeitliche Perioden versucht der Service zu erkennen – und lässt sich eines Besseren belehren, wenn wir einen Zeitbereich markieren und diesen als Periode rückmelden.

Für vorhersehbare Anomalien, die zeitliche Gründe haben (Feiertage, Wochenenden, zyklisch wiederkehrende Ereignisse), gibt es eigene Möglichkeiten zur Konfiguration. Diese sollten daher nicht nachträglich als Feedback gemeldet, sondern als sogenannte Preset Events hinterlegt werden.

Alerts

Wir sollten nun an einem Punkt angekommen sein, an dem Daten regelmäßig importiert werden und die Anomalieerkennung hoffentlich zuverlässig funktioniert. Die beste Erkennung hilft aber nichts, wenn wir zu spät davon erfahren. Daher sollten Alert Configurations eingerichtet werden, die aktiv über Anomalien benachrichtigen. Derzeit stehen drei Kanäle zur Auswahl: per E-Mail, als WebHook oder als Ticket in Azure DevOps. Vor allem die WebHook-Variante bietet spannende Möglichkeiten der Integration: Wir können die erkannten Anomalien in unserer eigenen Anwendung anzeigen oder einen Workflow mit Hilfe der Azure Logic Apps triggern. Vielleicht starten wir als erste automatisierte Maßnahme einfach die betroffene Web-App neu.

Praktisch scheinen auch die Snooze-Settings: Ein Alert kann automatisch dafür sorgen, dass für einen konfigurierbaren Zeitraum danach keine Alerts mehr gesendet werden. Das vermeidet, dass man in der Früh mit 500 E-Mails im Posteingang aufwacht, die alle denselben Inhalt haben.

Resümee

Der Metrics Advisor bietet einen spannenden und leichten Einstieg in die Welt der Anomalieerkennung zeitbasierter Daten. Langjährige Data Scientists werden möglicherweise andere Mittel und Wege bevorzugen (und vielleicht am Paper unter https://arxiv.org/abs/1906.03821 interessiert sein), aber für Anwendungsentwickler, die mit passenden Daten erste Versuche starten wollen, stellt dieser Service eine potente Einstiegsdroge dar. Der Preview-Status ist derzeit vor allem noch im Webportal und in der mangelnden Dokumentationsqualität des REST API ersichtlich; gute konzeptionelle Dokumentation ist aber bereits vorhanden.

Viel Spaß beim Ausprobieren und Experimentieren mit Ihren eigenen Datenquellen.