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
• Probleme mit öffentlichen Verfügbarkeitsdiagnosen beheben
• Probleme mit privaten Verfügbarkeitsdiagnosen beheben
• Fehlerbehebung bei synthetischen Monitoren

Protokolle finden

In diesem Abschnitt erfahren Sie, wie Sie Protokolle für synthetische 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 Logging 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 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-Version aus oder geben Sie die folgende Abfrage in den Abfrageeditor ein und klicken Sie dann auf Abfrage ausführen:

     resource.type="cloud_run_revision"
     

   • In den Suchprotokollen, die Informationen zur Antwort enthalten, die bei der Ausführung eines synthetischen Monitors oder einer Verfügbarkeitsdiagnose empfangen wurde, kann Folgendes geschehen:

     • 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"
       

     • Wenn Sie nach Logs suchen möchten, die Antwortdaten für Anfragen enthalten, die von synthetischen Monitoren und Uptime-Prüfungen gesendet 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.

     Dazu gehören:

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

     • Die ID eines zugehörigen Tracings, 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.

Probleme mit Benachrichtigungen beheben

In diesem Abschnitt werden einige Fehler beschrieben, die beim Konfigurieren von Benachrichtigungsrichtlinien auftreten können, und es werden Informationen zur Behebung dieser Fehler bereitgestellt.

Ein Prüftool ist fehlgeschlagen, andere nicht

Sie sehen sich die Messwerte für die Verfügbarkeitsdiagnose an und stellen fest, dass ein Prüftool einen Fehler gemeldet hat, während alle anderen Prüftools einen Erfolg gemeldet haben.

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

Wenn nur ein Prüfer einen Fehler meldet, kann das daran liegen, dass der Befehl des Prüfers aufgrund eines Netzwerkproblems eine Zeitüberschreitung auftritt. 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  Uptime-Prüfungen 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. Wenn Sie herausfinden möchten, wann die Verfügbarkeitsdiagnose zum ersten Mal fehlgeschlagen ist, müssen Sie möglicherweise den Zeitraum für das Diagramm ändern. Die Auswahl des Zeitraums befindet sich in der Symbolleiste der Seite Details zur Uptime.

   • Bei synthetischen Monitoren können Sie auf der Seite Details zur Verfügbarkeit nachsehen, wann der Fehler aufgetreten ist:

     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 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 Betriebszeitdetails für diese Diagnose an. Sie stellen fest, dass in der Grafik Überprüfte Elemente mindestens ein Prüfelement 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 für eine einzelne Region keine Antwort empfangen wird. 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 notifications 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 den Namen 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. Weitere Informationen finden Sie unter Schnellstart für Compute Engine. Bei Verwendung des Verbindungstyps HTTPS müssen Sie unter Umständen zusätzliche Konfigurationsschritte ausführen. Informationen zu Firewallproblemen finden Sie unter IP-Adressen der Server für die Verfügbarkeitsdiagnose auflisten.
• Name or service not found (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. Achten Sie darauf, dass die Firewall Traffic von den für die Verfügbarkeitsdiagnose verwendeten Servern zulässt. Weitere Informationen erhalten Sie unter IP-Adressen der Server für die Verfügbarkeitsdiagnose auflisten. Das Zeitlimit ist Teil der Antwortvalidierung angegeben.

Zur Fehlerbehebung bei 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. Anhand der Pings können Sie zwischen Fehlern unterscheiden, die beispielsweise durch Netzwerkverbindungsprobleme oder Zeitüberschreitungen in Ihrer Anwendung verursacht werden. 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 Uptime-Prüfungen auftreten können. Außerdem finden Sie Informationen zur Fehlerbehebung.

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 dem Dienstkonto die erforderlichen Rollen zuweisen:

Zugriff verweigert

Ihre Verfügbarkeitsdiagnosen schlagen mit dem Ergebnis VPC_ACCESS_DENIED fehl. Das 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 Netzwerkprojekt konfigurieren.

Anomalie bei privaten Verfügbarkeitsdiagnosen

Sie haben einen Dienstverzeichnisdienst mit mehreren VMs und Ihre Dienstkonfiguration enthält mehrere Endpunkte. Wenn Sie eine der VMs herunterfahren, zeigt die Verfügbarkeitsdiagnose weiterhin einen Erfolg an.

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

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 Uptime-Prüfung an einen Zielendpunkt gesendet wird, enthält sie die folgenden Header und Werte:

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

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

Keine Daten sichtbar

Wenn sich die Verfügbarkeitsdiagnose in einem anderen Google Cloud-Projekt als der Dienstverzeichnisdienst 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 überwachter Projekte und zum Hinzufügen weiterer Projekte 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:

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 bestätigt haben, dass die API aktiviert ist, können Sie mit dem Erstellungsvorgang fortfahren. Die Bedingung wird automatisch aufgehoben, nachdem die API-Aktivierung im Backend übernommen wurde.

Ausgehende HTTP-Anfragen werden nicht gefolgt

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

Um dieses Problem zu beheben, prüfen Sie, 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 sind:

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

   Rufen Sie IAM auf.

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

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

3. Wenn das Dienstkonto, das von Ihrem synthetischen Monitor verwendet wird, 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 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 weist darauf hin, dass die Funktion gelöscht wurde und daher nicht vom synthetischen Monitor ausgeführt werden 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, konnte die Funktion nicht bereitgestellt werden.

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

  Überprüfen Sie den Funktionscode und beheben Sie die Fehler, die das Erstellen oder Bereitstellen der Funktion verhindern.

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

Warnstatus

Unter Synthetische Monitore wird ein synthetischer Monitor mit dem Status Warning aufgeführt. 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“

Unter 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 bei einem Fehler eine Ausführungszeit von 0ms zurückgegeben wird, ist der Arbeitsspeicher der Cloud Run-Funktion möglicherweise aufgebraucht. Bearbeiten Sie Ihre Cloud Run-Funktion, um diesen Fehler zu beheben. Erhöhen Sie dann den Arbeitsspeicher 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.

Konfiguration eines Links mit Fehlern kann nicht bearbeitet werden

Sie haben mit der Google Cloud Console einen Checker für fehlerhafte Links erstellt und möchten die getesteten HTML-Elemente ändern oder die URI-Zeitüberschreitung, die Wiederholungen, die Option „Warten auf Auswahl“ und die Optionen pro Link anpassen. 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 more_vert 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 klicken Sie dann auf Funktion anwenden.

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

5. Klicken Sie auf Speichern.

In der Google Cloud Console wird angezeigt, 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 zusammen mit ausführlicheren Informationen angezeigt:

• InvalidStorageLocation
• StorageValidationError
• BucketCreationError
• ScreenshotFileUploadError

So beheben Sie diese Fehler:

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

• Rufen Sie die Logs für Ihre Cloud Run-Funktion auf. 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.