Comment empêcher AWS OpsWorks Stacks de démarrer ou redémarrer de manière intempestive des instances saines ?

Date de la dernière mise à jour : 23/04/2019

AWS OpsWorks Stacks redémarre les instances qu'il estime non saines, même si les vérifications d’état d’Amazon Elastic Compute Cloud (Amazon EC2) aboutissent. Comment empêcher cette situation ?

Brève description

La réparation automatique redémarre les instances non saines ou défaillantes dans la pile, même si les vérifications d’état Amazon EC2 des instances aboutissent. La réparation automatique est activée par défaut dans les paramètres de couche de la pile. Les événements suivants se produisent pendant la réparation automatique :

  • L'agent OpsWorks Stacks envoie des signaux keepalive environ toutes les 30 secondes. Si le service ne reçoit pas de signaux keepalive au bout de cinq minutes, il considère que l’instance est défaillante. Si la réparation automatique est activée pour la couche d'une instance lancée par l’API AWS OpsWorks Stacks, cette dernière arrête et redémarre l'instance.
  • Si l'instance est basée sur Amazon Elastic Block Store (Amazon EBS), l'API AWS OpsWorks arrête et redémarre l'instance Amazon EC2 sous-jacente. S’il s’agit d’une instance basée sur le stockage d’instance, l'instance Amazon EC2 est arrêtée sur un arrêt d’instance. Ensuite, l'instance est recréée lorsque OpsWorks Stacks la redémarre. Pour plus d'informations, consultez Utilisation de la réparation automatique pour remplacer les instances défaillantes.
  • Si l'instance est lancée dans Amazon EC2 et enregistrée dans une pile OpsWorks, l'API AWS OpsWorks arrête et redémarre l'instance. Si les vérifications d’état AWS OpsWorks d’une instance locale enregistrée échouent, l'instance est marquée comme connexion perdue et n’est pas redémarrée. Pour plus d'informations, consultez Gestion des instances enregistrées.

Résolution

Rechercher les signes de réparation automatique dans la sortie des appels d'API StopInstances Amazon EC2

1.    Ouvrez la console AWS CloudTrail.

2.    Choisissez Event history (Historique des événements).

3.    Pour Filter (Filtre), choisissez Event name (Nom de l’événement). Pour plus d'informations, consultez la section Événements de filtrage CloudTrail.

4.    Dans la zone de recherche, choisissez StopInstances.

5.    Pour Filter (Filtre), choisissez Ressource name (Nom de la ressource).

6.    Dans la zone de recherche, saisissez l'ID de l'instance EC2, puis notez l'horodatage.

Si OpsWorks Stacks a arrêté l'instance, l'API StopInstances Amazon EC2 affiche la sortie suivante :

"invokedBy": "opsworks.amazonaws.com"

Rechercher les signes de réparation automatique dans la sortie des appels d'API StopInstances AWS OpsWorks

1.    Ouvrez la console CloudTrail.

2.    Choisissez Event history (Historique des événements).

3.    Pour Filter (Filtre), choisissez Event name (Nom de l’événement).

4.    Dans la zone de recherche, choisissez StopInstances.

5.    Pour Filter (Filtre), choisissez Ressource name (Nom de la ressource).

6.    Dans la zone de recherche, saisissez l’ID d’instance OpsWorks, puis notez l'horodatage.

7.    Recherchez l'appel d’API StopInstance au moment où l'instance a été arrêtée dans Amazon EC2, puis notez l'horodatage.

Remarque : si vous ne trouvez pas l'appel d'API, cela implique que la réparation automatique a été appliquée à l'instance.

Veuillez tenir compte des points suivants :

  • Configurez les instances gérées OpsWorks Stacks à l’aide de l’API AWS OpsWorks et non pas avec Amazon EC2.
  • Vérifiez que les instances gérées sont dans un état cohérent avec le service OpsWorks Stacks.
    Remarque : par exemple, si une instance est arrêtée dans Amazon EC2, l'instance est marquée comme défectueuse parce OpsWorks Stacks attend un signal de l’agent de l’instance. OpsWorks Stacks répare automatiquement l'instance (si elle est active), ce qui peut la bloquer, car le statut dans OpsWorks Stacks ne correspond pas à celui dans Amazon EC2. Dans ce cas, utilisez l'indicateur --force pour arrêter l'instance avec la commande stop-instance.

Créer une règle CloudWatch pour écouter les événements de réparation automatique dans votre pile

1.    (Facultatif) Pour recevoir des notifications lorsque la réparation automatique est appliquée à une instance, configurez des notifications.

2.    Créez la rubrique SNS OpsWorksAutoHealingNotifier, puis abonnez un point de terminaison à la rubrique (tel qu’une adresse e-mail ou un numéro de téléphone).

3.    Créez une règle d’événements CloudWatch, puis définissez la rubrique SNS comme cible.

4.    Dans les configurations de la règle, utilisez le modèle suivant pour configurer une règle CloudWatch pour écouter un événement de réparation automatique :

{
  "source": [
    "aws.opsworks"
  ],
  "detail": {
    "initiated_by": [
      "auto-healing"
    ]
  }
}

5.    Pour enregistrer les configurations, choisissez Create rule (Créer une règle).

Résoudre les problèmes en utilisant les fichiers journaux de l'instance

1.    Pour afficher les fichiers journaux qui se trouvent dans /var/log/aws/opsworks pour Linux, connectez-vous à l’instance en utilisant SSH. Pour afficher les fichiers journaux qui se trouvent dans C:\ProgramDataOpsWorksAgent\var\logs pour Windows, connectez-vous à l’instance en utilisant RDP.

2.    Résolvez les problèmes en utilisant les fichiers journaux suivants :
Dans le journal opsworks-agent.keep_alive.log, recherchez les tentatives réussies et infructueuses d’envoi par l’agent de signaux keepalive à OpsWorks. Pour plus d'informations, consultez Exécution d’une pile dans un cloud VPC.
Vérifiez le journal opsworks-agent.statistics.log pour déterminer comment le système gère la charge du processeur et la mémoire. Vous pouvez examiner la quantité de mémoire utilisée et déterminer si les valeurs des métriques du processeur et de charge sont élevées.
Dans le journal opsworks-agent.log, recherchez les rapports relatifs à l’état général de l’agent exécuté sur l’instance, y compris lorsque l’agent était arrêté ou redémarré.
Dans le journalopsworks-agent.process_command.log, recherchez les rapports sur les commandes de l’agent qui ont abouti et échoué sur les instances.

Remarque : ces fichiers journaux sont conservés uniquement si le périphérique racine de l'instance est basée sur Amazon EBS. Les instances basées sur le stockage d'instance sont arrêtées par un appel d’API StopInstance dans OpsWorks, ce qui entraîne la perte des journaux.

3.    Vérifiez les journaux système pour déterminer l'état général de l'instance lorsque la réparation automatique est appliquée.

Remarque : il peut arriver que les journaux omettent des informations système (par exemple, des erreurs de mémoire insuffisante) si l'agent est affecté par des problèmes causés par un événement de réparation automatique.

Empêcher OpsWorks Stacks de réparer automatiquement les instances qu'il gère

  • Vérifiez que les instances ont accès à Internet avec une passerelle Internet ou une NAT sur les tables de routage VPC.
  • Déverrouillez le port 443 au niveau de l’instance, du groupe de sécurité VPC et de la liste LCA VPC.
    Remarque : les modifications apportées à un cloud VPC ou à un VPC créé de façon incorrecte peuvent empêcher une instance de communiquer avec OpsWorks Stacks sur Internet.
  • Vérifiez que votre application dispose de suffisamment de ressources (par exemple, mémoire et processeur) au niveau de l'instance pour pouvoir fonctionner lorsque cette dernière est surchargée.
    Remarque : il est judicieux de se préparer à faire face à une charge supplémentaire. Par exemple, un événement de cycle de vie peut placer une charge imprévue sur l'instance.
  • Utilisez les métriques et alarmes CloudWatch pour être averti que l’instance a une charge processeur, mémoire ou de trafic réseau élevée.
    Si la réparation automatique ne fonctionne pas pour votre application, désactivez-la dans vos configurations de couche.

Cette page vous a-t-elle été utile ?

Cette page peut-elle être améliorée ?


Vous avez besoin d'aide ?