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.

Résoudre les problèmes liés à votre cluster Amazon MSK

Les informations suivantes peuvent vous aider à résoudre les problèmes que vous pourriez rencontrer avec votre MSK cluster Amazon. Vous pouvez également publier votre problème sur AWS re:Post. Pour résoudre les problèmes liés à Amazon MSK Replicator, consultezRésoudre les problèmes MSK de Replicator.

Le remplacement du volume entraîne une saturation du disque en raison d'une surcharge de réplication

En cas de panne matérielle imprévue d'un volume, Amazon MSK peut remplacer le volume par une nouvelle instance. Kafka reremplit le nouveau volume en répliquant les partitions provenant d'autres courtiers du cluster. Une fois les partitions répliquées et rattrapées, elles peuvent devenir membres de Leadership et Insync Replica (ISR).

Problème

Dans un courtier qui se remet d'un remplacement de volume, certaines partitions de tailles différentes peuvent être remises en ligne avant d'autres. Cela peut être problématique car ces partitions peuvent servir du trafic provenant du même courtier qui continue de rattraper (répliquer) d'autres partitions. Ce trafic de réplication peut parfois saturer les limites de débit du volume sous-jacentes, qui sont de 250 MiB par seconde dans le cas par défaut. Lorsque cette saturation se produit, toutes les partitions déjà rattrapées seront affectées, ce qui se traduira par une latence au sein du cluster pour tous les courtiers partageant ISR avec ces partitions rattrapées (et pas seulement les partitions principales dues à des connecteurs distantsacks=all). Ce problème est plus fréquent dans le cas de grands clusters comportant un plus grand nombre de partitions dont la taille varie.

Groupe de consommateurs bloqué à l'état PreparingRebalance

Si un ou plusieurs de vos groupes de consommateurs sont bloqués dans un état de rééquilibrage perpétuel, cela peut être dû au problème KAFKA-9752 d'Apache Kafka, qui affecte les versions 2.3.1 et 2.4.1 d'Apache Kafka.

Pour résoudre ce problème, nous vous recommandons de mettre à niveau votre cluster vers la version MSKCorrectif de bogue Amazon version 2.4.1.1, qui contient un correctif pour ce problème. Pour plus d'informations sur la mise à jour d'un cluster existant vers Amazon MSK bug-fix version 2.4.1.1, consultez. Mettre à jour la version d'Apache Kafka

Les solutions pour résoudre ce problème sans mettre à niveau le cluster vers la version 2.4.1.1 du MSK correctif de bogue Amazon consistent soit à configurer les clients Kafka à utiliserProtocole d'appartenance statique, soit à les placer sur le nœud courtier coordinateur Identifier et redémarrer du groupe de consommateurs bloqué.

Mise en œuvre d'un protocole d'appartenance statique

Pour mettre en œuvre le protocole d'appartenance statique dans vos clients, procédez comme suit :

L'utilisation du protocole d'appartenance statique est plus efficace si le délai d'expiration de la session dans la configuration client est défini sur une durée qui permet au consommateur de récupérer sans déclencher prématurément un rééquilibrage du groupe de consommateurs. Par exemple, si votre application consommateur peut tolérer 5 minutes d'indisponibilité, une valeur raisonnable pour le délai d'expiration de la session serait de 4 minutes au lieu de la valeur par défaut de 10 secondes.

Redémarrage du nœud d'agent de coordination

Pour redémarrer le nœud d'agent de coordination, procédez comme suit :

Erreur lors de la transmission des journaux du courtier à Amazon CloudWatch Logs

Lorsque vous essayez de configurer votre cluster pour envoyer les journaux des courtiers à Amazon CloudWatch Logs, il se peut que vous obteniez l'une des deux exceptions suivantes.

Si vous obtenez une exception InvalidInput.LengthOfCloudWatchResourcePolicyLimitExceeded, réessayez mais utilisez les groupes de journaux qui commencent par /aws/vendedlogs/. Pour de plus amples informations, consultez Activation de la journalisation à partir de certains services Amazon Web Services.

Si vous obtenez une InvalidInput.NumberOfCloudWatchResourcePoliciesLimitExceeded exception, choisissez une politique Amazon CloudWatch Logs existante dans votre compte et ajoutez-y ce qui suitJSON.

{"Sid":"AWSLogDeliveryWrite","Effect":"Allow","Principal":{"Service":"delivery.logs.amazonaws.com"},"Action":["logs:CreateLogStream","logs:PutLogEvents"],"Resource":["*"]}

Si vous essayez d'ajouter ce qui JSON précède à une politique existante mais que vous recevez un message d'erreur indiquant que vous avez atteint la longueur maximale pour la politique que vous avez sélectionnée, essayez de l'ajouter JSON à une autre de vos politiques Amazon CloudWatch Logs. Après l'avoir ajouté JSON à une politique existante, essayez à nouveau de configurer la livraison des journaux de courtage à Amazon Logs. CloudWatch

Aucun groupe de sécurité par défaut

Si vous essayez de créer un cluster et que vous recevez un message d'erreur indiquant qu'il n'existe aucun groupe de sécurité par défaut, cela peut être dû au fait que vous en utilisez un VPC qui a été partagé avec vous. Demandez à votre administrateur de vous autoriser à décrire les groupes de sécurité concernés VPC et réessayez. Pour un exemple de politique autorisant cette action, consultez Amazon EC2 : permet de gérer les groupes de EC2 sécurité associés à un groupe spécifiqueVPC, par programmation et dans la console.

Le cluster semble bloqué dans l'CREATINGétat

Parfois, la création de cluster peut prendre jusqu'à 30 minutes. Attendez 30 minutes et vérifiez à nouveau l'état du cluster.

L'état du cluster passe de CREATING à FAILED

Réessayez de créer le cluster.

État du cluster : les producteurs ACTIVE ne peuvent pas envoyer de données ou les consommateurs ne peuvent pas recevoir de données

AWS CLI ne reconnaît pas Amazon MSK

Si vous les avez AWS CLI installées, mais qu'elles ne reconnaissent pas MSK les commandes Amazon, passez AWS CLI à la dernière version. Pour obtenir des instructions détaillées sur la mise à niveau du AWS CLI, voir Installation du AWS Command Line Interface. Pour plus d'informations sur l'utilisation des MSK commandes AWS CLI pour exécuter Amazon, consultezAmazon MSK : comment ça marche.

Les partitions se déconnectent ou les réplicas sont désynchronisés

Ceux-ci peuvent être des symptômes de faible espace disque. Consultez L'espace disque est faible.

L'espace disque est faible

Consultez les bonnes pratiques suivantes pour gérer l'espace disque : Surveiller l'espace disque et Ajuster les paramètres de rétention des données.

Mémoire faible

Si vous voyez que la métrique MemoryUsed est élevée ou que la métrique MemoryFree est faible, cela ne signifie pas qu'il y a un problème. Apache Kafka est conçu pour utiliser autant de mémoire que possible, et il le gère de manière optimale.

Le producteur obtient NotLeaderForPartitionException

Il s'agit souvent d'une erreur transitoire. Définissez le paramètre de configuration retries du producteur sur une valeur supérieure à sa valeur actuelle.

Partitions sous-répliquées (URP) supérieures à zéro

La métrique UnderReplicatedPartitions est importante à surveiller. Dans un MSK cluster sain, cette métrique a la valeur 0. Si elle est supérieure à zéro, cela peut être pour l'une des raisons suivantes.

Le cluster contient des rubriques appelées __amazon_msk_canary et __amazon_msk_canary_state

Il se peut que votre MSK cluster possède un sujet portant le nom __amazon_msk_canary et un autre portant le même nom__amazon_msk_canary_state. Il s'agit de rubriques internes MSK créées et utilisées par Amazon pour les indicateurs de santé et de diagnostic du cluster. Ces rubriques sont d'une taille négligeable et ne peuvent pas être supprimées.

Échec de la réplication des partitions

Vérifiez que vous n'avez pas défini ACLs CLUSTER _ACTIONS.

Impossible d'accéder au cluster dont l'accès public est activé

Si l'accès public est activé sur votre cluster, mais que vous ne pouvez toujours pas y accéder depuis Internet, procédez comme suit :

Impossible d'accéder au cluster depuis l'intérieur AWS : problèmes de réseau

Si une application Apache Kafka ne parvient pas à communiquer correctement avec un MSK cluster, commencez par effectuer le test de connectivité suivant.

Si la machine cliente est en mesure d'accéder aux courtiers, cela signifie qu'il n'y a aucun problème de connectivité. Dans ce cas, exécutez la commande suivante pour vérifier si votre client Apache Kafka dispose de la configuration adéquate. Pour obtenir bootstrap-brokers, utilisez l'une des méthodes décrites dansTrouvez les courtiers Bootstrap pour un cluster Amazon MSK. Remplacez topic avec le nom de votre sujet.

<path-to-your-kafka-installation>/bin/kafka-console-producer.sh --broker-list bootstrap-brokers --producer.config client.properties --topic topic

Si la commande précédente réussit, cela signifie que votre client possède la bonne configuration. Si vous ne parvenez toujours pas à produire et à consommer à partir d'une application, déboguez le problème au niveau de cette dernière.

Si la machine cliente n'est pas en mesure d'accéder aux courtiers, consultez les sous-sections suivantes pour obtenir des instructions basées sur votre configuration client-machine.

EC2Client Amazon et MSK cluster dans le même environnement VPC

Si la machine cliente se trouve dans le même emplacement VPC que le MSK cluster, assurez-vous que le groupe de sécurité du cluster dispose d'une règle entrante qui accepte le trafic provenant du groupe de sécurité de la machine cliente. Pour plus d'informations sur la configuration de ces règles, consultez Règles des groupes de sécurité. Pour un exemple de la façon d'accéder à un cluster depuis une EC2 instance Amazon qui se trouve dans la même instance VPC que le cluster, consultezCommencez à utiliser Amazon MSK.

EC2Client Amazon et MSK cluster dans différents VPCs

Si la machine cliente et le cluster se trouvent dans deux emplacements différentsVPCs, assurez-vous de ce qui suit :

Pour plus d'informations sur l'VPCappairage, consultez la section Utilisation des connexions d'VPCappairage.

Client sur site

Dans le cas d'un client local configuré pour se connecter au MSK cluster en utilisant AWS VPN, assurez-vous de ce qui suit :

Pour plus d'informations sur le AWS VPN dépannage, consultez la section Résolution des problèmes liés au client VPN.

AWS Direct Connect

Si le client l'utilise AWS Direct Connect, consultez la section Résolution des problèmes AWS Direct Connect.

Si les instructions données dans la résolution de problèmes ne suffisent pas, vérifiez si un pare-feu ne bloque pas le trafic. Pour poursuivre le débogage, utilisez des outils tels que tcpdump et Wireshark pour analyser le trafic et vous assurer qu'il atteint le MSK cluster.

Échec de l'authentification : trop de connexions

L'Failed authentication ... Too many connectserreur indique qu'un courtier se protège parce qu'un ou plusieurs IAM clients essaient de s'y connecter à un rythme agressif. Pour aider les courtiers à accepter un taux plus élevé de nouvelles IAM connexions, vous pouvez augmenter le paramètre reconnect.backoff.msde configuration.

Pour en savoir plus sur les limites de taux applicables aux nouvelles connexions par agent, consultez la page MSKQuota Amazon.

MSKSans serveur : échec de la création du cluster

Si vous essayez de créer un cluster MSK sans serveur et que le flux de travail échoue, vous n'êtes peut-être pas autorisé à créer un VPC point de terminaison. Vérifiez que votre administrateur vous a autorisé à créer un VPC point de terminaison en autorisant l'ec2:CreateVpcEndpointaction.

Pour obtenir la liste complète des autorisations requises pour effectuer toutes les MSK actions Amazon, consultezAWS politique gérée : A mazonMSKFull Access.