View a markdown version of this page

CloudWatch Alarmes recommandées pour les clusters Amazon MSK Provisioned - Amazon Managed Streaming for Apache Kafka

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

CloudWatch Alarmes recommandées pour les clusters Amazon MSK Provisioned

Surveillez vos clusters Amazon MSK Provisioned pour détecter les problèmes avant qu'ils n'affectent vos applications. CloudWatch les alarmes exécutent une action lorsqu'une CloudWatch métrique dépasse une valeur spécifiée pendant un certain temps. Par exemple, vous souhaiterez peut-être recevoir une notification par e-mail si le nombre de partitions dépasse la valeur recommandée pour la taille de votre instance de courtier pendant plus de 15 minutes. Les alarmes critiques du tableau suivant sont recommandées, mais elles ne constituent pas une liste exhaustive des alarmes que vous pouvez créer pour surveiller votre cluster.

Pour plus d'informations sur la configuration des alarmes, consultez la section Création d' CloudWatch alarmes Amazon dans le Guide de CloudWatch l'utilisateur Amazon.

Le tableau suivant répertorie les alarmes qui s'appliquent à la fois aux courtiers Standard et Express.

alerte Problème

CPUUser+ CPUSystem Moyenne >= 60 pendant 5 minutes, 3 fois consécutives

Dimensions: Cluster Name, Broker ID

Un ou plusieurs courtiers ont un CPUuser+système CPU moyen supérieur aux 60 % recommandés. Pour en savoir plus, veuillez consulter la section Surveiller l'utilisation de l'UC.

PartitionCountMoyenne >= X pendant 5 minutes, 3 fois consécutives (X = nombre de partitions recommandé pour la taille de l'instance du broker)

Dimensions: Cluster Name, Broker ID

Un ou plusieurs courtiers ont des partitions supérieures à la limite de partition recommandée. Pour en savoir plus, consultez Right-size votre cluster : nombre de partitions par courtier standard et Quota de partition d'Express Broker.

SumOffsetLagMoyenne >= X pendant 5 minutes, 3 fois consécutives (X est défini pour une combinaison de groupes de consommateurs et de sujets en fonction du cas d'utilisation)

Dimensions : Cluster Name, Consumer Group, Topic

Le décalage de décalage agrégé pour toutes les partitions d'une rubrique est supérieur à X. Pour plus d'informations sur le décalage, vous pouvez utiliser la Offset métrique au niveau de la partition, qui représente le décalage pour chaque partition, ou utiliser l'outil de ligne de commande Kafka pour décrire le groupe de consommateurs. Passez en revue la vitesse de traitement de votre demande de consommation par rapport aux producteurs pour savoir si les consommateurs ne sont pas en mesure de suivre le rythme et vérifiez si des rééquilibres de consommation ralentissent les consommateurs.

Le tableau suivant répertorie les alarmes qui s'appliquent uniquement aux courtiers Standard.

alerte Problème

OfflinePartitionsCountMoyenne >= 1 pendant 1 minute, 3 fois consécutives

Dimensions : Cluster Name

Une ou plusieurs partitions thématiques ne sont pas disponibles. Lorsque des partitions ne sont pas disponibles, les opérations de production et de consommation sur ces partitions échouent. Les partitions hors ligne ne doivent pas se trouver sur un cluster bien équilibré, correctement dimensionné et correctement configuré. Pour en savoir plus, veuillez consulter la section Créer des clusters hautement disponibles.

UnderMinIsrPartitionCountMoyenne >= 1 pendant 1 minute, 3 fois consécutives

Dimensions: Cluster Name, Broker ID

Une ou plusieurs rubriques ont des partitions inférieures au jeu de répliques synchronisées (ISR) minimum configuré. Lorsque les partitions tombent en dessous de l'ISR minimum, les opérations de production échouent (avec le producteuracks=all). Pour en savoir plus, veuillez consulter la section Créer des clusters hautement disponibles.

KafkaDataLogsDiskUsedMoyenne >= 80 pendant 5 minutes, 3 fois consécutives

Dimensions: Cluster Name, Broker ID

Un ou plusieurs courtiers utilisent les disques de données d'au moins 80 %. Pour en savoir plus, veuillez consulter la section Surveiller l'espace disque.

HeapMemoryAfterGCMoyenne >= 60 pendant 5 minutes, 3 fois consécutives

Dimensions: Cluster Name, Broker ID

Un ou plusieurs courtiers ont 60 % ou plus de la mémoire totale utilisée après le ramassage des déchets. Pour en savoir plus, veuillez consulter la section Surveiller la mémoire Apache Kafka.

(Sum (VolumeReadBytes) + Sum (VolumeWriteBytes))/(5 * 60 * 1024 * 1024) >= X MiB pendant 5 minutes, 3 fois consécutives (X = 80 % du débit disponible)

Dimensions: Cluster Name, Broker ID

Un ou plusieurs courtiers ont une activité sous-jacente de lecture et d'écriture de volumes utilisant jusqu'à 80 % de leur débit de volume disponible. Pour en savoir plus, consultez la section Débit de stockage provisionné.

CPUCreditBalanceMoyenne <= 100 pendant 5 minutes, 3 fois consécutives

Dimensions: Cluster Name, Broker ID

Cela ne concerne que le type de courtier t3.small. Un ou plusieurs courtiers ont épuisé leur solde créditeur CPU d'un maximum de 576 à moins de 100. Lorsque le solde atteint 0, le courtier ne peut pas dépasser la base de référence de 20 % du processeur. Pour éviter l'épuisement des crédits CPU, passez d'un type d'instance broker t3 à un type d'instance m7g, qui n'utilise pas de crédits CPU.

RequestHandlerAvgIdlePercentMoyenne <= 0,3 pendant 5 minutes, 3 fois consécutives

Dimensions: Cluster Name, Broker ID

Un ou plusieurs courtiers constatent une congestion des activités sur le pool de threads chargé de traiter les demandes (le pool de threads est inactif à moins de 30 %). La saturation indique ici des requêtes lentes, ce qui peut entraîner des délais d'attente côté client. Vérifiez également si vos clients génèrent trop de demandes. Par exemple, des clients non autorisés peuvent réessayer de manière agressive des demandes que les courtiers refusent. Pour en savoir plus sur l'optimisation du débit des clusters, consultezOptimisez le débit du cluster pour les instances m5.4xl, m7g.4xl ou supérieures.

NetworkProcessorAvgIdlePercentMoyenne <= 0,3 pendant 5 minutes, 3 fois consécutives

Dimensions: Cluster Name, Broker ID

Un ou plusieurs courtiers constatent une congestion des activités sur le pool de threads de connexion réseau (le pool de threads est inactif à moins de 30 %). La saturation peut provoquer des délais d'attente. Vérifiez également si vos clients génèrent trop de demandes. Par exemple, des clients non autorisés peuvent réessayer de manière agressive des demandes que les courtiers refusent. Pour en savoir plus sur l'optimisation du débit des clusters, consultezOptimisez le débit du cluster pour les instances m5.4xl, m7g.4xl ou supérieures.

KafkaFileDescriptorsUsagePercent> 80 % pendant 5 minutes, 3 fois consécutives

Dimensions: Cluster Name, Broker ID

Pourcentage de descripteurs de fichiers utilisés par le broker. À 100% d'épuisement, le courtier Kafka pourrait ne pas être en mesure de démarrer. Le nombre de descripteurs de fichiers augmente en fonction du nombre de partitions, du nombre de segments de journal dans chaque partition et du nombre de connexions client. Vérifiez si vous avez des sujets dont segment.ms les valeurs sont faibles, ce qui entraîne des journaux fréquents, et envisagez de réduire le nombre de connexions client.

KafkaMemoryMappedFilesUsagePercent> 80 % pendant 5 minutes, 3 fois consécutives

Dimensions: Cluster Name, Broker ID

Pourcentage de fichiers mappés en mémoire utilisés par le broker. À 100% d'épuisement, le courtier Kafka pourrait ne pas être en mesure de démarrer. Le nombre d'utilisation des fichiers mappés en mémoire augmente avec le nombre de partitions et le nombre de segments de journal dans chaque partition. Vérifiez si vous avez des sujets dont les segment.ms valeurs sont faibles, ce qui entraîne de fréquentes relectures de journaux.

Alarmes de contrôle d'accès IAM

Outre les alarmes précédentes, nous vous recommandons de créer des alarmes pour les mesures suivantes spécifiques au contrôle d'accès IAM. Ces alarmes s'appliquent aux courtiers Standard et Express pour lesquels l'authentification IAM est activée. Amazon MSK impose des limites logiques aux connexions IAM afin de protéger le broker contre la surcharge des demandes de connexion IAM. Le non-respect de l'une de ces limites entraîne des délais de connexion du client, ce qui aura un impact sur votre charge de travail.

alerte Problème

ClientConnectionCountSomme >= X pendant 1 minute, 3 fois consécutives (X = 80 % du maximum de connexions TCP par courtier)

Dimensions : Cluster Name, Broker ID, Client Authentication

Un ou plusieurs courtiers ont un nombre de connexions égal à 80 % de la limite de connexion. Le nombre maximum de connexions TCP par courtier par défaut pour le contrôle d'accès IAM est de 3 000. Cette valeur ne peut pas être modifiée. Pour plus d'informations, consultez Quota de courtiers Amazon MSK Express les rubriques Courtiers Express et Quota de courtiers Amazon MSK Standard Courtiers Standard.

ConnectionCreationRateSomme >= X pendant 1 minute, 3 fois consécutives (X = 80 % de la limite de taux de création de connexion pour la taille de votre instance)

Dimensions: Cluster Name, Broker ID

Un ou plusieurs courtiers ont des clients qui créent des connexions IAM à un taux égal à 80 % de leur limite de taux de création de connexions. Le débit de connexions TCP maximal par courtier pour le contrôle d'accès IAM dépend de la taille de l'instance. Pour plus d'informations, consultez Quota de courtiers Amazon MSK Express les rubriques Courtiers Express et Quota de courtiers Amazon MSK Standard Courtiers Standard.