Custom Amazon CloudWatch Metriken: Wenn Standard nicht reicht

Was ist Amazon CloudWatch?

CloudWatch ist ein Überwachungsdienst mit einer Vielzahl von Funktionen, die wichtige betriebliche Aufgaben und Einblicke in AWS-Ressourcen und -Anwendungen ermöglichen. Die wichtigsten Funktionen von CloudWatch umfassen:

• Protokolle (Logs).
• Alarme.
• Dashboards.
• Visualisierung.
• Benutzerdefinierte Aktionen.
• Überwachung der Betriebszeit (Uptime).
• Metrikverwaltung.
• Automatisierte Fehlerbehebung bei Vorfällen.
• Anwendungsleistungsmanagement.

All diese Funktionen sind für die Zuverlässigkeit, Leistung, Sicherheit, optimale Kosten und effiziente Abläufe von Anwendungen von großer Bedeutung.

EC2 liefert nativ CloudWatch-Metriken zur Auslastung der Recheninfrastruktur. Da EC2 auch einer der wichtigsten Dienste in AWS ist, ist die Verwaltung von Metriken zwischen EC2 und CloudWatch ein wichtiger Bereich, den es beim Starten und Warten von Anwendungen in AWS zu verstehen gilt.

Standardmäßig listet EC2 Infrastruktur-Nutzungsmetriken wie CPUUtilization, DiskReadOps, NetworkIn und StatusCheckFailed in CloudWatch auf. Diese Metriken ermöglichen es Anwendungsbesitzern, die Nutzung der Recheninfrastruktur zu überwachen, den Systemzustand zu bewerten, Benachrichtigungen zu automatisieren und Optimierungen vorzunehmen. Sie können in der AWS CloudWatch-Konsole oder durch Erstellen benutzerdefinierter CloudWatch-Dashboards visualisiert werden. CloudWatch-Alarme können basierend auf Parametern konfiguriert werden, die sich auf Metrikschwellenwerte, Statistiken und Zeiträume beziehen. Metrikdaten können auch mit dem AWS SDK für benutzerdefinierte Automatisierungsprozesse abgerufen werden.

Im Jahr 2025 wurden mehrere Erweiterungen des CloudWatch-Agenten und der Monitoring-Funktionen eingeführt, die die Überwachung noch detaillierter und präziser machen. Der CloudWatch-Agent unterstützt jetzt die Erfassung detaillierter EBS-Leistungsmetriken wie Eingabe-/Ausgabe-Operationen pro Sekunde (IOPS), Durchsatz und Queue-Tiefe, was eine genauere Analyse der Storage-Performance ermöglicht. Darüber hinaus bietet Amazon CloudWatch neue Database Insights, die eine tiefere Einblicknahme in Datenbankmetriken erlauben und so Anomalien oder Leistungsengpässe frühzeitig erkennen helfen.

Erweiterte Alarmierungsfunktionen wie Query Alarms erlauben die Überwachung einzelner Metriken mit komplexeren Abfragen, wodurch individuellere und effiziente Alarmierungsstrategien möglich sind. Zudem wurden benutzerdefinierte Real User Monitoring (RUM)-Metriken durch Amazon Evidently erweitert, was detailliertere Einblicke in das Nutzerverhalten bietet. Diese Entwicklungen erweitern die Nutzungsmöglichkeiten von CloudWatch und sollten bei der Planung und Implementierung von Cloud-Überwachungen berücksichtigt werden.

Warum benutzerdefinierte Metriken von CloudWatch verwenden?

Benutzerdefinierte Metriken ermöglichen die Überwachung spezifischer Anwendungsverhalten, Konfigurationen und Anforderungen. Obwohl die von EC2 veröffentlichten Metriken sehr hilfreich sind, gibt es viele Situationen, in denen anwendungsspezifischere Metriken erforderlich sind, um eine Bereitstellung ordnungsgemäß zu überwachen, unter anderem:

• Kenntnis der Nutzungsanzahl für bestimmte Anfragen in einer Webanwendung, zum Beispiel /login und /landing-page.
• Verfolgung abgeschlossener Prozesse wie Kunden-Onboarding/Offboarding und spezifischer Produkt-Checkouts.
• Überwachung spezifischer Fehlercodes, die von einer Anwendung zurückgegeben werden.

Die Anwendungsfälle für benutzerdefinierte Metriken sind vielfältig und hängen von den spezifischen Anwendungsimplementierungen und Anforderungen ab. Entwickler können diese Metriken mit der AWS CLI oder dem SDK ausgeben und sie mit denselben Mechanismen visualisieren wie die von AWS-Diensten veröffentlichten Standardmetriken.

Funktionen und Parameter

Benutzerdefinierte Metriken unterstützen auch die Hochauflösungsfunktion, mit der Metriken mit einer höheren Granularität als bei der Standardauflösung aggregiert werden können. Die Standardauflösung unterstützt einen Zeitraum von 1 Minute, während die Hochauflösung 1, 5, 10 oder 30 Sekunden unterstützt, was für Szenarien nützlich ist, die eine Überwachung mit höherer Genauigkeit erfordern. Allerdings ist die Standardauflösung in den meisten Anwendungsfällen ausreichend.

Benutzerdefinierte Metriken werden mithilfe der PutMetricData-API veröffentlicht, die aus dem Quellcode der Anwendung aufgerufen werden kann, der in EC2-Instanzen oder einer anderen Recheninfrastruktur bereitgestellt wird. Die wichtigsten Parameter für diese API sind die folgenden.

Namespace. Namespace (Namensraum) ist eine Möglichkeit, Metriken nach einem Namensmuster zu gruppieren, das für eine bestimmte Bereitstellung relevant ist. Beispielsweise veröffentlichen alle AWS-Dienste Metriken unter einem Namespace, der dem Muster AWS/<Dienst> folgt. Bei benutzerdefinierten Metriken können Namespaces nützlichen Mustern wie <Anwendung>/<Komponente>/<Bereitstellungsphase> folgen, was dabei hilft, Metriken auf eine für Überwachungs- und Fehlerbehebungszwecke relevante Weise zu gruppieren.

MetricData. MetricData enthält den Namen der zu veröffentlichenden Metrik und Daten, die mit messbaren Parametern verbunden sind, wie beispielsweise Datenanzahl, Zeitstempel, Einheitsmetrikwerte und Statistiken. Metrikdimensionen sind ein wichtiger Parameter in MetricData, da sie zusätzlichen Kontext für jede veröffentlichte Metrik liefern. Die Kombination aus Metrik-Namespaces und -dimensionen ist für die Gruppierung der veröffentlichten benutzerdefinierten Metrikdaten unerlässlich.

Jeder PutMetricData-API-Aufruf erlaubt maximal 1.000 Metrikdatensätze und eine Anforderungsgröße von bis zu 1 MB. Bei Anwendungen mit einem sehr hohen Nutzungsvolumen ist es sehr wichtig, die Häufigkeit der erforderlichen API-Aufrufe zu bewerten. In Fällen, in denen das Nutzungsvolumen diese Grenzen überschreitet, können Anwendungen während Zeiten extrem hoher Nutzung eine benutzerdefinierte Datenaggregation oder asynchrone Verarbeitung von Metrikdaten durchführen.

CloudWatch-Agent

Eine sehr nützliche Methode zum Veröffentlichen von Metriken ist der CloudWatch-Agent, der in EC2-Instanzen, benutzerdefinierten lokalen Servern und Containern installiert werden kann. Der CloudWatch-Agent ist Open Source und in GitHub verfügbar.

Der CloudWatch-Agent benötigt eine Konfigurationsdatei mit Details zu den Metriken und Anwendungsprotokollen, die in CloudWatch exportiert werden sollen. Der CloudWatch-Agent ermöglicht die Veröffentlichung wichtiger EC2-Instanzmetrikenzum Beispiel in Bezug auf Memory-Auslastung und Festplattenspeicher, die in CloudWatch standardmäßig nicht verfügbar sind. Auch wenn der CloudWatch-Agent benutzerdefinierte Werte aus relevanten Quellen wie Anwendungsprotokollen extrahiert, ist es in vielen Fällen praktischer, die CloudWatch-API zu verwenden, um anwendungsspezifische Metriken als benutzerdefinierte Metriken in CloudWatch zu veröffentlichen.

Preismodell

Metriken gelten als aktiv, wenn Daten an CloudWatch gesendet werden, die stündlich anteilig berechnet werden. Wenn eine Anwendung keine Daten mehr für eine bestimmte Metrik sendet, wird diese Metrik nicht mehr in die Metrik-Zählgebühr einbezogen.

Um die AWS-Kosten effektiv zu planen, müssen IT-Teams die Anzahl der zu veröffentlichenden Metriken und das erwartete API-Aufrufvolumen bewerten. Eine Anwendung mit einer Kombination von Dimensionen, die 5 Metriken pro Instanz bei 51.000 Instanzen verfolgt, ergibt 255.000 Metriken. Die ersten 10.000 benutzerdefinierten Metriken kosten 0,30 US-Dollar pro Metrik, was 3.000 Dollar ergibt. Zwischen 10.000 und 250.000 fallen 0,10 US-Dollar an. In unserem Rechenbeispiel werden dann also 24.000 US-Dollar abgerechnet. Für alles ab 250.000 Metriken zahlt der Anwender nur noch 0,05 US-Dollar, also hier für 5.000 Metriken, insgesamt 250 US-Dollar. Insgesamt liegen die Endkosten für dieses Beispiel bei 27.250 US-Dollar pro Monat. Bei über einer Million Metriken kostet eine Metrik nur noch 0,02 US-Dollar. Leider gibt AWS nur Preise in Dollar an, auch für die Region Frankfurt (Europa).

Bei der Veröffentlichung hochauflösender Metriken müssen Sie das zu erwartende API-Aufrufvolumen berechnen, da es im Vergleich zu Metriken mit Standardauflösung wahrscheinlich höher sein wird.