Warum wechselt mein Amazon-MSK-Cluster in den Status HEALING?

Lösung

Dein Amazon-MSK-Cluster wechselt in den Status HEALING, wenn der Service einen internen Vorgang zur Behebung eines Problems ausführt. Wenn beispielsweise die Broker nicht reagieren und Amazon MSK einen internen Vorgang durchführt, um die nicht reagierenden Broker zu reparieren.

Du kannst den Cluster weiterhin verwenden, um Daten zu produzieren und zu nutzen, auch wenn sich der Cluster im Zustand HEALING befindet. Du kannst jedoch keine Amazon-MSK-API- oder AWS Command Line Interface (AWS CLI)-Aktualisierungsvorgänge auf dem Cluster ausführen, bis dieser wieder in den Zustand ACTIVE zurückkehrt.

Du kannst die Amazon-CloudWatch-Metriken für Amazon MSK verwenden, um zu überprüfen, warum sich der Cluster im Zustand HEALING befindet.

Führe die folgenden Schritte aus:

1. Öffne die Amazon-CloudWatch-Konsole.
2. Wähle im Navigationsbereich Metriken und dann Alle Metriken.
3. Wähle auf der Registerkarte Durchsuchen die Option AWS/Kafka aus.
4. Wähle unter Metriken die Option Cluster-Name aus.
5. Wähle den Cluster aus, den du überwachen möchtest.
   Hinweis: Wenn du Spitzen in der ActiveControllerCount- oder OfflinePartitionsCount-Metrik siehst, sind ein oder mehrere Broker fehlerhaft. Die fehlerhaften Broker haben möglicherweise dazu geführt, dass der Cluster in den Zustand HEALING übergegangen ist.
6. Um Metriken auf Brokerebene zu überprüfen, wähle unter Metriken Broker-ID, Cluster-Name aus.
7. Wähle aus der Liste die Einträge mit dem Clusternamen und den Metriken CpuUser und CpuSystem aus.
8. Prüfe, ob die Summe der CpuUser- und CpuSystem-Werte für alle Einträge einen Durchschnitt von 60 % oder mehr für den Cluster erreicht. Wenn der Durchschnitt höher als 60 % ist, hat eine hohe CPU-Auslastung möglicherweise dazu geführt, dass der Broker in den Zustand HEALING übergegangen ist. Weitere Informationen findest du unter CPU-Auslastung überwachen.

Ein Amazon-MSK-Cluster kann aus einem der folgenden Gründe auch in den Zustand HEALING wechseln:

• Amazon MSK muss aufgrund eines Hardware-Fehlers einen Knoten oder ein Amazon Elastic Block Store (Amazon EBS)-Volume ersetzen.
• Ein Knoten erfüllt nicht den Amazon-MSK-Leistungs-SLA für den Broker, und Amazon MSK muss den Knoten für eine effiziente Leistung ersetzen.

Amazon MSK ist ein vollständig verwalteter Service, sodass Broker über selbst verwaltete Workflows verfügen, die Korrekturmaßnahmen an sich selbst durchführen. Wenn beispielsweise ein Amazon-EBS-Volume in einem Broker fehlerhaft wird, beobachtet Amazon MSK den Zustand des Volumes über einen bestimmten Zeitraum. Wenn das Volume während dieser Zeit fehlerfrei wird, ergreift AWS MSK keine Maßnahmen. Wenn das Volumen nach diesem Zeitraum weiterhin fehlerhaft ist, ersetzt Amazon MSK dieses Volumen automatisch. Der Cluster geht in den Zustand HEALING über, wenn Amazon MSK diese Aktionen ausführt. Der Amazon-MSK-Cluster ist jedoch verfügbar, solange du die Best Practices befolgst.

Der Amazon-MSK-Cluster befindet sich in einem permanenten HEALING-Zustand

Die Workload auf dem Cluster ist hoch

Wenn die Workload auf dem Cluster hoch ist und AWS MSK die Broker kontinuierlich ersetzt, geht der Cluster möglicherweise in einen dauerhaften HEALING-Zustand über. Verwende keine t3.small-Instances zum Hosten von Produktions-Clustern, um eine hohe Workload auf dem Cluster zu vermeiden. Wenn du m5-Instances verwendest, stelle sicher, dass du die richtige Größe für den Cluster wählst. Überwache die CPU-Auslastung, die Partitionsanzahl oder den Durchsatz, um die richtige Größe für den Cluster auf der Grundlage der Workload zu ermitteln.

Stelle außerdem sicher, dass die Anzahl der Partitionen pro Broker den empfohlenen Wert nicht überschreitet.

Die Auto-Scaling-Gruppe kann keine neue Instance aufrufen

Wenn es ein internes Problem gibt, z. B. eine fehlende Abhängigkeit, kann die Auto-Scale-Gruppe keine neue Instance aufrufen und der Cluster geht in einen dauerhaften HEALING-Zustand über.

Du kannst beispielsweise länger auf den AWS Key Management Service (AWS KMS)-Schlüssel zugreifen, den du bei der Clustererstellung angegeben hast.

Ein internes Ereignis wirkt sich auf die Verfügbarkeit der EC2-Instance aus

Der Cluster könnte aus einem der folgenden Gründe auch in einen dauerhaften HEILUNG-Zustand übergehen:

• Ein internes Ereignis wirkt sich auf die Verfügbarkeit der zugrunde liegenden Amazon Elastic Compute Cloud (Amazon EC2)-Instances aus.
• Ein interner Fehler verursacht sogar Amazon-EBS-Latenz in einer Availability Zone oder AWS-Region.

Wenn der Cluster dauerhaft im HEALING-Zustand bleibt und dies nicht auf hohe Workloads zurückzuführen ist, wende dich an den AWS Support.

Ähnliche Informationen

Grundlegendes zu von MSK bereitgestellten Clusterzuständen

Willkommen beim Amazon-MSK-Entwicklungshandbuch

Einen von Amazon MSK bereitgestellten Cluster überwachen

Best Practices für Apache-Kafka-Clients