Fehler beim synthetischen Monitoring und Verfügbarkeitsdiagnosen beheben

In diesem Dokument erfahren Sie, wie Sie Protokolldaten finden und Fehler beim synthetischen Monitoring und Verfügbarkeitsdiagnosen beheben:

• Logs suchen
• Fehlerbehebung bei Benachrichtigungen
• Fehler bei öffentlichen Verfügbarkeitsdiagnosen beheben
• Fehlerbehebung bei privaten Verfügbarkeitsdiagnosen
• Fehler beim synthetischen Monitoring beheben

Hinweis: Die HTTP(S)-Anfrageheader enthalten ein Feld mit der Bezeichnung Check-Id, das die ID des synthetischen Monitors oder der zugehörigen Verfügbarkeitsdiagnose speichert mit der Anfrage.

Logs suchen

Dieser Abschnitt enthält Informationen dazu, wie Sie Logs für Ihre synthetische Überwachung und Verfügbarkeitsdiagnosen:

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

2. Sie haben folgende Möglichkeiten:

   • So finden Sie alle Logs, die mit Ihren synthetischen Monitoren oder Verfügbarkeitsdiagnosen verknüpft sind: nach Ressourcentyp abfragen können. Sie können das Menü Ressource verwenden oder geben Sie eine Abfrage ein.

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

     resource.type="uptime_url"
     

     Wählen Sie für synthetisches Monitoring im Menü Ressource die Option Cloud Run-Überarbeitung oder geben Sie die folgende Abfrage in die Abfrage ein Editor und klicken Sie dann auf Abfrage ausführen:

     resource.type="cloud_run_revision"
     

   • Die Suchprotokolle, die Informationen zur erhaltenen Antwort enthalten Führen Sie während eines synthetischen Monitorings oder einer Verfügbarkeitsdiagnose Folgendes:

     • So führen Sie eine Abfrage mithilfe der ID des synthetischen Monitors oder der Verfügbarkeitsdiagnose durch: verwenden Sie das folgende Format, wenn Sie die ID in den Abfrageeditor eingeben: Klicken Sie dann auf Abfrage ausführen.

       labels.check_id="my-check-id"
       

     • Zum Abfragen von Logs, die Antwortdaten für Anfragen enthalten das von synthetischen Monitoring- und Verfügbarkeitsdiagnosen ausgegeben wird, geben Sie nach der folgenden Abfrage in den Abfrageeditor ein und klicken Sie auf Abfrage ausführen.

       "UptimeCheckResult"
       

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

     Diese Logs enthalten Folgendes:

     • ID des synthetischen Monitors oder der Verfügbarkeitsdiagnose, die in folgendem Verzeichnis gespeichert wird: Das Feld labels.check_id.

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

     • Wenn Trace-Daten erfasst werden, die ID eines verknüpften Trace, die im Feld trace gespeichert ist.

   • Um zu prüfen, ob Ihr Dienst Anfragen erhalten hat von Google Cloud-Servern hochladen möchten, 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 vom Verfügbarkeitsdiagnose-Server. Informationen zum Auflisten aller IP-Adressen -Adressen finden Sie unter IP-Adressen auflisten.

Fehlerbehebung bei Benachrichtigungen

In diesem Abschnitt werden einige Fehler beschrieben, die bei der Konfiguration Benachrichtigungsrichtlinien und Informationen zu deren Behebung.

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

1. Führen Sie einen der folgenden Schritte aus, um zu ermitteln, wann der Fehler zum ersten Mal aufgetreten ist:

   • Um bei Verfügbarkeitsdiagnosen festzustellen, wann der Fehler aufgetreten ist, Rufen Sie die Seite Verfügbarkeitsdetails auf:

     1. Rufen Sie in der Google Cloud Console die Seite  Verfügbarkeitsdiagnosen auf:

        Verfügbarkeitsdiagnosen aufrufen

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

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

        Im Diagramm Bestandene Prüfungen wird der Verlauf der Prüfungen angezeigt. Um zu ermitteln, wann die Verfügbarkeitsdiagnose zum ersten Mal fehlgeschlagen ist, müssen Sie möglicherweise Zeitraum für das Diagramm ändern Die Zeitraumauswahl in der Symbolleiste auf der Seite Verfügbarkeitsdetails.

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

     1. Wechseln Sie in der Google Cloud Console zur Seite Synthetisches Monitoring:

        Zur Seite Synthetisches Monitoring

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

     2. Suchen Sie den synthetischen Monitor und wählen Sie ihn aus.

2. Informationen zum Suchen zugehöriger Protokolldaten finden Sie im Abschnitt der Seite Logs finden.

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

Sie haben eine Verfügbarkeitsdiagnose konfiguriert und sehen sich die Seite Verfügbarkeitsdetails für die Prüfung ab. Im Diagramm Bestandene Prüfungen sehen Sie, dass mindestens eine Prüfung fehlgeschlagen. Sie haben jedoch keine Benachrichtigung erhalten.

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

Sie können die Bedingung der Benachrichtigungsrichtlinie bearbeiten, damit Sie benachrichtigt werden Eine einzelne Region erhält keine Antwort. Wir empfehlen Ihnen jedoch, die Standardkonfiguration zu verwenden, wodurch die Anzahl der Benachrichtigungen reduziert wird, bei vorübergehenden Ausfällen.

So rufen Sie eine Benachrichtigungsrichtlinie auf oder bearbeiten sie:

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

   Zu Benachrichtigungen

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

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 auf das Name der Richtlinie.

   Du kannst die Richtlinie auf der Seite Richtliniendetails ansehen und bearbeiten.

Fehlerbehebung bei öffentlichen Verfügbarkeitsdiagnosen

In diesem Abschnitt werden einige Fehler beschrieben, die bei der Verwendung von öffentlichen Verfügbarkeitsdiagnosen und liefert Informationen zu deren Behebung.

Ihre öffentlichen Verfügbarkeitsdiagnosen schlagen fehl

Sie konfigurieren eine öffentliche Verfügbarkeitsdiagnose, erhalten aber eine Fehlermeldung, wenn Sie führen Sie den Bestätigungsschritt aus.

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. sieh dir die 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 Listen Sie die IP-Adressen des Verfügbarkeitsdiagnose-Servers auf.
• 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; Siehe Listen Sie die IP-Adressen des Verfügbarkeitsdiagnose-Servers auf. Das Zeitlimit ist Teil der Antwortvalidierung angegeben.

Für die Fehlerbehebung bei fehlgeschlagenen öffentlichen Verfügbarkeitsdiagnosen können Sie Folgendes konfigurieren: Verfügbarkeitsdiagnosen senden, um bis zu drei ICMP-Pings während der Prüfung Mithilfe der Pings können Sie zwischen Fehler verursacht werden, z. B. durch Probleme mit der Netzwerkverbindung und durch Zeitüberschreitungen in Ihrer Anwendung. Weitere Informationen finden Sie unter Verwenden Sie ICMP-Pings.

Fehlerbehebung bei privaten Verfügbarkeitsdiagnosen

In diesem Abschnitt werden einige Fehler beschrieben, die bei der Verwendung von private Verfügbarkeitsdiagnosen und stellt Informationen zu deren Behebung bereit.

Erstellen der Verfügbarkeitsdiagnose schlägt fehl

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

In diesem Abschnitt wird beschrieben, wie Sie die vom Dienstkonto erfordert:

Google Cloud Console

Wenn Sie die private Verfügbarkeitsdiagnose mit der Google Cloud Console erstellen, gibt die Google Cloud Console Befehle aus, Service Directory-Rollen für das Dienstkonto.

Informationen zum Zuweisen von Rollen zu einem Dienstkonto Siehe Dienstkonto autorisieren.

API: Umfang festlegendes Projekt

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

• Die erste Verfügbarkeitsdiagnose ist erfolgreich, wenn Ihr Projekt dies zulässt Automatische Rollenzuweisungen für Dienstkonten. Ein Dienstkonto ist die für Sie erstellt wurden, und erhält die erforderlichen Rollen.

• Die erste Verfügbarkeitsdiagnose schlägt fehl, wenn Ihr Projekt dies nicht zulässt Automatische Rollenzuweisungen für Dienstkonten. Ein Dienstkonto ist erstellt, aber es werden keine Rollen gewährt.

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

1. Autorisieren Sie das Dienstkonto.
2. Warten Sie einige Minuten, bis die Berechtigungen wirksam werden.
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 eine Service Directory-Dienst in einem überwachten Projekt oder privaten Ressourcen in verschiedenen Google Cloud-Projekten schlägt die Anfrage fehl und führt zur Erstellung einer Monitoring-Dienstkonto.

Wie Sie das Dienstkonto autorisieren, hängt von der Anzahl der Google Cloud-Projekte, die Sie verwenden, und deren Beziehungen. Es 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 das Service Directory-Dienst.
• Das Projekt, in dem Sie das VPC-Netzwerk konfiguriert haben.
• Das Projekt, in dem Netzwerkressourcen wie VMs oder Load-Balancer verwendet werden konfiguriert. Dieses Projekt hat keine Rolle in der Dienstkontoautorisierung die hier besprochen werden.

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

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

Zugriff verweigert

Ihre Verfügbarkeitsdiagnosen schlagen fehl und es werden VPC_ACCESS_DENIED Ergebnisse zurückgegeben. Dieses Ergebnis bedeutet, dass ein Teil Ihrer Netzwerkkonfiguration oder Ihres Dienstkontos Autorisierung ist nicht korrekt.

Dienstkontoautorisierung für die Verwendung eines Bereichs prüfen oder ein überwachtes Projekt wie in Erstellen der Verfügbarkeitsdiagnose schlägt fehl.

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

Ungewöhnliche Ergebnisse privater Verfügbarkeitsdiagnosen

Sie haben einen Service Directory-Dienst mit mehrere VMs vorhanden sind und Ihre Dienstkonfiguration mehrere Endpunkte enthält. Wenn Sie eine der VMs herunterfahren, zeigt die Verfügbarkeitsdiagnose weiterhin Erfolg an.

Wenn Ihre Dienstkonfiguration mehrere Endpunkte enthält, ist einer davon zufällig ausgewählt werden. Wenn die mit dem ausgewählten Endpunkt verknüpfte VM ausgeführt wird, ist die Verfügbarkeitsdiagnose erfolgreich, obwohl eine der VMs ausgefallen ist.

Standardheader

Die Verfügbarkeitsdiagnosen geben Fehler oder unerwartete Ergebnisse zurück. Dies könnte tritt auf, wenn Sie Standardheaderwerte überschrieben haben.

Wenn eine Anfrage für eine private Verfügbarkeitsdiagnose an einen Zielendpunkt gesendet wird, Die Anfrage enthält 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	Berechnet aus Post-Daten zur Betriebszeit

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

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

Keine Daten sichtbar

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

Achten Sie darauf, dass das Google Cloud-Projekt, das die Verfügbarkeitsdiagnose enthält, überwacht das Google Cloud-Projekt, das die Service Directory-Dienst.

Weitere Informationen zum Auflisten überwachter Projekte und zum Hinzufügen zusätzlicher finden Sie unter Messwertbereich für mehrere Projekte konfigurieren

Fehler beim synthetischen Monitoring beheben

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

Fehlermeldung nach dem Aktivieren der APIs

Sie öffnen den Erstellungsablauf für einen synthetischen Monitor und werden aufgefordert, die Funktion zu aktivieren mindestens eine API. Nachdem Sie die APIs aktiviert haben, wird eine Meldung wie die folgende angezeigt wird 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 überprüfen, ob die API aktiviert ist, und dann weist darauf hin, dass Sie warten und die Aktion wiederholen.

Wenn Sie überprüfen möchten, ob die API aktiviert ist, gehen Sie zu APIs und Dienste für Ihrem Projekt:

Rufen Sie "APIs & Dienste" auf.

Nachdem Sie sich vergewissert haben, dass die API aktiviert ist, können Sie mit der Ablauf zu erstellen. Die Bedingung löst sich automatisch nach der API auf Die Aktivierung wird über das Back-End weitergegeben.

Ausgehende HTTP-Anfragen werden nicht verfolgt

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

Prüfen Sie, ob Ihr Dienstkonto Ihnen wurde die Rolle des Cloud Trace-Agents (roles/cloudtrace.agent) gewährt. Die Rolle „Bearbeiter“ (roles/editor) ist ebenfalls ausreichend.

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

1. Öffnen Sie in der Google Cloud Console die Seite IAM:

   Rufen Sie IAM auf.

   Wenn Sie diese Seite über die Suchleiste finden, wählen Sie das Ergebnis mit der Zwischenüberschrift IAM und Verwaltung.

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

3. Wenn das von Ihrem synthetischen Monitor verwendete Dienstkonto nicht aufgeführt ist hat keine Rolle mit den Berechtigungen der Rolle Cloud Trace-Agent (roles/cloudtrace.agent) und weisen Sie diese Rolle dann Ihrem Dienstkonto.

   Wenn Sie den Namen Ihres Dienstkontos nicht kennen, die Option Dienstkonten aus.

Status „In Bearbeitung“

Auf der Seite Synthetisches Monitoring wird ein synthetischer Monitor aufgeführt. mit dem Status In progress. Der Status In progress bedeutet, dass weil der synthetische Monitor kürzlich erstellt wurde und keine Daten vorhanden sind. oder die Funktion nicht bereitgestellt werden konnte.

Um festzustellen, ob die Funktion nicht bereitgestellt werden konnte, versuchen Sie Folgendes:

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

• Öffnen Sie die Cloud Functions-Seite für die Funktion. So öffnen Sie diese Seite: Klicken Sie auf der Seite Details zum synthetischen Monitor auf Code und dann auf auf den Funktionsnamen.

  Wenn eine Meldung wie die folgende angezeigt wird, ist die Funktion fehlgeschlagen die Sie bereitstellen können.

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

  Überprüfen Sie den Funktionscode und korrigieren Sie die Fehler, um diesen Fehler zu beheben. durch die die Funktion nicht erstellt oder bereitgestellt wird.

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

Warnstatus

Das synthetische Monitoring listet einen synthetischen Monitor auf. mit dem Status Warning. Der Status Warning bedeutet, dass die Ausführung Ergebnisse sind inkonsistent. Dies könnte auf ein Designproblem mit Ihrem Test oder es kann darauf hindeuten, dass das, was getestet wird, ein inkonsistentes Verhalten aufweist.

Status „Nicht bestanden“

Das synthetische Monitoring listet einen synthetischen Monitor mit dem Status Failing Um mehr über die Fehlerursache zu erfahren, Aufrufen des letzten Ausführungsverlaufs.

• Wenn die Fehlermeldung Request failed with status code 429 angezeigt wird, wurde der Befehl vom Ziel der HTTP-Anfrage abgelehnt. Lösung fehlgeschlagen ist, müssen Sie das Ziel des synthetischen Monitors ändern.

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

• Wenn der Fehler die Ausführungszeit 0ms zurückgibt, ist der Die Cloud Functions-Funktion hat möglicherweise nicht mehr genügend Arbeitsspeicher. Lösung Fehler beheben, die Cloud Functions-Funktion bearbeiten und dann den Arbeitsspeicher erhöhen auf mindestens 2 GiB und legen Sie das CPU-Feld auf 1 fest.

Das Löschen schlägt bei einem synthetischen Monitor fehl

Sie verwenden die Cloud Monitoring API, um einen synthetischen Monitor zu löschen, aber die API mit einer Antwort wie der folgenden fehlschlägt:

{
  "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 Benachrichtigungsrichtlinien, die Ergebnisse des synthetischen Monitors überwachen und dann den synthetischen Monitor löschen.

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

Sie haben mit der Google Cloud Console eine Prüfung auf fehlerhafte Links erstellt und möchten, die getesteten HTML-Elemente ändern oder URI-Zeitüberschreitung, Wiederholungsversuche, Warten auf die Auswahl und Optionen pro Link. Wenn Sie jedoch die Prüfung auf fehlerhafte Links bearbeiten, Konfigurationsfelder anzeigen.

So beheben Sie diesen Fehler:

1. Wechseln Sie in der Google Cloud Console zur Seite Synthetisches Monitoring:

   Zur Seite Synthetisches Monitoring

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

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 options-Objekt in der Datei index.js und dann Klicken Sie 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.

Google Cloud Console-Anzeige, bei der Screenshots nicht gespeichert werden können

Hinweis: Ein synthetischer Monitor, der keine Screenshots speichern kann, die in einem URI enthaltenen Links testen

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 Warnungen angezeigt: mit ausführlicheren Informationen:

• InvalidStorageLocation
• StorageValidationError
• BucketCreationError
• ScreenshotFileUploadError

Um diese Fehler zu beheben, gehen Sie so vor:

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

• Sehen Sie sich die Logs für Ihre Cloud Functions-Funktion an. Weitere Informationen finden Sie unter Logs suchen.

• Prüfen Sie, ob das Dienstkonto, das im entsprechenden Cloud Function haben die Rolle „Identity and Access Management“, und in Cloud Storage-Buckets schreiben.