Comment savoir ce qui a arrêté mon instance AWS OpsWorks Stacks ?

Brève description

Il existe deux façons d'arrêter une instance OpsWorks Stacks :

• manuellement dans la console OpsWorks ou à l'aide de l'API OpsWorks Stacks.
• La fonction de réparation automatique OpsWorks Stacks.

Important : OpsWorks Stacks ne reconnaît pas les opérations de démarrage, d'arrêt ou de redémarrage effectuées dans la console Amazon EC2. Pour plus d'informations, voir Démarrage, arrêt et redémarrage manuels d'instances 24 heures sur 24, 7 jours sur 7.

Pour vérifier ce qui a arrêté votre instance OpsWorks Stacks, vous pouvez effectuer l'une des opérations suivantes :

Consulter votre AWS CloudTrail pour les appels d'API Amazon EC2 StopInstances et les appels d'API StopInstance OpsWorks Stacks simultanés

Si les deux appels d'API sont consignés sur la même période, l'instance a été arrêtée manuellement du côté d'OpsWorks Stacks. Si un appel d'API Amazon EC2 StopInstances est enregistré uniquement, la réparation automatique a été appliquée à l'instance.

Consulter les journaux de l'agent de votre instance pour voir si l'agent OpsWorks envoyait toujours son signal keepalive lorsque l'instance s'est arrêtée.

Si des signaux keepalive réussis sont consignés lorsque l'instance s'est arrêtée, l'instance a été arrêtée manuellement du côté d'OpsWorks Stacks. Si les journaux keepalive sont manquants ou si des tentatives de signal échouées sont consignées lorsque l'instance s'est arrêtée, la réparation automatique a été appliquée.

Si la réparation automatique a été appliquée à votre instance, consultez Comment empêcher AWS OpsWorks Stacks de redémarrer inopinément des instances saines ? Si votre instance a été arrêtée manuellement, vérifiez le rôle AWS Identity and Access Management (IAM) qui a effectué l'appel d'API StopInstance. Ensuite, déterminez qui a accès à ce rôle et découvrez pourquoi ils ont arrêté l'instance.

Résolution

Consulter les journaux CloudTrail de votre instance pour les appels d'API StopInstances Amazon EC2

1.    Ouvrez la console CloudTrail.

Important : assurez-vous que la région AWS sélectionnée est la même région que celle de votre instance.

2.    Dans le panneau de navigation de gauche, cliquez sur Historique des événements.

3.    Dans la partie supérieure gauche de la page Historique des événements, sélectionnez la liste déroulante des filtres. Ensuite, choisissez Nom de la ressource.

4.    Dans la zone de texte de recherche située à droite de la liste déroulante des filtres, saisissez votre ID d'instance Amazon EC2. Les résultats de tous les événements associés à l'instance s'affichent.

5.    Dans la colonne Nom de l'événement, recherchez StopInstances.

6.    Dans la colonne Heure de l'événement de la ligne d'événement StopInstances, notez l'horodatage de l'appel d'API. Vous vous réfèrerez à l'horodatage lorsque vous examinerez les journaux CloudTrail de votre instance pour les appels d'API StopInstance OpsWorks Stacks.

7.    Ouvrez l'enregistrement d'événement en choisissant le nom de l'événement (StopInstances) dans la colonne Nom de l'événement.

8.    Dans le volet Enregistrement d'événement, recherchez la valeur « InvokedBy ». Si l'instance a été arrêtée du côté d'OpsWorks Stacks (manuellement ou via la réparation automatique), la réponse de l'API Amazon EC2 StopInstances affiche le résultat suivant :

"invokedBy": "opsworks.amazonaws.com"

Remarque : il n'y a pas d'indicateur dans l'enregistrement d'événement si la réparation automatique a été appliquée à l'instance ou non.

Consulter les journaux CloudTrail de votre instance pour les appels d'API StopInstance OpsWorks Stacks

1.    Ouvrez la console CloudTrail.

Important : assurez-vous que la région AWS sélectionnée est la même que celle dans laquelle se trouve votre point de terminaison d'API OpsWorks Stacks.

2.    Dans le panneau de navigation de gauche, cliquez sur Historique des événements.

3.    Dans la partie supérieure gauche de la page Historique des événements, sélectionnez la liste déroulante des filtres. Ensuite, choisissez Nom de la ressource.

4.    Dans la zone de texte de recherche située à droite de la liste déroulante des filtres, saisissez votre ID d'instance OpsWorks Stacks. Les résultats de tous les événements associés à l'instance s'affichent.

5.    Dans la colonne Nom de l'événement, recherchez StopInstance.

6.    Dans la colonne Heure de l'événement de la ligne d'événement StopInstance, vérifiez si l'horodatage de l'événement est identique ou non à l'horodatage de l'événement StopInstances Amazon EC2.

Si l'appel d'API StopInstance est consigné en même temps que l'appel d'API StopInstances, l'instance a été arrêtée manuellement du côté d'OpsWorks Stacks.

Si aucun appel d'API StopInstance n'est enregistré en même temps que l'appel d'API StopInstances, la réparation automatique a été appliquée à l'instance.

(Facultatif) Consulter les journaux de l'agent de votre instance pour voir si l'agent OpsWorks envoyait toujours son signal keepalive lorsque l'instance s'est arrêtée

Connectez-vous à votre instance Linux à l'aide de SSH (Secure Shell) ou connectez-vous à votre instance Windows à l'aide du protocole RDP (Windows Remote Desktop Protocol). Ensuite, recherchez le fichier de journal opsworks-agent.keep_alive.log dans le journal de l'agent OpsWorks de l'instance.

Si des signaux keepalive réussis sont consignés lorsque l'instance s'est arrêtée, l'instance a été arrêtée manuellement du côté d'OpsWorks Stacks. Si les journaux keepalive sont manquants ou si des tentatives de signal échouées sont consignées lorsque l'instance s'est arrêtée, la réparation automatique a été appliquée.

Informations connexes

Comment configurer les notifications de réparation automatique AWS OpsWorks Stacks dans Amazon CloudWatch Events

Comment empêcher AWS OpsWorks Stacks de redémarrer inopinément les instances saines ?

Comment puis-je résoudre le messages d'erreur interne lors de l'arrêt d'une instance AWS OpsWorks Stacks dans l'état « stop_failed » ?

---