Fehlerbehebung beim Herunterfahren und Neustarten von VMs

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

Das Herunterfahren oder Neustarten von Instanzen kann durch Systemereignisse oder Administratoraktivitäten verursacht werden. Shutdown- und Neustarts von Systemereignissen werden von Google-Systemen oder dem Betriebssystem Ihrer Instanz 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 Instanz initiiert werden.

Hinweis

• 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 so bei Compute Engine authentifizieren:

  Wählen Sie den Tab für die gewünschte Verwendung der Beispiele auf dieser Seite aus:

  Console

  Wenn Sie über die Google Cloud Console auf Dienste und APIs von Google Cloud zugreifen, müssen Sie die Authentifizierung nicht einrichten.

  gcloud

  1. Installieren Sie die Google Cloud CLI. Initialisieren Sie die Google Cloud CLI nach der Installation mit dem folgenden Befehl:

     gcloud init

     Wenn Sie einen externen Identitätsanbieter (IdP) verwenden, müssen Sie sich zuerst mit Ihrer föderierten Identität in der gcloud CLI anmelden.

     Hinweis:Wenn Sie die gcloud CLI zuvor installiert haben, prüfen Sie, ob Sie die aktuelle Version haben, indem Sie gcloud components update ausführen.
• Legen Sie eine Standardregion und -zone fest.

Shutdowns und Neustarts von Instanzen diagnostizieren

Sie können die Logs einer Instanz abfragen, um die Ursache für das Herunterfahren oder Neustarten einer Instanz 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 Logs in den Feldern method und principalEmail, welches Ereignis oder welcher Nutzer bzw. Dienst den Herunterfahren oder Neustart initiiert 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.

Erforderliche Berechtigungen für diese Aufgabe

Zum Ausführen dieser Aufgabe benötigen Sie die folgenden Berechtigungen:

• Die Rolle Logging/Loganzeige oder die Rolle Project/Viewer.

Console

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

   Zum Log-Explorer

   Hinweis: Unter Umständen müssen Sie auf Upgrade klicken, um statt der alten Loganzeige die Loganzeige zu verwenden.

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.

   

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

   Tipp: Klicken Sie auf Abfrageergebnisse im Vollbildmodus eingeben, um die Größe des Abschnitts Abfrageergebnisse zu erhöhen.

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 wurde.

   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.

   Hinweis: Wenn Ihre VM neu gestartet wurde und in der folgenden Tabelle in den Cloud-Audit-Logs keine vergleichbare Methode aufgeführt ist, ist der Neustart wahrscheinlich aufgetreten, da das Betriebssystem Ihrer VM den Neustart initiierte. Gründe für Neustarts lassen sich häufig nur schwer identifizieren. Wenn bei Ihren VMs häufig Neustarts auftreten, sollten Sie Support anfordern.

   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: Hardwarefehler. Beenden einer Spot-VM. Infrastrukturwartungsereignisse, wenn die VM-Instanz nicht auf Live-Migration eingestellt ist. Löschen einer MIG-Instanz mit einer der folgenden Methoden: Der API-Methode instances.delete. Befehl gcloud compute instances delete Hinweis: Damit Konfigurationsänderungen nicht von der MIG rückgängig gemacht werden, ist es wichtig,Methoden der Gruppe zu verwenden. Wenn Sie beispielsweise eine verwaltete Instanz löschen möchten, verwenden Sie eine der folgenden Methoden: Für eine zonale MIG: instanceGroupManagers.deleteInstances Regionale MIGs: regionInstanceGroupManagers.deleteInstances In gcloud: gcloud compute instance-groups managed delete-instances
   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 führte. 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 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. Wenn bei einer Compute-Instanz ein Hostfehler auftritt oder Sie den Host als fehlerhaft melden, ist eine ungeplante Notfallwartung des Hosts der Instanz erforderlich. Standardmäßig benachrichtigt Compute Engine einige Stunden im Voraus, wenn diese Art von Wartung geplant ist. Manchmal reagiert eine Compute-Instanz möglicherweise nicht mehr, bevor ein Hostfehler signalisiert 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. Weitere Informationen finden Sie unter Richtlinie für eine vorhandene Instanz 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: Robuste Systeme konzipieren Skalierbare und robuste Anwendungen erstellen Verwaltete Instanzgruppen erstellen 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 oder Systemereignis	Ein Nutzer oder Dienstkonto hat Ihre VM gelöscht oder die VM wurde so konfiguriert, dass sie automatisch gelöscht wird. Wichtig:Anfragen zum Löschen Ihrer VM, die in Cloud-Audit-Logs durch die Methode compute.instances.delete angegeben werden, können andere Anfragen für Ihre VM, die zu einem ähnlichen Zeitpunkt gestellt wurden, inkonsistent überschreiben. Auch wenn diese anderen Anfragen erfolgreich waren, kann die compute.instances.delete-Methode inkonsistent verhindern, dass die Methoden aus diesen anderen Anfragen in den Cloud-Audit-Logs für Ihre VM angezeigt werden. Ein Log für die Methode compute.instances.delete kann auf eine der folgenden Anfragen für Ihre VM hinweisen: Anfragen von einem Nutzer oder Dienstkonto zum direkten Löschen Ihrer VM werden nur durch eine compute.instances.delete-Methode des Nutzers oder Dienstkontos angegeben. Anfragen, die Ihre VM automatisch löschen, werden durch die Methode compute.instances.delete aus [e-mail] angegeben. Die Methode, die die Ursache für das automatische Löschen erklärt, wird jedoch möglicherweise nicht in Cloud-Audit-Logs angezeigt. Wenn eine Spot-VM beispielsweise so konfiguriert ist, dass sie bei einer vorzeitigen Beendigung automatisch gelöscht wird, und sie vorzeitig beendet wird, wird eine compute.instances.delete-Methode von [e-mail] angezeigt. Möglicherweise wird aber auch eine compute.instances.preempted-Methode angezeigt. Anfragen an die VM, die kurz vor oder nach einer compute.instances.delete-Methode erfolgen, werden möglicherweise in Cloud-Audit-Logs angezeigt. Wenn beispielsweise eine VM aufgrund von Hostwartung kurz vor dem Löschen der VM beendet wird, sehen Sie eine compute.instances.delete-Methode, aber möglicherweise auch eine compute.instances.terminateOnHostMaintenance-Methode. 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	Ein Nutzer oder Dienstkonto hat Ihre VM 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
   [e-mail]	Ein Systemereignis hat das Herunterfahren oder den Neustart verursacht.
   [e-mail]	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: [e-mail].

   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-Ereignisse (einschließlich Herunterfahren, Neustarts und Hostfehler) überwachen, indem Sie ein Cloud Monitoring-Dashboard erstellen.

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

Abbildung 1. Ein Beispieldashboard, das die Verfügbarkeit einer Instanz und ihre Lifecycle-Events zeigt, z. B. eine beendete Instanz.

Hinweis: Die in diesem Dashboard verwendeten generierten Logs sind abrechenbare Messwerte.

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 zuzuweisen, 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 Daten angezeigt, wenn auf einer Instanz 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 für eine vorhandene Instanz aus oder erstellen Sie eine neue VM für Testzwecke.

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. Beschränken 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, die in einer Instanz auftreten:

1. Das Diagramm VM-Lebenszyklus-Zeitachse enthält Folgendes:

   • 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, mit dem die Anzahl der Lebenszyklusaktionen wie stop oder start gezählt wird, die zu einem bestimmten Zeitpunkt für die Instanz ausgeführt wurden.

2. Das Diagramm „Ereignisse“ zeigt denselben logbasierten Messwert vm-lifecycle-events, aber in einer vergrößerten Ansicht, um die Lesbarkeit zu verbessern. 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 freigegebene VPC-Hostprojekt verbunden sind, wenn die Abrechnung des Hostprojekts der freigegebene VPC inaktiv oder deaktiviert ist.

Suchen Sie nach Stoppvorgängen, die von [e-mail] 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 gemeinsam genutzte 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 gemeinsam genutzten 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.