• TL;DR
• Der Weg ins Monitoring
• Schwellwert
• Geschirrspülmaschinenphilosophiererei
• Schwellenwerte
• Normalität
• Performanceprobleme
  • Von Anfang an ….
  • War plötzlich da …
  • Über die Zeit ….
• Ignoriert …
• 105% ?
• Normalitätsmonitoring
• Modell der Normalität
• Grün ist normal
• Statistik
• Badende Frösche
• Verschiebung
• Automatisch
• Ansätze
• Postskriptum

Ich habe seit ein paar Tagen Urlaub. Eine Reihe von Dingen hat auch da wieder meine eigentliche Planung über den Haufen geworfen und nach hinten geschoben. Ich habe die Zeit mal genutzt, um einen Gedanken aufzuschreiben, der mir in den vergangenen Tagen durch den Kopf geisterte.

TL;DR

Ich glaube auch dieser Text wird wieder ein Stück vor sich hin mäandern, bevor zum Punkt kommt. Daher ein TL;DR: Wäre neben einem Schwellenwertmonitoring nicht auch ein zeit- und lastangepasstes Normalitätsmonitoring sinnvoll in der Überwachung von IT-Systemen anstatt nur auf statische Schwellenwerte zu monitoren? Also das Monitoring die Frage zu beantworten zu lassen: Ist gemessen am Zeitpunkt und an der Last, das was da auf dem System zu sehen ist, eigentlich “normal”

Der Weg ins Monitoring

Ich hab ja schon mal geschrieben, das mein RSS-Reader (der mittlerweile eine Applikation auf einem NAS ist und nicht mehr wie ganz ganz früher beispielsweise Netnewsreader oder später Reeder), mir immer noch sehr viele sehr interessante Artikel ins Hirn spült. Auch wenn RSS irgendwie aus der Mode gekommen scheint. Schade eigentlich.

Ein solcher Artikel war vor einer Weile dieser Artikel über Monitoring, den ich an dieser Stelle sehr empfehlen möchte.

Ich habe vor einigen Tagen an diesen Artikel gedacht, wegen eines Nebenthemas des Artikels : Schwellenwerte als Subthema des Subthemas Alarmierung in diesem Gemisch von Dingen die man Bedenken muss, wenn man Monitoring aufsetzt.

Schwellwert

Oder wie viel zu oft geschrieben und wie die Autorin richtigerweise ausführt, eben viel zu oft falsch geschrieben: Schwellwerte. Verwende ich selbst viel zu oft. Auch wenn ich weiss, dass es Schwellenwert heißt. Ich mag auch gerade nicht ausschliessen, das sich nicht irgendwo (ausser gerade eben und gleich nochmal) ein „Schwellwert“ eingeschlichten hat. Ist wahrscheinlich sowas wie LCD-Display. Das Thema „Schwellenwert“ ist wahrscheinlich thematisch auch zu randständig, als das der Duden Verlag diesen Umstand irgendwann durch Aufnahme des Wortes „Schwellwerte“ in den Duden erledigen wird. Und dann würde es sowieso wieder „Schwellenwert“-Ultras geben. So wie Ph-Ultras. Delfin. F ? Over my dead body! Es heisst Delphin! Und Telephon. Und Photographie. Naja, egal … was schrieb ich noch vorhin zum Thema “mäandern”.

Geschirrspülmaschinenphilosophiererei

Also Schwellenwerte. Wie komme ich gerade jetzt darauf? Und warum fiel mir der Text, auf den ich verlinkt habe, dabei ein. Eigentlich ein loses Gespräch am Ende einer beruflichen Videokonferenz („Bleibst bitte noch mal im Call …. “), das in postpandemischen Zeiten oft das Gespräch an der Geschirrspülmaschine ersetzt, während man den Becher des letzten Meetings diesem unverzichtbaren Gerät in den mittlerweile bei manchen Maschinen beleuchten Schlund ¹ warf. Da ging es um die Diskussion: Welche Schwellenwerte will man eigentlich nehmen, und wer legt die eigentlich fest? Und wer sorgt dafür, dass diese sinnvoll sind? Und wie definiert sich eigentlich „sinnvoll“? Was will ich eigentlich von der Alarmierung ob eines überschrittenen Schwellenwertes? Wie monitored man eigentlich etwas, das da sein müsste, es aber nicht ist? Wie monitored man etwas, das sich in seiner Zusammensetzung geändert hat?

Geschirrspülmaschinenphilosophiererei eben. Ich mag diese Gespräche. Weil anders als eben der Call ein solches entglittenes Thema eben nicht vorbereitet ist. Und die Fragen, die sich darin ergeben, oftmals weitere Fragen haben. Fragenfraktale, um mit Kaptn Peng zu sprechen. Und das meistens in einer sehr interessanten Ecke endet.

Schwellenwerte

Schwellenwerte können ja recht einfach definiert werden: Wenn Wert grösser gleich 80%, dann sende Warnung. Wenn Wert grösser als 95%, dann steuere das Schiffstyphon im Adminbüro an, auf das diese endlich wach werden und ihre werten Hintern bewegen. Ein Ping kommt durch, alles okay. Mehrere Pings kommen nicht durch. Irgendwas ist wohl nicht in Ordnung.

Ich will hier nicht zum Ausdruck bringen, dass diese Art des Monitorings unnötig ist. Ganz und gar nicht. In dem was mir da vorschwebt, ist es sogar wichtig, das es sie gibt. Warum komme ich später drauf. Ich glaube nur, dass in diesen Daten, die man da aufzeichnet, deutlich mehr Information ist, die es auszuwerten gilt, selbst wenn das ganze Dashboard auf Grün steht. Und das man das ständig (und damit automatisiert) machen sollte.

Normalität

Die Information, die ich hier meine ist Normalität. Schwellenwerte wie oben beschrieben testen ja auf angenommene obere Limits, die eine besonderen Würdigung bedürfen. Das hat aber erst mal sehr wenig mit Normalität zu tun. Etwas kann noch innerhalb herkömmlicher durch Schwellenwerte gesetzter Limits sein, aber ganz und gar nicht normal.

Beispiel: Ich sehe üblicherweise 25% CPU-Auslastung und plötzlich steht da 50% in meinen Aufzeichnungen. Der 80% oder 95%-Schwellenwert triggert da noch lange nicht, dennoch ist das eine Information in meinen Aufzeichnungen, über die ich gerne informiert werden möchte. Ein anderes Beispiel: Meine Pings mögen alle durchkommen, aber in der Information, dass sich Zeit bis zum Reply regelhaft seit einiger Zeit verzwanzigfacht hat, wohnt eine eigene Erkenntnis inne. Und auch das möchte ich eigentlich von einem Monitoring mitgeteilt bekommen. „Jörg, ist zwar noch irgendwie noch nicht katastrophal, aber gut ist das alles nicht mehr“.

Klar, kann ich da deutlich niedrige Schwellenwerte setzen. Der Ping gilt bereits nach 10 ms als fehlgeschlagen, statt beispielsweise nach einer Sekunde oder sogar länger. Aber das verschiebt auch hier das Problem nur: Denn dem 5ms Ping, der früher 1ms gedauert hat, wohnt die gleiche Information inne, das sich da etwas in eine Richtung bewegt, in die es nicht soll.

Es ist bei Normalität primär nicht interessant, welchen absoluten Wert der gemessene und überwachte Wert hat, sondern wie weit dieser aus einem Erwartungskorridor herausfällt.

Performanceprobleme

Vielleicht ist diese Sichtweise ein wenig von meiner Arbeit geprägt. Ein Teilgebiet meines Berufes ist die Beschäftigung mit Performanceproblemen, da diese Arbeit viel mit Erwartungskorridoren zu tun hat. Die gibt es meiner Beobachtung nach in drei Hauptgeschmacksrichtungen: Jenen, die von Anfang an da sind, jenen die plötzlich da sind, aber auf ein klares einzelnes Ereignis zurückzuführen sind und jenen, die über die Zeit entstehen.

Von Anfang an ….

Die Performanceprobleme, die von Anfang da sind, sind meistens unpassende Konfiguration. Ich mag hier nicht von fehlerhafter Konfiguration sprechen, weil die Leute meist keinen Fehler gemacht haben, sondern eine Konfiguration bei einem neuen System einfach nur inadäquat werden kann. Ja, okay, ist irgendwie auch ein Fehler. Aber Fehler hört sich oft so als, als wüssten die Leute vor dem Monitor nicht, was sie tun. Das wissen die Menschen meist sehr genau. Aber weil Dinge eben neu sind, sind diese Erfahrungen möglicherweise unbrauchbar für die neue Situation.

Beispiel kann mit einer neuen Applikation ein Hashing-Algorithmus fürs LACP, der bisher ganz gut gepasst hat (oder dessen Inadäquatheit bisher einfach nur nicht aufgefallen ist), plötzlich nicht mehr hinreichend sein und die Performance eines Systems beeinflussen. Hatte ich vor nicht allzu langer Zeit: Bin auf dem Weg zur Lösung eine ganze Menge Switche durchgegangen, um den schuldigen Switch zu finden.

Nebenbei angemerkt: Ich haette gerne etwas wie einen Layer-2-Kabelpiepser. Ich markiere ein Paket mit einem Secret und die Switche sagen mir „Hab ich gesehen. Auf Port x reingekommen und auf Port y wieder rausgeschickt.“ Sowas wie traceroute, nur einen Layer drunter ….

Hier gibt es noch keine Normalität. Alles ist neu. Ich habe zwar Erfahrungswerte, die mir sagen, was potentiell ungewöhnlich ist. Aber ich habe keine Messwerte, die mir Normalität aufzeigen, um damit helfen, das Anormale zu filtern. Was ich stattdessen habe, sind Erwartungen. Vom Kunden eingebracht und gefordert. Von mir selbst mitgebracht. Man muss in dieser Situation erst das “Normal” lernen.

War plötzlich da …

Plötzlich auftretende Performanceprobleme sind meist damit verbunden, dass irgendwas den Geist aufgibt. Wobei Performanceproblem hier ein relativer Begriff ist. Denn oft ist es kein Performanceproblem im Sinne eines SLA-Verstoss, sondern ein gefühltes Performanceproblem, weil sich das System langsamer handhabt, als man es gewohnt hat. Es verhält sich “nicht normal”. Das Phänomen tritt insbesondere bei active-active Clustern auf.

Man sollte schon das System, für da man verantwortlich ist, so sizen, dass auch beim Wegfall eines Systems genügend Performance da ist (ich sollte meiner Autokorrektur mal beibringen, dass ich meine Systeme nicht sieze, sondern size). Da in meiner Umgebung doch recht viel mit Clustern mit zwei Nodes (wegen HA, nicht wegen Skalierung) gearbeitet wird, heißt das zwangsläufig, das doppelt so viel Leistung zur Verfügung steht, wie eigentlich benötigt wird. Denn sollte ich das nicht machen, habe ich im Ausfallfalle zu wenig Leistung, wenn die geforderte Leistung 50% des Auslegungsszenarios überschreitet.

Es ist das gleiche Phänomen wie bei Flugzeugen: Ein Flugzeug muss immer mit dem Ausfall eines Triebwerks auch im blödestmöglichen Moment klarkommen. Das heißt, ein Triebwerk muss auch beim Start reichen, das Flugzeug mit einem bestimmten Mindestwinkel zu starten. Hat zur Folge, dass wenn beide Triebwerke funktionieren, viel zu viel Leistung zur Verfügung steht. Bei einer zweimotorigen Maschine halt 100% mehr, da ein Triebwerk reichen muss, um die Kiste sicher zu ins Pattern zu bringen, das für solche Fälle vorgesehen ist. Eine vierstrahlige Maschine braucht da deutlich weniger zusätzliche Leistung, da nach einem Ausfall immer noch drei Triebwerke die zum Start nötige Leistung erbringen. Bei Flugzeugen macht man sich das dadurch zunutze das man die Triebwerke beim Start dann nicht auf vollen Schub bringt, sondern auf gerade so viel Leistung, dass es sicher zum Start reicht. Spart Sprit und schont das Triebwerk. Oder man nutzt das, in dem man sehr schnell startet bei zweistrahligen Flugzeugen. ²

Das macht man aber bei Clustern in der IT nicht. Daher merkt man oft einen einzelnen Ausfall in einem Active-Active Cluster dann doch schon: Das kann je nach Applikation von rasend schnell auf „hält gerade das SLA ein“ gehen. Das im Normalbetrieb die Clusternodes runtergeregelt werden, damit im Ausfallfalle die Performancewahrnehmung gleichbleibt, sehe ich eher selten.

Aber all das führt zu dem interessanten Effekt, das man bei halbwegs brauchbarer Skalierung über die Anzahl der Nodes Ressourcen durch mehr Nodes sparen kann.

Aber das Ausfallen eines System wird durch das Schwellenwert-Monitoring sowie das „ist da/is nicht mehr da“-Monitoring vollumfänglich abgedeckt. Ich sehe ja „Server C hat gerade die Grätsche gemacht“ und kann demenstprechend handeln. Das vielleicht all die Komponenten sich nicht mehr normal verhalten, ist interessant, aber für die notwendige Aktion erst mal von eingeschränkten Nutzen Natürlich verdoppeln sich die Requests auf dem verbleibenden System, wenn ein von zwei Systemen nicht mehr läuft. Mein Problem ist System C, nicht die Verdoppelung der Requests.

Über die Zeit ….

Aber ich schweife ab. Es gibt dann eben auch die Performanceprobleme, die langsam entstehen, über die Zeit. Und eine Erfahrung, die ich gemacht habe, ist, dass diese Probleme oft absehbar waren. Es ist natürlich immer sehr gefährlich nicht in das „Hindsight is 20/20“ zu fallen, wenn man sich nach dem man ein Problem gefunden hat, mal die weiteren Aufzeichnungen anguckt und dabei sieht „Jo, erste Vorboten dieser Entwicklungen sind 2 Wochen vorher zu erkennen“. Mit dem Wissen, was passieren würde, ist das naemlich immer sehr einfach zu sagen.

Aber meist sind in diesen Daten Tendenzen zu erkennen, die man im Wissen im das Kommende als Vorboten identifizieren kann. Lange bevor irgendwelche statischen Schwellenwerte triggern. Und da sind wir dann wieder bei den Schwellenwerten.

Ich gehe üblicherweise mit der Information, das Vorboten früh zu erkennen waren, sehr vorsichtig um. Diese Information gewinnt nach wirklich grossen Problemen sehr schnell eine politische Dimension. Ich bin sehr großer Fan des „blameless post mortems“, da nur so alle Beteiligten lernen können. Die Luftfahrt macht da sehr vieles sehr richtig. Aber schnell wird aus „Wenn Du vor zwei Wochen den Grund für einen Ausfall gekannt hättest, von dem Du nicht wusstest, das er passieren würde, und auf den richtigen Wert geguckt hättest, von dem Du noch nicht wissen konntest, dass er relevant werden würde, hätte man den Ausfall voraussehen und verhindern können“ kann auch ein „Das hättest Du sehen müssen“ werden. Das ist einfach völlig unrealistisch.Und mit solchen Erwartungen ist niemanden geholfen. Okay, wenn man sieht, dass der Plattenfüllstand bei 95% vor zwei Wochen war und man gewarnt wurde, aber nichts tat, ist das eine andere Sache. Aber von sowas rede ich hier nicht.

Einen Vorboten post-factum zu erkennen ist halt immer einfach. Das ist keine Kunst.

Ignoriert …

Schwellenwerte haben ohnehin mitunter ein Problem. Das Gleiche wie wiederverschliessbare Schokoladenpackungen oder Blinker beim BMW. Es ist durchaus nicht selten, das Schwellenwerte ignoriert werden: Der stets rote Wert im Monitoring. “Ach der? Der ist immer rot … darauf achten wir schon nicht mehr”

Ich bin selbst dieser Sache schuldig. In meinem Hausmonitoring gibt es einen Wert, der ständig orange ist. Die Warnung dazu habe ich längst abgeklemmt. Es ist der von meiner Lambdasonde errechnete Abgasverlust meiner mittlerweile zur Spitzenlastheizung degradierten Pelletheizung. Ich hatte mir da beim Abgasverlust mal vor langer Zeit ein Ziel gesetzt, das ich nie erreicht habe, oder wenn nur sehr kurzfristig. Dieses heere Ziel steht aber bis heute im Monitoring drin. Die nächste Lieferung Pellets hat das dann wieder alles über den Haufen geworfen. Und so ignoriere ich den Wert. Ich gucke nur kurz nach einer Pelletlieferung drauf, um zu gucken, was mir da jetzt wieder geliefert wurde und justire da ggf. die Luftzufuhr nach (Ich bin sooooo dankbar, das das jetzt nicht mehr die Hauptheizung war, es gab eine Zeit, da konnte ich mich kaum von dieser Entfernen, ohne das ein Anruf kam). Ja, ich weiss. Schuldig. Im Sinne der Anklage. Ich weiß nicht, warum ich den Wert da immer noch im Monitoring habe. Vielleicht als ständige Mahnung, das da noch technische Schulden in meiner Heizung stecken.

Ich denke aber, dass wir uns darauf einigen können, das ein ignorierter Schwellenwert universell schlecht ist. Das hat so etwas von: Der Held/Die Heldin des Films klopft gegen den Öldruckanzeiger/Warpplasmawarner und sagt dann „Fsck that shit. Hier wird Geschichte gemacht!“ Oder der Admin krault sich wissend den Bart, die Administratorin fährt sich durchs wallende Haupthaar und merkt nur an „Das muss das Boot aushalten“.

In diesem Fall ist die mehr als berechtigte Frage: „Warum gibt es diesen Öldruckanzeiger?“. Wenn ich etwas ignoriere, brauch ich es nicht messen. Etwas nicht zu messen, wäre ja ein glaubhaftes Dementi, wenn wegen diesem Parameter irgendwas auf die Nase fliegt. Und was ich messe, sollte ich nicht ignorieren. Nein, in Filmen gibt es bei jedem technischen Gerät immer den Moment, in dem eine rote Warnleuchte gibt, die um ihr Leben blinkt, aber nach kurzem klopfen keiner weiteren Beachtung würdig ist. Interessanterweise ist es ja je nach dramaturgischer Notwendigkeit dann oft auch genau das Teil, was dann später den Geist aufgibt. ich denke daran erkennt man, das Drehbuchschreiben eben nichts damit zu tun hat, ein technisches System am Arbeiten zu halten. Schreibmaschinen oder Rechner fliegen halt recht selten spektakulär um die Ohren.

Die heldenhafte Ingenieurin repariert das dann auch kurz bevor der Schaden alle Beteiligten hinwegrafft, meistens unter Einsatz des eigenen Lebens. Wobei … dieses Problemwegklopfverhalten habe ich bisher in Filmen nur bei männlichen Ingenieuren gesehen. Vielleicht auch mal einer Untersuchung wert, ob das wirklich so ist oder nur eine selektive Wahrnehmung meinerseits. Und alles hätte verhindert werden, wenn mal jemand sich gefragt hätte, warum der Druckanzeigerzeiger dort war, wo er stand. Und warum es ihn überhaupt gab.

105% ?

Das nächste Problem mit Schwellenwerten wird auch in einem Film gut gezeigt. Was sind eigentlich 100%? „Der Ingenieur meldet, 105 Prozent auf dem Reaktor möglich, aber nicht zu empfehlen“ aus dem Film „Roter Oktober“ fasst irgendwie das Problem mit den Schwellenwerten gut zusammen. Wenn 105% auf dem Reaktor möglich ist, warum ist dann 105% nicht 100% und alles über 95% wäre nicht zu empfehlen (ja, ich weiss das das nicht ganz richtig ist). Aber vielleicht klingt das einfach nicht so dramatisch. Über 100% als Proxy für Heldenhaftigkeit, als das unbekannte Land der Überlastung eines technischen Systems.

Was ist eine zu 100% ausgelastete CPU? Ich mein, bei Speicher, bei Plattenplatz ist es einfach. Futsch ist futsch ³ . Verbraucht ist verbraucht. Zumindestens bis ich aufräumen kann. Aber bei der CPU?

Normalitätsmonitoring

Damit ich nicht falsch verstanden werde. Das Monitoren gegen feste Schwellenwerte ist wichtig, als letzte Warnung vor dem Zusammenbruch. Gleich bricht die Tragfläche ab, gleich geht der Reaktor durch. Oder ist eben im etwas langweiligen Alltag die Festplatte voll, der Hauptspeicher wegallokiert ist .

Ist es aber das, was man eigentlich monitoren will? Mit all der Rechenleistung, die in heutigen Systemen ist, müsste man eigentlich mehr von Monitoring erwarten als ein „grösser gleich“ oder ein „kleiner gleich“ . Möchte ich nicht eigentlich neben diesen einfachen Schwellenwerten auch die Normalität als Benchmark verwenden. Die ganz einfache Frage: „Ist das normal so?“. So wie man ja auch in sich reinhorcht und sich überlegt, ob die Magenschmerzen jetzt einfach normal sind. Nach einem deftigen Grünkohlessen wahrscheinlich schon, nach einer normalen Mahlzeit und dauerhaft wahrscheinlich nicht.

Modell der Normalität

Also Normalitätsmonitoring: Was so einfach klingt, ist es leider nicht. Normalität ist keine Konstante. Denn Normalität ist eine Funktion über die Zeit. Messwerte, die zu einer Zeit einfach signalisieren „Ist der erste Arbeitsmontag im neuen Jahr , wird gleich besser … ist vom Management so akzeptiert“, sind vermutlich sonntags in den frühen Morgenstunden ganz und gar nicht normal.

Oder umgekehrt, wenn kurz vor Weihnachten kurz nach der Tagesschau noch die letzten Geschenke zusammengekrallt werden, weil der Tatort wieder ausnehmend mies ist, dann mag eine Last erreicht werden, die an jedem anderen Tag des Jahres das Blut der Verantwortlichen aus deren Gesichtern treibt.

Normalität ist auch eine Funktion über die Last. Ich habe schon häufiger zum Thema Performance gesagt, das es nur wenige Werte gibt, die universell schlecht sind, Scan Rate im vmstat ist da ein Klassiker. Wenn im kstat plötzlich Parameter hochschnellen, die im Namen „fail“ tragen, ist das selten ein gutes Zeichen. Aber viele Werte sind einfach nur Folge dessen, das etwas auf dem System passiert.

Normalität als Funktion über die Last kann bedeuten, zu monitoren, ob die Last auf dem System beispielsweise zu 3000 Kundenrequests passt. Vielleicht sogar ob die Mischung der Requests passt? Es ist ja eine Aussage in sich, wenn auf 3000 Selects und 1000 Updates und 500 Inserts plötzlich was ganz anderes wird, weil irgendein Entwickler nicht Bescheid gesagt hat, dass er „leichte“ Änderungen am Persistenzlayer vorgenommen hat. Oder das aus „Ich habe da eine Kleinigkeit am Businessprozess geändert. Nix Großes!“ plötzlich eine Verdopplung von allem wird.

Interessante Fragen an ein Monitoring wären im Grunde genommen also „Ist das, was ich auf dem System sehe, dieser Zeit angemessen?“ oder „Ist das, was ich auf dem System sehe, dieser Last angemessen?“. Nicht „Bin ich noch ein paar Prozent von einer angenommenen Maximalleistung entfernt?“

Zumal ja die Einrichtung eines Normalitätsmonitorings einen auch ein Stück weit unabhängiger macht vom organisatorischen Wissen, das die Admins haben, wenn sie auf ihre Dashboards gucken und einschätzen, ob alles sich in einem geregelten Rahmen bewegt.

Grün ist normal

Ich fände die „grün“ im Dashboard leuchtende Zusicherung, das alle gemessenen Werte hinreichend nah an den erwartenden Werten entspricht, irgendwie vertrauenseinflössender als die Aussage „Okay, sieht nicht so aus, als würde gleich alles auseinanderliegen“. Und das wäre genau der Unterschied zwischen statischen Schwellenwerten und etwas, das deutlich dynamischer reagieren könnte.

Aber wie kommt man an solche Werte? Wie kommt man an solche dynamischen Schwellenwerte?

Statistik

Jetzt gibt es einen ganzen Bereich der Mathematik, der sich mit Normalität beschäftigt. Oder genauer gesagt: Der sich damit beschäftigt, anderen Wissenschaften das Werkzeug zu geben, Normalität festzulegen: Den normalen Verbraucher, den normalen Wähler. Um Voraussagen treffen zu können, aber auch Abweichungen von der erwarteten Entwicklung feststellen zu können. Statistik! Yeah! Denn wenn ich weiss, was Normalität ist, kann ich auch sagen, was eben nicht normal ist.

In einer sehr einfachen Variante benutze ich dies sehr regelmässig bei Performanceanalysen, wenn die Werte nicht auf einen eindeutigen Schuldigen hinweisen. Oder wenn ich erst mal die ganzen Werte ausdünnen muss. Weil ich in Messwerten ersaufe.

Beispiel: Ich nehme mir eine Aufzeichnung der iostat-Werte der letzten 24 Stunden und berechne einige statistische Parameter daraus: Durchschnitt, Median, 80% Quantil, 95% Quantil.

Wenn ich viele Daten habe, versuche ich statische Analysen über Subdatasets, die jeweils beispielsweise nur Werte der letzten vier Wochen beispielsweise um 11:00 Uhr nimmt, oder um 20:17, kurz nach der Tagesschau, um ein Gefühl für den Normalzustand auf dem System zu bekommen.

Für mich ist R respektive Python, manchmal wenn nichts anderes erlaubt, ist auch Excel, ein essentielles Werkzeug, um mich in diesen Tools im Datengrab zurecht zu finden.

Als ganz einfache Regel: Ich habe beispielsweise die Erfahrung gemacht, dass es sich zuerst lohnt, zu den Zeiten in die anderen Logfiles zu gucken, die ich durch Bildung eines Subdatasets auf Basis des 95% Quantils erhalte.

Jetzt mag man sagen: Da ist doch dieser der 95% Schwellenwert? Nein, äh … jein. Ja, es sind 95%, aber ich rede hier von den 5% höchsten gemessenen Werten, nicht jenen werten, die mehr als 95% eines angenommenen Grenzwertes entsprechen. Die Überlegung mit den 95% ist an sich schon richtig, nur halt “von was“ ist halt interessant.

Was ich auch mache, wenn ich sehr viele Daten zur Verfügung habe, ist den Tag in 10 Minuten intervalle zu „subsetten“, dafür statische Grössen wie Median, Perzentile und so weit zu berechnen und dann die Tageweise zu vergleichen. Über den ganzen Tag hinweg (ohne Python oder R ist das aber mithin kaum noch vernünftig zu machen)

Im Grunde genommen, ist das ja auch das was man mit Hirn Version 1 ständig macht, wenn man auf die Graphen guckt, die einem beispielsweise Grafana anzeigt, man guckt drauf, sieht etwas, bringt es mit dem Kontext in Verbindung und denkt sich „Yup, sieht normal aus“ oder „Verdammt … sieht nicht gut aus“.

Aber wer macht das ständig? Und auf allen Systemen? Wenn ich das für immer mehr Instanzen machen muss, wird das irgendwann nicht mehr handhabbar. Warum also nicht ein automatisiertes Monitoring im Sinne von „Ich erwarte um 09:41:00 folgende Messungen. Weicht meine reale Messung um mehr als einen bestimmten Wert abweicht, habe ich möglicherweise ein Problem. Merken. Bleibt das durchgehend bis 09:44:00 genauso, werfe ich eine Warnung“.

Braucht man daher vielleicht nicht nur einen fixen Schwellenwert, sondern wäre ein ständig nachgeführtes Schwellenwertfeld oder eine Schwellenwertformel zusätzlich nicht deutlich nützlicher? Einen Korridor mit Werten, die ich erwarte. Einen Erwartungskorridor. Einen Normalitätskorridor.

Und auch das ist nicht wirklich einfach: So wie man auf einen Hypochonder nicht mehr hört, wenn dieser jedes Magengrummeln zur Krankheit hochstilisiert, so dürfte ein solches Normalitätsmonitoring nicht bei jeder kleinen Abweichung sich melden. Die Abstimmung zwischen einem Dauerwolf schreienden Monitoring und einem Monitoring, das sich erst meldet, wenn eigentlich schon alles auseinander gefallen ist, will wohl überlegt sein.

Badende Frösche

Ich schrieb ja mehrfach, das ich die statischen Schwellenwerte als weiterhin extrem wichtig ansehe. Der Grund ist eigentlich sehr einfach. Angenommenermassen, ich habe ein Verfahren das Normalität modelliert auf Basis der letzten 28 Tage. Was passiert aber, wenn die Messwerte in den letzten meinetwegen 365 Tagen langsam aber stetig steigen. In meinem 28 Tage Fenster hätte ich einen stetig steigenden Normalitätskorridor der am Ende auch meinetwegen die 80% oder 95% Schwellenwerte übersteigen könnte. Trotzdem wären die beobachteten Messwerte immer noch im erwartenden Normalitätskorridor und würden keine Warnung triggern.

An der Stelle brauche ich die statischen Schwellenwerte um zu überwachen, das mein Topf eine froschfreundliche Badetemperatur nicht überschreitet, um nicht in die Situation zu geraten, das ich “This is fine” aufrufe, weil ich im Normalitätskorridor bin, es gleichzeitig aber entweder nach blanchiertem Frosch oder nach geröstetem Hund duftet/riecht/stinkt.

Ich brauche also weiterhin den statischen Schwellenwert, um die Werte gegen erwartete technische Limits zu monitoren, um nicht in Normalität in die Grenzen zu rennen.

Verschiebung

Ich sprach ja gerade von der Verschiebung des Erwartungskorridors über die Zeit. Auch diese gälte es zu monitoren, da sich in dieser Verschiebung die Weiterenwicklung der Last ausdrückt.

Erkenntnisse dürften sich hier an zwei Stellen finden:

• Wenn der Erwartungskorridor den Schwellenwert von 80% überschreitet, gilt es sich mit Sicherheit gedanken über die Weiterentwicklung der Kapazität zu machen.
• Letztlich habe ich ja auch für die Weiterentwicklung des Erwartungskorridors eine Erwartung, gegen die ich die die reale Entwicklung monitoren sollte. Ich kann natürlich auch versuchen, die Weiterentwicklung des Erwartungskorridors in die Zukunft zu extrapolieren. Wenn ich dann davon beginne stark abweichende Erwartungskorridore in der realen Welt für einen Messwert zu sehen, ist das sicherlich ein Grund, näher zu untersuchen, was sich im zugrundeliegenden System geändert hat, das zu wieder Abweichung geführt hat. Wobei es gerade hier wichtig wäre nicht nur einen Erwartungskorridior über die Zeit zu haben, sondern auch einen Erwartungskorridor über die Last (bspw Nutzertransaktionen mit dem System).

Automatisch

Ich erzaehle ja da alles nichts Neues. Vieles davon ist gute betriebliche Praxis. Ich denke nur, das man das so weit wie möglich automatisieren sollte, so das es auf vielen Werten wie möglich so oft wie möglich ausführen kann und nicht nur auf einem Surrogat von Messwerten das wir für einen guten Platzhalter für den Zustand des Systems halten vielleicht nur einmal im Monat und dann auch nur mit dem Blick auf einige Graphiken. Ich meine, so Gesamt-IT weit gesehen, geben wir furchtbar viele Rechenzyklen aus, um beispielsweise unsere Photos auf “Studio Ghibli”-style umrechnen zu lassen, da sollte eigentlich ein bisschen Rechenzyklen für den Erkenntnisgewinn aus Monitoringdaten universell auch drin sein.

Ansätze

Ich weiss das es dafür Ansätze gibt: Der mit dem ich mich am meisten beschäftige, ist das Oracle Autonomous Health Framework, das sowas in der Art implementiert, das gleichzeitig auch automatisiert versucht, aus den Messungen das eigentliche Problem zu „root causen“. Denn auch dafür gibt es mathematische Verfahren. Beispielsweise „Bayesian Network-based diagnostic root cause models“ ⁴ . Damit kenne ich mich ganz gut aus. Aber ich glaube, dass das auch außerhalb dieses Frameworks eine sehr gute Herangehensweise an das Problem ist.

Postskriptum

Man könnte das Ganze auch an ein LLM koppeln, um die Requests und deren Antworten ein wenig interessanter zu gestalten. „Monitor, Monitor an der Wand, läuft alles auf meinem dotierten Sand?“ „Ja, meine Administratorin, eure Server sind die Verfügbarsten hier. Jedoch bei den sieben Adminschergen, den besser bezahlten Schwestern und Brüdern der sieben Zwerge, da laufen die Server noch sehr viel besser …“