Cloud-Monitoring: Analyse- und Vorhersageverfahren
Cloud-Computing bedeutete für die IT den Schritt in eine neue Ära. Nie konnten Unternehmen ihren Kunden besser und schneller einen direkten Mehrwert liefern. Und dabei ist es gar nicht lange her, dass die IT "nur" eine unterstützende Rolle für das Geschäft hatte. Heute ist die IT der Treiber des Geschäftserfolgs. Und die IT-Verantwortlichen? Sie haben plötzlich die Möglichkeit, massive Neuerungen voranzutreiben, die sich direkt auf das eigene Unternehmen, Geschäftsmodelle oder die Art und Weise, Umsatz zu generieren auswirken. Nicht selten getrieben durch die Cloud, bringen diese Neuerungen jedoch auch neue Herausforderungen für die IT-Infrastruktur mit sich.
Neue Denkmuster
Der Aufbau einer modernen Cloud-Plattform – ganz gleich ob öffentlich, privat oder hybrid – lässt Unternehmen jeder Größe einen schnelleren Service anbieten; intern genauso wie extern dem Kunden. Methodische Kapazitätsplanung und manuelle Infrastruktur-Updates machen den Weg frei für automatisch skalierende und von Dienstleistern verwaltete Infrastrukturen, die Entwickler- und Operations-Teams Luft für den Fokus auf gewinnbringende Geschäftsziele verschaffen. Starre Dienstleister-Suites weichen modularen, individuell anpassbaren Best-of-Breed-Technologie-Stacks, bestehend aus gehosteten Cloud-Services und Open Source-Softwarekomponenten. Und langsame, manuelle, fehleranfällige Entwicklungsprozesse werden ersetzt durch automatisierte Build-Test-Deploy-Zyklen in einem API-zentrierten Cloud-Universum.
Aus der Cloud ist viel mehr geworden, als "nur" eine neue, bessere Technologieplattform. Sie ist ein Ort des kulturellen und prozessualen Wandels geworden. Sie ist Nährboden für die aktuelle Entwicklerkultur und dessen agile Methoden. Software-definierte Infrastruktur und Plattformen, zu denen sich der Nutzer selbst anmelden und ohne großen Konfigurationsaufwand loslegen kann, erlauben es uns, viel mehr mit neuen Technologien zu experimentieren und diese kennenzulernen. Sie ermöglichen aber auch eine schnellere Anpassung an neue Marktgegebenheiten oder Kundenpräferenzen, um genau die Multi-Plattform- und "Always-on"-Dienste zu liefern, die Nutzer heute erwarten.
Neuer Blickwinkel
Mit dem Wandel, den die Cloud weiterhin mit sich bringt – technisch, kulturell und prozessual – machen viele der bewährten Verfahren, wie wir IT-Projekte verwalten, monitoren oder am Laufen halten, oftmals keinen Sinn mehr. Wer die Vorteile moderner Cloud-Infrastrukturen nutzen möchte, muss auch das Management und Monitoring neu denken. Nur so kann mit dem Tempo mitgehalten, der Anspruch, dass jede Komponente in einem heterogenen Cloud-Stack richtig performt, gewahrt und die Kosten unter Kontrolle gehalten werden.
Der Druck auf die IT wächst, denn die Cloud ist auch ein großer Gleichmacher.
Setzt ein Unternehmen auf die Cloud, sollte die IT unmittelbar entsprechende Kennzahlen mitmessen, um zu überprüfen, wie effektiv sich der Wechsel auf das Unternehmen auswirkt. Ähnlich wie Boris Beckers "Bin ich schon drin?" hat sich auch "Wir sind jetzt in der Cloud" längst zu einem geflügelten Schlagwort entwickelt. Aber mit dem Wechsel von der einen auf die andere Plattform alleine ist es nicht getan. Klar, einzelne Anwendungskomponenten können nach dem Motto "Lift and Shift" von On-Premise-Hardware auf Cloud-Server geladen werden, während die bestehenden Werkzeuge und Prozesse für die Anwendung weiter Bestand haben. Doch kann damit oft nur ein Bruchteil der Möglichkeiten und Kapazitäten ausgeschöpft werden. Und auch wenn hier erste Anpassungen vorgenommen worden sind, so müssen IT-Verantwortliche stets einen Blick darauf haben, wo weitere Stellschrauben zu finden sind, um Durchlauf- und Entwicklungszeiten zu verkürzen oder mehr neue Projekte anstoßen zu können.
Neue Chancengleichheit
Jeder IT-Manager sollte mehr noch als bisher das Ziel haben, sein Unternehmen entsprechend der Möglichkeiten zum Marktführer in seiner Branche zu entwickeln. Der Druck auf die IT wächst, denn die Cloud ist auch ein großer Gleichmacher. Sie macht keine Unterschiede, sondern bietet jedem Unternehmen und jedem Entwickler die gleiche Ausgangsposition. Wer daher nicht kontinuierlich sein Bestes gibt, sich so schnell und effektiv wie möglich aufzustellen, der läuft dauerhaft Gefahr, dass andere Unternehmen – ganz gleich ob Start-up oder etablierter Konzern – schneller sind und sich einen Wettbewerbsvorteil erarbeiten. Wer sich auf seinen Lorbeeren der Vergangenheit ausruht, wird schnell überholt. Das galt in der Geschäftswelt zwar schon immer, hat durch den "Chancengleichmacher Cloud" aber eine neue Dynamik und kann nicht mehr binnen Jahren, sondern Wochen der Fall sein.
Neue Perspektiven
Jedes Cloud-Projekt jenseits von Shift-and-Lift bestehender Anwendungen geht mit neuen Technologien und neuen Komplexitäten einher. Gerade große, etablierte Unternehmen verlassen damit oft die vertraute Umgebung einer All-Inclusive-Suite und betreten eine heterogene Welt aus Open Source-Ökosystemen, verschiedenen Cloud-Anbietern und anderen Dienstleistern.
Die Verwaltung eines komplexen Gefüges heterogener Services ist mit einem einzigen Altsystem kaum möglich. So öffnet man Tür und Tor für Performance-Probleme, die unentdeckt bleiben und die IT-Kollegen dazu zwingen, Löcher ad hoc zu stopfen und Probleme nur dann zu anzugehen, wenn sie auftauchen, nicht jedoch bevor diese überhaupt eintreten. Und obwohl gerade die großen Cloud-Anbieter leistungsstarke Konsolen und Management-Tools für ihre gehosteten Services anbieten, so versagen diese doch allzu oft bei der nahtlosen Integration von Open Source-Lösungen, die zunehmend hinter dem Erfolg von Unternehmen am Markt stehen. Verwaltungs- und Monitoring-Tools sollten daher stets die Breite des Cloud-Ökosystems abdecken und auch zukünftige Entwicklungen berücksichtigen können.
Zum Glück hat die Cloud-Revolution auch den Markt für Monitoring-, Management- und Analyse-Lösungen befruchtet. Mit Infrastructure-as-a-Code-Frameworks, so wie etwa Terraform, können Anwender Cloud-Ressourcen zum Beispiel sicher und nachvollziehbar vorhalten, modifizieren und verwalten. Und weil Terraform Open Source, erweiterbar und Plattform-agnostisch ist, passt es sich natürlich an sich entwickelnde Infrastrukturen an – ganz gleich, ob einzelne Komponenten ausgetauscht werden oder einzelne Anwendungen von einem Cloud-Provider zu einem anderen geschoben werden.
Ähnlich verhält es sich beim Monitoring, dass mit dynamisch skalierenden, sich schnell wandelnden Infrastrukturen mithält. Durch die Integration einer Vielzahl an Cloud-Services und Infrastruktur-Technologien sowie die Möglichkeit, auch Nischentechnologien über individuelle Integrationen anzubinden, wird es überhaupt erst möglich, die Performance und Nutzung jeder einzelnen Komponente einer modernen Cloud-Umgebung im Blick zu behalten.
Neue Datenkenntnis
Monitoringdaten kommen in den verschiedensten Formen und Varianten daher – manche Systeme liefern laufend neue Datenpunkte, andere nur dann, wenn seltene Ereignisse eintreten. Manche Daten eignen sich besonders, um auf Probleme hinzuweisen, andere um diese zu untersuchen. In jedem Fall liefern sie jedoch einen Einblick in das Innenleben der Systeme.
Die Kennzahlen erfassen dabei zunächst einmal einen Ist-Zustand zu einem bestimmten Zeitpunkt, etwa die Anzahl der User, die in einer Web-Applikation eingeloggt sind. Neben verschiedenen Werten, wie dem Zugriff auf gecachte Inhalte oder Datenbanksperren, können die Kennzahlen, die Cloud-Nutzer im Blick haben sollten, grob in Arbeits- und Ressourcenkennzahlen unterteilt werden:
Arbeitskennzahlen (die sogenannten "Work Metrics") sind für den Gesamtüberblick extrem wichtig. Es handelt sich dabei um übergeordnete Datensätze, die eine schnelle Antwort liefern sollen, ob das System funktioniert, wie es soll, und ob Geschwindigkeit sowie Qualität stimmen. So hält der Durchsatz (Throughput) die Last nach, die das System innerhalb eines bestimmten Zeitfensters abarbeitet. Erfolgskennzahlen (Success) messen die erfolgreich ausgeführten Anwendungen und liefern oft einen Prozentsatz. Fehler (Error) halten nach, wie viele fehlerhafte Ergebnisse – oft in einem bestimmten Zeitfenster – vorkommen. Da Fehler verschiedene Gründe haben können und einige schwerwiegender sind als andere, wird dieser Wert oft separat von Erfolgskennzahlen getrackt. Performancekennzahlen quantifizieren, wie effizient eine Komponente arbeitet, etwa im Hinblick auf die Latenz.
Beispiel Arbeitskennzahlen: Web Server
| Subtype | Description | Value |
|---|---|---|
| throughput | requests per second | 312 |
| success | percentage of responses that are 2xx since last measurement | 99.1 |
| error | percentage of responses that are 5xx since last measurement | 0.1 |
| performance | 90th percentile response time in seconds | 0.4 |
| throughput | queries per second | 949 |
| success | percentage of queries successfully executed since last measurement | 100 |
| error | percentage of queries yielding exceptions since last measurement | |
| error | percentage of queries returning stale data since last measurement | 4.2 |
| performance | 90th percentile query time in seconds | 0.02 |
Die meisten Komponenten innerhalb der Systeminfrastruktur dienen als Ressource für andere Systeme. Von Serverressourcen, inklusive physischen Komponenten wie CPU, Speicherplatz, Disks oder Netzwerkverbindungen, bis hin zu Datenbanken oder Geolocation Microservices kann dies alles umfassen. Ressourcenkennzahlen (Resource Metrics) können dabei helfen, einen detaillierten Blick auf das System zu werfen und vor allem auch Probleme zu untersuchen oder zu diagnostizieren. Nutzungskennzahlen (Utilization) zeigen dabei anteilig, wie oft oder wie viel eine bestimmte Ressource genutzt wird. Die Sättigung (Saturation) zeigt, wie viele Anfragen eine Ressource nicht direkt bedienen kann. Fehler (Errors) zeigen auch hier, wo es hakt. Und die Verfügbarkeit (Availability) zeigt, wie oft eine Ressource auf eine Anfrage reagiert hat beziehungsweise hätte reagieren können.
Beispiel Ressourcenkennzahlen
| Resource | Utilization | Saturation | Errors | Availability |
|---|---|---|---|---|
| Disk IO | % time that device was busy | wait queue length | # device errors | % time writable |
| Memory | % of total memory capacity in use | swap usage | N/A (not usually observable) | N/A |
| Microservice | average % time each request-servicing thread was busy | # enqueued requests | # internal errors such as caught exceptions | % time service is reachable |
| Database average | % time each connection was busy | # enqueued queries | # internal errors, e.g. replication errors | % time database is reachable |
Bei Kennzahlen gilt, ist man sich unsicher, ob ein bestimmter Wert von Bedeutung ist, sollte er zumindest testweise einmal mitgetrackt werden. Neben den Zahlen aus dem laufenden Betrieb sollten aber auch seltene oder singuläre Ereignisse (Events) gemonitort werden, um besser zu verstehen, was sich möglicherweise im System geändert hat. Hier kommen vor allem folgende Events infrage:
- Veränderungen: Interne Code Releases, die Einführung neuer Technologie oder auch Fehlermeldungen.
- Störmeldungen: Interne Alerts oder solche aus Drittanwendungen.
- Skalierung: Hinzufügen oder Entfernen von Hosts.
Anders als einzelne Datenpunkte, die ohne Kontext oft wenig aussagekräftig sind, bringt ein Event in der Regel genug Informationen mit, um für sich interpretiert werden zu können. Sie halten fest, was zu einem bestimmten Zeitpunkt passiert ist und liefern dazu weitere Informationen. Sie können für sich – ebenso wie die einzelnen Kennzahlen natürlich auch – genutzt werden, um einen Alert auszulösen – etwa, wenn ein systemkritischer Prozess nicht funktioniert hat.
Beispiel Events
| Was ist passiert | Uhrzeit | Zusätzliche Informationen |
|---|---|---|
| Hotfix f464bfe released to production | 2018–02–15 04:13:25 UTC | Time elapsed: 1.2 seconds |
| Pull request 1630 merged | 2018–02–19 14:22:20 UTC | Commits: ea720d6 |
| Nightly data rollup failed | 2018–02–27 00:03:18 UTC | Link to logs of failed job |
Die Daten, die über das Cloud-System hinweg gesammelt werden, sollten folgende Charakteristika aufweisen:
- Verständlichkeit: Es sollte für den Anwender schnell ersichtlich sein, welchen Wert er vor sich hat, wie er zustande kommt und was er aussagt. Gerade bei einem Ausfall sollte keine Zeit damit verschwendet werden müssen, herauszufinden, was eine Zahl bedeutet. Kennzahlen und Events sollten daher so einfach und verständlich wie möglich sein. Vor allem sollten sie klar benannt sein!
- Granularität: Werden Kennzahlen zu unregelmäßig erhoben oder Durchschnittswerte auf einen zu langen Zeitraum gezogen, fällt es oft schwer, das Systemverhalten genau nachzuvollziehen. Zu kurze Zeitfenster oder zu oft erhobene Datenpunkte können aber auch unübersichtlich werden und das System eher fluten. Hier gilt, den richtigen Mittelweg zu finden, welcher den optimalen Einblick liefert. Gleiches gilt für den Geltungsbereich. Die Gesamtproduktivität eines Service mag genauso interessant sein, wie seine Produktivität auf einem bestimmten Host.
- Langlebig: Wer Daten zu schnell verwirft oder diese für Speicheroptimierung aggregiert, der verliert damit auch Informationen über die Vergangenheit. Wer Rohdaten für ein Jahr oder länger sichert, der versteht viel besser, was "normaler Betrieb" bedeutet – insbesondere, wenn es monatliche, saisonale oder jährliche Abweichungen gibt.
Beispiel Alerts und Diagnose
| Datensatz | Alert | Trigger |
|---|---|---|
| Work metric: Throughput | Page | value is much higher or lower than usual, or there is an anomalous rate of change |
| Work metric: Success | Page | the percentage of work that is successfully processed drops below a threshold |
| Work metric: Errors | Page | the error rate exceeds a threshold |
| Work metric: Performance | Page | work takes too long to complete (e.g., performance violates internal SLA) |
| Resource metric: Utilization | Notification | approaching critical resource limit (e.g., free disk space drops below a threshold) |
| Resource metric: Saturation | Record | number of waiting processes exceeds a threshold |
| Resource metric: Errors | Record | number of errors during a fixed period exceeds a threshold |
| Resource metric: Availability | Record | the resource is unavailable for a percentage of time that exceeds a threshold |
| Event: Work-related | Page | critical work that should have been completed is reported as incomplete or failed |
Neue Vorhersagen
Mittlerweile bieten moderne Cloud-Monitoring-Umgebungen die Fähigkeit, mögliche Performance-Probleme oder Downtime- oder Performance-Risiken bereits Tage, Wochen oder sogar Monate vorherzusagen. Die Vorhersagealgorithmen machen dabei Gebrauch von Machine Learning-Technologie, um die Entwicklung einer Metrik kontinuierlich bewerten zu können. Das Analyseverfahren kann beispielsweise konkrete Zeiträume erfassen, in denen vermehrte Kundenzugriffe auf der Website verursacht werden, und diese auch für zukünftige Lastspitzen vorhersagen. Nutzer können dann beispielsweise auf einen Blick erkennen, an welchen Tagen sie Serverkapazitäten oder sogar ihren physischen Kundenservice aufstocken müssen.
Wer in die Cloud geht, der darf nicht erwarten, dass all seine bestehende Software diese Reise auch mitgehen kann.
Und ganz egal ob es saisonale Schwankungen gibt, Grundlinien-Verschiebungen oder sonstige unvorhersehbare Entwicklungen, je mehr Daten zur Verfügung stehen, desto genauer wird die Einschätzung des bevorstehenden Problems. Die eigenen Daten bieten in diesem Fall jedoch nur eine Teilprognose. Schließlich kann auf ihrer Basis kaum mehr als eine tendenzielle Weiterentwicklung bisheriger Verlaufszahlen prognostiziert werden. Spannend wird es, wenn mithilfe des entsprechenden Anbieters anonymisierte Daten aus einem breiten Netzwerk zur Hilfe herangezogen werden. Damit vervielfacht sich die Datenbasis schnell um das Tausendfache – wenn nicht sogar noch mehr – und die Prognosen werden immer feingranularer.
Neue Kostenkontrolle
Durch schier endlose Skalierbarkeit und DIY-Natur der Cloud können Entwickler- und Operations-Teams neue Services schnell bauen und ausrollen. Auf der anderen Seite kann es aber auch zu einer Infrastruktur führen, die im wahrsten Sinne vermüllt ist mit redundanten sowie kaum oder gar nicht mehr genutzten Komponenten. Im Vergleich zu den relativ fixen Kosten eines Rechenzentrumbetriebs gibt es bei Cloud-Services kaum Grenzen nach oben. Ohne die richtigen Sicherheitsvorkehrungen kann die monatliche Servicerechnung des Cloud-Providers da schon schnell mal einige hundert oder tausend Euro – oder in großen Umgebungen sogar mehr – ausmachen.
Verschiedene Lösungen für das Tracken, die Vorhersage und die Optimierung der Cloud-Nutzung und -kosten sind daher sicher nicht ohne Grund in den letzten Jahren entstanden. Dienste wie CloudHealth Technologies und CloudCheckr helfen Unternehmen dabei, die Kosten ihrer Cloud-Infrastruktur zu verstehen und zu kontrollieren. Dabei bieten sie gleichzeitig automatische Analysen an und sprechen Optimierungs- und Umfangsempfehlungen aus.
Neuer Durchblick
In den letzten Jahren haben wir einen drastischen Wandel in der Akzeptanz von Cloud-Lösungen erlebt. Selbst in den risikoscheuesten Branchen wurden signifikante Cloud-Investitionen getätigt. Das Potenzial der Cloud, Innovationen schneller voranzutreiben und auf Marktveränderungen zu reagieren, schafft ganz neue Möglichkeiten, einen Wettbewerbsvorsprung zu halten und auszubauen, oder vielleicht auch erstmal Lücken zu Wettbewerber zu schließen.
Wer jedoch in die Cloud geht – egal ob zum ersten Mal oder mit Komponenten, die bislang noch on-Premise liefen – der darf nicht erwarten, dass all seine bestehende Software für Entwicklung, Anwendungssupport und -management oder Monitoring diese Reise auch mitgehen kann.
