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 :

    Select the tab for how you plan to use the samples on this page:

    Console

    When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

    gcloud

    1. Install the Google Cloud CLI, then initialize it by running the following command: 

      gcloud init
    2. Set a default region and zone.

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.

Console

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

    Accéder à l'explorateur 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.

    Définissez la période de la requête.

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

  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.

    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 :
    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 :

    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.

    E-mail Description
    system@google.com Un événement système est à l'origine de l'arrêt ou du redémarrage.
    project-number@cloudservices.gserviceaccount.com

    Un agent de service a lancé l'arrêt.

    Pour déterminer le projet à partir duquel le service a initié l'arrêt, consultez le fichier project-number de l'agent 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 :cloudysanfrancisco@gmail.com

    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.

Tableau de bord "Cycle de vie d'une VM" : événements d'arrêt et de démarrage 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.

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 page Gérer l'accès aux projets, aux dossiers et aux organisations.

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 Sélectionner un projet ou un bucket de journaux, 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 page Gérer l'accès aux projets, aux dossiers et aux organisations.

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 cloud-cluster-manager@prod.google.com.

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.