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

La documentation suivante peut vous aider à résoudre les problèmes que vous pouvez rencontrer avec votre cluster Amazon MSK. Vous pouvez également publier votre problème sur AWS re:Post. Pour résoudre les problèmes liés à Amazon MSK Replicator, consultez. Ré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 and In-Sync 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 l'ISR avec les partitions rattrapées (et pas seulement les partitions principales en raison de prises distantesacks=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 Version de correction de bogues Amazon MSK 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 la version de correction de bogues Amazon MSK 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 de correction des bogues Amazon MSK 2.4.1.1 consistent soit à configurer les clients Kafka pour qu'ils utilisent Protocole d'appartenance statique, soit à les placer sur le nœud d'agent de coordination 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.

En cas d'InvalidInput.NumberOfCloudWatchResourcePoliciesLimitExceededexception, choisissez une politique Amazon CloudWatch Logs existante dans votre compte et ajoutez-y le code JSON suivant.

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

Si vous essayez d'ajouter le JSON ci-dessus à 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 d'ajouter le JSON à une autre de vos politiques Amazon CloudWatch Logs. Après avoir ajouté le 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 obtenez une erreur indiquant qu'il n'y a pas de groupe de sécurité par défaut, cela peut être dû au fait que vous utilisez un VPC partagé avec vous. Demandez à votre administrateur de vous accorder l'autorisation de décrire les groupes de sécurité sur ce 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 VPC spécifique, par programmation et dans la console.

Le cluster apparaît bloqué à l'état En cours de création.

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 En cours de création à En échec.

Réessayez de créer le cluster.

L'état du cluster est Actif mais les producteurs ne peuvent pas envoyer de données ou les consommateurs ne peuvent pas en recevoir.

AWS CLI ne reconnaît pas Amazon MSK

Si vous avez AWS CLI installé les commandes Amazon MSK, mais qu'elles ne les reconnaissent pas, passez AWS CLI à la dernière version. Pour obtenir des instructions détaillées sur la mise à niveau du AWS CLI, consultez la section Installation du AWS Command Line Interface. Pour plus d'informations sur l'utilisation des commandes AWS CLI pour exécuter Amazon MSK, consultezCaractéristiques et concepts clés d'Amazon MSK.

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 cluster MSK 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 cluster MSK possède une rubrique portant le nom __amazon_msk_canary et une autre portant le nom __amazon_msk_canary_state. Il s'agit de rubriques internes créées et utilisées par Amazon MSK pour les métriques d'intégrité 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

Assurez-vous que vous n'avez pas ACLs activé 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 vous disposez d'une application Apache Kafka qui ne parvient pas à communiquer avec un cluster MSK, 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 l'obtenirbootstrap-brokers, utilisez l'une des méthodes décrites dansObtenez les courtiers bootstrap pour un cluster Amazon MSK. Remplacez topic par 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.

EC2 Client Amazon et cluster MSK dans le même VPC

Si l'ordinateur client se trouve dans le même VPC que le cluster MSK, 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 l'ordinateur client. Pour plus d'informations sur la configuration de ces règles, consultez Règles des groupes de sécurité. Pour un exemple d'accès à un cluster depuis une EC2 instance Amazon située dans le même VPC que le cluster, consultez. Commencez à utiliser Amazon MSK

EC2 Client Amazon et cluster MSK dans des environnements différents VPCs

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

Pour de plus amples informations sur l'appairage de VPC, veuillez consulter Utilisation des connexions d'appairage de VPC.

Client sur site

Dans le cas d'un client sur site configuré pour se connecter au cluster MSK à l'aide de AWS VPN, assurez-vous de ce qui suit :

Pour plus d'informations sur la AWS VPN résolution des problèmes, consultez la section Résolution des problèmes liés au VPN du Client.

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 un débogage plus poussé, utilisez des outils comme tcpdump et Wireshark pour analyser le trafic et pour vous assurer qu'il atteint le cluster MSK.

Échec de l'authentification : trop de connexions

L'erreur Failed authentication ... Too many connects indique qu'un agent se protège parce qu'un ou plusieurs clients IAM tentent de s'y connecter à un rythme effréné. Pour aider les agents à accepter un taux plus élevé de nouvelles connexions IAM, vous pouvez augmenter le paramètre de configuration reconnect.backoff.ms.

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

Échec de l'authentification : session trop courte

L'Failed authentication ... Session too shorterreur se produit lorsque votre client essaie de se connecter à un cluster à l'aide d'informations d'identification IAM sur le point d'expirer. Assurez-vous de vérifier comment vos informations d'identification IAM sont actualisées. Il est fort probable que les informations d'identification soient remplacées trop près de l'expiration de la session, ce qui entraîne des problèmes côté serveur et des échecs d'authentification.

MSK sans 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 point de terminaison de VPC. Vérifiez que votre administrateur vous a autorisé à créer un point de terminaison de VPC en autorisant l'action ec2:CreateVpcEndpoint.

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