Fehlerbehebung bei synthetischen Monitoren und Verfügbarkeitsdiagnosen

Wenn Sie Probleme beim Erstellen, Ausführen oder Löschen eines synthetischen Monitors oder einer Verfügbarkeitsdiagnose haben oder wenn Sie keine erwarteten Benachrichtigungen erhalten, können Sie die Ursache ermitteln, indem Sie Ausführungsprotokolle, Messwerte und Traces untersuchen. Sie können auch häufige Konfigurationsfehler im Zusammenhang mit IAM-Berechtigungen, VPC Service Controls-Perimetern und privaten Netzwerkzielen beheben.

Logs finden

Damit Sie Anfragen mit Ihren Logs in Beziehung setzen können, enthalten HTTP- und HTTPS-Anfragen, die von Cloud Monitoring gesendet werden, einen Check-Id-Header, in dem die ID des zugehörigen synthetischen Monitors oder Uptime-Checks gespeichert ist. So finden Sie Logs für Ihre synthetischen Monitore und Verfügbarkeitsdiagnosen::

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

    Zum Log-Explorer

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

  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 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 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 synthetische Monitore im Menü Ressource die Option Cloud Run-Überarbeitung aus oder geben Sie die folgende Abfrage in den Abfrageeditor ein und klicken Sie auf Abfrage ausführen:

      resource.type="cloud_run_revision"

    • So finden Sie Logs, 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 der Verfügbarkeitsdiagnose ausfü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 Verfügbarkeitsdiagnosen ausgegeben wurden, geben Sie die folgende Abfrage in den Abfrageeditor ein und klicken Sie dann 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.

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

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

    • 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 Adressen, die von den Uptime-Check-Servern verwendet werden. 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. Außerdem finden Sie Informationen zur Fehlerbehebung.

Ein Checker ist fehlgeschlagen, andere nicht

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

Es besteht kein Handlungsbedarf.

Wenn nur eine Prüfung einen Fehler meldet, kann dies daran liegen, dass das Zeitlimit für den Befehl 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üfern erforderlich, bevor eine Benachrichtigung erstellt und 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 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. 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 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 auf der Seite Details zur Betriebszeit.

    • Um festzustellen, wann der Fehler bei synthetischen Monitoren aufgetreten ist, rufen Sie 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 aus.
      3. Suchen Sie den synthetischen Monitor und wählen Sie ihn aus.

  2. Informationen zum Suchen zugehöriger Logdaten finden Sie unter Logs finden.

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

Sie haben eine Verfügbarkeitsdiagnose konfiguriert und rufen die Seite Verfügbarkeitsdetails für diese Diagnose auf. Sie sehen im Diagramm Passed checks (Bestandene Prüfungen), dass mindestens eine Prüfung fehlgeschlagen ist. Sie haben jedoch keine Benachrichtigung erhalten.

Standardmäßig ist die Benachrichtigungsrichtlinie so konfiguriert, dass 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 in einer einzelnen Region keine Antwort eingeht. 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:

    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 aus.
  3. Klicken Sie im Bereich Richtlinien auf Alle Richtlinien ansehen.

  4. Suchen Sie nach der 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 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, sowie Informationen zur Behebung dieser Fehler.

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. Auf einer neuen Instanz kann ein Verbindungsfehler auftreten, wenn Sie keinen Webserver installiert haben. Weitere Informationen finden Sie in der 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 Server-IP-Adressen 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 Server-IP-Adressen 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. Die Pings können Ihnen helfen, zwischen Fehlern zu 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.

Sie können keine öffentliche Verfügbarkeitsdiagnose erstellen

Sie versuchen, eine öffentliche Verfügbarkeitsdiagnose zu erstellen, aber die Aktion schlägt mit einer Meldung ähnlich der folgenden fehl:

Public uptime checks cannot be configured in a VPC Service Controls perimeter.

Diese Fehlermeldung weist darauf hin, dass sich Ihr Google Cloud -Projekt in einem aktivierten VPC Service Controls-Perimeter befindet. Sie können für diese Konfigurationen keine öffentlichen Verfügbarkeitsdiagnosen erstellen.

Erstellen Sie eine private Verfügbarkeitsdiagnose, um dieses Problem zu beheben.

Fehlerbehebung bei privaten Verfügbarkeitsdiagnosen

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

Erstellung der Verfügbarkeitsdiagnose schlägt fehl

Die Google Cloud Projekteinstellungen verhindern möglicherweise, dass die Rollen geändert werden, die dem Dienstkonto zugewiesen sind, das von Verfügbarkeitsdiagnosen 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:

Console

Wenn Sie die Google Cloud Console verwenden, um die private Verfügbarkeitsdiagnose zu erstellen, werden in der Google Cloud Console die Befehle zum Zuweisen der Service Directory-Rollen an das Dienstkonto ausgegeben.

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

gcloud: Umfang festlegendes Projekt

Wenn Sie zum ersten Mal eine private Uptime-Prüfung 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 automatische Rollenzuweisungen für Dienstkonten in Ihrem Projekt deaktiviert haben:

  • Die erste Erstellung eines Uptime-Checks ist erfolgreich, wenn in Ihrem Projekt automatische Rollenzuweisungen für Dienstkonten zulässig sind. Ein Dienstkonto wird für Sie erstellt und erhält die erforderlichen Rollen.

  • Das Erstellen des ersten Uptime-Checks schlägt fehl, wenn in Ihrem Projekt keine automatischen Rollenzuweisungen für Dienstkonten zulässig sind. Ein Dienstkonto wird erstellt, aber es werden keine Rollen zugewiesen.

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

  1. Dienstkonto autorisieren
  2. Es kann einige Minuten dauern, bis die Berechtigungen übernommen werden.
  3. Versuchen Sie noch einmal, die private Verfügbarkeitsdiagnose zu erstellen.

gcloud: Überwachtes Projekt

Wenn Sie zum ersten Mal einen privaten Uptime-Check erstellen, der auf einen Service Directory-Dienst in einem überwachten Projekt oder auf private Ressourcen in einem anderen Google Cloud Projekt ausgerichtet ist, schlägt die Anfrage fehl und es wird ein Monitoring-Dienstkonto erstellt.

Wie Sie das Dienstkonto autorisieren, hängt von der Anzahl derGoogle Cloud -Projekte ab, die Sie verwenden, und von ihren Beziehungen. Möglicherweise sind bis zu vier Projekte beteiligt:

  • 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 spielt bei der hier beschriebenen Dienstkontoautorisierung keine Rolle.

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

  1. Dienstkonto autorisieren
  2. Es kann einige Minuten dauern, bis die Berechtigungen übernommen werden.
  3. Versuchen Sie noch einmal, die private Verfügbarkeitsdiagnose zu erstellen.

Cloud Run-Dienst kann nicht als Ziel verwendet werden

Sie möchten einen Cloud Run-Dienst mit einer privaten Uptime-Prüfung als Ziel festlegen, aber ein Cloud Run-Dienst hat keine IPv4-Adresse in einem VPC-Netzwerk des Kunden, die Sie als Service Directory-Endpunkt registrieren können.

Wenn Sie einen Cloud Run-Dienst mit einer privaten Uptime-Prüfung als Ziel verwenden möchten, konfigurieren Sie einen internen Application Load Balancer mit einem serverlosen NEG-Backend und registrieren Sie die interne IP-Adresse des Load Balancers in Service Directory. Ein Beispiel für das Einrichten des Load Balancers finden Sie unter Regionalen internen Application Load Balancer mit Cloud Run einrichten.

Zugriff verweigert

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

Prüfen Sie die Autorisierung Ihres Dienstkontos für die Verwendung eines Bereichsprojekts oder eines überwachten Projekts, wie unter Fehler beim Erstellen von Uptime-Checks 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 bei der Uptime-Prüfung weiterhin „Erfolg“ 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 Diagnose erfolgreich, auch wenn eine der VMs ausgefallen 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 eine private Uptime-Prüfung 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 Daten zur Verfügbarkeit POST

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 die Verfügbarkeitsdiagnose keine Daten angezeigt.

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 und Hinzufügen von überwachten Projekten 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 auszuführen.

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 Trace-Daten enthalten nur einen Span, ähnlich wie im folgenden Screenshot:

In Cloud Trace wird nur ein Trace angezeigt.

Um dieses Problem zu beheben, müssen Sie dafür sorgen, dass 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 sind:

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

    IAM aufrufen

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

  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 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 Synthetische Monitore wird 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 Anzeigen vorhanden sind oder dass die Bereitstellung der Funktion fehlgeschlagen ist.

So stellen Sie fest, 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. Klicken Sie auf der Seite Details zum synthetischen Monitor auf Code und dann auf den Funktionsnamen, um diese Seite zu öffnen.

    Wenn Sie eine Meldung wie die folgende sehen, konnte die Funktion nicht bereitgestellt werden.

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

    Sehen Sie sich den Funktionscode an und beheben 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

Auf der Seite Synthetische Monitore wird ein synthetischer Monitor 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“

Auf der Seite 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 der Fehler eine Ausführungszeit von 0ms zurückgibt, kann es sein, dass die Cloud Run-Funktion nicht mehr genügend Arbeitsspeicher hat. 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 Tools zur Überprüfung auf defekte Links kann nicht bearbeitet werden

Sie haben mit der Google Cloud -Konsole eine Prüfung 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 pro Link anpassen. Wenn Sie den Link-Checker jedoch bearbeiten, werden die Konfigurationsfelder in der Google Cloud Konsole 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 aus.
  3. Suchen Sie den synthetischen Monitor, den Sie bearbeiten möchten, klicken Sie auf  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.

In derGoogle Cloud -Konsole wird gemeldet, dass das Speichern von Screenshots fehlgeschlagen ist.

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 mit detaillierteren Informationen angezeigt:

  • InvalidStorageLocation
  • StorageValidationError
  • BucketCreationError
  • ScreenshotFileUploadError

Versuchen Sie Folgendes, um diese Fehler zu beheben:

  • Wenn die Meldung InvalidStorageLocation angezeigt wird, prüfen Sie, ob der Cloud Storage-Bucket vorhanden ist, der im Feld options.screenshot_options.storage_location angegeben 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 IAM-Rolle (Identity and Access Management) hat, mit der es Cloud Storage-Buckets erstellen, darauf zugreifen und darin schreiben kann.