Machine Learning für die Überwachung von relationalen Datenbanksystemen
Die Überwachung eines Datenbanksystems muss in den meisten Fällen meist mehr sein als nur die Nutzung eines Dashboards und die klassische Verwaltung von Alarmmeldungen. Es ist auch oft das notwendige Verstehen der jeweiligen Applikationen und des Workloads, welche durch diese entsteht. Des Weiteren besteht die Notwendigkeit eines höheren Grades an Automatisierung, da IT-Umgebungen – auch durch Cloud-Technologien getrieben – immer stärker wachsen.
Auf der anderen Seite haben viele relationale Datenbanksysteme durchaus den Ruf, dass sie sich immer wieder unvorhersehbar verhalten und von einem Tag auf den anderen ihr Laufzeitverhalten ändern.
In den letzten Jahren hat in vielen Bereichen des IT-Betriebs der Trend der Verwendung von Machine-Learning-Ansätzen Einzug gehalten. Dieser Artikel möchte eine Einführung in die Möglichkeiten von Machine Learning bzw. AIOps für die Überwachung von relationalen Datenbankservern geben und auch eine Forderung dafür sein, dass die Disziplin des Datenbankmonitorings dringend eine Evolution erfahren muss.
Zum großen Teil werden heute noch Technologien und Ansätze verwendet, welche das Thema nicht mehr zeitgemäß adressieren und auch nicht das Potenzial verfügbarer Konzepte ausschöpfen. Die verantwortlichen Administratoren werden häufig mit eher generischen Werkzeugen ausgestattet, die Datenbanksysteme oft nur oberflächlich adressieren. Darüber hinaus gibt es auch eine Reihe von dedizierten Monitoring-Lösungen für Datenbankserver, die aber auch oft nicht alle Möglichkeiten der Sicherstellung des Betriebs ausschöpfen.
Um einen Fokus zu haben beschränkt sich der Artikel primär auf den Betrieb von Microsoft SQL Servern, wobei viele der genannten Punkte auch für andere relationale Datenbanksysteme wie Oracle DB, PostgreSQL, MySQL/MariaDB usw. gelten. Dabei ist es unerheblich, ob der Microsoft SQL Server on-premise oder in einer Public Cloud wie Azure, GCP oder AWS betrieben wird.
Monitoring
Zunächst ein Blick auf das Thema Überwachung des Betriebs eines Datenbanksystems im Generellen. Grob kann die Überwachung aufgeteilt werden in zwei Bereiche:
- Die Überwachung der verwendeten Ressourcen des Host- als auch des Datenbanksystems.
- Die Überwachung der internen Prozesse innerhalb des Datenbanksystems.
Ersteres kann ohne Weiteres auch durch ein rein infrastrukturelles Monitoringsystem realisiert werden. Hierfür werden betriebssystemseitig die entsprechenden Metriken wie CPU-Nutzung, Speicher-Auslastungen, Storage-Latenzen und Netzwerknutzung gesammelt. Diese Werte können einfach und effizient von einer großen Anzahl an Hostsystemen gesammelt, gespeichert und visualisiert werden.
Der zweite Bereich stellt sich meist als wesentlich komplexer heraus, da er Auskunft über die Verarbeitung von Anfragen an das Datenbanksystem geben soll. Die notwendigen Kenntnisse zur Interpretation dieser Werte sind häufig nicht in der notwendigen Tiefe vorhanden, so dass sich die Nutzung der Monitoring-Lösungen meist auf den ersten Bereich beschränkt.
Daraus lässt sich auch ableiten, dass ein häufiges Verkaufsargument und Entscheidungskriterium für spezialisierte Datenbankmonitoring-Lösungen die vermeintliche Vereinfachung der internen Abläufe des Systems durch die Darstellung von optimierten und ansprechenden Dashboards ist. Fakt ist aber, dass häufig die Komplexität der internen Prozesse so hoch und die Menge an möglichen Zusammenhängen nahezu endlos ist, dass auch eine Vielzahl von Dashboards diese nicht adäquat wiedergeben können. Von einer vereinfachten Problemlösung ganz zu schweigen.
Die Mehrzahl der häufig genutzten Datenbanksysteme stellt eine Vielzahl von Systemsichten und -funktionen bereit, um Informationen über den Status der Verarbeitung von Anfragen zu liefern. Der Microsoft SQL Server ist hier keine Ausnahme. Ganz im Gegenteil, teilweise entsteht der Eindruck, dass dieser gerade durch die große Anzahl von verfügbaren Informationen als komplexer als vielleicht andere Systeme wahrgenommen wird.
Zwar nutzen verantwortliche Administratoren auch oft eigene Abfragen oder solche aus Publikationen und Blogs, um Informationen über ihre Systeme abzufragen, aber häufig kann mit einzelnen Abfragen nur eine Analyse des aktuellen Zeitpunktes durchgeführt werden.
Für viele Fragestellungen sind aber Vergleiche mit historischen Daten notwendig. Und sofern eine solche Sammlung durch den programmierkundigen Administrator entworfen und eingerichtet worden ist, dann fehlt aber vielleicht die Zeit, um die gesammelten Daten auszuwerten und einfach zugänglich zu machen.
So sind viele der angesprochenen Monitoringlösungen entstanden, um eben gerade die durch das Datenbanksystem bereitgestellten Informationen zu sammeln, zu speichern und ansprechend zu visualisieren.
Visualisierung
In letzter Zeit wird die Herausforderung der Visualisierung immer häufiger durch den Einsatz von Self-Service-BI/Analyse-Lösungen wie PowerBI gelöst, wobei hierbei oft schnell die Grenzen dieser Tool-Kategorie erreicht werden. Auf der anderen Seite gibt es im Open-Source-Umfeld Lösungen wie zum Beispiel Grafana oder Kibana, welche auch sehr einfach genutzt werden können, um Monitoringdaten zu visualisieren. Im Vordergrund steht dabei meist eine ansprechende optische Aufbereitung und das interaktive Bewegen innerhalb der gesammelten Daten.
Neben der reinen Visualisierung steht häufig auch ein sogenanntes Alerting zur Verfügung, welches Verantwortliche in den Organisationen über negative Veränderungen oder auch gravierende Fehlfunktionen an den Systemen informieren soll. Häufig wird ein Alert-Ereignis durch die Über- und/oder Unterschreitung eines Schwellwertes ausgelöst. Dieser Schwellwert kann meist entweder statisch sein oder wird dynamisch auf Basis von gesammelten Daten errechnet. Fortschrittlichere Systeme bieten dabei auch die Möglichkeit, dass eine sogenannte Baseline berechnet wird. Dabei handelt es sich meist um einen zeitlichen Verlauf eines gemessenen Wertes, wobei zum Beispiel dann ein täglicher oder wöchentlicher Zyklus berücksichtigt werden.
Von der primären Motivation ausgehend kann auch eine der wesentlichen Herausforderungen bzw. Nachteile einer klassischen Monitoring-Lösung abgeleitet werden. Die Visualisierung von gesammelten Daten steht im Vordergrund. Dazu kommt, dass häufig dennoch ein Mindestmaß an Know-how über den Microsoft SQL Server in der Organisation benötigt wird, um die aufbereiteten Daten richtig interpretieren zu können.
Viele weitere Informationen, die ein Microsoft SQL Server beitragen kann, um Aufschluss über Interna und vielleicht schleichende Probleme zu geben, werden entweder gar nicht erst gesammelt oder zumindest nicht in den primären Dashboards dargestellt, da dann die Übersichtlichkeit dieser sofort verloren gehen würde. Die Menge an unterschiedlichen Metriken wäre einfach zu groß.
Ein häufig implementierter Weg ist, dass diese Werte zum Teil auf nachgelagerten Analysefunktionen manuell ausgewählt und eingesehen werden können. Dabei wird es den Anwendern überlassen, aus einer meist quasi unüberschaubaren Anzahl an unterschiedlichen Metriken zu wählen. Um den Anwendern diese Informationen zumindest ein wenig näher zu bringen, werden Informationen oft gruppiert und damit wieder in eine darstellbare Form transformiert.
Aber gerade aus der Summe der verfügbaren Informationen eines Datenbanksystems wie des Microsoft SQL Server lassen sich sehr viele Details ableiten, wenn der Fokus nicht auf der reinen Visualisierung dieser Daten, sondern auf einer automatisierten Analyse liegt.
Um ein Verständnis dafür zu bekommen, mit welchen Herausforderungen die verantwortlichen Administratoren primär konfrontiert werden, macht es Sinn, sich ebenfalls Gedanken über die Rolle der Disziplin "Monitoring im IT-Betrieb" Gedanken zu machen.
Der Betrieb eines Datenbankservers aber auch die Analyse und Beseitigung von Performance- und Skalierungsproblemen erfordert in hohem Maße ein planvolles und organisiertes Vorgehen. Viele Lösungen positionieren sich aber eher in der reinen Tool-Ecke statt die Verantwortlichen aktiv bei den Herausforderungen zu unterstützen oder gar zu führen.
Es hat sich als durchaus hilfreich herausgestellt, die Monitoring-Lösung als Teil eines umfassenderen Risikomanagements zu sehen, welches sowohl den Betrieb als auch die Entwicklungsprozesse abdeckt. Die Vorgehensweise, den Betrieb einer IT-Umgebung mittels eines Risikomanagements zu organisieren, hat sich bei vielen Organisationen bereits erfolgreich etabliert.
Performance und Skalierbarkeit
Bezogen auf ein Datenbanksystem muss im Vordergrund dabei die Stabilität des Gesamtsystems stehen. Dabei sind sowohl die Performance des Datenbanksystems als auch die Eigenschaft einer Skalierbarkeit der Applikation entscheidend.
Unter Performance werden alle Aspekte zusammengefasst, welche die reibungslose Verarbeitung der Abfragen durch die Applikationen gefährden können.
- Latenzen im Storage-System,
- Konstante verfügbare Menge an Hauptspeicher für die Datenbank-Engine und
- Anzahl und Auslastung der verfügbaren CPU-Kerne.
Unter Skalierbarkeit werden alle Risiken gruppiert, welche eine stabile und gleichmäßige Nutzung der Ressourcen für die Verarbeitung der Abfragen verhindern, während über die Zeit die Datenmenge anwächst und zusätzliche gleichzeitige Anwender hinzukommen.
- Veränderungen am Workload-Verhalten der Applikationen,
- Veränderungen in den vom Query Optimizer erstellten Ausführungsplänen,
- Veränderungen in der Nutzung der Index-Strukturen und
- Veränderungen im Verhalten des Sperrverhaltens.
Veränderungen an der Verarbeitung der Abfragen sind für die Risiko-Skalierbarkeit der entscheidende Faktor. Häufig wird hier aber zu sehr auf die anwachsende Datenmenge geschaut und diese als vermeintliche Quelle für alle Problemen adressiert. Daher wird dann schnell der Wunsch geäußert, dass man doch historische Geschäftsvorfälle (also ältere Daten) auslagern müsste, was meist gar nicht notwendig wäre und die Situation auch nur vorübergehend verbessert.
Wie bereits beschrieben, ist ein wesentliches Thema eines Risiko-Managements der eigentliche Entwicklungs- bzw. Weiterentwicklungsprozess der Applikation. Hierbei ist es unerheblich, ob die Entwicklung durch ein internes oder ein externes Entwicklerteam oder durch einen unabhängigen Softwarehersteller vorgenommen wird. Das Risiko, welches weitgehend abgemildert werden muss, ist ein negatives Verhalten der Softwarelösung nach dem Deployment eines Updates. Gerade die Nachvollziehbarkeit der Änderungen an den Strukturen eines Systems, aber auch des Verhaltens des Workloads sind elementar.
Des Weiteren sollte der Monitoringansatz auch aktiv in Optimierungsprozesse bzw. -projekte eingebunden werden. Dabei geht es primär darum, auch kleine aber kontinuierliche Verbesserungen in der Stabilität der Skalierbarkeit einer Applikation zu analysieren und zu dokumentieren, damit diese mit den ursprünglichen Anforderungen oder auch Zusagen abgeglichen werden können.
Hinzu kommt, dass bei Performance- und Skalierungsproblemen häufig die Ursache in einer vermeintlich schlechten Programmierung bzw. einem nicht optimalen Code gesucht wird. Hier wird klassische Programmierung in einer Hochsprache (Java, C#, Golang usw.) verglichen mit dem SQL-Code der Applikation. Und genau in diesem Missverständnis liegt eine der häufigsten Ursachen für unvorhergesehene Skalierungsprobleme.
Die Herausforderung beim Monitoring eines Datenbankservers aus der Sicht eines IT-Infrastruktur-Administrators ist das häufig vermeintlich nicht deterministische Verhalten.
Andere Komponenten einer IT-Umgebung, wie zum Beispiel Fileshares, Netzwerke, Web- und als auch Applikationsserver, verhalten sich i. d. R. unter Last in hohem Maße vorhersehbar. Je mehr Last durch Anwender bzw. Services auf den Servern entsteht, um so mehr werden diese belastet und die durchschnittlichen Antwortzeiten werden entsprechend länger. Dieses Verhalten lässt auf recht einfache Art und Weise erwartete Antwortzeiten in definierten Lastsituation formulieren. Sowohl die Applikationen als auch die Serversysteme verhalten sind meist linear mit der Last, daher ist die Eigenschaft einer berechenbaren Skalierbarkeit erfüllt.
Klassische relationale Datenbankserver scheinen diesem Muster aber oft nicht zu folgen. Was sind dafür die Gründe?
Die richtige Sprache
Die meisten Systeme sprechen die Datenbanksprache SQL, welche zunächst einmal einem allgemeingültigen Standard (ANSI SQL) folgt. Dieser Standard wird von allen Anbietern mehr oder weniger vollständig implementiert. Bekannte Vertreter sind hier zum Beispiel die Dialekte PL/SQL (Oracle), T-SQL (Microsoft) und PL/pgSQL (PostgreSQL).
Bei der Datenbanksprache SQL handelt es sich nicht um eine klassische Programmiersprache, wie sie zum Beispiel bei den Prozessen auf Applikationsservern zum Einsatz kommt. Programmiersprachen werden häufig vor dem Deployment mit Compilern in unveränderbaren Code übersetzt. Dabei kann es sich entweder um direkten Maschinencode handeln, welcher direkt ausgeführt werden kann oder um einen Code, welcher zur Ausführung eine sogenannte Runtime erfordert, die zunächst installiert werden muss. Als Beispiele für direkten Maschinencode können zum Beispiel C/C++, Golang und Rust genannt werden. Beispiele für Sprachen mit Runtime sind u. a. Java und C#.
Darüber hinaus gibt es noch Sprachen, welche zur Laufzeit immer wieder direkt interpretiert werden. Diese erfordern zwar keine Kompilierung, sind aber auch bei weitem nicht zu performant bei der Ausführung und sind daher hier nur der Vollständigkeit halber aufgeführt.
Auch wenn man bei der Arbeit mit einer Datenbanksprache wie SQL von einer Kompilierung innerhalb des Systems spricht, verhält sich diese aber während des Betriebs des Datenbankservers dennoch völlig anders. Die meisten gängigen Implementierungen von SQL nutzen eine Komponente im Server – meist als Query Optimizer bezeichnet. So auch der Microsoft SQL Server. Der Zweck dieser Komponente ist u. a., dass die SQL-Befehle, die von den Applikationen zum Server zur Ausführung gesendet werden, übersetzt werden in einen ausführbaren Pseudocode, auch häufig als Ausführungsplan bezeichnet.
Nur ist die Generierung dieses Codes nicht bei jeder Übersetzung unveränderlich, wie bei einer Programmiersprache, sondern folgt weiteren dynamischen Rahmenbedingungen. Eine wesentliche Größe bei der Erzeugung eines Ausführungsplans ist die erwartete Menge an Datensätzen, die für die Verarbeitung des SQL-Befehls benötigt bzw. gelesen werden müssen. Dabei muss es sich aber nicht zwingend um die Größe der Ergebnismenge handeln, sondern es wird auch berücksichtigt, was für Filterungen im Hintergrund benötigt wird. Diese Größe hängt von den Parametern ab, welche einem SQL-Befehl bei der Ausführung von der Anwendung mitgegeben werden.
Der Query Optimizer des Microsoft SQL Servers analysiert dazu sowohl den Code der SQL-Statements als auch die verfügbaren Indizes für die Tabellenobjekte als auch interne Statistiken über die in den Tabellen gespeicherten Daten, um die notwendigen Schätzungen durchzuführen. Je nach Menge und benötigter Sortierung der Daten, erstellt der Query Optimizer einen Plan für die Abarbeitung einer Abfrage.
Daraus folgt, dass derselbe SQL-Befehl unterschiedliche Pläne in Abhängigkeit von der Parametrisierung durch die Applikation und die Anwender erzeugen kann. Sollen zum Beispiel nur Daten von gestern angezeigt werden oder die Daten für das gesamte vorherige Geschäftsjahr? Ein Datenbankserver versucht also immer einen optimalen Ausführungsplan für die jeweilige Fragestellung zu erzeugen. Der offensichtliche Nachteil ist daher, dass auf produktiven Datenbankservern sehr häufig Ausführungspläne zur Ausführung kommen, die die jeweiligen Entwickler sehr wahrscheinlich nie gesehen oder getestet haben. Die Erzeugung der Pläne folgt immer der Prämisse, dass die Parameter (Daten zu einem Zeitraum, Verkäufe über eine Produktgruppe, Kunden mit unterschiedlichen Beleggrößen usw.) und die erwartete Datenmenge zusammengebracht werden. Damit verändert sich die Erstellung von Ausführungsplänen mit einem evtl. veränderten Nutzungsverhalten der Applikation als auch jeweils mit der benötigten Datenmenge für Abfragen.
Da die Kompilierung der SQL-Befehle in einen Ausführungsplan eine CPU-intensive Operation darstellt, werden diese in einem sogenannten Plan Cache für eine spätere wiederholte Verwendung gespeichert. Die Erkennung eines Plans für eine Wiederverwendung ist eine sehr schnelle Operation innerhalb der Datenbank-Engine, aber diese vergleicht nicht, ob die nun übergebenen Parameter zur Strategie innerhalb des Plans passen. Daher kommt es in der Praxis häufig zu der Situation, dass einzelne SQL-Befehle in der Lage sind, über die Zeit hinweg unterschiedliche Pläne zu generieren.
Diese Herausforderung wird auch als Parameter Sniffing bezeichnet und ist eines der Hauptrisiken, welches zu einem vielleicht unvorhersehbaren Verhalten eines Datenbankservers führen kann. Wichtig ist dabei zu verstehen, dass das Vorgehen Pläne dynamisch in Abhängigkeit zu den Parametern zu erzeugen grundsätzlich gerade eine wesentliche Stärke aller relationalen Datenbanksysteme ist. Zu Problemen führt dieses Verhalten nur, wenn bei der Entwicklung und Pflege von Systemen dieses Verhalten wenig oder gar nicht berücksichtigt wird.
Um nun all dieser und noch weiteren Herausforderungen bei der Ausführung von SQL-Code und der Nutzung von Indizes zu begegnen, ist ein geäußerter Wunsch im Rahmen eines Monitorings einer Datenbank-Engine die Protokollierung aller erfolgten SQL-Ausführungen. Damit möchte man erreichen, dass eine quasi lückenlose Nachverfolgung aller Statements möglich wird.
Und tatsächlich existieren auch entsprechende Mechanismen im Microsoft SQL Server, welche eine solche Sammlung ermöglichen. Am bekanntesten, aber auch schon fast berüchtigt, ist hier zum Beispiel der SQL Profiler. Dieser ist aber auch dafür bekannt, dass er durch die reine Beobachtung die Performance des Servers deutlich beeinträchtigt. Im Hintergrund verwendet der Profiler einen SQL Trace, welcher zwar isoliert betrachtet deutlich leichtgewichtiger ist als die GUI des Profilers, aber dennoch sind die Möglichkeiten der isolierten Betrachtung von nur einzelnen Datenpunkten stark eingeschränkt.
Seit dem SQL Server 2008 R2 bzw. SQL Server 2012 sind die wesentlich leichtgewichtigeren Extended Events implementiert, welche eine Aufzeichnung deutlich schlanker ermöglichen.
Nur all diesen Ansätzen ist gemeinsam, dass auf einem produktiven System die Menge an ausgeführten SQL Statements meist so hoch ist, dass es quasi keinen Weg gibt, diese Menge effizient zu speichern. Und natürlich sind gerade die Datenbanksysteme mit einer höheren Last von Interesse.
Hierbei sind zum Beispiel 5.000 bis 30.000 Ausführungen pro Sekunde keine Seltenheit. Sofern von einem Schnitt von nur 5.000 Ausführungen pro Sekunden ausgegangen wird, kommt man auf einen Tagesschnitt von 432.000.000 Ausführungen für einen mittleren Server. Diese Zahl lässt leicht erkennen, dass die Aufzeichnung und Speicherung aller Statements kein wirklich gangbarer Weg ist, da die Datenmenge für die Protokollierung aller Ausführungen die Datenbankgröße um ein Vielfaches übertreffen würde.
Daher verfolgen die meisten Monitoring-Systeme den Weg, dass sie nur einen Bruchteil der Ausführungen im Detail aufzeichnen und die Auswirkungen des gesamten Workloads daraus ableiten. Der interessante Teil hierbei ist die Auswahl des Anteils an Ausführungen, die aufgezeichnet werden sollen. Dabei verfolgen die Hersteller unterschiedliche Ansätze. Einige Hersteller sprechen von einer Menge von auffällig teuren Abfragen, während andere Hersteller Abfragen mit besonders auffälligen Warteverhalten auswählen. Es ist auch immer eine Frage des zugrundeliegenden Ansatzes, was eine auffällige Abfrage ist.
Zusammenfassend kann daher gesagt werden, dass für die Überwachung von Datenbankservern häufig eine Reihe von eher infrastrukturellen Metriken und eine mehr oder weniger repräsentative Auswahl des Workloads zur Verfügung steht. Der Administrator ist nun gefragt, aus diesen gesammelten und dargestellten Daten die notwendigen Schlüsse zu ziehen.
Einsatz im Machine Learning
Wie passt nun in diese Gemengelage von Zielen, Herausforderungen und Tools der Trend Machine Learning oder gar die oft bemühte KI?
Zunächst einmal verspricht man sich oft einen deutlichen Nutzen von einer (autonomeren) Erkennung von Veränderungen und Problemen. Der sogenannten Outliner bzw. Anomaly Detection. Des Weiteren ist die Erwartung, dass ein machine-learning-unterstütztes System auch selbst Strategien für Problemlösungen beisteuern kann. Also von der reinen Visualisierung von Metriken hin zur aktiven Unterstützung bei Problemen. Idealerweise sogar Probleme proaktiv verhindern, bevor diese auftreten.
Machine Learning (ML) ist ein gar nicht mehr so neuer Bereich der Informatik, in dem Applikationen direkt aus gesammelten Daten "lernen" können ohne jeweils explizit für jede Problemlösung programmiert worden zu sein. ML-Algorithmen erkennen dabei automatisch wiederkehrende Muster in Daten, leiten statistische Modelle ab und treffen damit in der Zukunft ohne menschliche Unterstützung selbständig Vorhersagen für die Wiedererkennung dieser Muster. Diese Modelle drücken meist eine Wahrscheinlichkeit über eine mögliche Klassifizierung aus oder es wird eine Zeitreihe von Daten in die nahe Zukunft erweitert.
ML ist gerade durch die Fähigkeit der Mustererkennung eine Schlüsselkomponente von AIOps-Lösungen. Bei AIOps (Algorithmic IT Operations) handelt es sich um einen von Gartner geprägten Begriff, um den Einsatz von komplexeren Analysen und Big-Data-Ansätzen für den Betrieb von IT-Umgebungen zu beschreiben.
- AIOps-Systeme verwenden Machine Learning u. a., um die Prozesse zur Erkennung und Behebung von Problemen in der IT-Umgebungen weitestgehend zu automatisieren.
- Mit der maschinengestützten Ursachenanalyse ermöglicht AIOps einen Level an Monitoring, der weit über das übliche Maß der Erkennung von möglichen Zusammenhängen hinausgeht.
- AIOps ist ein sehr schnell wachsender Bereich zur Unterstützung des Betriebs von komplexen IT-Umgebungen.
Im Rahmen von AIOps wird Machine Learning meist für die Anomaly Detection verwendet. Wie bei quasi jeder Anwendung von ML wird mit einem dreistufigen Prozess vorgegangen:
- Berechnung eines (statistischen) Modells, um das normale Verhalten einer Umgebung oder eines Services zu lernen.
- Verwendung des Modell zur Prognose zukünftiger Werte.
- Identifizierung von Anomalien auf Basis der Prognosen, da neue gemessene Werte mit den Vorhersagen des Modells in Echtzeit abgeglichen werden können.
Ein großer Vorteil dieses Ansatzes ist, dass die Modelle mit der Zeit dazulernen können. Mit neuen Daten werden die ML-Modelle automatisch aktualisiert. Wichtig hierbei ist die Definition, über welchen Zeitraum ein Modell als gültig bezeichnet werden kann und wann es alte Daten besser wieder verlernen sollte, um sich einer aktualisierten Umgebung anzupassen. Diese Form von adaptiven Algorithmen muss gut geplant und überwacht werden, damit nicht auf veralteten Modellen Vorhersagen getroffen werden. Das eigentliche Lernen der aktuellen Daten bedarf dann aber wieder keinerlei Änderungen an Code und damit auch keines menschlichen Eingreifens.
Wichtig ist hierbei noch zu erwähnen, dass die meisten AIOps-Systeme sich nicht nur auf einen Algorithmus verlassen. In der Regel werden mehrere unterschiedliche Ansätze verwendet, welche jeweils Daten, Vorhersagen oder auch Klassifizierungen für nachgelagerte Modelle vorbereiten. Man nennt diesen Ansatz auch das Stapeln von Modell (Stacking).
Wie aus dieser kurzen Beschreibung von Monitoring auf Basis von Machine Learning bereits deutlich wird, ist eine der wesentlichen Herausforderungen für den Einsatz die Bereitstellung von "normalen" Werten.
Jetzt ist es aber so, dass Machine Learning generell in zwei Bereiche aufgeteilt werden kann. Es gibt auf der einen Seite das sogenannte Supervised Learning und auf der anderen Seite das Unsupervised Learning.
Der Unterschied liegt darin, dass einem Algorithmus aus dem Supervised-Learning-Umfeld für den Lernprozess vorqualifizierte Daten geliefert werden müssen. Man spricht auch von gelabelten Daten. Dieser Ansatz funktioniert sehr gut zum Beispiel bei Bilddatenbanken mit entsprechenden Beschreibungen. Wie schon erwähnt, existieren diese Daten für ein Monitoringsystem meist nicht.
Im Gegensatz dazu sind die Algorithmen aus dem Unsupervised-Learning-Umfeld in der Lage, Daten nur auf Basis ihrer "Ähnlichkeit" zu klassifizieren. Dieses Vorgehen kennt man evtl. auch noch aus der Ära des Data Minings, welches eine Art Vorläufer zum heutigen ML darstellt.
Die wohl mit bekanntesten Algorithmen für diese Aufgabe sind K-Means Clustering und DBSCAN (Density-based spatial clustering of applications with noise).
Beide Ansätze werden genutzt, um eine gegebene Datenmenge in Abhängigkeit von ihrer Ähnlichkeit in Gruppen (Cluster) aufzuteilen. K-Means erwartet dafür eine gegebene Anzahl von Gruppen während DBSCAN diese selbst errechnet. Ein weiterer Vorteil von DBSCAN ist es, dass er Daten, welche nicht eindeutig zu einer Gruppe passen, als Ausreißer klassifiziert. Beide Algorithmen haben in der Anwendung jeweils ihre Vor- und Nachteile.
Ein gemeinsamer Vorteil ist, dass sie in der Lage sind, aus einer quasi unüberschaubaren Menge an einzelnen Datenpunkten Muster bzw. Cluster abzuleiten. In der Literatur werden häufig zweidimensionale Beispiele bemüht, in der Realität sind dieses aber häufig multidimensionale Datenräume, welche einen Menschen sehr leicht überfordern bzw. zu Fehleinschätzungen verleiten würden.
Statt aber immer gleich komplexe Machine-Learning-Ansätze einzusetzen und zu versuchen, direkt aus den aufgezeichneten Daten lernen zu lassen, gibt es auch verschiedene Zwischenschritte, um die Daten aufzubereiten. Ein Beispiel hierfür ist die statistische Analyse von Daten. Die Mehrheit der anfallenden Daten in einer Überwachung sind meist sogenannte Zeitreihen.
Ein Datenpunkt hat einen Wert und einen Zeitstempel, an dem dieser Wert gemessen wurde. Das kann zum Beispiel die Auslastung einer CPU durch einen Prozess sein, die Latenz beim Schreiben auf ein Storagesystem oder auch die Anzahl von gleichzeitigen Verbindungen zu einem System. Zeitreihen lassen sich intuitiv sehr gut visualisieren und werden daher auch gerne 1:1 von der Messung durchgereicht im Form eines Charts zum Anwender.
Des Weiteren sind Zeitreihen ideale Kandidaten für ein statisches Alerting. Es wird mit fixen Schwellenwerten gearbeitet. Zum Beispiel ist eine Latenz von mehr als 15-25ms für das Schreiben auf ein Storagesystem meist schon ein nicht optimaler Wert und zumindest eine Warnung wert.
Nun besteht häufig der Reflex, wie bereits beschrieben, Zeitreihen direkt als Datenquelle für Machine-Learning-Modelle zu nutzen. Das ist natürlich möglich, geht aber oft schon zu weit. Ein guter Ansatz ist es, zunächst den Daten mit klassischer Mathematik zu begegnen.
Die deskriptive Statistik kennt u. a. die Zeitreihenzerlegung, welche wiederum dazu dient, Muster aus Reihen zu extrahieren. Dabei wird dann von sogenannten Komponenten gesprochen, welche jeweils technisch gesehen wieder Zeitreihen sind:
- Trendkomponente (langfristige Faktoren führen zu einer kontinuierlichen Änderung),
- Zyklische Komponente (unregelmäßig wiederholende Faktoren führen zu Wellenbewegungen),
- Saisonale Komponente (regelmäßige Faktoren führen zu gleichmäßigen Welleneffekten) und
- irreguläre Komponente (eine zufällige Streuung bzw. Noise).
Diese Einzelkomponenten sind sowohl einzeln als auch in Kombination mit darauf aufbauenden Schritten für die Analyse eines Datenbanksystems sehr nützlich. So kann beispielsweise mittels der Trendkomponente mit wenig Aufwand ein sonst vielleicht unbemerkter Trend in einem Wert sichtbar gemacht werden. Wichtig hierbei ist zu verstehen, dass es nicht immer gleich wieder eine Visualisierung sein muss. Nachgelagerte Modelle können als Beispiel die Information bekommen, welche Zeitreihen einen Aufwärts-/Abwärts- oder gar keinen Trend haben. Ganz andere Informationen können wiederum aus der zyklischen als auch saisonalen Komponente gewonnen werden. Solche Informationen können dann wiederum als Daten für nachfolgende Machine-Learning-Algorithmen verwendet werden.
Das erklärte Ziel vieler Ansätze und Anbieter von AIOps-Produkten ist es, die eigentliche Ursache, welche für ein aufgetretenes Problem verantwortlich ist, klar und eindeutig zu identifizieren.
Zunächst einmal nochmals der Hinweis, dass das AI in AIOps für Algorithmic IT steht und nicht für Artificial Intelligence. Also keine künstliche Intelligenz mittels Machine Learning!
Viel entscheidender ist für einen AIOps-Ansatz, dass das jeweilige Domain Knowledge, also die Kenntnis über die möglichen Abhängigkeiten, in das System eingeflossen ist. Zwar kann man sich theoretisch vorstellen, dass ein ausreichend großes Machine-Learning-Modell, welches mit ausreichend vielen gelabelten Daten trainiert wurde, auch viele Abhängigkeiten erkennen und lernen könnte. Es ist aber meist wesentlich effizienter als auch kostengünstiger, wenn man zunächst in Form eines sogenannten Knowledge-Graphen die bekannten und auch meist generischen Abhängigkeiten einer Technologie wie einem Datenbanksystem in ein AIOps-System einfließen lässt.
Neu ist dieser Ansatz wiederum nicht. Bekannt wurde er u. a. als Rule based AI, welche am Ende nichts anderes ist als eine Sammlung von vielen Regeln, die aufeinander aufbauen. Diese Regeln können dann u. a. mit den gemessenen Daten interagieren, indem ermittelt wird, welche Metriken sich über die Zeit hinweg langsam oder auch spontan geändert haben und das Wissen aus dem Knowledge-Graphen genutzt wird, die nächsten denkbaren Ebenen für dieses Verhalten wiederum zu untersuchen.
Die Ermittlung dieser Abweichungen können entweder mittels statischer Schwellenwerte, statistischer Methoden oder auch Machine-Learning-Modellen erfolgen. Im Grunde wird mittels eines "Wenn-dann"-Baums eine oder mehrere vermeintliche Anomalien in den Werten an eine nächste Ebene weitergereicht, welche wiederum ihre eigenen Analysen durchführt.
Fazit
Zusammenfassend kann festgestellt werden, dass die Überwachung von relationalen Datenbanksystemen eine große Herausforderung darstellt. Wichtig ist, zu verstehen, dass der isolierte Einsatz von Machine-Learning-Algorithmen zur Erkennung von Anomalien in Zeitreihen nicht sofort die Analyse des gesamten Systems deutlich vereinfacht.
Erst durch die Kombination von aufeinander aufbauenden Ansätzen und eine Integration in ein stringentes Managementkonzept profitiert eine Organisation wirklich von einem Investment in diesen Bereich, wie zum Beispiel in AIOps-Lösungen.
