Résoudre les problèmes liés aux arrêts et aux redémarrages de VM

---

Ce document décrit les causes les plus fréquentes d'arrêts et de redémarrages inattendus des instances de machine virtuelle (VM), et explique comment les éviter.

Les arrêts et redémarrages de VM peuvent être dus à des événements système ou à des activités d'administration. Les arrêts et les redémarrages des événements système sont générés par les systèmes Google ou le système d'exploitation de votre VM. Les arrêts et les redémarrages d'activités d'administration sont générés par un appel d'API généré par un utilisateur ou un compte de service. Tous les arrêts et les redémarrages sont consignés, à l'exception des redémarrages initiés à partir de la VM.

Avant de commencer

• Si ce n'est pas déjà fait, configurez l'authentification. L'authentification est le processus permettant de valider votre identité pour accéder aux services et aux API Google Cloud. Pour exécuter du code ou des exemples depuis un environnement de développement local, vous pouvez vous authentifier auprès de Compute Engine comme suit :
  

  Sélectionnez l'onglet correspondant à la façon dont vous prévoyez d'utiliser les exemples de cette page :

  Console

  Lorsque vous utilisez la console Google Cloud pour accéder aux services et aux API Google Cloud, vous n'avez pas besoin de configurer l'authentification.

  gcloud

  1. Installez Google Cloud CLI, puis initialisez-la en exécutant la commande suivante :

     gcloud init

     Remarque : Si vous avez déjà installé gcloud CLI, assurez-vous que vous disposez de la dernière version en exécutant gcloud components update.
  2. Définissez une région et une zone par défaut.

Diagnostiquer les arrêts et les redémarrages des VM

Pour diagnostiquer la cause de l'arrêt ou du redémarrage spontanés d'une VM, vous devez interroger les journaux de votre VM. Pour identifier rapidement la cause des futurs arrêts ou redémarrages de VM, créez un tableau de bord contenant les journaux. Après avoir interrogé les journaux, examinez les champs method et principalEmail pour déterminer quel événement et quel utilisateur ou service a déclenché l'arrêt ou le redémarrage.

Interroger les journaux d'audit Cloud

Interrogez les journaux d'audit Cloud pour afficher la liste des événements système et des activités d'administration qui ont pu entraîné l'arrêt ou le redémarrage.

Autorisations requises pour cette tâche

Pour effectuer cette tâche, vous devez disposer des autorisations suivantes :

• Les rôles Journalisation/Visionneuse de journaux ou Projet/Lecteur

Console

1. Dans la console Google Cloud, accédez à la page Explorateur de journaux.

   Accéder à l'explorateur de journaux

   Remarque : Vous devrez peut-être cliquer sur Mettre à niveau pour utiliser l'explorateur de journaux au lieu de l'ancienne visionneuse de journaux.

2. Dans le champ Requête, saisissez la requête suivante :

   resource.type="gce_instance"
   "VM_NAME"
   logName:("logs/cloudaudit.googleapis.com%2Fsystem_event" OR "logs/cloudaudit.googleapis.com%2Factivity")
   

   Remplacez VM_NAME par le nom de la VM qui s'est arrêtée ou a redémarré.

3. Si l'événement que vous recherchez s'est produit il y a plus d'une heure, définissez une période personnalisée en cliquant sur le symbole de l'horloge et en saisissant une plage personnalisée.

   

4. Cliquez sur Run query. Les résultats sont affichés dans la section Résultats de la requête.

   Conseil : Pour augmenter la taille de la section Résultats de la requête cliquez sur Saisir les résultats de la requête en plein écran.

5. Cliquez sur la flèche de développement à côté de chaque résultat pour afficher des informations détaillées.

6. Consultez la page Examiner les journaux d'audit Cloud pour en savoir plus sur les champs method et principalEmail associés aux arrêts et aux redémarrages, et découvrir comment y remédier.

gcloud

1. Affichez les journaux d'audit Cloud à l'aide de la commande gcloud logging read :

   gcloud logging read --freshness=TIME 'resource.type="gce_instance" "VM_NAME" logName:("logs/cloudaudit.googleapis.com%2Fsystem_event" OR "logs/cloudaudit.googleapis.com%2Factivity")'
   

   Remplacez les éléments suivants :

   • TIME : période que vous souhaitez interroger. Par exemple, 1h interroge les entrées du journal de la dernière heure. Pour en savoir plus sur les formats de date et d'heure, consultez Date et heure gcloud.
   • VM_NAME : nom de la VM qui s'est arrêtée ou a redémarré.

   Les résultats s'affichent.

2. Consultez la page Examiner les journaux d'audit Cloud pour en savoir plus sur les champs method et principalEmail associés aux arrêts et aux redémarrages, et découvrir comment y remédier.

Examiner les journaux d'audit Cloud

Consultez les champs method et principalEmail des journaux d'audit Cloud pour déterminer pourquoi votre VM s'est arrêtée ou a redémarré.

1. Consultez les champs method des journaux d'audit Cloud et comparez-les aux méthodes répertoriées dans le tableau suivant.

   Remarque : Si votre VM a redémarré et que vous ne trouvez pas de méthode comparable dans le tableau suivant de Cloud Audit Logs, le redémarrage est probablement dû au fait que le système d'exploitation de votre VM a lancé le redémarrage. Les causes des redémarrages sont souvent difficiles à identifier. Si vos VM connaissent un redémarrage régulier, envisagez d'obtenir de l'aide.

   Méthode	Type d'arrêt	Description
   compute.instances.repair.recreateInstance	Événement système	Si votre VM appartient à un groupe d'instances géré (MIG), celui-ci recrée la VM si la VM a quitté l'état RUNNING et que le MIG n'a pas initié ce changement d'état. Parmi les modifications de l'état d'une instance qui ne sont pas générées par le MIG, citons : les défaillances matérielles ; l'arrêt d'une instance préemptive ; les événements de maintenance de l'infrastructure dans le cas d'une instance de VM pour laquelle la migration à chaud n'est pas activée. Pour supprimer une instance MIG, utilisez l'une des méthodes suivantes : La méthode d'API instances.delete La commande gcloud compute instances delete Remarque : Pour vous assurer que vos modifications de configuration ne sont pas annulées par le MIG, il est important d'utiliser les méthodes du groupe. Par exemple, pour supprimer une instance gérée, utilisez l'une des méthodes suivantes : Pour un MIG géré zonal : instanceGroupManagers.deleteInstances Pour un MIG régional : regionInstanceGroupManagers.deleteInstances Dans gcloud : gcloud compute instance-groups managed delete-instances
   compute.instances.hostError	Événement système	Une erreur d'hôte (compute.instances.hostError) signifie qu'un problème matériel ou logiciel s'est produit sur la machine physique hébergeant votre VM, ce qui a entraîné le plantage de votre VM. Une erreur d'hôte qui implique une défaillance matérielle totale ou d'autres problèmes matériels peut empêcher la migration à chaud de votre VM. Si votre VM est configurée pour redémarrer automatiquement, ce qui est le paramètre par défaut, Google la redémarre, généralement dans les trois minutes suivant la détection de l'erreur. Selon le problème, le redémarrage peut prendre jusqu'à 5,5 minutes. VM dotées de disques SSD locaux Si une erreur d'hôte se produit sur une VM associée à un ou plusieurs disques SSD locaux, Compute Engine tente de se reconnecter à la VM et de préserver les données du disque SSD local. Lors de la restauration de votre VM et de votre disque SSD local par Compute Engine, le système hôte et le disque sous-jacent ne répondent pas. Vous pouvez spécifier le temps que Compute Engine passe à récupérer des données de disques SSD locaux en définissant le délai de récupération des disques SSD locaux. Pour en savoir plus sur le comportement des disques SSD locaux lorsqu'une erreur d'hôte se produit, consultez la section Persistance des données des disques SSD locaux. VM qui ne répondent pas Il peut arriver qu'une VM ne réponde plus avant qu'une erreur d'hôte ne soit détectée. Vous pouvez réduire le temps d'attente de Compute Engine avant le redémarrage ou l'arrêt de la VM en définissant le délai avant expiration de récupération d'erreur de l'hôte (bêta). Pour en savoir plus, consultez la section Définir des règles de disponibilité. Des pannes matérielles et logicielles peuvent se produire occasionnellement, mais sont rares. Pour protéger vos applications et vos services des événements système potentiellement perturbateurs, consultez les ressources suivantes : Concevoir des systèmes robustes Modèles d'applications évolutives et résilientes Créer des groupes d'instances gérés Google propose également des services gérés tels que App Engine et l'environnement flexible App Engine.
   compute.instances.automaticRestart	Événement système	Cet événement se produit après un événement hostError ou terminateOnHostMaintenance si la stratégie de maintenance de l'hôte automaticRestart de votre VM est définie sur true. Dans les journaux, une entrée de journal de type hostError ou terminateOnHostMaintenance précède ce journal. Si vous souhaitez modifier la stratégie de maintenance de l'hôte de votre VM, consultez la section Mettre à jour les options d'une instance.
   compute.instances.guestTerminate	Événement système	Le système d'exploitation de votre VM a déclenché l'arrêt.
   compute.instances.terminateOnHostMaintenance	Événement système	Si vous définissez la stratégie de maintenance de l'hôte onHostMaintenance de votre VM sur TERMINATE, Compute Engine arrête votre VM lors d'un événement de maintenance nécessitant que Google la déplace vers un autre hôte. Si vous souhaitez modifier la règle onHostMaintenance de votre VM, consultez la section Mettre à jour les options pour une instance.
   compute.instances.preempted	Événement système	Compute Engine a préempté votre VM Spot ou votre ancienne VM préemptive : Lorsque Compute Engine préempte une VM Spot, il l'arrête ou la supprime en fonction de son action d'arrêt. Les VM Spot n'ont pas d'environnement d'exécution maximal. Lorsque Compute Engine préempte une VM préemptive, il l'arrête après un délai d'exécution maximal de 24 heures. Pour éviter ces problèmes, utilisez plutôt des VM Spot. Les VM Spot et les VM préemptives représentent la capacité excédentaire de Compute Engine. Par conséquent, Compute Engine peut les préempter chaque fois que la capacité est requise ailleurs. Vous pouvez contribuer à limiter les effets de la préemption en suivant les bonnes pratiques. Si vous avez besoin de VM avec des environnements d'exécution contrôlés par l'utilisateur, vous pouvez également créer des VM standards.
   compute.instances.stop	Activité d'administration	Un utilisateur ou un compte de service a arrêté votre VM. Passez à l'étape suivante pour identifier l'utilisateur ou le compte de service qui a arrêté votre VM. Pour en savoir plus sur le redémarrage de votre VM, consultez la section Redémarrer une instance arrêtée.
   compute.instances.delete	Activité d'administration	Un utilisateur ou un compte de service a supprimé votre VM. Passez à l'étape suivante pour identifier l'utilisateur ou le compte de service qui a supprimé votre VM. Pour en savoir plus sur la création d'une VM, consultez la section Créer et démarrer une VM.
   compute.instances.insert	Activité d'administration	Un utilisateur ou un compte de service a créé votre VM. Passez à l'étape suivante pour identifier l'utilisateur ou le compte de service qui a créé votre VM. Pour en savoir plus sur la création d'une VM, consultez la section Créer et démarrer une VM.
   compute.instances.reset	Activité d'administration	Un utilisateur ou un compte de service a réinitialisé votre VM. Passez à l'étape suivante pour identifier l'utilisateur ou le compte de service qui a arrêté votre VM.

2. Examinez les champs principalEmail des journaux d'audit Cloud pour identifier l'utilisateur ou le service qui a lancé l'arrêt ou le redémarrage. Le tableau suivant présente les services gérés par Google fréquents qui lancent des arrêts ou des redémarrages.

   Adresse e-mail	Description
   [e-mail]	Un événement système est à l'origine de l'arrêt ou du redémarrage.
   [e-mail]	Un compte de service géré par Google est à l'origine de l'arrêt. Pour déterminer le projet à partir duquel le service a initié l'arrêt, consultez le fichier project-number du compte de service. Pour déterminer quel service Google a émis la requête, consultez le champ protoPayload.requestMetadata.callerSuppliedUserAgent.

   Si un utilisateur a déclenché l'arrêt ou le redémarrage, son adresse e-mail apparaît dans le champ principalEmail. Exemple :[e-mail]

   Les administrateurs peuvent empêcher les utilisateurs de modifier l'état des VM du projet en modifiant les autorisations Identity and Access Management sur les comptes d'utilisateur. Pour en savoir plus, consultez la page Accorder, modifier et révoquer les accès à des ressources.

Surveiller les événements de cycle de vie d'une VM

Vous pouvez surveiller les événements de cycle de vie des VM (y compris les arrêts, les redémarrages et les erreurs d'hôte) en créant un tableau de bord Cloud Monitoring.

Ce tableau de bord vous permet de visualiser les événements système et les activités d'administration décrits plus en détail dans la section Examiner les journaux d'audit du présent document.

Figure 1. Exemple de tableau de bord indiquant la disponibilité d'une instance et ses événements de cycle de vie, tels que les arrêts d'instance.

Remarque : Les journaux générés utilisés dans ce tableau de bord sont des métriques facturables.

Créer une métrique basée sur les journaux

Pour capturer des événements de cycle de vie de VM, créez une métrique basée sur les journaux définie par l'utilisateur. Cette métrique utilise les journaux d'audit pour comptabiliser le nombre d'occurrences d'un événement de cycle de vie de VM particulier.

Pour obtenir les autorisations nécessaires pour créer la métrique, demandez à votre administrateur de vous accorder le rôle IAM Rédacteur de journaux (roles/logging.logWriter) sur le projet. Pour en savoir plus sur l'attribution de rôles, consultez la section Gérer les accès.

Vous pouvez également obtenir les autorisations requises via des rôles personnalisés ou d'autres rôles prédéfinis.

Créez une métrique basée sur les journaux définie par l'utilisateur en procédant comme suit :

1. Dans la console Google Cloud, accédez à la page Métriques basées sur les journaux.

   Accéder aux métriques basées sur les journaux

2. Cliquez sur Créer une métrique.

Dans la section Type de métrique, procédez comme suit :

• Sélectionnez Counter.
• Laissez le champ Distribution défini sur le paramètre par défaut (non sélectionné).

Dans la section Détails, saisissez les informations suivantes :

• Nom de la métrique basée sur les journaux : vm-lifecycle-events. Vous devez utiliser ce nom exact pour que le tableau de bord fonctionne correctement.
• Description : facultatif) - saisissez une description de la métrique.
• Unités : 1

1. Dans la section Sélection de filtres, spécifiez les éléments suivants :

   • Dans le menu déroulant Sélectionner le champ d'application du journal, sélectionnez : Journaux de projet.
   • Dans le champ Construire un filtre, saisissez :

     resource.type = "gce_instance" AND
     log_id("cloudaudit.googleapis.com/activity") OR
     log_id("cloudaudit.googleapis.com/system_event")
     operation.first="true"

2. Dans la section Libellés, cliquez sur Ajouter un libellé.

3. Renseignez les champs suivants :

   • Nom du libellé : method
   • Type de libellé : STRING
   • Nom du champ : protoPayload.methodName
   • Expression régulière :

     (recreateInstance|hostError|automaticRestart|guestTerminate|terminateOnHostMaintenance|preempted|insert|stop|delete|reset|start)

4. Cliquez sur Terminé.

5. Cliquez sur Créer une métrique.

Utiliser le tableau de bord

Aucune donnée n'apparaît dans le tableau de bord tant qu'une VM ne rencontre pas d'événement système ni d'activité d'administration. Pour vérifier que le tableau de bord fonctionne, effectuez une activité d'administration, telle qu'une opération stop et start :

1. Effectuez une opération stop et start sur n'importe quelle VM existante, ou créez-en une à des fins de test.

Pour obtenir les autorisations nécessaires pour utiliser le tableau de bord, demandez à votre administrateur de vous accorder le rôle IAM Lecteur de tableau de bord Monitoring (roles/monitoring.dashboardViewer) sur le projet. Pour en savoir plus sur l'attribution de rôles, consultez la section Gérer les accès.

Vous pouvez également obtenir les autorisations requises via des rôles personnalisés ou d'autres rôles prédéfinis.

1. Ouvrez Tableaux de bord dans la console Google Cloud.

   Accéder à la page Tableaux de bord

2. Dans l'onglet Liste de tableaux de bord, ouvrez le tableau de bord GCE VM Lifecycle Events Monitoring.

3. Sélectionnez la VM dans le menu déroulant Nom.

4. Limitez la série temporelle à une période pertinente.

   Pour découvrir d'autres moyens de filtrer le tableau de bord, consultez la section Ajouter un filtre temporaire.

Le tableau de bord contient deux graphiques qui affichent une chronologie des événements système et des activités d'administration sur une VM :

1. Le graphique Chronologie de cycle de vie de la VM affiche les éléments suivants :

   • La métrique compute.googleapis.com/instance/uptime, qui indique si la VM était en cours d'exécution à un moment donné, 1 signifiant que la VM est opérationnelle et 0 qu'elle est indisponible. Notez que cette métrique reflète la disponibilité déduite de l'activité des utilisateurs et des événements système. Cette métrique n'a pas de validité au regard du Contrat de niveau de service de Compute Engine.
   • La métrique basée sur les journaux vm-lifecycle-events pour compter le nombre d'actions de cycle de vie, telles que stop ou start, effectuées sur la VM à un moment donné.

2. Le graphique "Événements" affiche la même métrique basée sur les journaux vm-lifecycle-events, mais dans une vue agrandie pour faciliter la lisibilité. Bien que les axes X soient alignés, les couleurs ne sont pas synchronisées entre les deux graphiques.

Enquêter sur l'arrêt massif de VM entre les projets

Compute Engine peut arrêter plusieurs VM connectées à un projet hôte de VPC partagé si la facturation de ce projet est inactive ou désactivée.

Pour déterminer si vos VM ont été arrêtées par une requête d'arrêt de masse, recherchez les opérations d'arrêt lancées par [e-mail].

Le démarrage d'une instance concernée renvoie une erreur semblable à celle-ci :

Starting instance(s) INSTANCE_NAME...failed.
ERROR: (gcloud.compute.instances.start) The default network interface [nic0] is frozen.

Pour résoudre ce problème, procédez comme suit :

1. Identifiez le VPC partagé utilisé par les VM à l'aide de la commande gcloud compute instances describe :

   gcloud compute instances describe VM_NAME \
      --format="flattened(networkInterfaces[].network)"
   

   Le résultat ressemble à ce qui suit :

   networkInterfaces[0].network: https://www.googleapis.com/compute/v1/projects/SHARED_VPC_PROJECT/global/networks/FROZEN_NETWORK
   

2. Vérifiez dans le projet hôte du VPC partagé si la facturation a été désactivée.

   resource.type="project"
   protoPayload.request.@type="type.googleapis.com/google.internal.cloudbilling.billingaccount.v1.DisableResourceBillingRequest"
   protoPayload.response.resourceBillingInfo.billingAccountAssignmentType="DISABLED"
   

3. Le cas échéant, activez la facturation sur le projet hôte.

Pour éviter que ce problème ne se reproduise, consultez la section Sécuriser l'association entre un projet et son compte de facturation.