Fehlerbehebung bei synthetischen Monitoren und Verfügbarkeitsdiagnosen

In diesem Dokument finden Sie Informationen dazu, wie Sie Logdaten finden und Fehler bei synthetischen Monitoren und Verfügbarkeitsdiagnosen beheben:

• Logs finden
• Fehlerbehebung bei Benachrichtigungen
• Probleme mit öffentlichen Verfügbarkeitsdiagnosen beheben
• Probleme mit privaten Verfügbarkeitsdiagnosen beheben
• Fehlerbehebung bei synthetischen Monitoren

Logs suchen

In diesem Abschnitt finden Sie Informationen dazu, wie Sie Logs für Ihre synthetischen Monitore und Verfügbarkeitsdiagnosen aufrufen:

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

   Zum Log-Explorer

   Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Logging ist.

2. Wählen Sie in der Symbolleiste der Google Cloud -Console Ihr Google Cloud -Projekt aus. Wählen Sie für App Hub-Konfigurationen das App Hub-Hostprojekt oder das Verwaltungsprojekt des für Apps aktivierten Ordners aus.

3. Sie haben folgende Möglichkeiten:

   • Wenn Sie alle Logs für Ihre synthetischen Monitore oder Verfügbarkeitsdiagnosen aufrufen möchten, führen Sie eine Abfrage nach Ressourcentyp aus. Sie können das Menü Ressource verwenden oder eine Abfrage eingeben.

     Wählen Sie für Verfügbarkeitsdiagnosen im Menü Ressource die Option URL für Verfügbarkeitsdiagnose aus oder geben Sie die folgende Abfrage in den Abfrageeditor ein und klicken Sie dann auf Abfrage ausführen:

     resource.type="uptime_url"
     

     Wählen Sie für synthetische Monitore im Menü Ressource die Option Cloud Run-Überarbeitung aus oder geben Sie die folgende Abfrage in den Abfrageeditor ein und klicken Sie dann auf Abfrage ausführen:

     resource.type="cloud_run_revision"
     

   • So finden Sie Protokolle, die Informationen zur Antwort enthalten, die während der Ausführung eines synthetischen Monitors oder einer Verfügbarkeitsdiagnose empfangen wurde:

     • Wenn Sie eine Abfrage mit der ID des synthetischen Monitors oder Uptime-Checks durchführen möchten, geben Sie die ID im Abfrageeditor im folgenden Format ein und klicken Sie dann auf Abfrage ausführen.

       labels.check_id="my-check-id"
       

     • Wenn Sie Logs abfragen möchten, die Antwortdaten für Anfragen enthalten, die von synthetischen Monitoren und Uptime-Prüfungen ausgegeben wurden, geben Sie die folgende Abfrage in den Abfrageeditor ein und klicken Sie dann auf Abfrage ausführen.

       "UptimeCheckResult"
       

       Die vorherige Abfrage entspricht allen Logeinträgen, die den String "UptimeCheckResult" enthalten.

     Diese Logs enthalten Folgendes:

     • Die ID des synthetischen Monitors oder der Verfügbarkeitsdiagnose, die im Feld labels.check_id gespeichert ist.

     • Für synthetische Monitore der Name Ihrer Cloud Run-Funktion, die im Feld resource.labels.service_name gespeichert ist.

     • Wenn Trace-Daten erhoben werden, wird die ID eines zugehörigen Traces im Feld trace gespeichert.

   • Um zu prüfen, ob Ihr Dienst Anfragen von Google Cloud -Servern erhalten hat, kopieren Sie die folgende Abfrage in den Abfrageeditor und klicken Sie dann auf Abfrage ausführen:

     "GoogleStackdriverMonitoring-UptimeChecks"
     

     Das Feld protoPayload.ip enthält eine der von den Verfügbarkeitsdiagnose-Servern verwendeten Adressen. Informationen zum Auflisten aller IP-Adressen finden Sie unter IP-Adressen auflisten.

Probleme mit Benachrichtigungen beheben

In diesem Abschnitt werden einige Fehler beschrieben, die bei der Konfiguration von Benachrichtigungsrichtlinien auftreten können, und es werden Informationen zur Behebung dieser Fehler bereitgestellt.

Ein Checker ist fehlgeschlagen, andere jedoch nicht

Sie sehen sich die Messwerte für die Verfügbarkeitsdiagnose an und stellen fest, dass ein Checker einen Fehler gemeldet hat, während alle anderen Checker erfolgreich waren.

Es besteht kein Handlungsbedarf.

Wenn nur eine Prüfung einen Fehler meldet, kann dies daran liegen, dass das Zeitlimit des Befehls der Prüfung aufgrund eines Netzwerkproblems überschritten wurde. Das heißt, der Befehl schlägt nicht fehl, sondern wird nicht innerhalb des angegebenen Zeitlimits abgeschlossen.

Für Benachrichtigungsrichtlinien, die die Standardkonfiguration verwenden, sind Fehler von mindestens zwei Prüfungen erforderlich, bevor ein Vorfall erstellt und eine Benachrichtigung gesendet wird. Ein von einem einzelnen Checker gemeldeter Fehler führt nicht zu einer Benachrichtigung.

Sie haben eine Benachrichtigung erhalten und möchten den Fehler beheben.

1. Führen Sie einen der folgenden Schritte aus, um herauszufinden, wann der Fehler aufgetreten ist:

   • Wenn Sie bei Verfügbarkeitsdiagnosen feststellen möchten, wann der Fehler aufgetreten ist, rufen Sie die Seite Verfügbarkeitsdetails auf:

     1. Rufen Sie in der Google Cloud Console die Seite  Uptime-Prüfungen auf:

        Verfügbarkeitsdiagnosen aufrufen

        Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Monitoring ist.

     2. Wählen Sie in der Symbolleiste der Google Cloud -Console Ihr Google Cloud -Projekt aus. Wählen Sie für App Hub-Konfigurationen das App Hub-Hostprojekt oder das Verwaltungsprojekt des für Apps aktivierten Ordners aus.

     3. Suchen Sie nach der Verfügbarkeitsdiagnose und wählen Sie sie aus.

        Im Diagramm Bestandene Prüfungen wird der Verlauf der Prüfungen angezeigt. Um herauszufinden, wann die Verfügbarkeitsdiagnose zum ersten Mal fehlgeschlagen ist, müssen Sie möglicherweise den Zeitraum für das Diagramm ändern. Die Zeitraumauswahl befindet sich in der Symbolleiste der Seite Uptime details (Details zur Betriebszeit).

   • Um festzustellen, wann der Fehler aufgetreten ist, rufen Sie für synthetische Monitorings die Seite Verfügbarkeitsdetails auf:

     1. Rufen Sie in der Google Cloud Console die Seite Synthetisches Monitoring auf:

        Zu Synthetisches Monitoring

        Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Monitoring ist.

     2. Wählen Sie in der Symbolleiste der Google Cloud -Console Ihr Google Cloud -Projekt aus. Wählen Sie für App Hub-Konfigurationen das App Hub-Hostprojekt oder das Verwaltungsprojekt des für Apps aktivierten Ordners aus.
     3. Suchen Sie den synthetischen Monitor und wählen Sie ihn aus.

2. Informationen zum Suchen zugehöriger Logdaten finden Sie auf dieser Seite im Abschnitt Logs finden.

Sie werden nicht benachrichtigt, wenn eine Verfügbarkeitsdiagnose fehlschlägt

Sie haben eine Verfügbarkeitsdiagnose konfiguriert und rufen die Seite Betriebszeitdetails für diese Diagnose auf. Sie stellen fest, dass im Diagramm Bestandene Prüfungen mindestens eine Prüfung fehlgeschlagen ist. Du hast aber keine Benachrichtigung erhalten.

Standardmäßig ist die Benachrichtigungsrichtlinie so konfiguriert, dass ein Vorfall erstellt und eine Benachrichtigung gesendet wird, wenn Diagnosen in mindestens zwei Regionen keine Antwort auf eine Verfügbarkeitsdiagnose erhalten. Diese Fehler müssen gleichzeitig auftreten.

Sie können die Bedingung der Benachrichtigungsrichtlinie so bearbeiten, dass Sie benachrichtigt werden, wenn in einer einzelnen Region keine Antwort empfangen wird. Wir empfehlen jedoch, die Standardkonfiguration zu verwenden, da dadurch die Anzahl der Benachrichtigungen reduziert wird, die Sie aufgrund vorübergehender Fehler erhalten.

So rufen Sie eine Benachrichtigungsrichtlinie auf oder bearbeiten sie:

1. Rufen Sie in der Google Cloud Console- die Seite Benachrichtigungen auf:notifications

   Zu Benachrichtigungen

   Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Monitoring ist.

2. Wählen Sie in der Symbolleiste der Google Cloud -Console Ihr Google Cloud -Projekt aus. Wählen Sie für App Hub-Konfigurationen das App Hub-Hostprojekt oder das Verwaltungsprojekt des für Apps aktivierten Ordners aus.
3. Klicken Sie im Bereich Richtlinien auf Alle Richtlinien ansehen.

4. Suchen Sie die Richtlinie, die Sie aufrufen oder bearbeiten möchten, und klicken Sie dann auf den Namen der Richtlinie.

   Sie können die Richtlinie auf der Seite Richtliniendetails aufrufen und bearbeiten.

Fehlerbehebung bei öffentlichen Verfügbarkeitsdiagnosen

In diesem Abschnitt werden einige Fehler beschrieben, die bei der Verwendung öffentlicher Uptime-Prüfungen auftreten können, sowie Informationen zum Beheben dieser Fehler.

Ihre öffentlichen Verfügbarkeitsdiagnosen schlagen fehl

Sie konfigurieren eine öffentliche Verfügbarkeitsdiagnose, erhalten aber beim Ausführen des Bestätigungsschritts eine Fehlermeldung.

Im Folgenden sind einige mögliche Fehlerursachen bei Verfügbarkeitsdiagnosen aufgeführt:

• Connection Error – Refused (Verbindungsfehler – Abgelehnt): Achten Sie bei Verwendung des Standardverbindungstyps HTTP darauf, dass ein Webserver installiert ist, der auf HTTP-Anfragen reagiert. Ein Verbindungsfehler kann bei einer neuen Instanz auftreten, wenn Sie keinen Webserver installiert haben. Weitere Informationen finden Sie unter Kurzanleitung für Compute Engine. Bei Verwendung des Verbindungstyps HTTPS müssen Sie unter Umständen zusätzliche Konfigurationsschritte ausführen. Informationen zu Firewallproblemen finden Sie unter IP-Adressen von Servern für Verfügbarkeitsdiagnose auflisten.
• Name or service not found (Name oder Dienst nicht gefunden): Der Hostname ist möglicherweise falsch.
• 403 Forbidden (403 – Verboten): Der Dienst liefert während der Verfügbarkeitsdiagnose einen Fehlercode. Die Standardkonfiguration für den Apache-Webserver gibt diesen Code beispielsweise unter Amazon Linux zurück. Unter bestimmten Linux-Versionen erhalten Sie hingegen den Code 200 (Success) (200 (Erfolg)). Weitere Informationen finden Sie in der LAMP-Anleitung für Amazon Linux oder in der Dokumentation Ihres Webservers.
• 404 – Not found (Nicht gefunden): Möglicherweise ist der Pfad falsch.
• 408 Request timeout (408 – Zeitüberschreitung bei Anfrage) oder keine Antwort: Möglicherweise ist die Portnummer falsch, der Dienst wird nicht ausgeführt oder ist nicht erreichbar oder das Zeitlimit ist zu niedrig. Achten Sie darauf, dass die Firewall Traffic von den für die Verfügbarkeitsdiagnose verwendeten Servern zulässt. Weitere Informationen erhalten Sie unter IP-Adressen der Server für die Verfügbarkeitsdiagnose auflisten. Das Zeitlimit ist Teil der Antwortvalidierung angegeben.

Um Ihnen bei der Fehlerbehebung fehlgeschlagener öffentlicher Verfügbarkeitsdiagnosen zu helfen, können Sie Ihre Verfügbarkeitsdiagnosen so konfigurieren, dass während der Diagnose bis zu drei ICMP-Pings gesendet werden. Mithilfe der Pings können Sie zwischen Fehlern unterscheiden, die beispielsweise durch Probleme mit der Netzwerkverbindung und durch Zeitüberschreitungen in Ihrer Anwendung verursacht werden. Weitere Informationen finden Sie unter ICMP-Pings verwenden.

Fehlerbehebung bei privaten Verfügbarkeitsdiagnosen

In diesem Abschnitt werden einige Fehler beschrieben, die bei der Verwendung privater Uptime-Checks auftreten können. Außerdem finden Sie Informationen zum Beheben dieser Fehler.

Erstellung der Verfügbarkeitsdiagnose schlägt fehl

Die Einstellungen Ihres Google Cloud Projekts verhindern möglicherweise, dass die Rollen geändert werden, die dem Dienstkonto zugewiesen sind, das von Uptime-Checks verwendet wird, um Interaktionen mit dem Service Directory-Dienst zu verwalten. In diesem Fall schlägt die Erstellung der Verfügbarkeitsdiagnose fehl.

In diesem Abschnitt wird beschrieben, wie Sie die Rollen zuweisen, die das Dienstkonto benötigt:

Zugriff verweigert

Ihre Verfügbarkeitsdiagnosen schlagen mit VPC_ACCESS_DENIED-Ergebnissen fehl. Dieses Ergebnis bedeutet, dass ein Aspekt Ihrer Netzwerkkonfiguration oder der Autorisierung des Dienstkontos nicht korrekt ist.

Prüfen Sie die Autorisierung Ihres Dienstkontos für die Verwendung eines Bereichsprojekts oder eines überwachten Projekts, wie unter Uptime-Check kann nicht erstellt werden beschrieben.

Weitere Informationen zum Zugriff auf private Netzwerke finden Sie unter Netzwerkprojekt konfigurieren.

Anomale Ergebnisse von privaten Verfügbarkeitsdiagnosen

Sie haben einen Service Directory-Dienst mit mehreren VMs und Ihre Dienstkonfiguration enthält mehrere Endpunkte. Wenn Sie eine der VMs herunterfahren, wird in der Verfügbarkeitsdiagnose weiterhin „Erfolgreich“ angezeigt.

Wenn Ihre Dienstkonfiguration mehrere Endpunkte enthält, wird einer zufällig ausgewählt. Wenn die mit dem ausgewählten Endpunkt verknüpfte VM ausgeführt wird, ist die Verfügbarkeitsdiagnose erfolgreich, auch wenn eine der VMs nicht verfügbar ist.

Standardheader

Ihre Verfügbarkeitsdiagnosen geben Fehler oder unerwartete Ergebnisse zurück. Das kann passieren, wenn Sie Standardheaderwerte überschrieben haben.

Wenn eine Anfrage für einen privaten Uptime-Check an einen Zielendpunkt gesendet wird, enthält die Anfrage die folgenden Header und Werte:

Wenn Sie versuchen, diese Werte zu überschreiben, kann Folgendes passieren:

• Die Verfügbarkeitsdiagnose meldet Fehler
• Die Überschreibungswerte werden verworfen und durch die Werte in der Tabelle ersetzt.

Keine Daten sichtbar

Wenn sich Ihre Verfügbarkeitsdiagnose in einem anderen Google Cloud Projekt als der Service Directory-Dienst befindet, werden im Dashboard für Verfügbarkeitsdiagnosen keine Daten angezeigt.

Achten Sie darauf, dass das Google Cloud Projekt, das den Uptime-Check enthält, das Google Cloud Projekt überwacht, das den Service Directory-Dienst enthält.

Weitere Informationen zum Auflisten überwachter Projekte und zum Hinzufügen weiterer Projekte finden Sie unter Messwertbereich für mehrere Projekte konfigurieren.

Fehlerbehebung bei synthetischen Monitoren

Dieser Abschnitt enthält Informationen, die Ihnen bei der Fehlerbehebung bei Ihren synthetischen Monitoren helfen können.

Fehlermeldung nach dem Aktivieren der APIs

Sie öffnen den Erstellungsprozess für einen synthetischen Monitor und werden aufgefordert, mindestens eine API zu aktivieren. Nachdem Sie die APIs aktiviert haben, wird eine Meldung wie die folgende angezeigt:

An error occurred during fetching available regions: Cloud Functions API has
not been used in project PROJECT_ID before or it is disabled.

In der Fehlermeldung wird empfohlen, zu prüfen, ob die API aktiviert ist, und dann zu warten und die Aktion noch einmal zu versuchen.

So prüfen Sie, ob die API aktiviert ist: Rufen Sie die Seite APIs und Dienste für Ihr Projekt auf:

Rufen Sie "APIs & Dienste" auf.

Nachdem Sie bestätigt haben, dass die API aktiviert ist, können Sie mit dem Erstellungsvorgang fortfahren. Der Zustand wird automatisch behoben, nachdem die API-Aktivierung im Backend erfolgt ist.

Ausgehende HTTP-Anfragen werden nicht nachverfolgt

Sie konfigurieren den synthetischen Monitor so, dass Tracedaten für ausgehende HTTP-Anfragen erfasst werden. Ihre Tracedaten enthalten nur einen Span, ähnlich wie im folgenden Screenshot:

Um dieses Problem zu beheben, müssen Sie Ihrem Dienstkonto die Rolle „Cloud Trace Agent“ (roles/cloudtrace.agent) zuweisen. Die Rolle „Bearbeiter“ (roles/editor) ist ebenfalls ausreichend.

So rufen Sie die Rollen auf, die Ihrem Dienstkonto zugewiesen sind:

1. Rufen Sie in der Google Cloud Console die Seite IAM auf:

   Rufen Sie IAM auf.

   Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift IAM & Admin ist.

2. Wählen Sie in der Symbolleiste der Google Cloud -Console Ihr Google Cloud -Projekt aus. Wählen Sie für App Hub-Konfigurationen das App Hub-Hostprojekt oder das Verwaltungsprojekt des für Apps aktivierten Ordners aus.
3. Wählen Sie Von Google bereitgestellte Rollenzuweisungen einschließen aus.

4. Wenn das von Ihrem synthetischen Monitor verwendete Dienstkonto nicht aufgeführt ist oder ihm keine Rolle mit den Berechtigungen der Rolle „Cloud Trace Agent“ (roles/cloudtrace.agent) zugewiesen wurde, weisen Sie Ihrem Dienstkonto diese Rolle zu.

   Wenn Sie den Namen Ihres Dienstkontos nicht kennen, wählen Sie im Navigationsmenü Dienstkonten aus.

Status „In Bearbeitung“

Auf der Seite Synthetisches Monitoring wird ein synthetischer Monitor mit dem Status In progress aufgeführt. Der Status In progress bedeutet, dass der synthetische Monitor vor Kurzem erstellt wurde und keine Daten zum Anzeigen vorhanden sind oder dass die Bereitstellung der Funktion fehlgeschlagen ist.

So ermitteln Sie, ob die Bereitstellung der Funktion fehlgeschlagen ist:

• Achten Sie darauf, dass der Name Ihrer Cloud Run-Funktion keinen Unterstrich enthält. Wenn ein Unterstrich vorhanden ist, entfernen Sie ihn und stellen Sie die Cloud Run-Funktion noch einmal bereit.

• Öffnen Sie die Seite Details zum synthetischen Monitor für den synthetischen Monitor.

  Wenn die folgende Meldung angezeigt wird, löschen Sie den synthetischen Monitor.

  Cloud Function not found for this Synthetic monitor. Please confirm it exists or delete this monitor.
  

  Die Fehlermeldung weist darauf hin, dass die Funktion gelöscht wurde und der synthetische Monitor sie daher nicht ausführen kann.

• Öffnen Sie die Seite „Cloud Run-Funktionen“ für die Funktion. Wenn Sie diese Seite über die Seite Details zum synthetischen Monitor aufrufen möchten, klicken Sie auf Code und dann auf den Funktionsnamen.

  Wenn eine Meldung wie die folgende angezeigt wird, konnte die Funktion nicht bereitgestellt werden.

  This function has failed to deploy and will not work correctly. Please edit and redeploy
  

  Um diesen Fehler zu beheben, überprüfen Sie den Funktionscode und korrigieren Sie die Fehler, die verhindern, dass die Funktion erstellt oder bereitgestellt wird.

Wenn Sie einen synthetischen Monitor erstellen, kann es einige Minuten dauern, bis die Funktion bereitgestellt und ausgeführt wird.

Warnstatus

Unter Synthetisches Monitoring wird ein synthetisches Monitoring mit dem Status Warning aufgeführt. Der Status Warning bedeutet, dass die Ausführungsergebnisse inkonsistent sind. Das kann auf ein Designproblem mit dem Test oder auf ein inkonsistentes Verhalten des zu testenden Elements hindeuten.

Status „Nicht bestanden“

Unter Synthetische Monitore wird ein synthetischer Monitor mit dem Status Failing aufgeführt. Weitere Informationen zum Grund für den Fehler finden Sie im letzten Ausführungsverlauf.

• Wenn die Fehlermeldung Request failed with status code 429 angezeigt wird, hat das Ziel der HTTP-Anfrage den Befehl abgelehnt. Um diesen Fehler zu beheben, müssen Sie das Ziel Ihres synthetischen Monitors ändern.

  Der Endpunkt https://www.google.com lehnt Anfragen von synthetischen Monitoren ab.

• Wenn bei dem Fehler eine Ausführungszeit von 0ms zurückgegeben wird, kann es sein, dass der Cloud Run-Funktion der Arbeitsspeicher ausgeht. Um diesen Fehler zu beheben, bearbeiten Sie Ihre Cloud Run-Funktion, erhöhen Sie den Arbeitsspeicher auf mindestens 2 GiB und legen Sie das CPU-Feld auf 1 fest.

Fehler beim Löschen eines synthetischen Monitors

Sie verwenden die Cloud Monitoring API, um einen synthetischen Monitor zu löschen, aber der API-Aufruf schlägt mit einer Antwort ähnlich der folgenden fehl:

{
  "error": {
    "code": 400,
    "message": "Request contains an invalid argument.",
    "status": "INVALID_ARGUMENT",
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.DebugInfo",
        "detail": "[ORIGINAL ERROR] generic::invalid_argument: Cannot delete check 1228258045726183344. One or more alerting policies is using it.Delete the alerting policy with id projects/myproject/alertPolicies/16594654141392976482 and any other policies using this uptime check and try again."
      }
    ]
  }
}

Um den Fehler zu beheben, löschen Sie die Benachrichtigungsrichtlinien, die die Ergebnisse des synthetischen Monitors überwachen, und löschen Sie dann den synthetischen Monitor.

Konfiguration eines Linkprüfers kann nicht bearbeitet werden

Sie haben mit der Google Cloud -Konsole eine Funktion zum Prüfen auf defekte Links erstellt und möchten die getesteten HTML-Elemente ändern oder das URI-Zeitlimit, die Wiederholungsversuche, die Option „Auf Selektor warten“ und die Optionen für einzelne Links anpassen. Wenn Sie den Link-Checker bearbeiten, werden die Konfigurationsfelder in der Google Cloud Konsole jedoch nicht angezeigt.

So beheben Sie diesen Fehler:

1. Rufen Sie in der Google Cloud Console die Seite Synthetisches Monitoring auf:

   Zu Synthetisches Monitoring

   Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Monitoring ist.

2. Wählen Sie in der Symbolleiste der Google Cloud -Console Ihr Google Cloud -Projekt aus. Wählen Sie für App Hub-Konfigurationen das App Hub-Hostprojekt oder das Verwaltungsprojekt des für Apps aktivierten Ordners aus.
3. Suchen Sie nach dem synthetischen Monitor, den Sie bearbeiten möchten, klicken Sie auf more_vert Weitere Optionen und wählen Sie dann Bearbeiten aus.
4. Klicken Sie auf Funktion bearbeiten.

5. Bearbeiten Sie das options-Objekt in der Datei index.js und klicken Sie dann auf Funktion anwenden.

   Informationen zu den Feldern und der Syntax für dieses Objekt finden Sie unter broken-links-ok/index.js.

6. Klicken Sie auf Speichern.

Google Cloud Konsole zeigt an, dass das Speichern von Screenshots fehlschlägt

Sie haben eine Prüfung auf fehlerhafte Links erstellt und so konfiguriert, dass Screenshots gespeichert werden. In der Google Cloud Konsole wird jedoch eine der folgenden Warnmeldungen mit detaillierteren Informationen angezeigt:

• InvalidStorageLocation
• StorageValidationError
• BucketCreationError
• ScreenshotFileUploadError

Versuchen Sie Folgendes, um diese Fehler zu beheben:

• Wenn Sie die Meldung InvalidStorageLocation sehen, prüfen Sie, ob der im Feld options.screenshot_options.storage_location angegebene Cloud Storage-Bucket vorhanden ist.

• Rufen Sie die Logs für Ihre Cloud Run-Funktion auf. Weitere Informationen finden Sie unter Logs finden.

• Prüfen Sie, ob das in der entsprechenden Cloud Run-Funktion verwendete Dienstkonto eine Identity and Access Management-Rolle hat, mit der es Cloud Storage-Buckets erstellen, darauf zugreifen und darin schreiben kann.