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 en sélectionnant l'une des options suivantes:

    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 Google Cloud Console, 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 ou l'infrastructure du centre de données hébergeant votre instance de calcul, ce qui a entraîné le plantage de votre instance. Une erreur d'hôte impliquant une défaillance matérielle totale ou d'autres problèmes matériels peut empêcher la migration à chaud de votre instance. Si votre instance est configurée pour redémarrer automatiquement, ce qui est le paramètre par défaut, Compute Engine 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.

    Il peut arriver qu'une instance de calcul ne réponde plus avant qu'une erreur d'hôte ne soit signalée. Vous pouvez réduire le temps d'attente de Compute Engine avant le redémarrage ou l'arrêt de l'instance 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émarrageFigure 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.

Examiner les problèmes d'arrêt de VM avec gcpdiag

gcpdiag est un outil Open Source. Il ne s'agit pas d'un produit Google Cloud faisant l'objet d'une assistance officielle. Vous pouvez utiliser l'outil gcpdiag pour vous aider à identifier et à résoudre les problèmes liés au projet Google Cloud. Pour plus d'informations, consultez le projet gcpdiag sur GitHub.

Ce runbook gcpdiag examine les problèmes d'arrêt des VM, en examinant les domaines suivants :
  • Arrêts et redémarrages déclenchés par des événements système:identifie les arrêts déclenchés par les systèmes Google Cloud internes en raison d'événements de maintenance système, de pannes matérielles normales ou de contraintes de ressources.
  • Arrêts/redémarrages déclenchés par des activités d'administration système:analyse les arrêts dus à des actions directes, telles que des appels d'API effectués par des utilisateurs ou des comptes de service. Ces actions peuvent inclure des arrêts ou des redémarrages manuels, ou des processus automatisés affectant les états des VM.
  • Génération de texte non officielle sur l'analyse des causes:fournit un texte détaillé sur l'analyse des causes, décrivant la cause identifiée de l'arrêt, les systèmes ou activités concernés, et les recommandations pour éviter que cela ne se reproduise, le cas échéant.

console Google Cloud

  1. Terminez l'exécution, puis copiez la commande suivante. 
    2. gcpdiag runbook gce/vm-termination \
    --parameter project_id=PROJECT_ID \
    --parameter name=VM_NAME \
    --parameter zone=ZONE
  2. Ouvrez la console Google Cloud et activez Cloud Shell.
    3. Ouvrir la console Cloud
  3. Collez la commande copiée.
  4. Exécutez la commande gcpdiag, qui télécharge l'image Docker gcpdiag, puis effectue des vérifications de diagnostic. Le cas échéant, suivez les instructions de sortie pour corriger les échecs de vérification.

Docker

Vous pouvez exécuter gcpdiag à l'aide d'un wrapper qui démarre gcpdiag dans un conteneur Docker. Docker ou Podman doivent être installés.

  1. Copiez et exécutez la commande suivante sur votre station de travail locale : 
    curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
  2. Exécutez la commande gcpdiag. 
    ./gcpdiag runbook gce/vm-termination \
    --parameter project_id=PROJECT_ID \
    --parameter name=VM_NAME \
    --parameter zone=ZONE

Affichez les paramètres disponibles pour ce runbook.

Remplacez les éléments suivants :

  • PROJECT_ID: ID du projet contenant la ressource
  • VM_NAME : nom de la VM cible au sein de votre projet.
  • ZONE: zone dans laquelle se trouve votre VM cible.

Options utiles :

Pour obtenir la liste et la description de toutes les options de l'outil gcpdiag, consultez les instructions d'utilisation de gcpdiag.