Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Empfohlene CloudWatch Alarme für von Amazon MSK bereitgestellte Cluster
Überwachen Sie Ihre von Amazon MSK bereitgestellten Cluster, um Probleme zu erkennen, bevor sie sich auf Ihre Anwendungen auswirken. CloudWatch Alarme führen eine Aktion aus, wenn eine CloudWatch Metrik einen bestimmten Wert für eine gewisse Zeit überschreitet. Beispielsweise möchten Sie möglicherweise eine E-Mail-Benachrichtigung erhalten, wenn Ihre Partitionsanzahl den empfohlenen Wert für die Größe Ihrer Broker-Instanz länger als 15 Minuten überschreitet. Die kritischen Alarme in der folgenden Tabelle werden empfohlen, stellen jedoch keine vollständige Liste der Alarme dar, die Sie zur Überwachung Ihres Clusters erstellen können.
Weitere Informationen zur Konfiguration von Alarmen finden Sie unter Erstellen von CloudWatch Amazon-Alarmen im CloudWatch Amazon-Benutzerhandbuch.
In der folgenden Tabelle sind Alarme aufgeführt, die sowohl für Standard- als auch für Express-Broker gelten.
| Alarm | Problem |
|---|---|
|
Maße: |
Bei einem oder mehreren Brokern liegt der durchschnittliche CPU-Benutzer+CPU-System über den empfohlenen 60%. Weitere Informationen hierzu finden Sie unter CPU-Auslastung überwachen. |
|
Maße: |
Ein oder mehrere Broker haben Partitionen, die das empfohlene Limit für die Anzahl der Partitionen überschreiten. Weitere Informationen hierzu finden Sie unter Right-size Ihr Cluster: Anzahl der Partitionen pro Standard-Broker und Partitionskontingent für Express Broker. |
|
Dimensionen: |
Die aggregierte Offset-Verzögerung für alle Partitionen in einem Thema liegt über X. Für weitere Informationen zur Verzögerung können Sie die |
In der folgenden Tabelle sind Alarme aufgeführt, die nur für Standard-Broker gelten.
| Alarm | Problem |
|---|---|
|
Maße: |
Eine oder mehrere Themenpartitionen sind nicht verfügbar. Wenn Partitionen nicht verfügbar sind, schlagen Produktions- und Konsumvorgänge für diese Partitionen fehl. Offline-Partitionen sollten nicht in einem ausgewogenen, korrekt dimensionierten und korrekt konfigurierten Cluster vorkommen. Weitere Informationen hierzu finden Sie unter Erstellen hochverfügbarer Cluster. |
|
Maße: |
Bei einem oder mehreren Themen liegen die Partitionen unter dem Mindestwert für den konfigurierten In-Sync-Replikatsatz (ISR). Wenn Partitionen unter den Mindest-ISR fallen, schlagen die Produktionsvorgänge fehl (mit Producer). |
|
Maße: |
Bei einem oder mehreren Brokern liegt die Festplattenauslastung bei mindestens 80%. Weitere Informationen hierzu finden Sie unter Überwachen der Festplattenkapazität. |
|
Maße: |
Bei einem oder mehreren Brokern sind nach der Garbage-Collection 60% oder mehr des gesamten Heap-Speichers belegt. Weitere Informationen hierzu finden Sie unter Apache-Kafka-Arbeitsspeicher überwachen. |
|
(Sum ( Maße: |
Bei einem oder mehreren Brokern liegt die zugrunde liegende Volume Lese- und Schreibaktivität vor, die bis zu 80% des verfügbaren Volumendurchsatzes beansprucht. Weitere Informationen finden Sie unter Durchsatz https://docs.aws.amazon.com/msk/latest/developerguide/msk-provision-throughput-management.html für bereitgestellten Speicher. |
|
Maße: |
Dies ist nur für den Brokertyp t3.small relevant. Ein oder mehrere Broker haben ihr CPU-Guthaben von maximal 576 auf weniger als 100 aufgebraucht. Wenn das Guthaben 0 erreicht, darf der Broker den CPU-Basiswert von 20% nicht überschreiten. Um eine Erschöpfung des CPU-Guthabens zu vermeiden, führen Sie ein Upgrade von einem t3-Broker-Instance-Typ auf einen m7g-Instance-Typ durch, der kein CPU-Guthaben verwendet. |
|
Maße: |
Bei einem oder mehreren Brokern kommt es zu einer Überlastung des Threadpools, der für die Bearbeitung von Anfragen verantwortlich ist (der Threadpool ist zu weniger als 30% inaktiv). Eine Sättigung deutet hier auf langsame Anfragen hin, die zu clientseitigen Timeouts führen können. Prüfen Sie auch, ob Ihre Kunden übermäßig viele Anfragen generieren. Beispielsweise könnten nicht autorisierte Kunden Anfragen, die die Makler ablehnen, aggressiv wiederholen. Weitere Informationen zur Optimierung des Cluster-Durchsatzes finden Sie unter. Optimieren Sie den Cluster-Durchsatz für m5.4xl, m7g.4xl oder größere Instances |
|
Maße: |
Bei einem oder mehreren Brokern ist die Aktivität im Threadpool der Netzwerkverbindung überlastet (der Threadpool ist zu weniger als 30% inaktiv). Eine Überlastung hier kann zu Timeouts führen. Prüfen Sie auch, ob Ihre Kunden übermäßig viele Anfragen generieren. Beispielsweise könnten nicht autorisierte Kunden Anfragen, die die Makler ablehnen, aggressiv wiederholen. Weitere Informationen zur Optimierung des Cluster-Durchsatzes finden Sie unter. Optimieren Sie den Cluster-Durchsatz für m5.4xl, m7g.4xl oder größere Instances |
|
Maße: |
Der Prozentsatz der Dateideskriptoren, die auf dem Broker verwendet werden. Bei 100% iger Erschöpfung kann der Kafka-Broker möglicherweise nicht starten. Die Anzahl der Dateideskriptoren steigt mit der Anzahl der Partitionen, der Anzahl der Protokollsegmente in jeder Partition und der Anzahl der Client-Verbindungen. Prüfen Sie, ob Sie Themen mit niedrigen |
|
Maße: |
Der Prozentsatz der Dateien mit Speicherabbildung, die auf dem Broker verwendet werden. Bei 100% iger Erschöpfung kann der Kafka-Broker möglicherweise nicht starten. Die Anzahl der Speicherzuordnungsdateien steigt mit der Anzahl der Partitionen und der Anzahl der Protokollsegmente in jeder Partition. Prüfen Sie, ob Sie Themen mit niedrigen |
Alarme bei der IAM-Zugriffskontrolle
Zusätzlich zu den vorherigen Alarmen empfehlen wir, Alarme für die folgenden Metriken zu erstellen, die für die IAM-Zugriffskontrolle spezifisch sind. Diese Alarme gelten sowohl für Standard- als auch für Express-Broker mit aktivierter IAM-Authentifizierung. Amazon MSK legt logische Grenzwerte für IAM-Verbindungen fest, um den Broker vor einer Überlastung der IAM-Verbindungsanforderungen zu schützen. Das Überschreiten eines dieser Grenzwerte führt zu Timeouts bei der Client-Verbindung, was sich auf Ihre Arbeitslast auswirkt.
| Alarm | Problem |
|---|---|
|
Dimensionen: |
Bei einem oder mehreren Brokern entspricht die Verbindungsanzahl 80% des Verbindungslimits. Die Standardeinstellung für maximale TCP-Verbindungen pro Broker für die IAM-Zugriffskontrolle ist 3000. Dieser Wert kann geändert werden. Weitere Informationen finden Sie unter Amazon MSK Express-Brokerquote Für Express-Broker und Amazon MSK Standard-Broker-Kontingent für Standard-Broker. |
|
Maße: |
Ein oder mehrere Broker haben Kunden, die IAM-Verbindungen mit einer Rate herstellen, die 80% des Grenzwerts für die Verbindungserstellungsrate entspricht. Die maximale TCP-Verbindungsrate pro Broker für die IAM-Zugriffskontrolle hängt von der Instanzgröße ab. Weitere Informationen finden Sie unter Amazon MSK Express-Brokerquote Für Express-Broker und Amazon MSK Standard-Broker-Kontingent für Standard-Broker. |