Sie sehen die Dokumentation zu Apigee Edge.
Zur Apigee X-Dokumentation weitere Informationen
Symptom
Der Envoy-Proxy schlägt mit dem HTTP-Fehler 403 Forbidden
fehl, wenn er über den Apigee-Adapter für Envoy aufgerufen wird.
Fehlermeldung
Die folgende Fehlermeldung wird angezeigt:
HTTP/1.1 403 Forbidden content-length: 19 content-type: text/plain date: Tue, 03 Nov 2020 00:20:10 GMT server: istio-envoy
Mögliche Ursachen
Der Envoy-Proxy gibt den HTTP-Fehler 403
aus, wenn eine der folgenden Bedingungen eintritt:
Ursache | Beschreibung | Anleitungen zur Fehlerbehebung gelten für |
---|---|---|
API-Produkt ist nicht aktiviert | Das API-Produkt ist für die spezifische Umgebung nicht aktiviert. | Nutzer von Edge Public und Private Cloud |
Fehlender Zieldienst-URI-Pfad im API-Produkt | Der URI-Pfad des Zieldienstes fehlt oder wurde dem API-Produkt unter „API-Ressourcen“ nicht hinzugefügt. | Nutzer von Edge Public und Private Cloud |
Fehlender Hostname im API-Produkt | Der in der Client-API-Anfrage angegebene Hostname fehlt im API-Produkt unter Apigee-Remote-Dienstzielen. | Nutzer von Edge Public und Private Cloud |
Fehlender API-Schlüssel im Anfrageheader | Der API-Schlüssel wird nicht im x-api-key -HTTP-Header übergeben. |
Nutzer von Edge Public und Private Cloud |
Ungültiger API-Schlüssel | Der in der Anfrage übergebene API-Schlüssel ist ungültig. | Nutzer von Edge Public und Private Cloud |
Der Apigee-Adapter for Envoy kann nicht mit dem Remote Service API-Proxy kommunizieren. | Der Apigee-Adapter für Envoy kann nicht mit dem Remote-Dienst-API-Proxy kommunizieren. | Nutzer von Edge Public und Private Cloud |
Envoy-Proxy kann nicht mit Apigee-Adapter for Envoy kommunizieren | Envoy-Proxy kann nicht mit Apigee-Adapter for Envoy kommunizieren | Nutzer von Edge Public und Private Cloud |
Hinweis
- Prüfen Sie, ob Sie die Antwortnachricht
403 Forbidden
vom Envoy-Proxy erhalten. Beispiel:curl -i -H "x-api-key: $API_KEY" http://httpbin:8080/echo HTTP/1.1 403 Forbidden content-length: 19 content-type: text/plain date: Tue, 12 Jan 2021 08:18:08 GMT server: envoy RBAC: access denied
Debug-Protokolle aktivieren:
Achten Sie darauf, dass Sie Debug-Logs im Apigee Adapter for Envoy aktiviert haben, um weitere Details zum Fehler zu erfassen. Wenn nicht, beenden Sie den Apigee Adapter for Envoy und starten Sie ihn neu. Aktivieren Sie dabei die Fehlerbehebungslogs mit dem folgenden Befehl:
apigee-remote-service-envoy -c config.yaml -l debug
Ursache: API-Produkt ist nicht aktiviert
Dieser Fehler tritt auf, wenn das vom Envoy-Proxy verwendete API-Produkt in der spezifischen Umgebung, in der die API-Aufrufe aufgerufen werden, nicht aktiviert ist.
Diagnose
Führen Sie die folgenden Schritte aus, um das Problem zu diagnostizieren:
- Aktivieren Sie die Fehlerbehebungsprotokolle, wie in Schritt 2 oben beschrieben.
- Prüfen Sie die Logs des Apigee Adapters für Envoy und prüfen Sie, ob die folgende Meldung unter dem Abschnitt
Authorizing request
angezeigt wird:product: API_PRODUCT_NAME not found
Beispiel für Ausgabe des Fehlerbehebungsprotokolls:
2021-01-12T08:18:08.124Z DEBUG auth/auth.go:98 Authenticate: key: 7mQIG..., claims: map[string]interface {}(nil) 2021-01-12T08:18:08.124Z DEBUG auth/verify_api_key.go:106 fetchToken fetching: 7mQIG... 2021-01-12T08:18:08.589Z DEBUG auth/auth.go:125 using api key from request 2021-01-12T08:18:08.589Z DEBUG auth/auth.go:157 Authenticate success: &auth.Context{Context:(*server.Handle r)(0xc0001a0600), ClientID:"7mQIG...", AccessToken:"", Application:"ENVOY-APP-1", APIProducts:[]string{"ENVOY-PRODUCT-1"}, Expires:time.Time{wall:0x0, ext:63746037188, loc:(*time.Location)(0x14a3be0)}, DeveloperEmail:"[---masked---]", Scopes:[] string{""}, APIKey:"7mQIG..."} 2021-01-12T08:18:08.589Z DEBUG product/manager.go:89 Authorizing request: products: [ENVOY-PRODUCT-1] scopes: [] operation: GET /echo target: httpbin:8080 - product: ENVOY-PRODUCT-1 not found
Das obige Beispiel zeigt, dass das API-Produkt
ENVOY-PRODUCT-1
im Apigee Adapter for Envoy nicht gefunden wurde.Weitere Informationen zum Logging mit dem Apigee Adapter for Envoy finden Sie unter Logging.
- Wenn diese Meldung beim Autorisieren der API-Anfrage angezeigt wird, weist dies höchstwahrscheinlich darauf hin, dass das jeweilige API-Produkt nicht für eine bestimmte Umgebung aktiviert ist, in der Sie die API-Aufrufe ausführen.
- Führen Sie die folgenden Schritte aus, um dies zu überprüfen:
- Melden Sie sich bei der Edge-UI an.
- Klicken Sie auf der Seite Veröffentlichen > API-Produkte auf das spezifische API-Produkt, das Sie zum Konfigurieren des Apigee Adapters für Envoy verwendet haben.
- Prüfen Sie, ob die Umgebung, in der Sie die API-Anfragen senden, im API-Produkt aktiviert ist.
- Wenn die jeweilige Umgebung im API-Produkt nicht aktiviert ist, ist das die Ursache für das Problem.
- Wenn die spezifische Umgebung bereits aktiviert ist, gehen Sie zu Ursache: Fehlender Zieldienst-URI-Pfad im API-Produkt.
Auflösung
Wenn die spezifische Umgebung im API-Produkt nicht aktiviert ist, führen Sie die folgenden Schritte aus, um das Problem zu beheben:
- Melden Sie sich bei der Edge-UI an.
- Klicken Sie auf der Seite Veröffentlichen > API-Produkte auf das spezifische API-Produkt, das Sie zum Konfigurieren des Apigee Adapters für Envoy verwendet haben.
- Klicken Sie auf der Seite API-Produkte > Produktname auf Bearbeiten.
- Aktivieren Sie die Umgebung, in der Sie API-Anfragen stellen möchten, indem Sie das entsprechende Kästchen für die Umgebung anklicken.
- Klicken Sie auf Speichern.
Ursache: Zieldienst-URI-Pfad fehlt im API-Produkt
Dieser Fehler tritt auf, wenn der URI-Pfad des Ziels nicht in dem spezifischen API-Produkt angegeben ist, das vom Envoy-Proxy verwendet wird.
Diagnose
Führen Sie die folgenden Schritte aus, um das Problem zu diagnostizieren:
- Aktivieren Sie die Fehlerbehebungsprotokolle, wie in Schritt 2 oben beschrieben.
-
Prüfen Sie die Logs des Apigee Adapters für Envoy und prüfen Sie, ob für das jeweilige API-Produkt, das im Abschnitt
Authorizing request
mit einem bestimmten Ziel verknüpft ist, die folgende Meldung angezeigt wird:no path: REQUEST_URI_PATH
Beispiel für Ausgabe des Fehlerbehebungsprotokolls:
2021-01-12T08:09:02.604Z DEBUG auth/auth.go:98 Authenticate: key: 7mQIG..., claims: map[string]interface {}(nil) 2021-01-12T08:09:02.605Z DEBUG auth/auth.go:125 using api key from request 2021-01-12T08:09:02.605Z DEBUG auth/auth.go:157 Authenticate success: &auth.Context{Context:(*server.Handle r)(0xc0001a4180), ClientID:"7mQIG...", AccessToken:"", Application:"ENVOY-APP-1", APIProducts:[]string{"ENVOY-PRODUCT-1"}, Expires:time.Time{wall:0x0, ext:63746036507, loc:(*time.Location)(0x14a3be0)}, DeveloperEmail:"[---masked---]", Scopes:[] string{""}, APIKey:"7mQIG..."} 2021-01-12T08:09:02.605Z DEBUG product/manager.go:89 Authorizing request: products: [ENVOY-PRODUCT-1] scopes: [] operation: GET /echo1 target: httpbin:8080 - product: ENVOY-PRODUCT-1 no path: /echo1 2021-01-12T08:09:02.605Z DEBUG server/authorization.go:228 sending ok (actual: PERMISSION_DENIED)
Die Beispielausgabe zeigt die folgende Nachricht:
no path: /echo1
Dies gibt an, dass der Pfad
/echo1
im API-ProduktENVOY-PRODUCT-1
nicht gefunden wurde. - Wenn in den Fehlerbehebungsprotokollen des Apigee Adapters für Envoy die Meldung
no path: REQUEST_URI_PATH
angezeigt wird, ist das die Ursache des Problems. Ist dies nicht der Fall, gehen Sie zu Ursache: Fehlender Hostname im API-Produkt.
Auflösung
Wenn der spezifische Anfrage-URI dem API-Produkt für das jeweilige Ziel nicht hinzugefügt wird, führen Sie die folgenden Schritte aus, um das Problem zu beheben:
- Melden Sie sich bei der Edge-UI an.
- Klicken Sie auf der Seite Veröffentlichen > API-Produkte auf das spezifische API-Produkt, das Sie zum Konfigurieren des Apigee Adapters für Envoy verwendet haben.
- Klicken Sie auf der Seite API-Produkte > Produktname auf Bearbeiten.
- Fügen Sie im Bereich API-Ressourcen den URI der API-Anfrage zum API-Produkt hinzu.
- Überwachen Sie die Logs des Apigee Adapters for Envoy und warten Sie, bis der Apigee Adapter for Envoy das aktualisierte API-Produkt abruft. Senden Sie anschließend eine weitere API-Anfrage, um die Korrektur zu überprüfen.
Ursache: Fehlender Hostname im API-Produkt
Dieser Fehler tritt auf, wenn die Kombination aus Ziel-Hostname und Port nicht dem spezifischen API-Produkt hinzugefügt wird, das vom Envoy-Proxy verwendet wird.
Diagnose
Führen Sie die folgenden Schritte aus, um das Problem zu diagnostizieren:
- Aktivieren Sie die Fehlerbehebungsprotokolle, wie in Schritt 2 oben beschrieben.
Prüfen Sie die Logs des Apigee Adapters für Envoy und prüfen Sie, ob für das jeweilige API-Produkt, das im Abschnitt
Authorizing request
mit einem bestimmten Ziel verknüpft ist, die folgende Meldung angezeigt wird:no targets: HOSTNAME:PORT
Beispiel für Ausgabe des Fehlerbehebungsprotokolls:
2021-01-12T08:12:06.019Z DEBUG auth/auth.go:98 Authenticate: key: 7mQIG..., claims: map[string]interface {}(nil) 2021-01-12T08:12:06.019Z DEBUG auth/auth.go:125 using api key from request 2021-01-12T08:12:06.019Z DEBUG auth/auth.go:157 Authenticate success: &auth.Context{Context:(*server.Handle r)(0xc0001a4180), ClientID:"7mQIG...", AccessToken:"", Application:"ENVOY-APP-1", APIProducts:[]string{"ENVOY-PRODUCT-1"}, Expires:time.Time{wall:0x0, ext:63746036507, loc:(*time.Location)(0x14a3be0)}, DeveloperEmail:"[---masked---]", Scopes:[] string{""}, APIKey:"7mQIG..."} 2021-01-12T08:12:06.019Z DEBUG product/manager.go:89 Authorizing request: products: [ENVOY-PRODUCT-1] scopes: [] operation: GET /echo target: httpbin1:8080 - product: ENVOY-PRODUCT-1 no targets: httpbin1:8080 2021-01-12T08:12:06.020Z DEBUG server/authorization.go:228 sending ok (actual: PERMISSION_DENIED)
Das Beispiel oben zeigt, dass die Kombination aus Hostname und Port
httpbin1:8080
nicht im API-ProduktENVOY-PRODUCT-1
gefunden wurde.- Wenn die Logs von Apigee Adapter for Envoy während der Autorisierung der Anfrage einen Eintrag mit der Nachricht
no targets: HOSTNAME:PORT
enthalten, ist dies die Ursache des Problems. Falls nicht, gehen Sie zu Ursache: Fehlender API-Schlüssel im Anfrageheader.
Auflösung
Wenn die Kombination aus Hostname und Port nicht dem API-Produkt hinzugefügt wird, führen Sie die folgenden Schritte aus, um das Problem zu beheben:
- Melden Sie sich bei der Edge-UI an.
- Klicken Sie auf der Seite Veröffentlichen > API-Produkte auf das spezifische API-Produkt, das Sie zum Konfigurieren des Apigee Adapters für Envoy verwendet haben.
- Klicken Sie auf der Seite API-Produkte > Produktname auf Bearbeiten.
Fügen Sie im Bereich Apigee-Remote-Dienstziele den Zielhostnamen und -port hinzu und klicken Sie auf Speichern.
Wenn der Abschnitt Apigee-Remote-Dienstziele nicht in der Benutzeroberfläche angezeigt wird, fügen Sie dem API-Produkt ein benutzerdefiniertes Attribut mit dem Namen
apigee-remote-service-targets
hinzu und fügen Sie den Wert HOSTNAME:PORT mithilfe der Edge API hinzu. Beispiel:curl https://api.enterprise.apigee.com/v1/organizations/$ORG/apiproducts/$ENVOY_PRODUCT \ -X GET \ -H "Authorization: Bearer $ACCESS_TOKEN" \ -H "Content-Type:application/json" \ -d \ { "apiResources": [ "/echo", "/verifyApiKey" ], "approvalType": "auto", "attributes": [ { "name": "access", "value": "public" }, { "name": "apigee-remote-service-targets", "value": "localhost:8080" } ], "createdAt": 1610435989556, "createdBy": "---masked---", "description": "", "displayName": "ENVOY-PRODUCT-1", "environments": [ "test" ], "lastModifiedAt": 1612234134060, "lastModifiedBy": "---masked---", "name": "ENVOY-PRODUCT-1", "proxies": [ "remote-service" ], "scopes": [] }
- Überwachen Sie nach Abschluss der oben genannten Aufgabe die Logs des Apigee Adapters für Envoy und warten Sie, bis der Apigee Adapter for Envoy das aktualisierte API-Produkt abruft. Senden Sie anschließend eine weitere API-Anfrage, um die Korrektur zu überprüfen.
Ursache: Fehlender API-Schlüssel im Anfrageheader
Dieser Fehler tritt auf, wenn der API-Schlüssel nicht als Teil der Anfrageheader übergeben wird.
Diagnose
Führen Sie die folgenden Schritte aus, um das Problem zu diagnostizieren:
- Aktivieren Sie die Fehlerbehebungsprotokolle, wie in Schritt 2 oben beschrieben.
- Sehen Sie sich die Logs des Apigee Adapters für Envoy an und prüfen Sie, ob im Abschnitt
Authenticate error
die Meldung[missing authentication]
angezeigt wird.Beispiel für Ausgabe des Fehlerbehebungsprotokolls:
2021-01-12T08:20:31.461Z DEBUG auth/auth.go:98 Authenticate: key: , claims: map[string]interface {}(nil) 2021-01-12T08:20:31.461Z DEBUG auth/auth.go:159 Authenticate error: &auth.Context{Context:(*server.Handler) (0xc0001a0600), ClientID:"", AccessToken:"", Application:"", APIProducts:[]string(nil), Expires:time.Time{wall:0x0, ext:0, loc:(*time.Location)(nil)}, DeveloperEmail:"", Scopes:[]string(nil), APIKey:""} [missing authentication] 2021-01-12T08:20:31.461Z DEBUG server/authorization.go:205 sending denied: UNAUTHENTICATED 2021-01-12T08:20:32.448Z DEBUG server/header_context.go:68 No context header x-apigee-api, using target header : :authority
Die oben gezeigte Beispielausgabe enthält die Meldung
[missing authentication]
. Diese Meldung gibt an, dass der API-Schlüssel nicht als Teil des Anfrageheaders übergeben wird. - Wenn Apigee Adapter for Envoy-Logs einen Logeintrag mit der Meldung
[missing authentication]
im AbschnittAuthenticate error
enthalten, ist dies die Ursache des Problems. Falls nicht, gehen Sie zu Ursache: Ungültiger API-Schlüssel.
Auflösung
Wenn der Fehler [missing authentication]
in den Logs des Apigee Adapters für Envoy angezeigt wurde, führen Sie die folgenden Schritte aus, um das Problem zu beheben:
- Prüfe, ob der Client den API-Schlüssel mit dem HTTP-Header
x-api-key
in der API-Anfrage gesendet hat. Ist dies nicht der Fall, fordere den Client an, den API-Schlüssel im HTTP-Headerx-api-key
zu senden. - Prüfen Sie in der Konfigurationsdatei des Apigee Adapters für Envoy, ob der Headername des Standard-API-Schlüssels
x-api-key
geändert wurde. Beispiel:apiVersion: v1 kind: ConfigMap metadata: name: apigee-remote-service-envoy namespace: apigee data: config.yaml: | global: tls: ... tenant: ... auth: target_header: api-key
Im Beispiel oben wurde der Standardname des API-Schlüsselheaders in
api-key
geändert. In diesem Fall musst du den API-Schlüssel als Teil des Headersapi-key
übergeben. - Wenn der Standardheadername des API-Schlüssels geändert wurde, bitten Sie den Client, den aktualisierten Headernamen des API-Schlüssels zu verwenden. Senden Sie eine weitere API-Anfrage und prüfen Sie, ob das Problem dadurch behoben wird.
Ursache: Ungültiger API-Schlüssel
Dieser Fehler tritt auf, wenn ein ungültiger API-Schlüssel als Teil des Anfrageheaders übergeben wird.
Diagnose
Führen Sie die folgenden Schritte aus, um das Problem zu diagnostizieren:
- Aktivieren Sie die Fehlerbehebungsprotokolle, wie in Schritt 2 oben beschrieben.
- Prüfen Sie die Logs des Apigee Adapters für Envoy und prüfen Sie, ob im Abschnitt
Authenticate error
die Meldung[permission denied]
angezeigt wird. Dies wird normalerweise angezeigt, nachdem der API-Schlüssel vom Adapter abgerufen wurde. Dies ist an der MeldungfetchToken fetching: API_KEY
zu erkennen.Beispiel für Ausgabe des Fehlerbehebungsprotokolls:
2021-01-12T05:01:07.198Z DEBUG auth/auth.go:98 Authenticate: key: 123, claims: map[string]interface {}(nil) 2021-01-12T05:01:07.198Z DEBUG auth/verify_api_key.go:106 fetchToken fetching: API_KEY 2021-01-12T05:01:09.102Z DEBUG server/header_context.go:68 No context header x-apigee-api, using target header: :authority 2021-01-12T05:01:09.831Z DEBUG auth/auth.go:159 Authenticate error: &auth.Context{Context:(*server.Handler)(0xc0001640c0), ClientID:"", AccessToken:"", Application:"", APIProducts:[]string(nil), Expires:time.Time{wall:0x0, ext:0, loc:(*time.Location)(nil)}, DeveloperEmail:"", Scopes:[]string(nil), APIKey:""} [permission denied] 2021-01-12T05:01:09.832Z DEBUG server/authorization.go:228 sending ok (actual: PERMISSION_DENIED)
In diesem Beispiel war der in der API-Anfrage gesendete API-Schlüssel ungültig.
- Wenn Apigee Adapter for Envoy-Logs einen Logeintrag mit
[permission denied]
im AbschnittAuthenticate error
enthalten, weist dies darauf hin, dass der im Rahmen der Anfrage übergebene API-Schlüssel ungültig ist und die Ursache des Problems ist. Gehen Sie andernfalls zu Ursache: Apigee Adapter for Envoy kann nicht mit Remote-Dienst-API-Proxy kommunizieren.
Auflösung
Wenn in den Logs des Apigee Adapters für Envoy im Abschnitt Authenticate
error
die Meldung [permission denied]
angezeigt wird, führen Sie die folgenden Schritte aus, um das Problem zu beheben:
- Vergleichen Sie den in der API-Anfrage gesendeten API-Schlüssel mit dem API-Schlüsselwert der Anwendung, die mit dem API-Produkt verbunden ist.
- Wenn der vom Client verwendete API-Schlüssel ungültig ist, fordern Sie vom Client an, den gültigen API-Schlüssel zu senden.
- Wenn der vom Client verwendete API-Schlüssel gültig ist und der HTTP-Fehler
403
weiterhin angezeigt wird, wenden Sie sich an den Apigee Edge-Support, um das Problem weiter zu untersuchen.
Ursache: Der Apigee-Adapter for Envoy kann nicht mit dem Remote-Dienst-API-Proxy kommunizieren
Dieser Fehler tritt auf, wenn der Apigee Adapter for Envoy nicht mit dem API-Proxy des Remote-Dienstes kommunizieren kann, wenn der konfigurierte Remote-Diensthost ungültig ist.
Diagnose
Führen Sie die folgenden Schritte aus, um das Problem zu diagnostizieren:
- Aktivieren Sie die Fehlerbehebungsprotokolle, wie in Schritt 2 oben beschrieben.
-
Prüfen Sie die Logs des Apigee Adapters für Envoy und sehen Sie nach, ob die folgende Meldung angezeigt wird:
Error retrieving products: REQUEST_URI: no such host
Beispiel für Ausgabe des Fehlerbehebungsprotokolls:
2021-01-12T08:29:06.499Z DEBUG product/manager.go:188 retrieving products from: https://foo/remote-service/products 2021-01-12T08:29:06.505Z ERROR product/manager.go:164 Error retrieving products: GET "https://foo/remote-service/pro ducts": dial tcp: lookup foo on 169.254.169.254:53: no such host github.com/apigee/apigee-remote-service-golib/product.(*manager).start.func1 /go/pkg/mod/github.com/apigee/apigee-remote-service-golib@v1.4.0/product/manager.go:164 github.com/apigee/apigee-remote-service-golib/util.(*Looper).Run /go/pkg/mod/github.com/apigee/apigee-remote-service-golib@v1.4.0/util/looper.go:87 github.com/apigee/apigee-remote-service-golib/util.(*Looper).Start.func1 /go/pkg/mod/github.com/apigee/apigee-remote-service-golib@v1.4.0/util/looper.go:59
In diesem Beispiel konnte der Apigee-Adapter for Envoy nicht mit dem Remote-Dienst-API-Proxy kommunizieren, da der in der Remote-Server-API-Proxy-URL angegebene Hostname nicht gültig ist, wie durch den Fehler
no such host
angegeben . - Wenn die Logs von Apigee Adapter for Envoy einen Logeintrag mit der Nachricht
no such host
enthalten, ist dies die Ursache des Problems. Gehen Sie andernfalls zu Ursache: Envoy-Proxy kann nicht mit Apigee-Adapter for Envoy kommunizieren.
Auflösung
Wenn die oben genannten Fehler in den Logs des Apigee Adapters für Envoy angezeigt werden, führen Sie die folgenden Schritte aus, um das Problem zu beheben:
Prüfen Sie die Konfigurationsdatei des Apigee Adapters für Envoy und prüfen Sie, ob die angegebene Remote-Dienst-API-Proxy-URL gültig ist.
Ist dies nicht der Fall, beenden Sie den Apigee Adapter for Envoy, korrigieren Sie die Proxy-URL der Remote-Dienst-API in der Konfigurationsdatei, starten Sie Apigee Adapter for Envoy, senden Sie eine weitere API-Anfrage und prüfen Sie die Fehlerbehebung.
Beispielkonfiguration:
apiVersion: v1 kind: ConfigMap metadata: name: apigee-remote-service-envoy namespace: apigee data: config.yaml: | tenant: internal_api: https://istioservices.apigee.net/edgemicro remote_service_api: https://ORG-ENV.apigee.net/remote-service org_name: ORG env_name: ENV key: KEY secret: SECRET
- Prüfen Sie, ob der API-Proxy
remote-service
in der relevanten Edge-Umgebung bereitgestellt ist. Ist dies nicht der Fall, stellen Sie den API-Proxyremote-service
in der entsprechenden Edge-Umgebung bereit und versuchen Sie es noch einmal. - Prüfen Sie die Netzwerkverbindung zwischen dem Apigee-Adapter für Envoy und dem API-Proxy-Endpunkt
remote-service
. Wenn Probleme mit der Netzwerkverbindung festgestellt werden, wenden Sie sich an Ihr Netzwerkteam und versuchen Sie, das Problem zu beheben.
Ursache: Envoy-Proxy kann nicht mit Apigee-Adapter for Envoy kommunizieren
Diagnose
Führen Sie die folgenden Schritte aus, um das Problem zu diagnostizieren:
Achten Sie darauf, dass Sie Debug-Logs in Envoy aktiviert haben. Wenn nicht, beenden Sie Envoy und starten Sie es neu, um Debug-Logs zu aktivieren. Senden Sie dann eine weitere API-Anfrage.
Eigenständige Bereitstellungen:
envoy -c envoy-config.yaml -l debug
Auf Kubernetes bzw. Istio basierende Bereitstellungen:
kubectl -n=istio-system get pods kubectl -n=istio-system exec -it INGRESS_GATEWAY_NAME bash -- curl -X POST localhost:15000/logging?connection=debug
- Prüfen Sie die Logs des Apigee Adapters for Envoy und sehen Sie nach, ob ein Logeintrag mit der folgenden Nachricht vorhanden ist:
connecting to APIGEE_ENVOY_ADAPTER_HOST:5000
gefolgt von:
upstream connect error or disconnect/reset before headers. reset reason: ACTUAL_REASON
Beispiel für Ausgabe des Fehlerbehebungsprotokolls:
[2021-03-23 05:44:41.867][1303661][debug][connection] [external/envoy/source/common/network/connection_impl.cc:769] [C4] connecting to 127.0.0.1:5000 [2021-03-23 05:44:41.867][1303661][debug][connection] [external/envoy/source/common/network/connection_impl.cc:785] [C4] connection in progress [2021-03-23 05:44:41.868][1303661][debug][http2] [external/envoy/source/common/http/http2/codec_impl.cc:1173] [C4] updating connection-level initial window size to 268435456 [2021-03-23 05:44:41.869][1303661][debug][connection] [external/envoy/source/common/network/connection_impl.cc:634] [C4] delayed connection error: 111 [2021-03-23 05:44:41.869][1303661][debug][connection] [external/envoy/source/common/network/connection_impl.cc:203] [C4] closing socket: 0 [2021-03-23 05:44:41.869][1303661][debug][client] [external/envoy/source/common/http/codec_client.cc:96] [C4] disconnect. resetting 0 pending requests [2021-03-23 05:44:41.869][1303661][debug][pool] [external/envoy/source/common/conn_pool/conn_pool_base.cc:314] [C4] client disconnected, failure reason: [2021-03-23 05:44:41.869][1303661][debug][router] [external/envoy/source/common/router/router.cc:1031] [C0][S6149963213555558594] upstream reset: reset reason: connection failure, transport failure reason: [2021-03-23 05:44:41.869][1303661][debug][http] [external/envoy/source/common/http/async_client_impl.cc:100] async http request response headers (end_stream=true): ':status', '200' 'content-type', 'application/grpc' 'grpc-status', '14' 'grpc-message', 'upstream connect error or disconnect/reset before headers. reset reason: connection failure'
Das obige Beispiel zeigt, dass Envoy aus dem Grund
connection failure
nicht mit dem Apigee-Adapter für Envoy kommunizieren konnte. - Für
connection failure
kann es mehrere Gründe geben. Sehen wir uns die einzelnen Szenarien an.
Szenario 1: Adapterprozess wird nicht ausgeführt
Wenn der Apigee Adapter for Envoy-Prozess nicht ausgeführt wird, kann dieser Fehler auftreten.
- Prüfen Sie mit dem folgenden Befehl, ob der Apigee Adapter for Envoy-Prozess ausgeführt wird. Wenn der Apigee Adapter for Envoy-Prozess ausgeführt wird, sollte das Ergebnis des folgenden Befehls ihn auflisten.
ps -ef | grep apigee-remote-service-envoy
- Wenn sie nicht ausgeführt wird, ist das die Ursache des Problems.
Auflösung
- Wenn der Apigee Adapter for Envoy-Prozess nicht ausgeführt wird, starten Sie den Apigee Adapter for Envoy.
- Stellen Sie eine weitere API-Anfrage und prüfen Sie, ob das Problem behoben wurde.
Szenario 2: Der Adapterprozess überwacht den bestimmten Port nicht
Wenn der Apigee Adapter for Envoy-Prozess einen bestimmten Port nicht überwacht, kann dieser Fehler auftreten.
Wenn der Apigee Adapter for Envoy-Prozess ausgeführt wird, prüfen Sie, ob ein Socket vorhanden ist, der Port 5000 überwacht: APIGEE_ENVOY_ADAPTER_HOST:5000
. Mit dem Befehl netstat
können Sie dies prüfen:
sudo netstat -lnp | grep 5000
Beispielausgabe:
sudo netstat -lnp | grep 5000 tcp6 0 0 :::5000 :::* LISTEN 1596530/./apigee-re
Wenn kein Socket auf Port 5000 überwacht wird, könnte dies der Grund für das Problem sein.
Auflösung
- Beenden Sie den Apigee-Adapter for Envoy und starten Sie ihn neu.
- Stellen Sie eine weitere API-Anfrage und prüfen Sie, ob das Problem behoben wurde.
Szenario 3: Netzwerkverbindung zwischen Envoy und Apigee-Adapter für Envoy
- Prüfen Sie die Netzwerkverbindung zwischen Envoy und Apigee-Adapter für Envoy:
ssh $ENVOY_HOST telnet $APIGEE_ENVOY_ADAPTER_HOST 5000
Wenn Telnet eine TCP-Verbindung zum Apigee Adapter for Envoy herstellen könnte, wird eine Ausgabe wie diese angezeigt:
telnet $APIGEE_ENVOY_ADAPTER_HOST 5000 Trying ::1... Connected to localhost. Escape character is '^]'.
- Wenn bei Telnet der Fehler
Connection timed out
auftritt, deutet dies auf ein Problem mit der Netzwerkverbindung zwischen Envoy und Apigee Adapter for Envoy hin.
Auflösung
Wenn Sie Probleme mit der Netzwerkverbindung zwischen Envoy und Apigee Adapter for Envoy feststellen, wenden Sie sich an Ihr Netzwerkteam und versuchen Sie, das Problem zu beheben.
Wenn das Problem weiterhin besteht, lesen Sie die Informationen unter Diagnoseinformationen müssen erfasst werden.
Erfassen von Diagnoseinformationen erforderlich
Wenn das Problem nach Befolgen der obigen Anleitung weiterhin besteht, stellen Sie die folgenden Diagnoseinformationen zusammen und wenden Sie sich an den Apigee Edge-Support:
-
Verwendetes Apigee-Produkt:
Beispiel: Apigee Edge Cloud, Apigee OPDK, Apigee Hybrid, Apigee X
- Apigee-Organisation und -Umgebung
Lesen der API-Produktdefinition mit der Edge API:
curl -i -u $USER:$PASSWORD $MANAGEMENT_SERVER_ENDPOINT/v1/organizations/$ORGANIZATION/apiproducts/$API_PRODUCT
Referenz: Apigee Edge APIs
Starten Sie eine Trace-Sitzung im
remote-service
-API-Proxy mithilfe der Apigee Edge-Benutzeroberfläche. Reproduzieren Sie dieses Problem und geben Sie die XML-Datei der Trace-Sitzung frei.Referenz: Trace-Tool verwenden | Apigee Edge
Apigee Adapter for Envoy-Logs (vollständige Logs zum angegebenen Zeitraum)
Eigenständige Bereitstellungen:
# by default Apigee Envoy write logs to stdout and stderr, check your deployment configuration and collect logs accordingly
Auf Kubernetes bzw. Istio basierende Bereitstellungen:
kubectl -n=apigee get pods kubectl -n=apigee logs APIGEE_REMOTE_SERVICE_ENVOY_POD_NAME > apigee-remote-service-envoy.log
- Eine API-Anfrage, die mit einem
curl
-Befehl an den Envoy-Proxy gesendet wurde (die vollständige Ausgabe des Befehlscurl
):curl -v ENVOY_PROXY_ENDPOINT
- Eine API-Anfrage, die mit einem
curl
-Befehl (die vollständige Ausgabe des Befehlscurl
) an den Zieldienst gesendet wird:curl -v TARGET_SERVICE_ENDPOINT