Fehlerbehebung bei Neustarts und Neustarts 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 so bei Compute Engine authentifizieren.
  

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

  Console

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

  gcloud

  1. Installieren Sie die Google Cloud CLI und initialisieren Sie sie mit folgendem Befehl:

     gcloud init

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

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. Erstellen Sie ein Dashboard mit den Logs, um schnell die Ursache für das Herunterfahren oder Neustarten der VM zu ermitteln. 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.

Erforderliche Berechtigungen für diese Aufgabe

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

• Rolle Logging/Logbetrachter oder Projekt/Betrachter

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

   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 Instanz auf Abruf. Infrastrukturwartungsereignisse, wenn die VM-Instanz nicht auf Live-Migration eingestellt ist. Eine MIG-Instanz mit einer der folgenden Methoden löschen: 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, die Ihre VM hostet, ein Problem mit der Hardware oder Software aufgetreten ist, das zum Absturz der VM führte. Ein Hostfehler, der einen völligen Hardwareausfall oder andere Hardwareprobleme nach sich zieht, kann eine Live-Migration Ihrer VM verhindern. Wenn Ihre VM so eingestellt ist, dass sie automatisch neu startet (dies ist die Standardeinstellung), startet Google Ihre VM in der Regel innerhalb von drei Minuten ab dem Fehler. Je nach Problem kann der Neustart bis zu 5,5 Minuten dauern. VMs mit lokalen SSD-Laufwerken Wenn ein Hostfehler auf einer VM auftritt, an die ein oder mehrere lokale SSDs angehängt sind, versucht Compute Engine, die Verbindung zur VM wiederherzustellen und die lokalen SSD-Daten beizubehalten. Während Compute Engine Ihre VM und das lokale SSD-Laufwerk wiederherstellt, reagieren das Hostsystem und das zugrunde liegende Laufwerk nicht. Sie können festlegen, wie lange Compute Engine versuchen soll, lokale SSD-Daten wiederherzustellen, indem Sie das Zeitlimit für die lokale SSD-Wiederherstellung bestimmen. Weitere Informationen zum Verhalten lokaler SSD-Laufwerke bei einem Hostfehler finden Sie unter Datenpersistenz auf lokalen SSDs. Nicht reagierende VMs Manchmal reagiert eine VM möglicherweise nicht mehr, bevor ein Hostfehler erkannt wird. Sie können die Zeit verkürzen, die Compute Engine auf den Neustart oder die Beendigung der VM wartet. Legen Sie dazu das Zeitlimit für die Fehlerbehebung des Hosts fest (Vorschau). 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: 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	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	Die VM wurde von einem Nutzer oder Dienstkonto angelegt. 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]	Die Ausführung wurde von einem von Google verwalteten Dienstkonto initiiert. Sehen Sie sich die project-number des Dienstkontos 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-Lebenszyklus-Ereignisse überwachen

Sie können VM-Lebenszyklus-Ereignisse (einschließlich Herunterfahren, Neustarts und Hostfehler) durch Erstellen eines Cloud Monitoring-Dashboards überwachen.

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

Abbildung 1. Ein Beispiel-Dashboard, das die Verfügbarkeit einer Instanz und ihre Lebenszyklusereignisse wie eine angehaltene Instanz anzeigt.

Hinweis: Die in diesem Dashboard verwendeten Logs sind kostenpflichtige Messwerte.

Logbasierten Messwert erstellen

Erstellen Sie einen benutzerdefinierten logbasierten Messwert, um VM-Lebenszyklus-Ereignisse zu erfassen. Dieser Messwert verwendet Audit-Logs, um zu zählen, wie oft ein bestimmtes VM-Lebenszyklus-Ereignis 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 verwalten.

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

So erstellen Sie einen benutzerdefinierten logbasierten Messwert:

1. Wechseln Sie in der Google Cloud Console zur Seite Logbasierte Messwerte.

   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 Abschnitt Filterauswahl Folgendes an:

   • Wählen Sie im Drop-down-Menü Logbereich auswählen die Option „Projektlogs“ aus.
   • Geben Sie unter Build-Filter 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

Im Dashboard werden keine Daten angezeigt, bis bei 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 auf jeder vorhandenen VM die Vorgänge stop und start aus oder erstellen Sie zu Testzwecken eine neue VM.

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

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

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

   Dashboards aufrufen

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

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

4. Grenzen Sie die Zeitachsen auf einen relevanten Zeitraum ein.

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

Das Dashboard enthält zwei Diagramme mit einer Zeitachse der Systemereignisse und Administratoraktivitäten, die auf einer VM auftreten:

1. Das Diagramm VM-Lebenszyklus-Zeitachse zeigt Folgendes an:

   • 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 spiegelt die Verfügbarkeit aufgrund von Nutzeraktivitäten und Systemereignissen wider und ist kein Hinweis auf das Compute Engine-SLA.
   • Der logbasierte vm-lifecycle-events-Messwert, um die Anzahl der Lebenszyklusaktionen wie stop oder start zu zählen, die zu einem bestimmten Zeitpunkt für die VM ausgeführt wurden.

2. Das Ereignisdiagramm zeigt denselben logbasierten Messwert vm-lifecycle-events, jedoch in einer vergrößerten Ansicht, um die Lesbarkeit zu verbessern. Beachten Sie, dass die X-Achsen ausgerichtet sind, die Farben jedoch nicht zwischen den beiden Diagrammen synchronisiert sind.

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 [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 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 dieses Problem vermeiden können, finden Sie unter Verknüpfung zwischen einem Projekt und seinem Rechnungskonto sichern.