AWS CloudWatch meistern für proaktives Performance-Monitoring und Optimierung

AWS CloudWatch ist der Ort, an dem viele AWS-Vorfälle verständlich werden. Ein langsamer Checkout-Prozess, eine Lambda-Funktion, die plötzlich drosselt, eine RDS-Datenbank, die keine Verbindungen mehr zulässt, oder eine SQS-Warteschlange, die ständig wächst – all das hinterlässt Spuren in Metriken und Logs. Das Schwierige ist nicht, CloudWatch zu aktivieren. Das Schwierige ist, die Signale auszuwählen, die Ihnen helfen, zu handeln, bevor Benutzer Ihnen sagen, dass etwas kaputt ist.

Gutes CloudWatch-Monitoring verbindet Plattformsymptome mit Anwendungsverhalten. CPU, Arbeitsspeicher und I/O sind wichtig, aber auch Checkout-Fehler, Warteschlangenalter, Zahlungslatenz und die Anzahl erfolgreicher Jobs pro Minute.

Kernkomponenten von AWS CloudWatch

CloudWatch arbeitet mit einem System zur Erfassung von Zeitreihendaten, den sogenannten Metriken, die dann mithilfe von Alarmen gegen Schwellenwerte ausgewertet werden. Diese Daten werden über Dashboards visualisiert und durch Logs und Events ergänzt.

1. Metriken: Die Grundlage des Monitorings

Metriken sind numerische Messwerte, die im Zeitverlauf erfasst werden. Jeder AWS-Service veröffentlicht automatisch Standardmetriken (z. B. EC2 CPU-Auslastung, S3-Anfragenanzahl). Für ein echtes Performance-Monitoring ist es jedoch erforderlich, über die Standardeinstellungen hinauszugehen.

Standard- vs. benutzerdefinierte Metriken

• Standardmetriken: Werden automatisch von AWS-Services erfasst. Die Auflösung variiert je nach Service und Konfiguration; viele gängige Services veröffentlichen 1-Minuten-Metriken, während einige grundlegende oder ältere Konfigurationen 5-Minuten-Intervalle verwenden.
• Benutzerdefinierte Metriken: Daten, die Sie selbst veröffentlichen, oft verwendet, um anwendungsspezifische Leistungsindikatoren zu messen.

Veröffentlichen benutzerdefinierter Metriken mit der AWS-CLI:

Sie können benutzerdefinierte Metriken mit dem Befehl put-metric-data veröffentlichen. Dies ist entscheidend für die Überwachung von Anwendungsantwortzeiten, Warteschlangentiefen oder betriebskritischen Betriebsstatus.

aws cloudwatch put-metric-data \
    --metric-name "CheckoutLatency" \
    --namespace "MyApp/ECommerce" \
    --value 150 \
    --unit "Milliseconds" \
    --region us-east-1

Metrik-Granularität

Benutzerdefinierte CloudWatch-Metriken können eine Standardauflösung oder eine hohe Auflösung haben. Hochauflösende benutzerdefinierte Metriken können mit einer Auflösung von 1 Sekunde gespeichert und über kürzere Zeiträume alarmiert werden, was für schnelllebige Systeme nützlich ist. Verwenden Sie dies selektiv, da ein höheres Volumen und mehr Alarme die Kosten erhöhen können.

2. Alarme: Auslösen von Aktionen basierend auf Schwellenwerten

Alarme wechseln zwischen drei Zuständen: OK, INSUFFICIENT_DATA und ALARM. Ein Alarm löst eine Aktion aus, wenn der angegebene Schwellenwert für eine definierte Anzahl von Zeiträumen überschritten wird.

Einrichten von Performance-Alarmen

Effektive Performance-Alarme konzentrieren sich auf führende Indikatoren und nicht nur auf reaktive Fehler. Beispielsweise ist die Überwachung der EC2-CPU-Auslastung gut, aber die Überwachung der Metrik BurstBalance für T-Instanzen kann eine zukünftige Drosselung vorhersagen, bevor die Auslastung 100 % erreicht.

Beispiel: Einrichten eines Alarms für hohe Latenz

Wenn Ihre benutzerdefinierte Metrik CheckoutLatency über drei aufeinanderfolgende 1-Minuten-Zeiträume im Durchschnitt über 500 ms liegt, lösen Sie einen Alarm aus und benachrichtigen Sie ein SNS-Thema.

aws cloudwatch put-metric-alarm \
    --alarm-name "HighCheckoutLatencyAlarm" \
    --alarm-description "Alert when P95 latency exceeds 500ms" \
    --metric-name "CheckoutLatency" \
    --namespace "MyApp/ECommerce" \
    --statistic Average \
    --period 60 \
    --threshold 500 \
    --evaluation-periods 3 \
    --datapoints-to-alarm 3 \
    --comparison-operator GreaterThanThreshold \
    --actions-enabled \
    --alarm-actions arn:aws:sns:us-east-1:123456789012:PerformanceAlertsTopic

Best Practice: Verwendung von Perzentilen (p99, p95) Verlassen Sie sich bei der Überwachung der Latenz nicht nur auf den Durchschnitt. Eine kleine, aber schmerzhafte Gruppe langsamer Anfragen kann in einem gesund aussehenden Durchschnitt untergehen. Verwenden Sie Statistiken wie P99 oder P95, wenn die Latenz am Ende der Verteilung (Tail Latency) wichtig ist.

3. Dashboards: Visualisierung der Systemgesundheit

Dashboards fassen relevante Metriken in einer einzigen Ansicht zusammen. Effektive Dashboards sind auf die Zielgruppe zugeschnitten (z. B. Betrieb, Entwicklung, Führungsebene).

Erstellen eines Dashboards zur Leistungsoptimierung

Ein gut strukturiertes Dashboard zur Leistungsoptimierung sollte verwandte Metriken gruppieren.

• System Health Panel: CPU-Auslastung, Netzwerk ein/aus, Datenträger Lese-/Schreib-IOPS (für EC2/EBS).
• Application Performance Panel: Benutzerdefinierte Latenzmetriken (P99), Fehlerraten (HTTP-5xx-Zählungen), Anfragedurchsatz.
• Cost/Efficiency Panel: Anzahl laufender Instanzen, Auslastung reservierter Instanzen, EBS-Volume-Auslastung (zur Identifizierung ungenutzter Speicher).

CloudWatch-Dashboards unterstützen komplexe Widgets, darunter Textanmerkungen, Metrik-Mathe-Ausdrücke (z. B. zur Berechnung von Effizienzverhältnissen) und sogar das Einbetten von Ergebnissen von CloudWatch Logs Insights-Abfragen.

CloudWatch für automatisierte Leistungsoptimierung

Überwachungsdaten sind nur dann wertvoll, wenn sie Aktionen auslösen. CloudWatch-Alarme sind der primäre Mechanismus zum Initiieren automatisierter Optimierungs-Workflows.

Integration von Alarmen mit Auto Scaling

Eine der leistungsstärksten Optimierungstechniken ist die Verwendung von CloudWatch-Alarmen zur Steuerung von AWS Auto Scaling Groups (ASGs). Dadurch wird sichergestellt, dass die Kapazität genau der Nachfrage entspricht, wodurch Überbereitstellung (Kosteneinsparungen) und Unterbereitstellung (Leistungseinbußen) vermieden werden.

Beispiel: Skalieren basierend auf der Warteschlangentiefe

Skalieren Sie nicht nur basierend auf der CPU, sondern basierend auf dem Rückstand, der auf die Verarbeitung wartet. Für eine SQS-Warteschlange würden Sie einen Alarm für die Metrik ApproximateNumberOfMessagesVisible erstellen. Wenn der Alarm in den Zustand ALARM wechselt, löst er eine Auto-Scaling-Aktion aus, um eine EC2-Instanz zur ASG hinzuzufügen.

Konfigurationstipp: Stellen Sie sicher, dass Ihre Skalierungsrichtlinien Target Tracking Scaling verwenden, das so konfiguriert ist, dass eine durchschnittliche Auslastungsmetrik beibehalten wird (z. B. durchschnittliche CPU bei 60 %). Dadurch kann AWS die Skalierung dynamisch verwalten, was im Allgemeinen gegenüber statischem Step Scaling bevorzugt wird.

Nutzung von Logs für tiefgehende Analysen

Wenn Leistungsprobleme auftreten, sind CloudWatch Logs für die Ursachenanalyse unerlässlich.

• Zentralisiertes Logging: Konfigurieren Sie alle Anwendungen und Services (VPC Flow Logs, Lambda-Logs, ECS/EKS-Container-Logs) so, dass sie an CloudWatch Logs streamen.
• Log Insights: Verwenden Sie die leistungsstarke Abfragesprache in Log Insights, um schnell in großen Log-Volumes zu suchen. Um beispielsweise alle Anfragen zu finden, die länger als 2 Sekunden gedauert haben:

fields @timestamp, @message
| filter @message like /duration: \d{4,}/ 
| parse @message "*duration: *ms*" as duration
| filter as_number(duration) > 2000
| sort @timestamp desc
| limit 50

Best Practices für das CloudWatch-Monitoring

Um den Wert von CloudWatch zu maximieren und die Leistung zu optimieren:

1. Service Limits überwachen: Legen Sie Alarme für Ihre AWS-Service-Kontingente fest (z. B. maximale Anzahl gleichzeitig ausgeführter Lambda-Ausführungen, maximale EBS-IOPS, die Ihrem Konto zur Verfügung stehen). Das Erreichen eines Kontingents stoppt die Leistung sofort, oft ohne einen klaren Anwendungsfehler.
2. Basisleistung ermitteln: Bevor Sie optimieren, überwachen Sie Ihr System während Spitzen- und Nebenzeiten, um zu definieren, was normal ist. Dadurch wird verhindert, dass Alarme auf der Grundlage irrelevanten Rauschens gesetzt werden.
3. Metrik-Mathe für Verhältnisse verwenden: Berechnen Sie Effizienzverhältnisse direkt in CloudWatch. Zum Beispiel (Gesamtfehler / Gesamtanfragen) * 100, um einen direkten Prozentsatz der Fehlerrate zu erhalten, anstatt mit mehreren separaten Metriken zu jonglieren.
4. Kostenmanagement: Benutzerdefinierte, hochauflösende Metriken kosten mehr. Gehen Sie sparsam damit um. Verwenden Sie die 1-Minuten-Auflösung nur für kritische, sich schnell ändernde Systeme (wie Load Balancer). Die standardmäßige 5-Minuten-Auflösung ist für die meisten Backend-Dienste ausreichend.
5. Tagging-Strategie: Stellen Sie sicher, dass alle überwachten Ressourcen (EC2, RDS, Lambda) konsistent getaggt sind. Auf diese Weise können Sie gefilterte Dashboards und Alarme erstellen, die für bestimmte Umgebungen spezifisch sind (z. B. Env: Prod, App: CheckoutService).

Das Dashboard an den Vorfall anpassen

Ein CloudWatch-Dashboard sollte jemandem helfen, unter Druck eine Entscheidung zu treffen. Wenn das Dashboard nur beweist, dass das System viele Metriken hat, wird es während eines Ausfalls nicht helfen.

Für eine Webanwendung baue ich den ersten Bildschirm gerne um einen einfachen Pfad herum auf: Verkehr kommt herein, die Anwendung verarbeitet ihn, Abhängigkeiten antworten, und Benutzer haben entweder Erfolg oder scheitern. Das bedeutet normalerweise, dass diese Widgets nahe beieinander platziert werden:

• Anzahl der Anfragen und Anzahl der Fehler vom Load Balancer oder API Gateway.
• P95- oder P99-Latenz für denselben Einstiegspunkt.
• Anwendungsspezifische Erfolgs- und Fehlermetriken.
• CPU, Arbeitsspeicher und Aufgabenanzahl für ECS, EKS, Lambda oder EC2.
• RDS-, DynamoDB-, Redis-, SQS- oder Metriken externer Abhängigkeiten, die häufig langsame Anfragen erklären.

Die genauen Dienste ändern sich, aber die Form bleibt gleich. Wenn die Checkout-Latenz springt, möchten Sie sehen, ob der Verkehr angestiegen ist, Fehler zugenommen haben, die Datenbanklatenz gestiegen ist oder Arbeiter zurückgefallen sind. Bringen Sie diese Hinweise an einem Ort unter.

Vermeiden Sie Dashboards, die Produktion, Staging und Entwicklung ohne klare Kennzeichnung mischen. Während eines Vorfalls wird irgendwann jemand das falsche Diagramm lesen. Verwenden Sie Dimensionen, Tags und Namenskonventionen, die die Umgebung offensichtlich machen.

Perzentile mit Bedacht einsetzen

Perzentile sind nützlich für die Latenz, weil Durchschnittswerte schmerzhafte Benutzererfahrungen verbergen. Wenn die meisten Anfragen in 100 ms abgeschlossen sind, eine kleinere Gruppe jedoch 8 Sekunden benötigt, kann der Durchschnitt immer noch akzeptabel erscheinen. Ein Perzentil-Diagramm macht den langen Schwanz sichtbar.

Allerdings sind Perzentile keine Zauberei. Sie benötigen genügend Verkehr, um aussagekräftig zu sein, und können bei Diensten mit geringem Volumen verrauscht wirken. Für einen kleinen internen Job, der ein paar Mal pro Stunde läuft, kann eine maximale Dauer oder eine explizite Fehlermetrik nützlicher sein als P99. Für eine öffentliche API mit stetigem Verkehr sind P95 und P99 oft eine Überwachung wert.

Wenn Sie einen Alarm erstellen, stellen Sie sicher, dass der CLI-Befehl die Statistik verwendet, die Sie tatsächlich beabsichtigen. Verwenden Sie für einen Perzentil-Alarm --extended-statistic p95 oder p99, nicht --statistic Average:

aws cloudwatch put-metric-alarm \
  --alarm-name "HighCheckoutP95Latency" \
  --metric-name "CheckoutLatency" \
  --namespace "MyApp/ECommerce" \
  --extended-statistic p95 \
  --period 60 \
  --threshold 500 \
  --evaluation-periods 5 \
  --datapoints-to-alarm 3 \
  --comparison-operator GreaterThanThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:PerformanceAlertsTopic

Die Einstellung datapoints-to-alarm ist wichtig. Die Anforderung von drei von fünf Zeiträumen kann anhaltende Probleme erkennen, ohne für eine verrauschte Minute zu pagen. Passen Sie dies für kritische Systeme mit echtem historischem Verkehr an, anstatt zu raten.

Anwendungsmetriken neben AWS-Metriken platzieren

AWS-Service-Metriken zeigen Ihnen, was die Plattform sieht. Ihre Anwendungsmetriken zeigen Ihnen, was der Benutzer zu tun versucht. Sie brauchen beides.

Beispielsweise kann ein ECS-Service normale CPU- und Speicherwerte aufweisen, während der Checkout defekt ist, weil ein Zahlungsanbieter eine Zeitüberschreitung hat. CloudWatch wird das nicht wissen, es sei denn, Ihre Anwendung veröffentlicht eine Metrik wie PaymentAuthorizationFailure, CheckoutCompleted oder PaymentProviderLatency.

Gute benutzerdefinierte Metriken sind normalerweise an Geschäftsaktionen gebunden:

• LoginSucceeded und LoginFailed
• OrderCreated
• PaymentAuthorizationLatency
• QueueJobProcessed
• ImportRowsFailed

Halten Sie Dimensionen nützlich, aber nicht explosionsartig. Service, Environment und Region sind normalerweise in Ordnung. Eine Dimension für jede Benutzer-ID, Anfrage-ID oder jeden URL-Pfad kann zu hohen Kosten durch hohe Kardinalität führen und die Daten schwerer nutzbar machen. Für detaillierte anfragespezifische Untersuchungen sind Logs und Traces der bessere Ort.

Das CloudWatch Embedded Metric Format ist praktisch, wenn Sie bereits strukturierte JSON-Logs schreiben. Es ermöglicht Ihnen, Logs und Metriken aus demselben Ereignis auszugeben, was die Anwendungsinstrumentierung vereinfacht. Der Kompromiss sind Kosten und Volumen: Strukturierte Logs sind leistungsstark, aber verrauschte Logs werden schnell teuer.

Alarme um Symptome und Ursachen herum aufbauen

Ein häufiger Monitoring-Fehler ist das Alarmieren nur auf Ursachen: CPU hoch, Speicher hoch, Datenträger-Warteschlange hoch. Diese sind nützlich, bedeuten aber nicht immer, dass Benutzer betroffen sind. Ein weiterer Fehler ist das Alarmieren nur auf Symptome: Fehlerrate hoch, Latenz hoch, Bestellungen schlagen fehl. Diese sagen Ihnen, dass Benutzer betroffen sind, erklären aber nicht, warum.

Ein praktischer Aufbau verwendet beides:

• Symptomalarme pagen den Servicebesitzer: hohe Fehlerrate, hohe Latenz, keine erfolgreichen Bestellungen, Warteschlangenalter steigt.
• Ursachenalarme unterstützen die Diagnose: Datenbank-CPU, gedrosselte DynamoDB-Anfragen, Lambda-Parallelität, erschöpftes Burst-Guthaben, wenig Speicherplatz.
• Kapazitätsalarme warnen frühzeitig: Auto Scaling nahe am Maximum, Service-Kontingent nähert sich, Warteschlangenrückstand wächst schneller, als Arbeiter ihn abarbeiten können.

Wenn jeder Alarm denselben Kanal mit derselben Dringlichkeit benachrichtigt, hören die Leute auf, dem Kanal zu vertrauen. Machen Sie Warnalarme sichtbar, ohne jemanden aufzuwecken, und reservieren Sie Seitenalarme für Benutzerauswirkungen oder nahezu sichere Benutzerauswirkungen.

Logs Insights für Fragen verwenden, nicht nur für Suchen

CloudWatch Logs Insights ist am nützlichsten, wenn das Team Abfragen für Fragen speichert, die sie wiederholt stellen. Beispiele:

fields @timestamp, status, path, durationMs
| filter status >= 500
| stats count() as errors by path
| sort errors desc
| limit 20

fields @timestamp, requestId, customerId, durationMs
| filter durationMs > 2000
| sort durationMs desc
| limit 50

fields @timestamp, @message
| filter @message like /ThrottlingException|Rate exceeded/
| sort @timestamp desc
| limit 100

Diese Abfragen ersetzen kein Tracing, aber sie sind schnell genug für die erste Reaktion. Speichern Sie sie in Runbooks oder Dashboard-Text-Widgets, damit die nächste Person die Syntax nicht auswendig lernen muss, während das System langsam ist.

Kosten überprüfen, während Sie die Transparenz verbessern

CloudWatch kann teuer werden, wenn Teams hochauflösende benutzerdefinierte Metriken aktivieren, jedes Log für immer aufbewahren oder zu viele eindeutige Metrikdimensionen erstellen. Performance-Monitoring sollte keine Überraschungsrechnung verursachen.

Legen Sie Aufbewahrungsfristen bewusst fest. Produktionsanwendungs-Logs benötigen möglicherweise eine längere Aufbewahrung als Debug-Logs aus der Entwicklung. Sicherheits- und Audit-Logs können ihre eigenen Regeln haben. Erwägen Sie bei ausführlichen Diensten das Filtern oder Sampling von verrauschten Informationslogs, bevor sie CloudWatch erreichen.

Beginnen Sie bei Metriken mit der Auflösung, die zu der Aktion passt, die Sie ausführen können. Wenn ein Dienst mehrere Minuten benötigt, um sicher zu skalieren, verbessern Ein-Sekunden-Metriken möglicherweise nicht die Reaktion. Wenn ein Latenzanstieg sofort erkannt werden muss, können hochauflösende Metriken für dieses enge Signal den Aufwand wert sein.

Ein nützlicher erster CloudWatch-Setup

Für einen neuen Produktionsdienst ist ein solider erster Durchlauf:

1. Ein Dashboard mit Verkehr, Latenz, Fehlern, Sättigung und Abhängigkeitsgesundheit.
2. Alarme für hohe Fehlerrate, hohe Latenz, keinen erfolgreichen Verkehr, wenn Verkehr erwartet wird, Warteschlangenalter und ggf. wenig Speicherplatz.
3. Anwendungsmetriken für die wichtigsten Benutzeraktionen.
4. Strukturierte Logs mit Anfrage-IDs und genügend Feldern, um nach Route, Status, Dauer und Abhängigkeit zu filtern.
5. Gespeicherte Logs Insights-Abfragen für langsame Anfragen, 5xx-Fehler, Drosselung und fehlgeschlagene Hintergrundjobs.
6. Eine monatliche Überprüfung von verrauschten Alarmen, fehlenden Alarmen und CloudWatch-Kosten.

CloudWatch funktioniert am besten, wenn es ein Teil der Arbeitsweise des Teams wird, nicht ein Dashboard, das jemand erst öffnet, nachdem sich Benutzer beschweren. Beginnen Sie mit den Fragen, die Sie während Vorfällen stellen, und formen Sie dann Metriken, Alarme und Logs um diese Fragen herum.