From Logs to Insights: Observability on AWS

Von der Standortbestimmung zur Verbesserung

Im ersten Teil haben wir das Maturity-Modell kennengelernt: Vier Stufen von Foundation (reaktives Monitoring, Nutzer melden Probleme) bis Proactive (das System erkennt Probleme bevor sie entstehen). Die Standortbestimmung ist gemacht. Die Frage ist: Wie geht es weiter?

Die Antwort ist nicht "alles auf einmal umbauen". Observability verbessert sich iterativ – eine Verbesserung nach der anderen, jeweils dort, wo es am meisten weh tut.

Die 5 Schritte, die wir gleich vorstellen, sind das Rezept für eine einzelne Verbesserung. Man wendet sie an, um ein konkretes Problem zu lösen: Der Checkout ist nicht überwacht. Die Payment-API hat keine aussagekräftigen Alarme. Fehler im Order-Service sind schwer zu debuggen.

Um von einem Maturity-Level zum nächsten zu kommen, durchläuft man diese 5 Schritte mehrfach – jedes Mal für einen anderen kritischen Bereich des Systems. Nach mehreren Iterationen zeigt sich: Die Summe der Verbesserungen hat das Monitoring auf ein neues Level gehoben.

---

Die 5 Schritte: Ein wiederverwendbares Rezept

1. Verstehen: Was ist geschäftskritisch?

Der Start liegt nicht bei der Technik, sondern bei den Geschäftszielen. Welche Funktion ist kritisch für das Business? Welche Auswirkungen hat ein Ausfall auf Umsatz, Nutzererfahrung oder Compliance?

Aus den Geschäftszielen leiten sich die technischen Anforderungen ab: Welche Services sind beteiligt? Welche Abhängigkeiten bestehen? Was sind die kritischen Pfade durch das System?

Typische Fallstricke: Zu schnell in technische Details springen. Monitoring aufbauen, ohne zu wissen, welche Fragen es beantworten soll. Services überwachen, die für das Business gar nicht kritisch sind.

Die Kernfragen:

• Was passiert, wenn dieser Prozess ausfällt?
• Wer ist betroffen und wie stark?
• Welche SLA oder SLO gilt hier?
• Was muss man wissen, um das Problem schnell zu beheben?

2. Messen: Die richtigen Signale sammeln

Jetzt wird es technisch: Wie bekommt man die Daten, die die Fragen aus Schritt 1 beantworten? Drei Arten von Signalen sind relevant:

Logs: Strukturierte Logs (JSON) mit einheitlichen Feldern machen die Suche und Analyse erst möglich. Besonders wertvoll sind Canonical Logs – ein einzelner, umfassender Log-Eintrag pro Request, der alle relevanten Informationen bündelt: Correlation-ID, Causation-ID, Dauer, Ergebnis, beteiligte Ressourcen. Statt viele kleine Log-Einträge zu durchsuchen, liefert ein Canonical Log den kompletten Kontext auf einen Blick. Wie man Canonical Logs strukturiert und implementiert, wird in Teil III genauer betrachtet.

Metriken: CloudWatch liefert Standardmetriken für Serverless-Services automatisch – von Lambda (Invocations, Errors, Duration) über API Gateway (Latency, 4xx/5xx) bis hin zu DynamoDB und SQS. Diese technischen Metriken bilden die Basis.

Entscheidend sind aber geschäftsrelevante Custom Metrics. Nicht "Lambda wurde aufgerufen", sondern "Bestellung wurde abgeschlossen". Das Embedded Metric Format (EMF) macht es einfach, Custom Metrics direkt aus Lambda-Funktionen zu emittieren – ohne separaten API-Call, einfach als strukturierter Log-Eintrag.

Traces: Bei verteilten Systemen sind Traces unverzichtbar. Sie zeigen, wie ein Request durch verschiedene Services fließt und wo Zeit verloren geht. X-Ray bietet hier native AWS-Integration. Alternativ lassen sich mit Correlation-IDs und Causation-IDs in Canonical Logs eigene Trace-Pfade aufbauen – die Logs werden nach OpenSearch gestreamt und dort können Requests über Service-Grenzen hinweg verfolgt werden.

Typische Fallstricke: Alles loggen → Kosten explodieren, wichtige Signale gehen im Rauschen unter. Metriken ohne Kontext → "Invocation-Count steigt" sagt nichts über Business-Impact. Correlation-IDs nachträglich einbauen ist aufwendig.

Der Unterschied: Nicht "alles loggen", sondern "gezielt die Signale sammeln, die Fragen beantworten".

3. Alarmieren: Signal vom Rauschen trennen

Alarme sind nur dann wertvoll, wenn sie zu Aktionen führen. Ein ignorierter Alarm ist schlimmer als gar kein Alarm – er trainiert das Team, Alarme zu ignorieren.

Auf Business-Impact fokussieren: Nicht "Lambda Errors > 10", sondern "Checkout-Erfolgsrate < 95%". Technische Schwellwerte sind Mittel zum Zweck, nicht das Ziel. Wichtig ist: Welche geschäftliche Funktion ist beeinträchtigt?

Alarme konsolidieren: Wenn ein Service ausfällt, können 20 abhängige Alarme auslösen. CloudWatch Composite Alarms reduzieren das auf einen relevanten Alarm. Kurze Spikes (< 2-3 Minuten) sollten gefiltert werden, um Fehlalarme zu vermeiden.

Jeder Alarm braucht:

• Was: Klare Problembeschreibung
• Impact: Welche Auswirkung hat es?
• Action: Was ist der nächste Schritt? (Link zu Runbook, Dashboards, Logs)
• Owner: Wer ist verantwortlich?

Typische Fallstricke: Zu viele Alarme → Alarm-Fatigue. Alarme ohne klare Action → Verwirrung. Schwellwerte zu eng → Fehlalarme. Schwellwerte zu weit → echte Probleme werden zu spät erkannt.

Das Ziel: Jeder Alarm führt zu einer Aktion. Kein Alarm wird ignoriert.

4. Visualisieren: Kontext auf einen Blick

Dashboards zeigen den Systemzustand, ohne dass man erst Logs durchsuchen oder Queries schreiben muss. Ein gutes Dashboard beantwortet konkrete Fragen und macht Abweichungen vom Normalzustand sofort sichtbar.

Dashboard-Typen:

• Operational Dashboards: Zeigen den aktuellen Zustand (läuft der Service? Wie viele Requests? Fehlerrate?)
• Analytical Dashboards: Zeigen Trends über Zeit (wird es langsamer? Steigen die Fehler?)
• Business Dashboards: Zeigen geschäftliche KPIs (Umsatz, Conversions, aktive User)

CloudWatch Dashboards eignen sich gut für Operational und Analytical Dashboards mit Metriken. OpenSearch Dashboards bieten sich an, wenn Logs und Traces visuell analysiert werden sollen – etwa um die häufigsten Fehlertypen oder langsamsten Requests zu identifizieren.

Best Practices:

• Ein Dashboard = eine Fragestellung (z.B. "Ist Payment gesund?")
• Wichtigstes oben, Details unten
• Farbcodes verwenden: Grün = OK, Gelb = Achtung, Rot = Problem
• Zeiträume vergleichbar machen (Heute vs. Vorwoche)
• Links zu weiterführenden Dashboards und Log-Queries

Typische Fallstricke: Zu viele Metriken auf einem Dashboard → unübersichtlich. Dashboards ohne klaren Zweck → niemand schaut sie an. Statische Schwellwerte in Visualisierungen → funktioniert nicht bei schwankender Last.

Der Fokus: Nicht alle Daten zeigen, sondern die relevanten für konkrete Fragestellungen.

5. Analysieren: Von Symptom zur Root Cause

Wenn ein Problem auftritt, startet die Analyse. Das Ziel: Von "Alarm ist ausgelöst" zu "Ich weiß, was kaputt ist und wie ich es behebe" – in Minuten, nicht Stunden.

Der Analyse-Flow:

1. Kontext verstehen: Dashboard zeigt: Welcher Service? Seit wann? Wie stark betroffen?
2. Korrelation finden: Welche anderen Metriken zeigen Auffälligkeiten im selben Zeitraum?
3. Scope eingrenzen: Ist es ein einzelner Service, eine Region, ein Kunde?
4. Details untersuchen: Logs filtern nach Error-Zeitraum und betroffenen IDs
5. Traces folgen: Anhand der Correlation-ID den Request über alle Services verfolgen

Werkzeuge verknüpfen:

• Vom CloudWatch Dashboard zum Log Insights Query (mit vorgefertigten Queries)
• Von CloudWatch Logs zu OpenSearch (für tiefere Analyse der Canonical Logs)
• Über Correlation-ID den kompletten Request-Pfad in OpenSearch rekonstruieren
• Von Metriken zurück zu Logs (was hat der Service geloggt?)

CloudWatch und OpenSearch Features nutzen:

• CloudWatch Log Insights für schnelle Ad-hoc-Queries
• CloudWatch Contributor Insights für Top-Fehler oder Top-Nutzer
• CloudWatch Anomaly Detection für automatisches Erkennen von Abweichungen
• OpenSearch für komplexe Suchen über Canonical Logs und Trace-Rekonstruktion

Typische Fallstricke: Daten sind nicht verknüpft → manuelle Suche. Keine Correlation-IDs → Traces fehlen. Logs ohne Struktur → schwer durchsuchbar. Zu wenig Kontext in Logs → "Error" ohne zu wissen warum.

Die Fähigkeit: In wenigen Minuten vom Alarm zur Root Cause navigieren.

Diese fünf Schritte bilden das Grundgerüst für jede Iteration. Sie helfen dabei, Verbesserungen nicht isoliert umzusetzen, sondern systematisch von der fachlichen Fragestellung bis zur Analyse zu denken. Jede Iteration macht das System ein Stück beobachtbarer – und nach mehreren Durchläufen zeigt sich: Die Summe der Verbesserungen hat das Monitoring auf ein neues Level gehoben.

---

Querschnittsthemen: Von Anfang an mitdenken

Neben den 5 Schritten gibt es Themen, die in jeder Iteration relevant sind. Wer sie erst später berücksichtigt, steht vor aufwendigen Anpassungen.

Kostenkontrolle

Monitoring-Kosten skalieren mit der Datenmenge. Von Anfang an sollten klare Retention-Policies gesetzt und die Kosten mit dem Cost Explorer überwacht werden. Eine konsequente Tagging-Strategie (Environment:prod, Team:checkout) hilft, Kosten pro Service zu tracken. Bei OpenSearch ist die Cluster-Größe und Retention besonders relevant für die Kosten.

Quick Win: Custom Metric für CloudWatch-Kosten pro Service anlegen.

Security & GDPR

Personenbezogene Daten gehören nicht in Logs. CloudWatch Logs Data Protection kann sensible Felder automatisch maskieren. E-Mail-Adressen, IPs, Kreditkartennummern – alles filtern, bevor es gespeichert wird.

Zentralisiertes Logging

Bei Multi-Account-Setups unterstützt CloudWatch Cross-Account Observability. Ein zentraler Monitoring-Account gibt den Überblick, ohne Daten zu duplizieren. Logs können von dort nach OpenSearch gestreamt werden, um eine zentrale Analyseplattform zu schaffen.

Klare Identifizierbarkeit

Einheitliche Namen sind Gold wert. payment-service-prod vs. paymentProd vs. pmt-svc – das wird zum Alptraum in Queries. Naming Conventions sollten früh definiert und konsequent umgesetzt werden.

---

Der Start: Heute anfangen

Es braucht nicht gleich das perfekte Setup. Der Einstieg beginnt mit einem kritischen Business-Flow und den 5 Schritten:

1. Sprint 1: Verstehen & Messen – Welcher Prozess ist kritisch? Welche Signale werden gebraucht? Canonical Logs einführen.
2. Sprint 2: Alarmieren & Visualisieren – Erste Alarme und ein Dashboard für den kritischen Flow.
3. Sprint 3: Analysieren – Den ersten echten Incident damit untersuchen und lernen, was noch fehlt.

CloudWatch bietet alles out-of-the-box. Ein dedizierter Monitoring-Account schafft von Anfang an Ordnung. Und das Wichtigste: Einfach starten. Observability lebt von kontinuierlicher Verbesserung, nicht vom perfekten Plan.

---

Im nächsten Teil wird das Konzept der Canonical Logs im Detail betrachtet: Wie strukturiert man sie, welche Felder sind essentiell, und wie nutzt man sie für effektive Analyse in OpenSearch.