Fehlerbehebung bei synthetischen Monitorings und Verfügbarkeitsdiagnosen

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

• Protokolle finden
• Fehlerbehebung bei Benachrichtigungen
• Fehler bei öffentlichen Verfügbarkeitsdiagnosen beheben
• Probleme mit privaten Verfügbarkeitsdiagnosen beheben
• Fehler beim synthetischen Monitoring beheben

Hinweis: Die HTTP(S)-Anfrageheader enthalten ein Feld mit der Bezeichnung Check-Id, in dem die Kennung des synthetischen Monitors oder der Verfügbarkeitsdiagnose gespeichert ist, die mit der Anfrage verknüpft ist.

Logs suchen

In diesem Abschnitt erfahren Sie, 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:

   • Wenn Sie alle Logs finden möchten, die mit Ihren synthetischen Monitoren oder Verfügbarkeitsdiagnosen verknüpft sind, können Sie nach dem Ressourcentyp suchen. 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 URL der 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 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 während eines synthetischen Monitorings oder einer Verfügbarkeitsdiagnose Folgendes:

     • Wenn Sie eine Abfrage mit der ID des synthetischen Monitors oder der Uptime-Prüfung ausführen möchten, verwenden Sie das folgende Format, wenn Sie die ID in den Abfrageeditor eingeben, und klicken Sie dann auf Abfrage ausführen.

       labels.check_id="my-check-id"
       

     • Abfrage 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:

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

     • Bei synthetischen Monitoren der Name Ihrer Cloud Run-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 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.

Probleme mit Benachrichtigungen beheben

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

Ein Prüftool ist fehlgeschlagen, andere nicht

Sie überprüfen die Messwerte der Verfügbarkeitsdiagnose und stellen fest, dass ein Prüfung hat einen Fehler gemeldet, als alle anderen Prüfungen Erfolg gemeldet haben.

Sie müssen nichts weiter tun, um diese Situation zu beheben.

Wenn nur eine Prüfung einen Fehler meldet, kann dieser Fehler auf Zeitüberschreitung beim Befehl checker aufgrund eines Netzwerkproblems. Das heißt, der Befehl schlägt nicht fehl, sondern wird nicht innerhalb des angegebenen Zeitlimits abgeschlossen.

Bei Benachrichtigungsrichtlinien, die die Standardkonfiguration verwenden, sind Fehler von mindestens zwei Prüfern erforderlich, bevor ein Vorfall erstellt und eine Benachrichtigung gesendet wird. Ein Fehler, der von einem einzelnen Prüfer gemeldet wird, führt nicht zu einer Benachrichtigung.

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

1. So ermitteln Sie, wann der Fehler aufgetreten ist:

   • Wenn Sie bei Verfügbarkeitsdiagnosen feststellen möchten, wann der Fehler aufgetreten ist, rufen Sie die Seite Details zur Verfügbarkeit 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 Überprüfte Elemente 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 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:

        Gehen Sie zu 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 Protokolle finden auf dieser Seite.

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

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 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 bearbeiten, damit Sie benachrichtigt werden Eine einzelne Region erhält keine Antwort. Wir empfehlen jedoch, die Standardkonfiguration zu verwenden. Dadurch wird die Anzahl der Benachrichtigungen reduziert, die Sie aufgrund vorübergehender Fehler erhalten könnten.

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.

   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. Außerdem finden Sie Informationen zur Fehlerbehebung.

Ihre öffentlichen Verfügbarkeitsdiagnosen schlagen fehl

Sie konfigurieren eine öffentliche Verfügbarkeitsdiagnose, erhalten aber beim Bestätigungsschritt 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. 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 IP-Adressen der Server 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; 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 ICMP-Pings verwenden.

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 fehlgeschlagen

Die Google Cloud-Projekteinstellungen verhindern möglicherweise die Änderung der Rollen, die dem Dienstkonto zugewiesen sind, mit dem die Uptime-Prüfungen die Interaktionen mit dem Dienstverzeichnis 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 Uptime-Prüfung mit der Google Cloud Console erstellen, werden über die Google Cloud Console die Befehle ausgegeben, um dem Dienstkonto die Rollen für das Dienstverzeichnis zu gewähren.

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 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 übernommen 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 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 konfiguriert werden. Dieses Projekt spielt bei der hier beschriebenen Autorisierung von Dienstkonten keine Rolle.

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

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

Zugriff verweigert

Ihre Verfügbarkeitsdiagnosen schlagen mit dem Ergebnis VPC_ACCESS_DENIED fehl. Dies bedeutet, dass ein Aspekt Ihrer Netzwerkkonfiguration oder Dienstkontoautorisierung nicht korrekt ist.

Prüfen Sie die Autorisierung Ihres Dienstkontos für die Verwendung eines Projekts mit Begrenzung oder eines überwachten Projekts, wie unter Erstellen der Uptime-Prüfung fehlgeschlagen beschrieben.

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, wird einer davon zufällig ausgewählt. Wenn die mit dem ausgewählten Endpunkt verknüpfte VM ausgeführt wird, ist die Verfügbarkeitsdiagnose erfolgreich, obwohl eine der VMs ausgefallen ist.

Standard-Header

Ihre Verfügbarkeitsdiagnosen geben Fehler oder unerwartete Ergebnisse zurück. Das kann passieren, 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	Aus Daten zu Verfügbarkeitsmeldungen 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 aus der Tabelle ersetzt

Keine Daten sichtbar

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

Das Google Cloud-Projekt, das die Uptime-Prüfung enthält, muss das Google Cloud-Projekt überwachen, das den Service Directory-Dienst enthält.

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

Probleme mit synthetischen Monitoren beheben

In diesem Abschnitt finden Sie Informationen zur Fehlerbehebung bei synthetischen Monitoren.

Fehlermeldung nach dem Aktivieren der APIs

Sie öffnen den Erstellungsvorgang 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 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 prüfen, ob die API aktiviert ist. Anschließend wird empfohlen, zu warten und die Aktion noch einmal zu versuchen.

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

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 gefolgt

Sie konfigurieren den synthetischen Monitor so, dass Trace-Daten für die Ausgabe erfasst werden. HTTP-Anfragen Ihre Trace-Daten enthalten nur einen Span, ähnlich wie im 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 sind:

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 aus, dessen 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 in 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 Synthetische Monitore ist ein synthetischer Monitor mit dem Status In progress aufgeführt. Ein Status von In progress bedeutet, dass der synthetische Monitor vor Kurzem erstellt wurde und keine Daten zum Darstellen vorhanden sind oder dass die Funktion nicht bereitgestellt werden konnte.

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

• Der Name Ihrer Cloud Run-Funktion darf keinen Unterstrich enthalten. 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 gibt an, dass die Funktion gelöscht wurde und daher der synthetische Monitor die Funktion nicht ausführen kann.

• Öffnen Sie die Seite „Cloud Run-Funktionen“ für die Funktion. Wenn Sie diese Seite von der Seite Details zum synthetischen Monitor aus öffnen möchten, klicken Sie auf Code und dann 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ührungsergebnisse inkonsistent sind. Dies kann auf ein Designproblem mit Ihrem Test hinweisen oder darauf, dass das Testobjekt inkonsistent reagiert.

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. Um diesen Fehler zu beheben, müssen Sie das Ziel Ihres synthetischen Monitors ändern.

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

• Wenn bei einem Fehler eine Ausführungszeit von 0ms zurückgegeben wird, ist der Arbeitsspeicher der Cloud Run-Funktion möglicherweise aufgebraucht. Lösung Fehler beheben, die Cloud Run-Funktion bearbeiten und dann den Arbeitsspeicher erhöhen auf mindestens 2 GiB und legen Sie das CPU-Feld auf 1 fest.

Löschen eines synthetischen Monitors schlägt fehl

Sie verwenden die Cloud Monitoring API, um einen synthetischen Monitor zu löschen. Der API-Aufruf schlägt jedoch fehl und Sie erhalten eine Antwort, die in etwa so aussieht:

{
  "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 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 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 die Funktion zum Prüfen auf fehlerhafte Links bearbeiten, werden in der Google Cloud Console jedoch keine Konfigurationsfelder angezeigt.

So beheben Sie diesen Fehler:

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

   Gehen Sie zu 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.

In der Google Cloud Console wird angezeigt, dass das Speichern von Screenshots fehlgeschlagen ist

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

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

So können Sie diese Fehler 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.

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

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