Fehler beim synthetischen Monitoring und Verfügbarkeitsdiagnosen beheben

Dieses Dokument enthält Informationen zum Suchen von Logdaten und zur Fehlerbehebung bei Fehlern bei synthetischem Monitoring und Verfügbarkeitsdiagnosen:

• 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 dem Namen Check-Id, in dem die Kennung des synthetischen Monitors oder der Verfügbarkeitsdiagnose gespeichert ist, die mit der Anfrage verknüpft sind.

Logs suchen

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

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:

   • Sie können nach Ressourcentyp abfragen, um alle Logs zu ermitteln, die mit Ihren synthetischen Monitoren oder Verfügbarkeitsdiagnosen verknüpft sind. 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 auf Abfrage ausführen:

     resource.type="uptime_url"
     

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

     resource.type="cloud_run_revision"
     

   • Die Suchlogs, die Informationen zu der Antwort enthalten, die während eines synthetischen Monitorings oder einer Verfügbarkeitsdiagnose empfangen wurde, haben folgende Möglichkeiten:

     • Wenn Sie die ID des synthetischen Monitors oder der Verfügbarkeitsdiagnose für Abfragen verwenden möchten, geben Sie die ID im Abfrageeditor im folgenden Format ein. Klicken Sie dann auf Abfrage ausführen.

       labels.check_id="my-check-id"
       

     • Wenn Sie Logs abfragen möchten, die Antwortdaten für Anfragen von synthetischen Monitoren und Verfügbarkeitsdiagnosen enthalten, geben Sie die folgende 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 "UptimeCheckResult" enthalten.

     Diese Logs enthalten Folgendes:

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

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

     • Wenn Trace-Daten erfasst werden, die ID eines verknüpften 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 Verfügbarkeitsdiagnose-Servern 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. Außerdem erhalten Sie 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 zu ermitteln, 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 den Zeitraum für das Diagramm ändern. Die Zeitraumauswahl befindet sich in der Symbolleiste auf der Seite Verfügbarkeitsdetails.

   • Wenn Sie bei synthetischen Monitoren 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  Synthetisches Monitoring auf:

        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 Logdaten finden Sie im Abschnitt Logs suchen auf dieser Seite.

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 diese Diagnose an. Im Diagramm Bestandene Prüfungen sehen Sie, 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, die die Anzahl der Benachrichtigungen reduziert, die Sie aufgrund von vorübergehenden Fehlern erhalten können.

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 dann auf den Namen 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 öffentlicher Verfügbarkeitsdiagnosen auftreten können. Außerdem finden Sie Informationen zu deren Behebung.

Ihre öffentlichen Verfügbarkeitsdiagnosen schlagen fehl

Sie konfigurieren eine öffentliche Verfügbarkeitsdiagnose, erhalten jedoch beim Ausführen des Verifizierungsschritts 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. Siehe dazu 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 Server-IP-Adressen für Verfügbarkeitsdiagnosen 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 für die Verfügbarkeitsdiagnose verwendeten Servern zulässt. Weitere Informationen finden Sie unter Server-IP-Adressen für Verfügbarkeitsdiagnosen auflisten. Das Zeitlimit ist Teil der Antwortvalidierung angegeben.

Zur Fehlerbehebung mit fehlgeschlagenen öffentlichen Verfügbarkeitsdiagnosen können Sie Ihre Verfügbarkeitsdiagnosen so konfigurieren, dass während der Prüfung bis zu drei ICMP-Pings gesendet werden. Die Pings können Ihnen helfen, zwischen Ausfällen zu unterscheiden, die z. B. durch Probleme mit der Netzwerkverbindung verursacht werden, und Zeitüberschreitungen in Ihrer Anwendung. 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 Verfügbarkeitsdiagnosen auftreten können. Außerdem finden Sie 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 die Erstellung der Verfügbarkeitsdiagnose fehl.

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

Google Cloud Console

Wenn Sie die private Verfügbarkeitsdiagnose mit der Google Cloud Console erstellen, gibt 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 erfolgreich, wenn Ihr Projekt automatische Rollenzuweisungen 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 in Ihrem Projekt automatische Rollenzuweisungen für Dienstkonten nicht zulässig sind. Ein Dienstkonto wird 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 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 zum Erstellen eines Monitoring-Dienstkontos.

Wie Sie das Dienstkonto autorisieren, hängt von der Anzahl der verwendeten Google Cloud-Projekte und deren Beziehungen ab. 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 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 in der hier beschriebenen Dienstkontoautorisierung keine Rolle.

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. Dies bedeutet, dass ein Teil Ihrer Netzwerkkonfiguration oder Dienstkontoautorisierung nicht korrekt ist.

Prüfen Sie die Dienstkontoautorisierung für die Verwendung eines den Umfangs festgelegten Projekts oder eines überwachten Projekts, wie unter Erstellen der Verfügbarkeitsdiagnose schlägt fehl beschrieben.

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

Ungewöhnliche Ergebnisse privater 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 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 auch dann erfolgreich, wenn eine der VMs ausgefallen ist.

Standardheader

Die Verfügbarkeitsdiagnosen geben Fehler oder unerwartete Ergebnisse zurück. Dies 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	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

Sie sehen im Dashboard für Verfügbarkeitsdiagnosen keine Daten, wenn sich die Verfügbarkeitsdiagnose in einem anderen Google Cloud-Projekt als dem Service Directory-Dienst befindet.

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 zusätzlicher Projekte finden Sie unter Messwertbereich für mehrere Projekte konfigurieren.

Fehler beim synthetischen Monitoring 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 diese 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. Anschließend 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 du dich vergewissert hast, dass die API aktiviert ist, kannst du mit dem Erstellen fortfahren. Die Bedingung wird automatisch aufgelöst, nachdem die API-Aktivierung durch das Back-End weitergegeben wurde.

Ausgehende HTTP-Anfragen werden nicht verfolgt

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

Prüfen Sie zum Beheben dieses Problems, ob Ihrem Dienstkonto die Rolle Cloud Trace-Agent (roles/cloudtrace.agent) zugewiesen wurde. 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:

   Zu IAM

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

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 in der Rolle des Cloud Trace-Agents (roles/cloudtrace.agent) enthält, weisen Sie diese Rolle Ihrem Dienstkonto zu.

   Wenn Sie den Namen des Dienstkontos nicht kennen, wählen Sie im Navigationsmenü die Option 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 kürzlich erstellt wurde und keine Daten zum Anzeigen 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 Ihrer 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 auf der 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.

Warnstatus

Das synthetische Monitoring 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 oder auf ein inkonsistentes Verhalten hinweisen.

Status „Nicht bestanden“

Das synthetische Monitoring listet einen synthetischen Monitor mit dem Status Failing auf. Weitere Informationen zur Fehlerursache finden Sie im aktuellen Ausführungsverlauf.

• Wenn die Fehlermeldung Request failed with status code 429 angezeigt wird, wurde der Befehl vom Ziel der HTTP-Anfrage 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 der Fehler die Ausführungszeit 0ms zurückgibt, steht der Cloud Functions-Funktion möglicherweise nicht mehr genügend Arbeitsspeicher zur Verfügung. Um diesen Fehler zu beheben, bearbeiten Sie Ihre Cloud Functions-Funktion, erhöhen Sie den Arbeitsspeicher 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. Der API-Aufruf schlägt jedoch 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 dann den synthetischen Monitor.

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

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

So beheben Sie diesen Fehler:

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

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

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

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

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, gehen Sie so vor:

• 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 für Ihre Cloud Functions-Funktion an. Weitere Informationen finden Sie unter Logs suchen.

• Prüfen Sie, ob das in der entsprechenden Cloud Function verwendete Dienstkonto eine Rolle für Identity and Access Management hat, mit der Cloud Storage-Buckets erstellt, darauf zugegriffen und darin geschrieben werden kann.