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 liés à Amazon MSK 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 des partitions provenant d'autres courtiers du cluster. Une fois les partitions répliquées et rattrapées, elles peuvent devenir membres du groupe Leadership et In-Sync Replica (ISR).

Problème

Dans un broker 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 est toujours en train de rattraper (répliquer) d'autres partitions. Ce trafic de réplication peut parfois saturer les limites de débit des volumes sous-jacents, 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 sont affectées, ce qui entraîne une latence sur le cluster pour tous les courtiers partageant l'ISR avec ces partitions interceptées (et pas seulement les partitions principales en raison des acks distantsacks=all). Ce problème est plus fréquent avec les clusters de grande taille 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û à un problème avec Apache Kafka KAFKA-9752, 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 des courtiers à 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 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 de 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 obtenir un exemple de stratégie autorisant cette action, consultez Amazon EC2 : Autorise la gestion des groupes de sécurité EC2 associés à un VPC spécifique, par programme 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 les commandes Amazon MSK sont AWS CLI installées, mais qu'elles ne les reconnaissent pas, mettez-les à niveau AWS CLI vers la dernière version. Pour obtenir des instructions détaillées sur la mise à niveau du AWS CLI, reportez-vous à la section Installation du AWS Command Line Interface. Pour plus d'informations sur l'utilisation des commandes Amazon MSK AWS CLI pour exécuter les commandes, consultezPrincipales fonctionnalités et concepts 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.

Under-replicated partitions (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 défini d'ACL sur 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 via le bootstrap IPv6

Si vous ne parvenez pas à vous connecter à un cluster à l'aide des chaînes d'amorçage IPv6 fournies, procédez comme suit :

Impossible d'accéder au cluster depuis l'intérieur AWS: Problèmes de mise en 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 peut 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 dansTrouvez les courtiers Bootstrap pour un cluster Amazon MSK. topicRemplacez-le par le titre 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 ne parvient pas à accéder aux courtiers, consultez les sous-sections suivantes pour obtenir des conseils basés sur la configuration de votre machine cliente.

Client Amazon EC2 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 obtenir un exemple de la façon d'accéder à un cluster à partir d'une instance Amazon EC2 située dans le même VPC que le cluster, consultez Commencez à utiliser Amazon MSK.

Client Amazon EC2 et cluster MSK dans différents VPC

Si l’ordinateur du client et le cluster se trouvent dans deux VPC différents, veillez à ce que :

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

On-premises client

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

Pour obtenir des conseils de Site-to-Site VPN dépannage supplémentaires, consultez la section Résolution des problèmes liés au VPN client.

Direct Connect

Si le client l'utilise Direct Connect, consultez la section Résolution des problèmes 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 tente 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 stratégie gérée : AmazonMSKFullAccess.

Impossible de mettre à jour KafkaVersionsList dans la configuration MSK

Lorsque vous mettez à jour la KafkaVersionsList propriété dans la ressource AWS : :MSK : :Configuration, la mise à jour échoue avec l'erreur suivante.

Resource of type 'AWS::MSK::Configuration' with identifier '<identifierName>' already exists.

Lorsque vous mettez à jour la KafkaVersionsList propriété, AWS CloudFormation recrée une nouvelle configuration avec la propriété mise à jour avant de supprimer l'ancienne configuration. La mise à jour de la CloudFormation pile échoue car la nouvelle configuration porte le même nom que la configuration existante. Une telle mise à jour nécessite le remplacement d'une ressource. Pour réussir la mise à jourKafkaVersionsList, vous devez également mettre à jour la propriété Name au cours de la même opération.

En outre, si votre configuration est associée à des clusters créés à l'aide du Console de gestion AWS ou AWS CLI, ajoutez ce qui suit à votre ressource de configuration pour éviter les tentatives de suppression de ressources infructueuses.

UpdateReplacePolicy: Retain

Une fois la mise à jour réussie, accédez à la console Amazon MSK et supprimez l'ancienne configuration. Pour de plus amples informations sur les configurations MSK, veuillez consulter Configuration provisionnée d'Amazon MSK.

Erreurs de configuration de noms de domaine personnalisés

Lorsque vous créez ou appliquez une configuration qui inclutcustom.advertised.listeners, vous pouvez rencontrer les erreurs suivantes. Pour plus d'informations sur la configuration de noms de domaine personnalisés, consultezConfigurer des noms de domaine personnalisés pour votre cluster Amazon MSK.

Format non valide

L'API renvoie une erreur HTTP 400 invalidParameter=serverproperties accompagnée du message suivant.

Invalid custom.advertised.listeners format. Expected: LISTENER_NAME://host:port+{broker_id} (comma-separated for multiple).

La valeur que vous avez fournie custom.advertised.listeners ne respecte pas le format requis. Corrigez-le pour qu'il utilise le modèleLISTENER_NAME://hostname:port+{broker_id}, assurez-vous que la variable de {broker_id} modèle apparaît dans le port afin que chaque courtier utilise une adresse unique, et séparez les différents auditeurs par une virgule. Soumettez ensuite à nouveau la configuration corrigée à l'aide UpdateClusterConfiguration de.

L'écouteur n'est pas lié au cluster

L'API renvoie une erreur HTTP 400 invalidParameter=configurationInfo accompagnée du message suivant.

Custom advertised listener(s) [CLIENT_SECURE] are not bound on this cluster. Valid client listeners: [CLIENT_IAM]. A broker cannot advertise a listener it does not bind.

L'écouteur que vous avez spécifié n'est pas actif sur votre cluster. Cette erreur se produit pendantUpdateClusterConfiguration, pas pendantCreateConfiguration. Un courtier ne peut faire de la publicité qu'à un auditeur qu'il lie réellement. Mettez à jour votre custom.advertised.listeners valeur pour faire référence à l'un des écouteurs clients valides que le message d'erreur répertorie pour votre cluster (par exemple,CLIENT_IAM). Si l'écouteur n'est pas encore activé sur le cluster (par exemple,CLIENT_SECURE), activez d'abord cette authentification ou ce type d'écouteur. Réappliquez ensuite la configuration à l'aide UpdateClusterConfiguration de.

Le processus de mise à jour échoue

Vérifiez votre custom.advertised.listeners valeur pour détecter des problèmes tels que des conflits de ports ou des noms d'hôte insolubles, corrigez la configuration et réappliquez-la à l'aide de. UpdateClusterConfiguration

Si l'échec est dû à une opération de dimensionnement, ajoutez l'écouteur Network Load Balancer, le groupe cible et l'enregistrement DNS correspondants pour tout nouveau broker. Vérifiez que tous les clients peuvent résoudre le nom de domaine personnalisé. Vous pouvez également revenir à la configuration de travail précédente en appliquant l'ancienne configuration.