Pourquoi mon cluster Amazon MSK passe à l'état HEALING ?

Lecture de 4 minute(s)
0

Je souhaite dépanner mon cluster Amazon Managed Streaming pour Apache Kafka (Amazon MSK) qui est en état de HEALING.

Résolution

Votre cluster Amazon MSK passe à l'état HEALING lorsque le service exécute une opération interne visant à résoudre un problème (exemple : les courtiers ne répondent pas). Vous pouvez toutefois utiliser le cluster pour produire et consommer des données. Vous ne pouvez pas effectuer d'opérations de mise à jour de l'API Amazon MSK ou de l'interface de la ligne de commande AWS (AWS CLI) sur le cluster tant que celui-ci n'est pas redevenu ACTIF.

Utilisez les métriques Amazon CloudWatch pour Amazon MSK afin de comprendre pourquoi le cluster est en état de guérison :

  1. Ouvrez la console CloudWatch.
  2. Dans le volet de navigation, choisissez Métriques, puis sélectionnez Toutes les métriques.
  3. Dans l'onglet Parcourir, choisissez AWS/Kafka.
  4. Sous Métriques, choisissez le nom du cluster.
  5. Sélectionnez le cluster que vous souhaitez surveiller.
    Si vous constatez des pics dans la métrique ActiveControllerCount ou OfflinePartitionsCount, cela indique qu'un ou plusieurs courtiers ne sont pas sains. Cela a peut-être amené votre cluster à passer à l'état HEALING.
  6. Pour les métriques au niveau du courtier, choisissez ID du courtier, nom du cluster sous Métriques.
  7. Dans la liste, sélectionnez les entrées avec le nom du cluster et les métriques CpuUser et CpuSystem. Vérifiez si la somme de ces deux valeurs pour toutes les entrées atteint une moyenne supérieure à 60 % pour le cluster. Si tel est le cas, une utilisation élevée du processeur peut avoir amené le broker à passer à l'état HEALING. Pour plus d'informations sur la surveillance de l'utilisation du processeur, consultez la section Meilleures pratiques : Surveiller l'utilisation du processeur.

Les raisons les plus courantes pour lesquelles un cluster Amazon MSK passe à l'état HEALING sont les suivantes :

  • Un nœud ou un volume Amazon Elastic Block Store (Amazon EBS) doit être remplacé en raison d'une panne matérielle.
  • Un nœud ne répond pas au SLA de performance Amazon MSK pour le courtier, et le nœud doit être remplacé pour des performances optimales.

Notez qu'Amazon MSK est un service entièrement géré. Par conséquent, les courtiers disposent de flux de travail autogérés qui exécutent eux-mêmes des actions correctives, telles que le remplacement de nœuds en cas de défaillance. Lorsqu'un volume Amazon EBS chez un courtier devient défectueux, Amazon MSK observe l'état du volume pendant un certain temps. Si le volume devient sain pendant ce temps, aucune action n'est effectuée. Si le volume ne fonctionne toujours pas correctement après cette période, Amazon MSK le remplace automatiquement. Le cluster passe à l'état HEALING lorsqu'Amazon MSK exécute ces actions. Toutefois, cela n'affecte pas la disponibilité du cluster Amazon MSK tant que vous suivez les meilleures pratiques. Même lorsque le courtier est en état HEALING, le cluster peut traiter les demandes des producteurs et des consommateurs.

Dans de rares cas, votre cluster peut entrer dans un état HEALING perpétuel. Cela peut être dû aux raisons suivantes :

  • La charge de travail sur le cluster est élevée et les courtiers sont constamment remplacés. Pour éviter ce problème, il est recommandé de ne pas utiliser les instances t3.small pour héberger des clusters de production. Si vous utilisez des instances m5, assurez-vous de choisir la bonne taille pour votre cluster. Vous pouvez déterminer la taille de votre cluster en fonction de votre charge de travail et en surveillant l'utilisation de votre processeur. Assurez-vous également que le nombre de partitions par courtier ne dépasse pas la valeur recommandée.
  • Le groupe Auto Scaling n'est pas en mesure de créer une nouvelle instance. Cela peut être dû à un problème interne ou à l'absence d'une dépendance. Par exemple, la clé AWS Key Management Service (AWS KMS) spécifiée lors de la création du cluster peut ne plus être accessible.
  • Un événement interne rare a eu une incidence sur la disponibilité des instances Amazon Elastic Compute Cloud (Amazon EC2) sous-jacentes ou a provoqué une latence Amazon EBS dans une zone de disponibilité ou une région AWS.

Si votre cluster reste dans un état HEALING perpétuel qui n'est pas dû à la charge, contactez AWS Support.

Informations connexes

États du cluster

AWS OFFICIEL
AWS OFFICIELA mis à jour il y a un an