Fehlerbehebung bei Antwortfehlern

Auf dieser Seite wird beschrieben, wie Sie Fehler beheben, die als Antwort auf eine Anfrage an Ihre API zurückgegeben werden.

BAD_GATEWAY

Wenn Sie den Fehlercode 13 und die Meldung BAD_GATEWAY erhalten, bedeutet dies, dass der Extensible Service Proxy (ESP) das Dienst-Back-End nicht erreichen kann. Prüfen Sie Folgendes:

  • Ob der Back-End-Dienst ausgeführt wird. Die dafür nötigen Schritte hängen vom Backend ab.

  • Ob der richtige IP-Adressport für den Back-End-Dienst angegeben wurde:
    • Prüfen Sie für GKE den Wert des Flags --backend für den ESP (Kurzform -a) in der Manifestdatei der Bereitstellung (heißt häufig deployment.yaml).
    • Prüfen Sie für Compute Engine den Wert des Flags --backend für den ESP (Kurzform -a) im Befehl docker run.

reset reason: connection failure

Wenn Sie den HTTP-Code 503 oder den gRPC-Code 14 und die Meldung upstream connect error or disconnect/reset before headers. reset reason: connection failure erhalten, bedeutet dies, dass ESPv2 das Backend des Dienstes nicht erreichen kann.

Prüfen Sie zur Fehlerbehebung folgende Elemente.

Backend-Adresse

ESPv2 muss mit der richtigen Backend-Adresse konfiguriert werden. Häufige Probleme:

  • Das Schema der Backend-Adresse sollte dem Typ der Backend-Anwendung entsprechen. OpenAPI-Back-Ends sollten http:// und gRPC-Back-Ends grpc:// sein.
  • Für in Cloud Run bereitgestellte ESPv2 sollte das Schema der Backend-Adresse https:// oder grpcs:// sein. s weist ESPv2 an, TLS mit dem Backend einzurichten.

DNS-Lookup

Standardmäßig versucht ESPv2, Domainnamen in IPv6-Adressen aufzulösen. Wenn die IPv6-Auflösung fehlschlägt, greift ESPv2 auf IPv4-Adressen zurück.

Bei einigen Netzwerken funktioniert der Fallback-Mechanismus möglicherweise nicht wie beabsichtigt. Stattdessen können Sie erzwingen, dass ESPv2 IPv4-Adressen über das Flag --backend_dns_lookup_family verwendet.

Dieser Fehler tritt häufig auf, wenn Sie einen serverlosen VPC-Connector für ein in Cloud Run bereitgestelltes ESPv2 konfigurieren. VPCs unterstützen IPv6-Traffic nicht.

API is not enabled for the project

Wenn Sie in der Anfrage einen API-Schlüssel gesendet haben, deutet eine Fehlermeldung wie z. B. "API my-api.endpoints.example-project-12345.cloud.goog ist für das Projekt nicht aktiviert" darauf hin, dass der API-Schlüssel in einem anderen Google Cloud-Projekt als die API erstellt wurde. Zur Behebung des Fehlers können Sie entweder den API-Schlüssel im selben Google Cloud-Projekt erstellen, mit dem die API verknüpft ist, oder die API in dem Google Cloud-Projekt aktivieren, in dem der API-Schlüssel erstellt wurde.

Service control request failed with HTTP response code 403

Wenn Sie den Fehlercode 14 und die Meldung Service control request failed with HTTP response code 403 erhalten, bedeutet das, dass die Service Control API (servicecontrol.googleapis.com) in dem Projekt nicht aktiviert ist.

  1. Unter Erforderliche Dienste prüfen können Sie prüfen, ob alle Dienste, die von Endpoints und dem ESP benötigt werden, in Ihrem Projekt aktiviert sind.

  2. Unter Erforderliche Berechtigungen prüfen erfahren Sie, wie Sie alle erforderlichen Berechtigungen für das Dienstkonto prüfen, das der Instanz zugeordnet ist, auf der der ESP ausgeführt wird.

Method doesn't allow unregistered callers

Der ESP gibt den Fehler Method doesn't allow unregistered callers zurück, wenn Sie im Abschnitt security Ihres OpenAPI-Dokuments einen API-Schlüssel angegeben haben, in der Anfrage an Ihre API jedoch kein API-Schlüssel einem Abfrageparameter mit dem Namen key zugeordnet ist.

Weitere Informationen zum Generieren eines API-Schlüssels, um Aufrufe an die API zu senden, finden Sie unter API-Schlüssel erstellen.

Method does not exist

Die Antwort Method does not exist bedeutet, dass die HTTP-Methode (GET, POST oder andere) im angegebenen URL-Pfad nicht gefunden wurde. Prüfen Sie zur Fehlerbehebung in der von Ihnen bereitgestellten Dienstkonfiguration, ob der Methodenname und der in der Anfrage gesendete URL-Pfad übereinstimmen:

  1. Rufen Sie in der Google Cloud Console die Seite Endpoints-Dienste für Ihr Projekt auf.

    Endpoints-Dienste aufrufen

  2. Wenn Sie mehrere APIs haben, wählen Sie die API aus, an die Sie die Anfrage gesendet haben.

  3. Klicken Sie auf den Tab Bereitstellungsverlauf.

  4. Wählen Sie die neueste Bereitstellung aus, um die Dienstkonfiguration aufzurufen.

Wenn Sie im Abschnitt paths Ihres OpenAPI-Dokuments die von Ihnen aufgerufene Methode nicht finden, können Sie entweder die Methode in die Datei aufnehmen oder das Flag x-google-allow auf oberster Ebene der Datei hinzufügen:

x-google-allow: all

Dieses Flag bedeutet, dass Sie in Ihrem OpenAPI-Dokument nicht alle Methoden auflisten müssen, die in Ihrem Backend unterstützt werden. Bei Verwendung von all werden alle Aufrufe – mit oder ohne API-Schlüssel oder Nutzerauthentifizierung – durch den ESP an Ihre API weitergeleitet. Weitere Informationen finden Sie unter x-google-allow.

Für die flexible App Engine-Umgebung spezifische Fehler

In diesem Abschnitt werden Fehlerantworten von APIs beschrieben, die in der flexiblen Umgebung von App Engine bereitgestellt werden.

Fehlercode 502 oder 503

Es kann einige Minuten dauern, bis App Engine erfolgreich auf Anfragen reagiert. Wenn Sie eine Anfrage senden und HTTP 502, 503 oder ein anderer Serverfehler zurückgegeben wird, warten Sie eine Minute und wiederholen Sie dann die Anfrage.

Fehlermeldung BAD_GATEWAY

Der Fehlercode 502 mit BAD_GATEWAY in der Meldung weist normalerweise darauf hin, dass App Engine die Anwendung aufgrund fehlenden Speichers beendet hat. Die Standard-VM der flexiblen App Engine-Umgebung hat nur 1 GB Speicher, wobei dem Anwendungscontainer lediglich 600 MB zur Verfügung stehen.

So beheben Sie Fehlercode 502:

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

    Zur Seite „Log-Explorer“

  2. Wählen Sie das jeweilige Google Cloud-Projekt oben auf der Seite aus.

  3. Wählen Sie Google App Engine-Anwendung aus und öffnen Sie vm.syslog.

  4. Suchen Sie nach einem Logeintrag wie dem Folgenden:

    kernel: [  133.706951] Out of memory: Kill process 4490 (java) score 878 or sacrifice child
kernel: [  133.714468] Killed process 4306 (java) total-vm:5332376kB, anon-rss:2712108kB, file-rss:0kB

    Wenn ein Out of memory-Eintrag im Log angezeigt wird:

    1. Fügen Sie der Datei app.yaml Folgendes hinzu, um die Größe der Standard-VM zu erhöhen:

      resources:
  memory_gb: 4

    2. Stellen Sie die API noch einmal bereit:

      gcloud app deploy

Wenn Sie Option rollout_strategy: managed im Abschnitt endpoints_api_service der Datei app.yaml angegeben haben, verwenden Sie den folgenden Befehl, um die API noch einmal bereitzustellen:

  gcloud app deploy

Weitere Informationen finden Sie unter API und ESP bereitstellen.

Cloud Logging-Logs prüfen

So verwenden Sie die Cloud Logging-Protokolle zur Fehlerbehebung bei Antwortfehlern:

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

    Zur Seite „Log-Explorer“

  2. Wählen Sie oben auf der Seite das Google Cloud-Projekt aus.

  3. Wählen Sie mithilfe der Drop-down-Menüs auf der linken Seite Produzierte API > [NAME_IHRES_DIENSTS] aus.

  4. Passen Sie den Zeitraum an, bis eine Zeile angezeigt wird, die den jeweiligen Antwortfehler enthält.

  5. Erweitern Sie die Anzeige der JSON-Nutzlast und suchen Sie nach error_cause.

    • Wenn error_cause auf application gesetzt ist, weist das auf ein Problem in Ihrem Code hin.

    • Wenn error cause auf etwas anderes verweist und Sie das Problem nicht beheben können, exportieren Sie das Log und fügen Sie es in eine Mitteilung an Google ein.

Weitere Informationen finden Sie hier:

  • Details zur Struktur der Logs im Log-Explorer finden Sie in der Referenz zu Endpoints-Logs.

  • Machen Sie sich zuerst mit der Log-Explorer vertraut.

  • Verwenden Sie erweiterte Logabfragen, um Filter zu präzisieren und so beispielsweise alle Anfragen mit einer Latenz von mehr als 300 Millisekunden zu ermitteln.

Probleme mit dem Beispiel "Invoke-WebRequest"

Bei einigen Versionen von Windows PowerShell funktioniert das Beispiel Invoke-WebRequest in den Anleitungen nicht. Wir haben auch einen Bericht erhalten, dass die Antwort eine Liste von Byte ohne Vorzeichen enthielt, die in Zeichen umgewandelt werden mussten. Wenn das Beispiel Invoke-WebRequest nicht das erwartete Ergebnis zurückgibt, versuchen Sie, die Anfrage mit einer anderen Anwendung zu senden. Hier einige Vorschläge dazu:

  • Starten Sie Cloud Shell und halten Sie sich an die Schritte für Linux aus der Anleitung, die Sie verwendet haben, um die Anfrage zu senden.

  • Installieren Sie eine Drittanbieteranwendung wie die Chrome-Browsererweiterung Postman (angeboten von www.getpostman.com). Beim Erstellen der Anfrage in Postman:

    • Wählen Sie POST als HTTP-Verb aus.
    • Wählen Sie für den Header den Schlüssel content-type und den Wert application/json aus.
    • Geben Sie als Text Folgendes ein: {"message":"hello world"}

    • Verwenden Sie in der URL den tatsächlichen API-Schlüssel und nicht die Umgebungsvariable. Beispiel:

      • In der flexiblen App Engine-Umgebung: https://example-project-12345.appspot.com/echo?key=AIza...
      • Auf anderen Back-Ends: http://192.0.2.0:80/echo?key=AIza...

  • Laden Sie curl herunter und installieren Sie es. Führen Sie es dann in der Eingabeaufforderung aus. Da Windows doppelte Anführungszeichen innerhalb von einfachen Anführungszeichen nicht verarbeitet, müssen Sie die Option --data im Beispiel so ändern:

    --data "{\"message\":\"hello world\"}"