Probleme mit synthetischen Monitoren und Verfügbarkeitsdiagnosen beheben

In diesem Dokument erfahren Sie, wie Sie Logdaten finden und Fehler beim synthetischen Monitor oder bei Verfügbarkeitsdiagnosen beheben:

Logs suchen

Dieser Abschnitt enthält Informationen zum Suchen von Logs für Ihre synthetischen Monitore und Verfügbarkeitsdiagnosen:

  1. Wählen Sie im Navigationsbereich der Google Cloud Console Logging und anschließend Log-Explorer aus:

    Zum Log-Explorer

  2. Sie haben folgende Möglichkeiten:

    • Wenn Sie alle Logs finden möchten, die mit Ihren synthetischen Monitoren oder Verfügbarkeitsdiagnosen verknüpft sind, führen Sie eine Abfrage nach Ressourcentyp durch. Sie können das Menü Ressource verwenden oder eine Abfrage eingeben.

      Wählen Sie für Verfügbarkeitsdiagnosen im Menü Ressource die Option Verfügbarkeitsdiagnose-URL 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 Überarbeitung in Cloud Run aus oder geben Sie die folgende Abfrage in den Abfrageeditor ein und klicken Sie dann auf Abfrage ausführen:

      resource.type="cloud_run_revision"

    • Die Suchlogs, die Informationen zu der Antwort enthalten, die während eines synthetischen Monitors oder einer Verfügbarkeitsdiagnose erhalten wurden, führen einen der folgenden Schritte aus:

      • Wenn Sie die ID des synthetischen Monitors oder der Verfügbarkeitsdiagnose verwenden 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"

      • Zum Abfragen von Logs, die Antwortdaten für Anfragen von synthetischen Monitoren und Verfügbarkeitsdiagnosen enthalten, geben Sie die folgende Abfrage in den Abfrageeditor ein und klicken dann auf Abfrage ausführen.

        "UptimeCheckResult"

        Die vorherige Abfrage stimmt mit allen Logeinträgen überein, die den String "UptimeCheckResult" enthalten.

      Diese Logs umfassen Folgendes:

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

      • Bei synthetischen Monitoren der Name Ihrer Cloud Functions-Funktion, der im Feld resource.labels.service_name gespeichert ist.

      • Wenn Tracedaten erfasst werden, ist dies die ID eines zugehörigen Trace, die im Feld trace gespeichert wird.

    • Wenn Sie prüfen möchten, 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 Servern für die Verfügbarkeitsdiagnose verwendeten Adressen. Informationen zum Auflisten aller IP-Adressen finden Sie unter IP-Adressen auflisten.

Fehlerbehebung bei Benachrichtigungen

In diesem Abschnitt werden einige Fehler beschrieben, die beim Konfigurieren von Benachrichtigungsrichtlinien auftreten können, sowie Informationen zu deren Behebung.

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

  1. Um zu ermitteln, wann der Fehler begann, führen Sie einen der folgenden Schritte aus:

    • Rufen Sie für Verfügbarkeitsdiagnosen die Seite Verfügbarkeitsdiagnosen auf, um den Zeitpunkt des Fehlers zu ermitteln:

      1. Wählen Sie im Navigationsbereich der Google Cloud Console Monitoring und dann  Verfügbarkeitsdiagnosen aus:

        Verfügbarkeitsdiagnosen aufrufen

      2. Suchen Sie die Verfügbarkeitsdiagnose und wählen Sie sie aus.

        Im Diagramm Bestandene Prüfungen wird der Verlauf der Prüfungen angezeigt. Damit Sie feststellen können, 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 auf der Seite Betriebszeitdetails.

    • Rufen Sie bei synthetischen Monitoring-Systemen die Seite Verfügbarkeitsdetails auf, um zu ermitteln, wann der Fehler aufgetreten ist:

      1. Wählen Sie im Navigationsbereich der Google Cloud Console Monitoring und dann  Synthetisches Monitoring aus:

        Zu Synthetisches Monitoring

      2. Wählen Sie den synthetischen Monitor aus.

  2. Informationen zum Suchen verknüpfter Logdaten finden Sie im Abschnitt Logs suchen auf dieser Seite.

Sie werden nicht benachrichtigt, dass eine Verfügbarkeitsdiagnose fehlgeschlagen ist

Sie haben eine Verfügbarkeitsdiagnose konfiguriert und sehen dafür die Seite Betriebszeitdetails. Sie stellen fest, dass im Diagramm Bestandene Prüfungen angezeigt wird, dass mindestens eine Prüfung fehlgeschlagen ist. Sie haben jedoch keine Benachrichtigung erhalten.

Standardmäßig ist die Benachrichtigungsrichtlinie so konfiguriert, dass ein Vorfall erstellt und eine Benachrichtigung gesendet wird, wenn Prüfer 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 eine einzelne Region keine Antwort erhält. Wir empfehlen Ihnen jedoch, die Standardkonfiguration zu verwenden, damit Sie weniger Benachrichtigungen aufgrund von vorübergehenden Fehlern erhalten.

So rufen Sie eine Benachrichtigungsrichtlinie auf oder bearbeiten sie:

  1. Wählen Sie im Navigationsbereich der Google Cloud Console Monitoring und anschließend  Benachrichtigungen aus:

    Zu Benachrichtigungen

  2. Klicken Sie im Bereich Richtlinien auf Alle Richtlinien ansehen.

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

Fehler bei privaten Verfügbarkeitsdiagnosen beheben

In diesem Abschnitt werden einige Fehler beschrieben, die bei der Verwendung öffentlicher Verfügbarkeitsdiagnosen auftreten können, sowie Informationen zu deren Behebung.

Ihre öffentlichen Verfügbarkeitsdiagnosen schlagen fehl

Sie konfigurieren eine öffentliche Verfügbarkeitsdiagnose, erhalten jedoch eine Fehlermeldung, wenn Sie den Bestätigungsschritt ausführen.

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. Bei einer neuen Instanz kann ein Verbindungsfehler auftreten, wenn Sie keinen Webserver installiert haben. Weitere Informationen finden Sie im Schnellstart 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 des Servers für die Verfügbarkeitsdiagnose auflisten.
  • 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. Prüfen Sie, ob Ihre Firewall Traffic von den Verfügbarkeitsservern zulässt. Weitere Informationen finden Sie unter IP-Adressen für Verfügbarkeitsdiagnosen auflisten. Das Zeitlimit ist Teil der Antwortvalidierung angegeben.

Um Fehler bei fehlgeschlagenen öffentlichen Verfügbarkeitsdiagnosen zu beheben, können Sie Ihre Verfügbarkeitsdiagnosen so konfigurieren, dass während der Prüfung bis zu 3 ICMP-Pings gesendet werden. Mithilfe der Pings können Sie leichter zwischen Fehlern unterscheiden, die beispielsweise durch Netzwerkverbindungsprobleme und Zeitüberschreitungen in Ihrer Anwendung verursacht werden. Weitere Informationen finden Sie unter ICMP-Pings verwenden.

Fehler bei privaten Verfügbarkeitsdiagnosen beheben

In diesem Abschnitt werden einige Fehler beschrieben, die bei der Verwendung privater Verfügbarkeitsdiagnosen auftreten können, sowie Informationen zu deren Behebung.

Erstellen der Verfügbarkeitsdiagnose schlägt fehl

Ihre Google Cloud-Projekteinstellungen verhindern möglicherweise, dass die Rollen geändert werden, die dem Dienstkonto zugewiesen sind, mit dem Verfügbarkeitsdiagnosen Interaktionen mit dem Service Directory-Dienst verwalten. In diesem Fall schlägt das Erstellen der Verfügbarkeitsdiagnose fehl.

In diesem Abschnitt wird beschrieben, wie Sie die für das Dienstkonto erforderlichen Rollen zuweisen können:

Google Cloud Console

Wenn Sie die private Verfügbarkeitsdiagnose in der Google Cloud Console erstellen, führt die Google Cloud Console die Befehle aus, mit denen dem Dienstkonto die Service Directory-Rollen zugewiesen werden.

Informationen zum Zuweisen von Rollen zu einem Dienstkonto finden Sie unter Dienstkonto autorisieren.

API: Umfang festlegendes Projekt

Wenn Sie zum ersten Mal eine private Verfügbarkeitsdiagnose für einen Service Directory-Dienst und private Ressourcen in einem einzelnen Google Cloud-Projekt erstellen, kann die Anfrage erfolgreich sein oder fehlschlagen. Das Ergebnis hängt davon ab, ob Sie die automatische Rollenzuweisung für Dienstkonten in Ihrem Projekt deaktiviert haben:

  • Die erste Verfügbarkeitsdiagnose ist nur dann erfolgreich, wenn Ihr Projekt die automatische Rollenzuweisung für Dienstkonten zulässt. Ein Dienstkonto wird für Sie erstellt und erhält die erforderlichen Rollen.

  • Die erste Verfügbarkeitsdiagnose schlägt fehl, wenn Ihr Projekt keine automatische Rollenzuweisung für Dienstkonten zulässt. Ein Dienstkonto wird erstellt, aber es werden keine Rollen gewährt.

Wenn das Erstellen der Verfügbarkeitsdiagnose fehlschlägt, gehen Sie so vor:

  1. Autorisieren Sie das Dienstkonto.
  2. Warten Sie einige Minuten, bis die Berechtigungen weitergegeben wurden.
  3. Versuchen Sie noch einmal, die private Verfügbarkeitsdiagnose zu erstellen.

API: Überwachtes Projekt

Wenn Sie zum ersten Mal eine private Verfügbarkeitsdiagnose erstellen, die auf einen Service Directory-Dienst in einem überwachten Projekt oder private Ressourcen in einem anderen Google Cloud-Projekt ausgerichtet ist, schlägt die Anfrage fehl und führt zur Erstellung eines Monitoring-Dienstkontos.

Wie Sie das Dienstkonto autorisieren, hängt von der Anzahl der verwendeten Google Cloud-Projekte und deren Beziehungen ab. An Ihnen können bis zu vier Projekte beteiligt sein:

  • Das Projekt, in dem Sie die private Verfügbarkeitsdiagnose definiert haben.
  • Das überwachte Projekt, in dem Sie den Service Directory-Dienst konfiguriert haben.
  • Das Projekt, in dem Sie das VPC-Netzwerk konfiguriert haben.
  • Das Projekt, in dem Netzwerkressourcen wie VMs oder Load-Balancer konfiguriert sind. Dieses Projekt hat keine Rolle in der hier beschriebenen Dienstkontoautorisierung.

Wenn die erste Verfügbarkeitsdiagnose fehlschlägt, gehen Sie so vor:

  1. Autorisieren Sie das Dienstkonto.
  2. Warten Sie einige Minuten, bis die Berechtigungen weitergegeben wurden.
  3. Versuchen Sie noch einmal, die private Verfügbarkeitsdiagnose zu erstellen.

Zugriff verweigert

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

Prüfen Sie die Dienstkontoautorisierung für die Verwendung eines Umfangsprojekts oder eines überwachten Projekts, wie unter Erstellung der Verfügbarkeitsdiagnose schlägt fehl 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, zeigt die Verfügbarkeitsdiagnose weiterhin einen Erfolg an.

Wenn Ihre Dienstkonfiguration mehrere Endpunkte enthält, wird einer nach dem Zufallsprinzip 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 ausgefallen ist.

Standardheader

Die Verfügbarkeitsdiagnosen geben Fehler oder unerwartete Ergebnisse zurück. Dieser Fehler kann auftreten, wenn Sie Standardheaderwerte überschrieben haben.

Wenn eine Anfrage für eine private Verfügbarkeitsdiagnose an einen Zielendpunkt gesendet wird, enthält die Anfrage die folgenden Header und Werte:

Header Wert
HTTP_USER_AGENT GoogleStackdriverMonitoring-UptimeChecks(https://cloud.google.com/monitoring)
HTTP_CONNECTION keep-alive
HTTP_HOST IP-Adresse des Service Directory-Endpunkts
HTTP_ACCEPT_ENCODING gzip, deflate, br
CONTENT_LENGTH Wird anhand von nach Verfügbarkeitsdaten berechneten Daten berechnet

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

  • Die Verfügbarkeitsdiagnose meldet Fehler
  • Die Überschreibungswerte werden gelöscht und durch die Werte in der Tabelle ersetzt

Keine Daten sichtbar

Wenn sich die 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 die Verfügbarkeitsdiagnose 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.

Probleme mit synthetischen Monitoren beheben

Dieser Abschnitt enthält Informationen zur Fehlerbehebung bei synthetischen Monitoren.

Fehlermeldung nach dem Aktivieren der APIs

Sie öffnen den Erstellungsablauf 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. Danach wird empfohlen, zu warten und die Aktion noch einmal auszuführen.

Wenn Sie prüfen möchten, ob die API aktiviert ist, rufen Sie die Seite APIs und Dienste für Ihr Projekt auf:

Rufen Sie "APIs & Dienste" auf.

Nachdem Sie sich vergewissert haben, dass die API aktiviert ist, können Sie mit dem Erstellen fortfahren. Die Bedingung wird automatisch aufgelöst, wenn die API-Aktivierung über das Back-End weitergeleitet wurde.

Ausgehende HTTP-Anfragen werden nicht verfolgt

Sie konfigurieren den synthetischen Monitor so, dass Trace-Daten für HTTP-Ausgabeanfragen erfasst werden. Ihre Trace-Daten zeigen nur einen Span, ähnlich wie im folgenden Screenshot:

Cloud Trace zeigt nur einen Trace an.

Prüfen Sie zum Beheben dieses Problems, ob Ihrem Dienstkonto die Rolle des Cloud Trace-Agents (roles/cloudtrace.agent) gewährt wurde. Außerdem reicht die Rolle „Editor“ (roles/editor) aus.

So rufen Sie die Ihrem Dienstkonto zugewiesenen Rollen auf:

  1. Wählen Sie im Navigationsbereich der Google Cloud Console IAM aus:

    Zu IAM

  2. Wählen Sie Von Google bereitgestellte Rollenzuweisungen einschließen aus.

  3. Wenn das von Ihrem synthetischen Monitor verwendete Dienstkonto nicht aufgeführt ist oder ihm keine Rolle gewährt wurde, die die Berechtigungen der Rolle des Cloud Trace-Agent (roles/cloudtrace.agent) enthält, weisen Sie diese Rolle Ihrem Dienstkonto zu.

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

Status „In Bearbeitung“

Auf der Seite Synthetische Monitore 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 die Funktion nicht bereitgestellt werden konnte.

Prüfen Sie so, ob die Funktion nicht bereitgestellt werden konnte:

  • Achten Sie darauf, dass der Name der Cloud Functions-Funktion keinen Unterstrich enthält. Wenn ein Unterstrich vorhanden ist, entfernen Sie ihn und stellen Sie die Cloud Functions-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 zeigt an, dass die Funktion gelöscht wurde und der synthetische Monitor die Funktion daher nicht ausführen kann.

  • Öffnen Sie die Cloud Functions-Seite für die Funktion. Klicken Sie zum Öffnen dieser Seite über die Seite Details zum synthetischen Monitor 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

    Prüfen Sie den Funktionscode und beheben Sie die Fehler, die das Erstellen oder Bereitstellen der Funktion verhindern, um diesen Fehler zu beheben.

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

Warnungsstatus

Der Bereich Synthetic Monitors listet einen synthetischen Monitor mit dem Status Warning auf. Der Status Warning bedeutet, dass die Ausführungsergebnisse inkonsistent sind. Dies kann auf ein Designproblem bei Ihrem Test hindeuten oder auf ein inkonsistentes Verhalten hinweisen.

„Nicht bestanden“

Unter Synthetic Monitors wird ein synthetischer Monitor mit dem Status Failing aufgelistet. Weitere Informationen zum Grund des Fehlers 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 des synthetischen Monitors ändern.

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

  • Wenn der Fehler eine Ausführungszeit von 0ms zurückgibt, hat die Cloud Functions-Funktion möglicherweise nicht genügend Arbeitsspeicher. Bearbeiten Sie die Cloud Functions-Funktion, erhöhen Sie den Arbeitsspeicher auf mindestens 2 GiB und setzen Sie das CPU-Feld auf 1, um diesen Fehler zu beheben.

Löschen schlägt bei einem synthetischen Monitor fehl

Sie verwenden die Cloud Monitoring API, um einen synthetischen Monitor zu löschen, aber der API-Aufruf schlägt mit einer Antwort wie 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."
      }
    ]
  }
}

Löschen Sie zum Beheben des Fehlers die Benachrichtigungsrichtlinien, die die Ergebnisse des synthetischen Monitors überwachen, und löschen Sie dann den synthetischen Monitor.

Konfiguration einer Prüfung auf fehlerhafte Links kann nicht bearbeitet werden

Sie haben in der Google Cloud Console eine Prüfung auf fehlerhafte Links erstellt und möchten die zu testenden HTML-Elemente oder das URI-Zeitlimit, die Wiederholungsversuche, das Warten auf einen Selektor und die Optionen pro Link ändern. Wenn Sie die Prüfung auf fehlerhafte Links bearbeiten, werden in der Google Cloud Console jedoch keine Konfigurationsfelder angezeigt.

So beheben Sie diesen Fehler:

  1. Wählen Sie im Navigationsbereich der Google Cloud Console Monitoring und dann  Synthetisches Monitoring aus:

    Zu Synthetisches Monitoring

  2. Suchen Sie den synthetischen Monitor, den Sie bearbeiten möchten, klicken Sie auf Weitere Optionen und wählen Sie Bearbeiten aus.
  3. Klicken Sie auf Funktion bearbeiten.

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

    Informationen zu den Feldern und zur Syntax dieses Objekts finden Sie unter broken-links-ok/index.js.

  5. Klicken Sie auf Speichern.

In der Google Cloud Console können Screenshots nicht gespeichert werden

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

  • InvalidStorageLocation
  • StorageValidationError
  • BucketCreationError
  • ScreenshotFileUploadError

Um diese Fehler zu beheben, versuchen Sie Folgendes:

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

  • Sehen Sie sich die Logs Ihrer Cloud Functions-Funktion an. Weitere Informationen finden Sie unter Logs suchen.

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