Fehlerbehebung beim Herunterfahren und Neustarten von VMs

In diesem Dokument werden die häufigsten Gründe für unerwartete Shutdowns und Neustarts von VM-Instanzen beschrieben und wie Sie diese verhindern.

Das Herunterfahren oder Neustarten von VMs kann durch Systemereignisse oder Administratoraktivitäten verursacht werden. Shutdown- und Neustarts von Systemereignissen werden von Google-Systemen oder dem Betriebssystem Ihrer VM generiert. Das Herunterfahren und Neustarten von Administratoraktivitäten werden durch einen vom Nutzer oder Dienstkonto generierten API-Aufruf generiert. Alle Shutdown- und Neustarts werden protokolliert, mit Ausnahme der Neustarts, die innerhalb der VM initiiert werden.

Hinweise

  • Richten Sie die Authentifizierung ein, falls Sie dies noch nicht getan haben. Bei der Authentifizierung wird Ihre Identität für den Zugriff auf Google Cloud-Dienste und APIs überprüft. Zur Ausführung von Code oder Beispielen aus einer lokalen Entwicklungsumgebung können Sie sich bei Compute Engine authentifizieren. Wählen Sie dazu eine der folgenden Optionen aus:

    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.

Shutdown- und Neustarts von VMs diagnostizieren

Sie können die Logs einer VM abfragen, um die Ursache für das Herunterfahren oder Neustarten einer VM zu ermitteln. Damit Sie in Zukunft schnell die Ursache für Shutdowns oder Neustarts von VMs finden können, erstellen Sie ein Dashboard, das die Logs enthält. Prüfen Sie nach dem Abfragen der Logging-Protokolle die Felder method und principalEmail, um festzustellen, welches Ereignis und welcher Nutzer oder Dienst das Herunterfahren oder den Neustart ausgelöst hat.

Cloud-Audit-Logs abfragen

Fragen Sie Cloud-Audit-Logs ab, um eine Liste der Systemereignisse und Administratoraktivitäten anzeigen zu lassen, die zu einem Herunterfahren oder Neustart geführt haben.

Console

  1. Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf.

    Zum Log-Explorer

  2. Geben Sie im Feld Query die folgende Abfrage ein:

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

    Ersetzen Sie VM_NAME durch den Namen der VM, die heruntergefahren oder neu gestartet wird.

  3. Wenn das gewünschte Ereignis vor mehr als einer Stunde aufgetreten ist, legen Sie einen benutzerdefinierten Zeitraum fest. Klicken Sie dazu auf das Uhrsymbol und geben Sie einen benutzerdefinierten Bereich ein.

    Abfragezeitraum festlegen.

  4. Klicken Sie auf Abfrage ausführen. Die Ergebnisse werden im Abschnitt Abfrageergebnisse angezeigt.

  5. Klicken Sie auf den Erweiterungspfeil neben jedem Ergebnis, um detaillierte Informationen aufzurufen.

  6. Unter Cloud-Audit-Logs überprüfen erfahren Sie mehr über die Felder method und principalEmail, die ein Herunterfahren und Neustarten verursachen, und wie Sie sie verhindern können.

gcloud

  1. Sehen Sie sich Cloud-Audit-Logs mit dem Befehl gcloud logging read an:

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

    Dabei gilt:

    • TIME: die Zeitspanne, die Sie abfragen möchten. Zum Beispiel fragt 1h Logeinträge aus der letzten Stunde ab. Weitere Informationen zu Datums- und Uhrzeitformaten finden Sie unter gcloud topic datetimes.
    • VM_NAME: der Name der VM, die heruntergefahren oder neu gestartet wird.

    Die Ergebnisanzeige.

  2. Unter Cloud-Audit-Logs überprüfen erfahren Sie mehr über die Felder method und principalEmail, die ein Herunterfahren und Neustarten verursachen, und wie Sie sie verhindern können.

Cloud-Audit-Logs prüfen

Prüfen Sie die Felder method und principalEmail der Cloud-Audit-Logs, um festzustellen, warum Ihre VM heruntergefahren oder neu gestartet wurde.

  1. Überprüfen Sie die method-Felder der Cloud-Audit-Logs und vergleichen Sie sie mit den in der folgenden Tabelle aufgeführten Methoden.

    Methode Shutdown-Typ Beschreibung
    compute.instances.repair.recreateInstance Systemereignis

    Wenn Ihre VM zu einer verwalteten Instanzgruppe gehört, erstellt die MIG die VM neu, wenn sich der Status der VM von RUNNING ändert und die MIG den Änderungsstatus nicht initiiert hat.

    Zu den Änderungen des Instanzstatus, die nicht von der MIG initiiert werden, gehören:
    compute.instances.hostError Systemereignis

    Ein Hostfehler (compute.instances.hostError) bedeutet, dass auf der physischen Maschine oder der Rechenzentrumsinfrastruktur, die Ihre Compute-Instanz hostet, ein Problem mit der Hardware oder Software aufgetreten ist, das zum Absturz der Instanz geführt hat. Ein Hostfehler, der einen völligen Hardwareausfall oder andere Hardwareprobleme nach sich zieht, kann eine Live-Migration Ihrer Instanz verhindern. Wenn Ihre Instanz so eingestellt ist, dass sie automatisch neu startet (dies ist die Standardeinstellung), startet die Compute Engine Ihre Instanz in der Regel innerhalb von drei Minuten ab dem Fehler. Je nach Problem kann der Neustart bis zu 5,5 Minuten dauern.

    Gelegentlich reagiert eine Compute-Instanz möglicherweise nicht mehr, bevor ein Hostfehler gemeldet wird. Sie können die Zeit verkürzen, die Compute Engine auf den Neustart oder die Beendigung der Instanz wartet. Legen Sie dazu das Zeitlimit für die Fehlerbehebung des Hosts fest (Vorabversion). Weitere Informationen finden Sie unter Verfügbarkeitsrichtlinien festlegen.

    Physische Hardware- und Softwarefehler können von Zeit zu Zeit auftreten, sind jedoch eher selten. Um Ihre Anwendungen und Dienste solchen potenziell störenden Systemereignissen zu schützen, sollten Sie folgende Ressourcen prüfen:

    Google bietet auch verwaltete Dienste wie App Engine und die flexible App Engine-Umgebung.
    compute.instances.automaticRestart Systemereignis

    Dieses Ereignis tritt nach einem hostError- oder terminateOnHostMaintenance-Ereignis auf, wenn die automaticRestart-Hostwartungsrichtlinie Ihrer VM auf true festgelegt ist. In den Logs steht vor diesem Log ein hostError- oder terminateOnHostMaintenance-Logeintrag.

    Informationen zum Ändern der Hostwartungsrichtlinie Ihrer VM finden Sie unter Aktualisierungsoptionen für eine Instanz.

    compute.instances.guestTerminate Systemereignis Das Betriebssystem Ihrer VM hat die Shutdown-Funktion gestartet.
    compute.instances.terminateOnHostMaintenance Systemereignis

    Wenn Sie die onHostMaintenance-Wartungsrichtlinie Ihrer VM auf TERMINATE setzen, beendet Compute Engine die VM, wenn ein Wartungsereignis vorliegt, bei dem Google die VM auf einen anderen Host verschieben muss.

    Wenn Sie die Richtlinie onHostMaintenance Ihrer VM ändern möchten, finden Sie weitere Informationen unter Aktualisierungsoptionen für eine Instanz.
    compute.instances.preempted Systemereignis

    Ihre Spot-VM oder die Legacy-VM auf Abruf wurde von Compute Engine vorzeitig beendet:

    • Wenn Compute Engine eine Spot-VM vorzeitig beendet, wird die Spot-VM entsprechend ihrer Beendigungsaktion von Compute Engine beendet oder gelöscht. Spot-VMs haben keine maximale Laufzeit.
    • Wenn Compute Engine eine VM auf Abruf vorzeitig beendet, wird sie nach einer maximalen Laufzeit von 24 Stunden beendet. Verwenden Sie stattdessen Spot-VMs, um diese Einschränkungen zu vermeiden.

    Spot-VMs und VMs auf Abruf sind überschüssige Compute Engine-Kapazitäten. Daher kann Compute Engine sie vorzeitig beenden, wenn die Kapazität an anderer Stelle benötigt wird. Sie können die Auswirkungen des vorzeitigen Beendens mindern, indem Sie die Best Practices befolgen. Wenn Sie hingegen VMs mit nutzergesteuerten Laufzeiten benötigen, erstellen Sie stattdessen Standard-VMs.
    compute.instances.stop Administratoraktivität

    Die VM wurde von einem Nutzer oder Dienstkonto beendet.

    Fahren Sie mit dem nächsten Schritt fort, um den Nutzer oder das Dienstkonto zu identifizieren, das die VM beendet hat. Weitere Informationen zum Neustarten der VM finden Sie unter Angehaltene Instanz neu starten.
    compute.instances.delete Administratoraktivität

    Die VM wurde von einem Nutzer oder Dienstkonto beendet.

    Fahren Sie mit dem nächsten Schritt fort, um den Nutzer oder das Dienstkonto zu identifizieren, das Ihre VM gelöscht hat. Informationen zum Erstellen einer neuen VM finden Sie unter VM erstellen und starten.
    compute.instances.insert Administratoraktivität

    Ihre VM wurde von einem Nutzer oder Dienstkonto erstellt.

    Fahren Sie mit dem nächsten Schritt fort, um den Nutzer oder das Dienstkonto zu identifizieren, der/das Ihre VM erstellt hat. Informationen zum Erstellen einer neuen VM finden Sie unter VM erstellen und starten.
    compute.instances.reset Administratoraktivität

    Ein Nutzer oder ein Dienstkonto setzt Ihre VM zurück.

    Fahren Sie mit dem nächsten Schritt fort, um den Nutzer oder das Dienstkonto zu identifizieren, das die VM beendet hat.

  2. Überprüfen Sie die principalEmail-Felder der Cloud-Audit-Logs, um den Nutzer oder Dienst zu identifizieren, der das Herunterfahren oder den Neustart initiiert hat. Die folgende Tabelle enthält gängige von Google verwaltete Dienste, die das Herunterfahren oder Neustarten der Instanzen auslösen.

    E-Mail Beschreibung
    system@google.com Ein Systemereignis hat das Herunterfahren oder den Neustart verursacht.
    project-number@cloudservices.gserviceaccount.com

    Ein Dienst-Agent hat das Herunterfahren eingeleitet.

    Sehen Sie sich die project-number des Dienst-Agents an, um festzustellen, über welches Projekt der Dienst gestartet wurde.

    Sehen Sie sich das Feld protoPayload.requestMetadata.callerSuppliedUserAgent an, um festzustellen, welcher Google-Dienst die Anfrage gesendet hat.

    Wenn ein Nutzer das Herunterfahren oder einen Neustart ausgelöst hat, wird seine E-Mail-Adresse im Feld principalEmail angezeigt. Beispiel: cloudysanfrancisco@gmail.com.

    Administratoren können Nutzer daran hindern, den Status von Projekt-VMs zu ändern, indem sie die Berechtigungen der Identitäts- und Zugriffsverwaltung für Nutzerkonten ändern. Weitere Informationen finden Sie unter Zugriff auf Ressourcen erteilen, ändern und entziehen.

VM-Lifecycle-Events überwachen

Sie können VM-Lifecycle-Events (einschließlich Herunterfahren, Neustarts und Hostfehler) überwachen, indem Sie ein Cloud Monitoring-Dashboard erstellen.

Auf diesem Dashboard können Sie Systemereignisse und Administratoraktivitäten visualisieren, die im Abschnitt Audit-Logs prüfen dieses Dokuments ausführlicher beschrieben werden.

VM Lifecycle Dashboard: Stopp- und StartereignisseAbbildung 1. Ein Beispieldashboard, das die Verfügbarkeit einer Instanz und ihre Lifecycle-Events zeigt, z. B. eine beendete Instanz.

Logbasierten Messwert erstellen

Erstellen Sie einen benutzerdefinierten logbasierten Messwert, um VM-Lifecycle-Events zu erfassen. Bei diesem Messwert werden Audit-Logs verwendet, um zu erfassen, wie oft ein bestimmtes VM-Lifecycle-Event aufgetreten ist.

Bitten Sie Ihren Administrator, Ihnen die IAM-Rolle Logs Writer (roles/logging.logWriter) für das Projekt zu erteilen, um die Berechtigungen zu erhalten, die Sie zum Erstellen des Messwerts benötigen. Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

So erstellen Sie einen benutzerdefinierten logbasierten Messwert:

  1. Rufen Sie in der Google Cloud Console die Seite Logbasierte Messwerte auf.

    Zu „Logbasierte Messwerte”

  2. Klicken Sie auf Messwert erstellen.

Führen Sie im Abschnitt Messwerttyp folgende Schritte aus:

  • Wählen Sie Counter aus.
  • Behalten Sie für Verteilung die Standardeinstellung bei.

Geben Sie im Abschnitt Details Folgendes ein:

  • Name des logbasierten Messwerts: vm-lifecycle-events. Sie müssen genau diesen Namen verwenden, damit das Dashboard ordnungsgemäß funktioniert.
  • Beschreibung: Optional – Geben Sie eine Beschreibung für diesen Messwert ein.
  • Einheiten: 1

  1. Geben Sie im Bereich Filterauswahl Folgendes an:

    • Wählen Sie im Menü Projekt oder Log-Bucket auswählen die Option „Projektlogs“ aus.
    • Geben Sie unter Filter erstellen Folgendes ein:
      resource.type = "gce_instance" AND
log_id("cloudaudit.googleapis.com/activity") OR
log_id("cloudaudit.googleapis.com/system_event")
operation.first="true"

  2. Klicken Sie im Bereich Labels auf Label hinzufügen.

  3. Geben Sie Folgendes an:

    • Labelname: method
    • Labeltyp: STRING
    • Feldname: protoPayload.methodName
    • Regulärer Ausdruck: 
      (recreateInstance|hostError|automaticRestart|guestTerminate|terminateOnHostMaintenance|preempted|insert|stop|delete|reset|start)

  4. Klicken Sie auf Fertig.

  5. Klicken Sie auf Messwert erstellen.

Dashboard verwenden

Auf dem Dashboard werden erst dann Daten angezeigt, wenn auf einer VM ein Systemereignis oder eine Administratoraktivität auftritt. Wenn Sie testen möchten, ob das Dashboard funktioniert, führen Sie eine Administratoraktivität aus, z. B. einen stop- und einen start-Vorgang:

  1. Führen Sie einen stop- und start-Vorgang auf einer vorhandenen VM aus oder erstellen Sie eine neue VM zu Testzwecken.

Bitten Sie Ihren Administrator, Ihnen die IAM-Rolle Monitoring Dashboard Viewer (roles/monitoring.dashboardViewer) für das Projekt zu erteilen, um die für die Nutzung des Dashboards erforderlichen Berechtigungen zu erhalten. Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

  1. Öffnen Sie in der Google Cloud Console Dashboards.

    Dashboards aufrufen

  2. Öffnen Sie auf dem Tab Dashboard-Liste das Dashboard GCE VM Lifecycle Events Monitoring.

  3. Wählen Sie die VM im Drop-down-Menü Name aus.

  4. Begrenzen Sie die Zeitreihe auf einen relevanten Zeitraum.

    Weitere Möglichkeiten zum Filtern des Dashboards finden Sie unter Temporären Filter hinzufügen.

Das Dashboard enthält zwei Diagramme mit einer Zeitachse für Systemereignisse und Administratoraktivitäten auf einer VM:

  1. Im Diagramm VM-Lebenszyklus wird Folgendes angezeigt:

    • Der Messwert compute.googleapis.com/instance/uptime, der angibt, ob die VM zu einem bestimmten Zeitpunkt ausgeführt wurde, wobei 1 aktiv und 0 inaktiv ist. Dieser Messwert gibt die Verfügbarkeit aufgrund von Nutzeraktivitäten und Systemereignissen an und ist kein Hinweis auf das Compute Engine-SLA.
    • Der logbasierte Messwert vm-lifecycle-events zum Zählen der Anzahl der Lebenszyklusaktionen, z. B. stop oder start, die zu einem bestimmten Zeitpunkt auf die VM ausgeführt wurden

  2. Das Diagramm „Ereignisse“ zeigt denselben vm-lifecycle-events-logbasierten Messwert, aber in einer vergrößerten Ansicht, um die Lesbarkeit zu erleichtern. Die X-Achsen sind zwar ausgerichtet, die Farben sind jedoch nicht zwischen den beiden Diagrammen synchronisiert.

Massive projektübergreifende Shutdowns von VMs untersuchen

Compute Engine kann mehrere VMs herunterfahren, die mit einem freigegebenen VPC-Hostprojekt verbunden sind, wenn die Abrechnung des Hostprojekts der freigegebenen VPC inaktiv oder deaktiviert ist.

Suchen Sie nach Stoppvorgängen, die von cloud-cluster-manager@prod.google.com initiiert wurden, um festzustellen, ob Ihre VMs durch eine Anfrage für massive Shutdowns heruntergefahren wurden.

Beim Starten einer betroffenen Instanz wird ein Fehler wie dieser zurückgegeben:

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

So beheben Sie das Problem:

  1. Ermitteln Sie die von den VMs verwendete freigegebene VPC mit dem Befehl gcloud compute instances describe:

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

    Die Ausgabe sieht etwa so aus:

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

  2. Überprüfen Sie im Hostprojekt der freigegebenen VPC, ob die Abrechnung deaktiviert wurde.

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

  3. Falls erforderlich aktivieren Sie die Abrechnung für das Hostprojekt.

Informationen dazu, wie Sie verhindern können, dass dieses Problem erneut auftritt, finden Sie unter Verknüpfung zwischen einem Projekt und seinem Rechnungskonto sichern.

Probleme beim Beenden von VMs mit gcpdiag untersuchen

gcpdiag ist ein Open-Source-Tool. Es ist kein offiziell unterstütztes Google Cloud-Produkt. Mit dem Tool gcpdiag können Sie Probleme mit Google Cloud-Projekten identifizieren und beheben. Weitere Informationen finden Sie im gcpdiag-Projekt auf GitHub.

In diesem gcpdiag-Runbook werden Probleme beim Beenden von VMs untersucht. Dabei werden die folgenden Bereiche geprüft:
  • Durch Systemereignisse ausgelöste Herunterfahren und Neustarts:Hier werden Herunterfahren, die von internen Google Cloud-Systemen aufgrund von Systemwartungsereignissen, normalen Hardwareausfällen oder Ressourceneinschränkungen initiiert wurden, erfasst.
  • Durch Aktivitäten von Systemadministratoren ausgelöste Herunter-/Neustarts:Hier werden Abschlüsse untersucht, die durch direkte Aktionen wie API-Aufrufe von Nutzern oder Dienstkonten verursacht wurden. Dazu gehören manuelle Herunter- und Neustarts oder automatisierte Prozesse, die sich auf den VM-Status auswirken.
  • Unofficial RCA text generation (Erstellung eines inoffiziellen RCA-Texts): Hier finden Sie einen detaillierten Text zur Ursachenanalyse, in dem die identifizierte Ursache für die Beendigung, die beteiligten Systeme oder Aktivitäten und Empfehlungen zur Vermeidung zukünftiger Vorfälle beschrieben werden.

Google Cloud Console

  1. Führen Sie den folgenden Befehl aus und kopieren Sie ihn. 
    2. gcpdiag runbook gce/vm-termination \
    --parameter project_id=PROJECT_ID \
    --parameter name=VM_NAME \
    --parameter zone=ZONE
  2. Öffnen Sie die Google Cloud Console und aktivieren Sie Cloud Shell.
    3. Cloud Console öffnen
  3. Fügen Sie den kopierten Befehl ein.
  4. Führen Sie den Befehl gcpdiag aus, um das Docker-Image gcpdiag herunterzuladen und dann Diagnoseprüfungen durchzuführen. Folgen Sie gegebenenfalls der Anleitung für die Ausgabe, um fehlgeschlagene Prüfungen zu beheben.

Docker

Sie können gcpdiag mit einem Wrapper ausführen, der gcpdiag in einem Docker-Container startet. Docker oder Podman muss installiert sein.

  1. Kopieren Sie den folgenden Befehl und führen Sie ihn auf Ihrer lokalen Workstation aus.
    curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
  2. Führen Sie den Befehl gcpdiag aus. 
    ./gcpdiag runbook gce/vm-termination \
    --parameter project_id=PROJECT_ID \
    --parameter name=VM_NAME \
    --parameter zone=ZONE

Verfügbare Parameter für dieses Runbook ansehen

Ersetzen Sie Folgendes:

  • PROJECT_ID: Die ID des Projekts, das die Ressource enthält
  • VM_NAME: Der Name der Ziel-VM in Ihrem Projekt.
  • ZONE: Die Zone, in der sich die Ziel-VM befindet.

Nützliche Flags:

Eine Liste und Beschreibung aller gcpdiag-Tool-Flags finden Sie in der gcpdiag-Nutzungsanleitung.