CloudWatch-Alarme und zusammengesetzte Alarme

Ein CloudWatch-Alarm überwacht eine einzelne Metrik oder das Ergebnis eines Metrikmathematik-Ausdrucks über einen von Ihnen festgelegten Zeitraum. Wenn die Metrik einen von Ihnen definierten Schwellenwert überschreitet, ändert der Alarm seinen Status und kann automatisch eine Aktion auslösen, etwa eine SNS-Benachrichtigung senden, eine Auto Scaling-Gruppe skalieren, eine EC2-Instance stoppen oder ein Systems Manager OpsItem ausführen. Alarme sind der wichtigste Mechanismus für automatisierte Betriebsreaktionen in AWS.

Ein CloudWatch-Alarm befindet sich immer in einem von drei Status: OK — die Metrik liegt innerhalb des definierten Schwellenwerts; ALARM — die Metrik hat den Schwellenwert während der erforderlichen Anzahl von Auswertungszeiträumen überschritten; INSUFFICIENT_DATA — der Alarm wurde gerade erstellt, die Metrik ist nicht verfügbar oder es wurden noch nicht genügend Daten gesammelt. Statusübergänge lösen Aktionen aus, die für diese Statusänderung konfiguriert wurden — Sie können für die Status OK, ALARM und INSUFFICIENT_DATA unterschiedliche SNS-Themen verwenden.

Beim Erstellen eines Alarms legen Sie Folgendes fest: die Metrik und den Namespace, die Statistik (Average, Sum, Maximum usw.), den Zeitraum (wie häufig die Metrik in Sekunden ausgewertet wird), die Auswertungszeiträume (wie viele aufeinanderfolgende Zeiträume den Schwellenwert überschreiten müssen), den Schwellenwert und den Vergleichsoperator. Der Alarm wird ausgelöst, wenn die Metrik den Schwellenwert während der angegebenen Anzahl aufeinanderfolgender Auswertungszeiträume überschreitet.

Alarmaktionen können auf mehrere Ziele verweisen: Amazon-SNS-Themen (zum Senden von E-Mails und SMS oder zum Auslösen von Lambda), Auto-Scaling-Richtlinien (zum Hoch- oder Herunterskalieren einer ASG) und EC2-Aktionen (zum Stoppen, Beenden, Neustarten oder Wiederherstellen einer EC2-Instance). Für jeden Status (OK, ALARM, INSUFFICIENT_DATA) können Sie einen anderen Aktionssatz festlegen — benachrichtigen Sie beispielsweise das Team bei ALARM, senden Sie bei der Wiederherstellung eine OK-Benachrichtigung und lösen Sie bei INSUFFICIENT_DATA einen Alarm aus, um Überwachungslücken zu erkennen.

Wenn CloudWatch einen Alarm auswertet und einige Datenpunkte fehlen, müssen Sie festlegen, wie damit umgegangen werden soll. Die Optionen sind: notBreaching (fehlende Daten werden als innerhalb des Schwellenwerts liegend behandelt — der Alarm bleibt auf OK, wenn die übrigen Daten OK sind), breaching (fehlende Daten werden als Überschreitung des Schwellenwerts behandelt — der Alarm wechselt zu ALARM), ignore (der Alarmstatus ändert sich nicht) und missing (der Alarm wechselt zu INSUFFICIENT_DATA). Die falsche Wahl führt zu Fehlalarmen oder unbemerkten Ausfällen — eine wichtige Besonderheit der SAA-C03-Prüfung.

Die Alarmauflösung ist das Produkt aus Zeitraum × Auswertungszeiträumen. Ein Zeitraum von 60 Sekunden mit 5 Auswertungszeiträumen bedeutet beispielsweise, dass der Alarm 5 aufeinanderfolgende Datenpunkte im Abstand von jeweils 1 Minute berücksichtigt. Standardmäßig wechselt der Alarm erst zu ALARM, wenn alle fünf Zeiträume den Schwellenwert überschreiten. Sie können datapoints-to-alarm so konfigurieren, dass nur M von N Zeiträumen den Schwellenwert überschreiten müssen — beispielsweise 3 von 5. Dadurch verringert sich die Zahl der Fehlalarme aufgrund kurzzeitiger Spitzen.

Ein Verbundalarm wertet den Status mehrerer anderer Alarme mithilfe boolescher Logik (AND, OR, NOT) aus. Er wechselt nur dann in den Status ALARM, wenn der Regelausdruck den Wert true ergibt. Verbundalarme werden verwendet, um Alarmrauschen zu reduzieren — lösen Sie beispielsweise nur dann einen Alarm aus, wenn sowohl der Alarm für hohe CPU-Auslastung ALS AUCH der Alarm für hohe Latenz gleichzeitig aktiv sind, da eine hohe CPU-Auslastung während einer Stapelverarbeitung allein akzeptabel sein kann. Sie können Verbundalarme außerdem verwenden, um untergeordnete Alarme während Wartungsfenstern zu unterdrücken.

Verbundalarme unterstützen Aktionen zur Alarmunterdrückung — Sie können einen Verbundalarm so konfigurieren, dass er seine untergeordneten Alarme während geplanter Wartungsarbeiten unterdrückt. Während eines Bereitstellungsfensters könnten Sie beispielsweise einen Verbundalarm einrichten, der einen Alarm „MaintenanceMode“ mit OR-Logik kombiniert und alle Benachrichtigungen untergeordneter Alarme unterdrückt, solange die Wartung aktiv ist. Dadurch verhindern Sie eine Flut von Alarmen, wenn Sie Dienste für Upgrades absichtlich offline nehmen.

Auto-Scaling-Gruppen verwenden CloudWatch-Alarme als Auslöser für Richtlinien zur Schritt-Skalierung und zur einfachen Skalierung. Wenn der Alarm in den Status ALARM wechselt, wird die Skalierungsrichtlinie ausgeführt. Bei der Schritt-Skalierung definieren Sie mehrere Skalierungsanpassungen für unterschiedliche Schwellenwertbereiche — beispielsweise 1 Instance hinzufügen, wenn die CPU-Auslastung 70–80 % beträgt, 3 bei 80–90 % und 5 bei über 90 %. Der Alarm löst anhand des Überschreitungsgrads zum Auswertungszeitpunkt den ersten passenden Schritt aus.

Sie können in CloudWatch Abrechnungsalarme erstellen, um benachrichtigt zu werden, wenn Ihre geschätzten AWS-Kosten einen Schwellenwert überschreiten. Abrechnungsmetriken werden nur in der Region us-east-1 veröffentlicht, unabhängig davon, wo Ihre Ressourcen ausgeführt werden, und ungefähr alle 6 Stunden aktualisiert. Um Abrechnungsalarme zu aktivieren, müssen Sie zunächst Billing Alerts in der AWS-Billing-Konsole einschalten. Das präzisere Werkzeug ist AWS Budgets, aber CloudWatch-Abrechnungsalarme sind weiterhin eine gültige und in der Prüfung behandelte Option.

Sie können den Alarmstatus mit dem Befehl set-alarm-state manuell festlegen, um Alarmaktionen zu testen, ohne auf eine tatsächliche Überschreitung des Schwellenwerts zu warten. Das ist nützlich, um zu überprüfen, ob Ihre SNS-Themen, Auto-Scaling-Richtlinien und Lambda-Funktionen korrekt reagieren. Testen Sie Alarmaktionen immer in einer Nicht-Produktionsumgebung und überprüfen Sie, dass die richtigen E-Mail-Abonnements für das SNS-Thema bestätigt wurden, bevor Sie sich bei Produktionsalarmen auf diese Alarme verlassen.

Testen Sie Ihr Verständnis der AWS-Solutions-Architect-Konzepte (SAA-C03) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: Alarme haben drei Status (OK, ALARM, INSUFFICIENT_DATA) und können SNS-, Auto-Scaling- und EC2-Aktionen auslösen; mit datapoints-to-alarm ist eine M-aus-N-Auswertung möglich, um Fehlalarme zu reduzieren; und Verbundalarme verwenden boolesche Logik, um mehrere Alarme zu kombinieren und Alarmrauschen zu unterdrücken. Als Nächstes sehen wir uns CloudWatch Logs und Log Insights für die zentrale Protokollverwaltung an.