Diese Seite wurde von der Cloud Translation API übersetzt.

Fehlerbehebung bei Antwortfehlern

OpenAPI | gRPC

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

`Upstream backend unavailable`

Wenn Sie den Fehlercode 14 und die Meldung upstream backend unavailable 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 Back-End ab.
- Lesen Sie für Compute Engine die Fehlerbehebung für Cloud Endpoints in Compute Engine.
- Verwenden Sie für GKE SSH, um auf den Pod zuzugreifen, und anschließend curl. Weitere Informationen finden Sie unter Fehlerbehebung bei Endpoints in Google Kubernetes Engine.

Der richtige IP-Adressport des Back-End-Dienstes wurde angegeben:
- 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.

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.
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 allow_unregistered_calls: false in der gRPC API-Konfigurationsdatei 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:

Rufen Sie in der Google Cloud Console die Seite Endpunkte-Dienste für Ihr Projekt auf.
Endpoints-Dienste aufrufen
Wenn Sie mehrere APIs haben, wählen Sie die API aus, an die Sie die Anfrage gesendet haben.
Klicken Sie auf den Tab Bereitstellungsverlauf.
Wählen Sie die neueste Bereitstellung aus, um die Dienstkonfiguration aufzurufen.

`Transport is closing`

Wenn Sie einen Fehlercode 13 und die Meldung transport is closing erhalten, bedeutet dies, dass der ESP nicht erreichbar ist.

Prüfen Sie die ESP-Fehlerlogs. Die dafür nötigen Schritte hängen vom Back-End ab. Weitere Informationen finden Sie hier:

Unerwartete Antworten

Wenn die HTTP-Antwort wie eine binäre Antwort aussieht, weist dies möglicherweise darauf hin, dass die Anfrage die API über den Port HTTP2 erreicht, während eigentlich Port HTTP1 beabsichtigt war.

Prüfen Sie die Portkonfigurationsoptionen für den ESP. Da die Kurzform-Flags -p (für HTTP1) und -P (für HTTP2) ähnlich aussehen, empfiehlt es sich, stattdessen die Langform-Flags zu verwenden: --http_port für HTTP1 und --http2_port für HTTP2.

Eine Fehlkonfiguration des ESP-Back-Ends kann ebenfalls zu unerwarteten Antworten führen. Sorgen Sie dafür, dass das Backend-Flag (-a oder --backend) auf eine gRPC-URL wie --backend=grpc://127.0.0.1:8081 festgelegt ist.

Weitere Informationen zu den ESP-Flags finden Sie unter ESP-Startoptionen.

Cloud Logging-Logs prüfen

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

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

Zur Seite „Log-Explorer“
Wählen Sie oben auf der Seite das Google Cloud-Projekt aus.
Wählen Sie mithilfe der Drop-down-Menüs auf der linken Seite Produzierte API > [NAME_IHRES_DIENSTS] aus.
Passen Sie den Zeitraum an, bis eine Zeile angezeigt wird, die den jeweiligen Antwortfehler enthält.
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:

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.