Fehlerbehebung bei Antwortfehlern

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.

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

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

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

    Zur Seite "Endpoints-Dienste"

  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.

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 Back-End-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:

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

    Loganzeige aufrufen

  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 in der Loganzeige finden Sie in der Referenz zu Endpoints-Logs.

  • Machen Sie sich zuerst mit der Loganzeige 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.