Performance Monitoring mit KI: Alarm bei 70 % CPU-Last

Langsame Systeme sind ein messbares Geschäftsrisiko: Nutzer brechen Anwendungen ab, die länger als fünf Sekunden laden, und Verlangsamungen ohne kompletten Ausfall können Schäden in zweistelliger Millionenhöhe verursachen. Proaktives Performance Monitoring setzt eine Schwelle bei 70 Prozent CPU-Auslastung, löst automatisch einen Alarm aus, sammelt Daten zu den betroffenen Datenbankabfragen und API-Endpunkten und legt die Ergebnisse in einem Ticket ab, bevor Nutzer etwas merken. Die häufigsten Ursachen für Performance-Probleme sind nicht optimierte Datenbankabfragen, Skalierung und Infrastruktur sowie die Lastverteilung.

Das Wichtigste in Kürze

• Eine Schwelle bei 70 Prozent CPU- oder Ressourcenauslastung löst automatisch einen Alarm aus, bevor das System ausfällt. Nutzer bekommen weder Verzögerungen noch 404-Fehlermeldungen zu sehen.
• Langsame Systeme kosten echtes Geld, auch ohne Totalausfall: Ein gemeinsamer Vorfall mit Verlangsamungen bei YouTube und Azure kostete mehr als 70 Millionen US-Dollar.
• KI-gestützte Monitoring-Tools wie Bits AI von Datadog finden genau die Datenbankabfrage oder den API-Endpunkt, der ein Performance-Problem verursacht, und verkürzen die Analyse von Stunden auf Minuten.
• Nach Rao Dhaligadoos Praxiserfahrung sind nicht optimierte Datenbankabfragen und die Konfiguration von Load Balancern bei hohem Datenverkehr die häufigsten Ursachen für Performance-Probleme in der Produktion.
• Wer ohne proaktive Überwachung nur auf Vorfälle reagiert, landet im Krisenstab: In einem konkreten Fall dauerte es 45 Stunden, bis der Betrieb wieder lief.

Langsame Systeme kosten Geld, lange bevor sie abstürzen

Ein langsames System verliert Kunden und Umsatz, obwohl es technisch noch läuft. Genau hier setzt Performance Monitoring an. Rao Dhaligadoo sagt es ohne Umschweife: Wer sich länger als fünf Sekunden durch den Login quält, gibt die App auf, und bei so vielen Alternativen am Markt ist die nächste nur einen Klick entfernt.

Die meisten Teams achten auf den Totalausfall. Die 404-Seite, das Ladesymbol, das sich endlos dreht, der schwarze Bildschirm. Das fällt auf, weil es niemand übersehen kann. Langsamkeit dagegen liegt im toten Winkel. Das System antwortet ja noch, nur eben so schlecht, dass die Leute gehen.

Rao nennt einen kombinierten Vorfall bei YouTube und Azure vor etwa zwei Jahren, der mehr als 70 Millionen US-Dollar gekostet hat. Die Systeme waren nicht ausgefallen. Sie waren langsam. Schon diese eine Zahl macht aus Performance ein Geschäftsthema statt einer technischen Feinheit.

Warum Nutzer nach fünf Sekunden abspringen

Nutzer messen jede Anwendung an der schnellsten, die sie kennen. Den Maßstab setzen mobile Apps: antippen, Ergebnis da. Hinkt eine Website oder ein Geschäftssystem hinterher, wirkt es kaputt, auch wenn es funktioniert.

Deshalb ist Langsamkeit das schwierigere Problem. Ein Absturz erzwingt eine Reaktion: Jemand schlägt Alarm, das Team legt los. Langsamkeit wirkt leise. Die Kunden gehen einzeln, und der Umsatzverlust taucht erst lange nach der Ursache in den Zahlen auf.

Performance Monitoring: Alarm bei 70 Prozent statt erst beim Ausfall

Der Kern dessen, was Rao beschreibt, ist eine Schwelle von 70 Prozent. Überschreitet die CPU-Auslastung oder der überwachte Wert 70 Prozent, geht automatisch ein Alarm raus. Handeln, bevor das System kippt, nicht hinterher.

Über 70 Prozent verlieren Systeme erfahrungsgemäß schnell an Leistung. Erst werden sie langsam, dann stürzen sie ab. Wer den Trend bei 70 Prozent erkennt, gewinnt Zeit für Diagnose und Behebung, während die Nutzer weiter bedient werden.

Raos Team setzt Datadog als Monitoring-Tool ein. Wird die Schwelle überschritten, sammelt das Tool selbst die nötigen Daten: betroffene Datenbanken, Abfragen, API-Endpunkte, die Netzwerkschicht. Dann legt es ein Ticket in Jira oder JSM an, in dem all das schon drinsteht.

Die Automatisierung sammelt. Ein Mensch bewertet. Diese Trennung ist wichtig, denn das Tool kann nicht wissen, ob ein Ausschlag ein echtes Problem war oder eine einmalige Abweichung, weil das Team an diesem Tag bewusst etwas in der Produktion geändert hat.

Vom Alarm bis zur Auslieferung der Korrektur

Bevor jemand am Ticket arbeitet, wird es geprüft. Ist der Alarm echt oder war es ein Ausreißer? Diese Prüfung schont die Kapazität des Teams, denn an einer Korrektur hängen Entwicklung, Test und Infrastruktur.

Danach läuft alles wie beim normalen Testen, nur eben für Performance:

Einen Fehler in der Testumgebung nachzustellen, ist für Tester Alltag. Bei Performance heißt das: dieselbe Verlangsamung erzeugen, bevor jemand versucht, sie zu beheben. Ist sie nachgestellt, weiß die Entwicklung genau, wo sie ansetzen muss.

Eine Verlangsamung aus der Produktion in einer kleineren Umgebung nachstellen

Gleiche deine Testumgebung so weit an die Produktion an, wie es die Ressourcen erlauben. Geht das nicht vollständig, skaliere proportional. Hast du nur die Hälfte der Ressourcen, fahre die Hälfte der Last. Über das Verhältnis bleibt der Test aussagekräftig.

Dass ein herunterskalierter Test trotzdem trägt, liegt an der Präzision. Ein allgemeiner Lasttest hofft, das Problem mit roher Gewalt auszulösen. Ein gezielter Test kennt die schuldige Datenbankabfrage oder den API-Endpunkt und schickt die Last genau dorthin.

Genau deshalb nutzt Raos Team Datadog zusätzlich zum Monitoring, das die Cloud-Plattformen ohnehin mitbringen. Die zusätzliche Detailtiefe zeigt, welche Abfrage und welcher Endpunkt die Verlangsamung verursachen. So stellst du das konkrete Problem nach, statt zu raten.

Die wahre Ursache in Gigabytes an Logs finden

Die eigentliche Schwierigkeit bei einem Performance-Problem liegt darin, in der Datenmenge die wenigen Stellen zu finden, die das Problem wirklich verursachen. Die Logs gehen in die Gigabytes, Dutzende Prozesse laufen parallel. Die eigentliche Ursache herauszuschälen, das ist die Arbeit.

Hier hilft laut Rao KI. Bits AI von Datadog wertet die Monitoring-Daten aus, etwa wie oft jeder Endpunkt aufgerufen wurde und welche Operationen gelaufen sind, und zeigt, wo das Problem sitzt. Von Hand dauert dieselbe Analyse leicht Stunden.

Zusätzlich liefert die KI Beispielabfragen und Vorschläge, wie sich der Code korrigieren lässt, und das landet direkt im Ticket. Die Entwicklung entscheidet dann auf einer fundierten Basis, statt bei null anzufangen.

Ein Mensch bleibt trotzdem beteiligt, und zwar wegen etwas, das die KI nicht liefern kann: Kontext. Das Tool weiß nicht, ob der heutige Ausschlag eine Anomalie war oder die Folge einer Änderung, die das Team selbst in der Produktion vorgenommen hat. Das muss ein Mensch beisteuern.

Die drei häufigsten Ursachen für Performance-Probleme

In den Systemen, an denen Rao gearbeitet hat, gehen die meisten Performance-Probleme auf drei Ursachen zurück.

• Datenbankabfragen. Die Datenmengen, die Anwendungen verarbeiten, wachsen ständig, und bei Big Data müssen die Abfragen optimiert sein. Nicht optimierte Abfragen sind nach seiner Erfahrung die häufigste Ursache.
• Skalierung und Infrastruktur. Wie das System aufgebaut und vernetzt ist, entscheidet, wie es sich unter Last hält.
• Lastverteilung. Steigt die Last, stellt sich die Frage, ob der Load Balancer sie noch richtig verteilt.

Proaktives Monitoring macht aus Monaten einen Sprint

Wer vom reaktiven Feuerlöschen auf proaktive Alarme umstellt, verkürzt die Reaktionszeit drastisch. Rao schätzt, dass Arbeit, die früher einen Monat oder zwei Wochen gedauert hat, heute ungefähr in einen Sprint passt.

Früher war jeder Schritt langsam. Kunden riefen an und meldeten, dass das System nicht geht. Wollte ein Team proaktiv sein, musste erst jemand den Bereitschaftstechniker auftreiben. Der brauchte zehn oder fünfzehn Minuten, bis er da war, dann eine halbe bis ganze Stunde für die Analyse und danach noch Zeit, um alles in ein Ticket oder eine E-Mail zu schreiben. Unterwegs schlichen sich Fehler ein.

Dazu kam der Widerstand. Entwickler gingen in die Defensive: Das erledigt sich von selbst, bei mir läuft es doch. Jede Übergabe kostete zusätzlich Zeit.

Die automatische Datensammlung nimmt den größten Teil dieser Reibung heraus. KI hilft außerdem beim Erstellen der Performance-Skripte, der JMeter-Skripte, was den Zyklus weiter verkürzt. Die Prüfung durch einen Menschen bleibt, weil das Team den Daten ohne Kontrolle nicht vollständig trauen kann.

Was reaktives Arbeiten die Menschen kostet

Wer nicht proaktiv arbeitet, zahlt einen Preis, der in keinem Ausfallbericht steht: den der Menschen, die das Problem lösen. Rao erzählt von einem Ausfall bei einer Bank, bei dem das Team 45 Stunden am Stück im Büro blieb. Eigentlich hatte er für dieses Wochenende Urlaub geplant.

“Der Stress in diesem Krisenstab war enorm. Der CIO kam gegen 13 Uhr im Anzug herein, er war entspannter, aber alle anderen waren … Und dann war es totenstill. Und er sagte nur: Wir können es uns nicht leisten, dass das System noch länger ausfällt.”

(Rao Dhaligadoo)

Selbst danach dauerte es noch zehn bis fünfzehn Stunden, bis die Produktion wieder lief. Verpasste Zeit mit der Familie, eine verpasste Schulaufführung des Kindes, ein abgesagter Urlaub. Das verlangt reaktives Arbeiten einem Team ab.

Proaktives Monitoring soll diesen Stress genauso verhindern, wie es den Umsatz schützt. Im Idealfall sieht der Nutzer nie das Ladesymbol oder die 404-Seite, und das Team muss nie im Krisenstab sitzen, um dafür zu sorgen.

Häufig gestellte Fragen

Warum bekommen langsame Systeme weniger Aufmerksamkeit als komplette Ausfälle?

Weil das System immer noch reagiert. Ein 404-Fehler oder ein Ladesymbol, das nie verschwindet, zwingt jemanden dazu, Alarm zu schlagen. Eine Verlangsamung zehrt still und leise an der Nutzerzahl und kostet nach und nach Kunden, während der Dienst technisch gesehen noch läuft. Der Umsatzverlust wird erst lange nach der Ursache sichtbar. Nutzer geben eine Anwendung auf, bei der die Anmeldung länger als fünf Sekunden dauert, und wechseln zu einer Alternative.

Kann eine Verlangsamung echtes Geld kosten, wenn eigentlich gar nichts ausfällt?

Ja. Ein kombinierter Vorfall, der YouTube und Azure betraf, kostete mehr als 70 Millionen US-Dollar, und diese Systeme waren nicht ausgefallen, sondern nur langsam. Das macht aus der Leistung kein technisches Detail mehr, sondern ein geschäftliches Risiko. Der Vergleich, den Nutzer anstellen, stammt aus mobilen Apps: Tippen, Ergebnis erscheint. Ein Geschäftssystem, das hinter dieser Erwartung zurückbleibt, wirkt wie defekt, auch wenn es funktioniert.

Sollte ein Monitoring-Tool oder ein Mensch entscheiden, ob eine Warnmeldung ein echtes Problem ist?

Beides, mit einer klaren Aufgabenteilung. Die Automatisierung sammelt die Belege, sobald ein Schwellenwert überschritten wird: betroffene Datenbanken, Abfragen, API-Endpunkte, die Netzwerkschicht. Dann eröffnet sie ein Ticket in Jira oder JSM mit den angehängten Daten. Eine Person führt dann eine Validierung durch, um zu überprüfen, ob der Alarm ein echtes Problem oder nur eine einmalige Anomalie widerspiegelt, denn eine Behebung erfordert die Einbindung von Entwicklern, Testern und Infrastrukturmitarbeitern.

Erfordert der Performanztest eine Testumgebung, die identisch mit der Produktion ist?

Nein. Passe die Testumgebung so gut wie möglich an die Produktionsumgebung an, soweit es deine Ressourcen zulassen, und skaliere dann proportional: Wenn du dir nur die Hälfte der Ressourcen leisten kannst, führe die Hälfte der Last aus. Das Verhältnis sorgt dafür, dass der Test aussagekräftig bleibt. Präzision ist wichtiger als Umfang. Ein gezielter Test, der die Last auf die spezifische fehlerhafte Abfrage oder den Endpunkt lenkt, ist besser als ein generischer Lasttest, bei dem man hofft, das Problem durch Brute-Force-Methoden auszulösen.

Kann KI die Grundursachenanalyse bei Leistungsproblemen übernehmen?

Nicht ganz. Bits AI von Datadog wertet die Überwachungsdetails aus (zum Beispiel, wie oft jeder Endpunkt aufgerufen wurde und welche Vorgänge ausgeführt wurden) und deckt so auf, wo das Problem liegt. Von Hand würde diese Analyse Stunden dauern. Außerdem erstellt sie Beispielabfragen und schlägt im Ticket Code-Korrekturen vor. Der Kontext bleibt menschlich: Das Tool kann nicht wissen, ob ein Spitzenwert abnormal oder selbst verursacht war.

Was verursacht die meisten Leistungsprobleme in Produktionssystemen?

Drei Ursachen tauchen immer wieder auf. Nicht optimierte Datenbankabfragen sind laut Rao Dhaligadoos Praxiserfahrung am häufigsten, da das Datenvolumen, das Anwendungen verarbeiten, ständig wächst. An zweiter Stelle stehen Skalierung und Infrastruktur: Wie das System aufgebaut und vernetzt ist, bestimmt, wie es unter Last standhält. An dritter Stelle steht der Lastausgleich, also die Frage, ob der Load Balancer den Datenverkehr auch bei steigender Last noch korrekt verteilt.

Wie viel Zeit spart proaktives Alerting im Vergleich zum Warten auf Berichte?

Arbeiten, die früher einen Monat oder zwei Wochen dauerten, passen nun in etwa in einen Sprint. Der reaktive Ansatz kostete bei jedem Schritt Zeit: ein Anruf vom Kunden, zehn oder fünfzehn Minuten, um den Bereitschaftstechniker zu erreichen, eine halbe bis eine Stunde Analyse, dann das Festhalten aller Informationen in einem Ticket oder einer E-Mail, und dabei immer die Gefahr von Fehlern. KI-generierte JMeter-Skripte verkürzen die Durchlaufzeit noch weiter.

Was kostet die reaktive Bearbeitung von Vorfällen die Leute, die sich darum kümmern?

Mehr, als jede Ausfallmeldung vermeldet. Während eines Ausfalls bei einer Bank blieb das Team 45 Stunden am Stück im Büro, und es dauerte weitere zehn bis fünfzehn Stunden, bis der Betrieb wieder lief. Ein gestrichener Urlaub, verpasste Zeit mit der Familie, eine verpasste Schulaufführung. Proaktives Monitoring zielt ebenso darauf ab, diesen Stress zu beseitigen wie den Umsatz zu schützen.