From Logs to Insights: Observability on AWS

Wenn Cloud Systeme wachsen, verändern sich die Anforderungen an das Monitoring. Am Anfang ist die Anwendung klein und überschaubar. Wenn etwas schiefgeht, findet man den Fehler meist schnell. Doch mit der Zeit wird aus der einst kleinen Anwendung ein größeres und komplexeres System. Zusätzliche Funktionalität und mehr Nutzer bringen zusätzliche Fehlerquellen und spürbarere Auswirkungen dieser mit sich. Murphy's Law. Ein Monitoring, das anfangs noch unterstützend und hilfreich war, ist nicht mehr ausreichend und bildet den Zustand des Systems nicht mehr ab.

Wenn das Monitoring nicht mitwächst, bleiben Probleme verborgen und sind schwer einzuordnen. Signale sind verstreut, ohne Kontext und ohne klare Hinweise auf Ursachen oder Auswirkungen. Je mehr Services miteinander kommunizieren, desto schwieriger wird die Fehlersuche.

Observability setzt genau dort an: Man will nicht nur sehen, dass ein Problem existiert, sondern woher es kommt und was die Auswirkungen sind.

Die Observability-Journey

Womit fängt man an? Diese Frage steht oft im Raum, sobald klar wird, dass das bisherige Monitoring nicht mehr ausreicht. Observability ist eine Journey und bevor man Maßnahmen plant, ist es zu klären, wo man steht und was man im nächsten Schritt erreichen will. Dabei hilft das Maturity-Model: Es funktioniert wie eine Landkarte und zeigt, wo man steht, wohin die Reise geht und welche Etappen vor einem liegen.

Das Maturity-Model besteht aus vier Stufen.

Der Foundation Level

Der Start jeder Observability-Journey: Es existieren Basis-Logs und -Metriken. Fehler werden erst nach dem Auftreten sichtbar und das Identifizieren der Ursachen ist schwierig.

Das bedeutet: Das Monitoring ist reaktiv, Ausfälle werden leider meist von Nutzern erkannt, nicht von DevOps oder Entwicklern.

Der Intermediate Level

Auf diesem Level ist man bereits wesentlich besser aufgestellt. Applikationsdaten und Audit-Trails werden nun zentral gesammelt und Probleme werden durch Alarme frühzeitig erkannt. Logs können durchsucht werden und Metriken stehen für zentrale technische Merkmale zur Verfügung.

Allerdings: Es ist schwer, Zusammenhänge zu erkennen - das Ermitteln der Ursache bleibt aufwendig und kompliziert. Alarmflut und fehlende Verknüpfungen stiften Verwirrung und Monitoring-Kosten werden langsam spürbar auf der monatlichen AWS-Rechnung und damit zu einem relevanten Thema.

Der Advanced Level

Ab hier wird es wirklich spannend! Geschäfts- und Systemdaten sind verknüpft, Zusammenhänge sind erkennbar und Probleme lassen sich gezielt analysieren, verstehen und beheben. Analysemöglichkeiten zur Erkennung verdächtiger Verhaltensmuster stehen bereit.

Aber: Es ist häufig noch Detailwissen zur Behebung von Fehlern nötig. Dazu kommt die Notwendigkeit manueller Feineinstellungen an Schwellwerten und Triggern, was zu Fehlalarmen bei Ausreißern führt.

Der Proactive Level

Auf diesem Level erkennt das System Probleme, bevor sie tatsächlich entstehen. Abweichungen vom normalen Verhalten werden automatisch gefunden, ohne dass Schwellenwerte eingestellt oder nachjustiert werden müssen, indem die KI-Modelle aus den Daten lernen. Typische Muster werden von echten Auffälligkeiten unterschieden, sodass Fehlalarme sinken. Wenn sich Veränderungen abzeichnen, greifen automatische Workflows ein und passen Konfigurationen oder Ressourcen an, bevor der Betrieb beeinträchtigt wird. Das System reagiert damit nicht erst im Fehlerfall, sondern verhindert Störungen aktiv.

Endlich durchgespielt? Jain, auch auf dem Proactive Level bleibt Observability ein kontinuierlicher Verbesserungsprozess. Modelle, Regeln, automatische Reaktionen und Abläufe werden regelmäßig überprüft und angepasst, wenn sich Systeme, Nutzung oder Geschäftsanforderungen verändern.

Fazit

Observability ist eine Journey. Anhand des Maturity-Models kann bestimmt werden, auf welchem Level sich das System befindet und welche Lücken zum nächsten bestehen. Diese Lücken bilden die Grundlage für die weitere Planung. Kleine Schritte und ein iteratives Vorgehen gepaart mit messbaren Zielen führen langfristig zum Erfolg und orientieren sich an den tatsächlichen Problemen und Fragestellungen der jeweiligen Architektur und Anwendung.

Im nächsten Artikel betrachten wir, wie eine Iteration aussieht und warum es umso wirkungsvoller ist, dabei einem Plan zu folgen: Part II: In 5 Schritten zu besserer Observability