Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Envoy-Proxy schlägt mit dem HTTP-Fehler 403 „Verboten“ im Apigee-Adapter für Envoy fehl

Sie lesen gerade die Dokumentation zu Apigee Edge.
Apigee X-Dokumentation aufrufen info

Symptom

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 einen HTTP-403-Fehler 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 jeweilige Umgebung nicht aktiviert.	Nutzer der Edge Public und Private Cloud
Fehlender URI-Pfad des Zieldienstes im API-Produkt	Der URI-Pfad des Zieldienstes fehlt oder wurde dem API-Produkt unter API-Ressourcen nicht hinzugefügt.	Nutzer der Edge Public und Private Cloud
Fehlender Hostname im API-Produkt	Der in der Client-API-Anfrage angegebene Hostname fehlt im API-Produkt unter Apigee-Remotedienstziele.	Nutzer der Edge Public und Private Cloud
Fehlender API-Schlüssel im Anfrage-Header	Der API-Schlüssel wird nicht im `x-api-key`-HTTP-Header übergeben.	Nutzer der Edge Public und Private Cloud
Ungültiger API-Schlüssel	Der API-Schlüssel, der als Teil der Anfrage übergeben wurde, ist ungültig.	Nutzer der Edge Public und Private Cloud
Apigee Adapter for Envoy kann nicht mit dem API-Proxy für den Remote-Dienst kommunizieren	Der Apigee-Adapter für Envoy kann nicht mit dem API-Proxy des Remotedienstes kommunizieren.	Nutzer der Edge Public und Private Cloud
Envoy-Proxy kann nicht mit Apigee Adapter for Envoy kommunizieren	Envoy-Proxy kann nicht mit dem Apigee Adapter for Envoy kommunizieren	Nutzer der 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

Fehlerbehebungsprotokolle aktivieren:

Achten Sie darauf, dass Sie Debug-Logs im Apigee-Adapter für Envoy aktiviert haben, um weitere Details zum Fehler zu erfassen. Falls nicht, stoppen Sie den Apigee-Adapter für Envoy und starten Sie ihn noch einmal. Aktivieren Sie dazu die Debug-Logs 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 spezifische API-Produkt, das vom Envoy-Proxy verwendet wird, nicht in der spezifischen Umgebung aktiviert ist, in der die API-Aufrufe aufgerufen werden.

Diagnose

Führen Sie die folgenden Schritte aus, um das Problem zu diagnostizieren:

Aktivieren Sie Debug-Logs wie oben in Schritt 2 beschrieben.

Prüfen Sie die Logs des Apigee-Adapters für Envoy und vergewissern Sie sich, dass die folgende Meldung im Abschnitt Authorizing request angezeigt wird:

product: API_PRODUCT_NAME not found

Beispiel für die Debug-Log-Ausgabe:

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 in Apigee Adapter for Envoy nicht gefunden wurde.

Weitere Informationen zum Logging des Apigee Adapter for Envoy finden Sie unter Logging.

Wenn diese Meldung beim Autorisieren der API-Anfrage angezeigt wird, ist das entsprechende API-Produkt höchstwahrscheinlich nicht für eine bestimmte Umgebung aktiviert, in der Sie die API-Aufrufe ausführen.
So kannst du das überprüfen:
1. Melden Sie sich in der Edge-Benutzeroberfläche an.
2. Klicken Sie auf der Seite Veröffentlichen > API-Produkte auf das API-Produkt, das Sie zum Konfigurieren von Apigee Adapter for Envoy verwendet haben.
3. Prüfen Sie, ob die spezifische Umgebung, in der Sie die API-Anfragen stellen, im API-Produkt aktiviert ist.
4. Wenn die spezifische Umgebung im API-Produkt nicht aktiviert ist, ist dies die Ursache für das Problem.
Wenn die jeweilige Umgebung bereits aktiviert ist, fahren Sie mit Ursache: Fehlender Ziel-URI-Pfad des Dienstes im API-Produkt fort.

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 in der Edge-Benutzeroberfläche an.
Klicken Sie auf der Seite Veröffentlichen > API-Produkte auf das API-Produkt, das Sie zum Konfigurieren von Apigee Adapter for 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 ankreuzen.
Klicken Sie auf Speichern.

Ursache: Fehlender URI-Pfad des Zieldienstes im API-Produkt

Dieser Fehler tritt auf, wenn der URI-Pfad des Ziels nicht im 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 Debug-Logs wie oben in Schritt 2 beschrieben.

Prüfen Sie die Apigee Adapter for Envoy-Logs und vergewissern Sie sich, dass die folgende Meldung für das spezifische API-Produkt angezeigt wird, das einem bestimmten Ziel unter dem Abschnitt Authorizing request zugeordnet ist:

no path: REQUEST_URI_PATH

Beispiel für die Debug-Log-Ausgabe:

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)

In der Beispielausgabe wird die Meldung angezeigt:

no path: /echo1

Das bedeutet, dass der Pfad /echo1 im API-Produkt ENVOY-PRODUCT-1 nicht gefunden wurde.

Wenn Sie die Meldung no path: REQUEST_URI_PATH in den Debug-Logs des Apigee-Adapters für Envoy sehen, ist das die Ursache des Problems. Andernfalls fahren Sie mit Ursache: Fehlender Hostname im API-Produkt fort.

Auflösung

Wenn der spezifische Anfrage-URI nicht dem API-Produkt für das spezifische Ziel hinzugefügt wurde, führen Sie die folgenden Schritte aus, um das Problem zu beheben:

Melden Sie sich in der Edge-Benutzeroberfläche an.
Klicken Sie auf der Seite Veröffentlichen > API-Produkte auf das API-Produkt, das Sie zum Konfigurieren von Apigee Adapter for Envoy verwendet haben.
Klicken Sie auf der Seite API-Produkte > Produktname auf Bearbeiten.
Fügen Sie im Bereich API-Ressourcen den API-Anfrage-URI dem API-Produkt hinzu.
Beobachten Sie die Logs des Apigee Adapter 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 Zielhostname 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 Debug-Logs wie oben in Schritt 2 beschrieben.

no targets: HOSTNAME:PORT

Beispiel für die Debug-Log-Ausgabe:

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)

Im obigen Beispiel ist zu sehen, dass die Kombination aus Hostname und Port httpbin1:8080 im API-Produkt ENVOY-PRODUCT-1 nicht gefunden wurde.

Wenn die Logs von Apigee Adapter for Envoy bei der Autorisierung der Anfrage einen Eintrag mit der Meldung no targets: HOSTNAME:PORT enthalten, ist dies die Ursache des Problems. Falls nicht, fahren Sie mit Ursache: Fehlender API-Schlüssel im Anfrage-Header fort.

Auflösung

Wenn die Kombination aus Zielhostnamen und ‑port nicht dem API-Produkt hinzugefügt wurde, führen Sie die folgenden Schritte aus, um das Problem zu beheben:

Melden Sie sich in der Edge-Benutzeroberfläche an.
Klicken Sie auf der Seite Veröffentlichen > API-Produkte auf das API-Produkt, das Sie zum Konfigurieren von Apigee Adapter for 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 in der Benutzeroberfläche nicht angezeigt wird, fügen Sie dem API-Produkt mit der Edge API ein benutzerdefiniertes Attribut mit dem Namen apigee-remote-service-targets und dem Wert HOSTNAME:PORT 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": []
}

Sobald die oben genannte Aufgabe erledigt ist, überwachen Sie die Logs von Apigee Adapter for Envoy und warten Sie, bis der Adapter 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 Anfrage-Header

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 Debug-Logs wie oben in Schritt 2 beschrieben.

Prüfen Sie die Logs des Apigee-Adapters für Envoy und vergewissern Sie sich, dass die Meldung [missing authentication] im Abschnitt Authenticate error angezeigt wird.

Beispiel für die Debug-Log-Ausgabe:

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

In der oben gezeigten Beispielausgabe ist die Meldung [missing authentication] enthalten. Diese Meldung gibt an, dass der API-Schlüssel nicht als Teil des Anfrageheaders übergeben wird.

Wenn die Logs von Apigee Adapter for Envoy einen Logeintrag mit der Meldung [missing authentication] im Abschnitt Authenticate error enthalten, ist dies die Ursache des Problems. Wenn nicht, fahren Sie mit Ursache: Ungültiger API-Schlüssel fort.

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üfen Sie, ob der Client den API-Schlüssel mit dem HTTP-Header x-api-key in der API-Anfrage gesendet hat. Falls nicht, bitten Sie den Client, den API-Schlüssel im HTTP-Header x-api-key zu senden.
Prüfen Sie die Konfigurationsdatei des Apigee-Adapters für Envoy und vergewissern Sie sich, dass der Standardheadername für den API-Schlüssel 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 obigen Beispiel wurde der Standardheadername für den API-Schlüssel in api-key geändert. In diesem Fall müssen Sie den API-Schlüssel als Teil des Headers api-key übergeben.
Wenn der Standardheadername für den API-Schlüssel geändert wurde, bitten Sie den Kunden, den aktualisierten Headername für den API-Schlüssel zu verwenden und eine weitere API-Anfrage zu senden, um zu prüfen, 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 Debug-Logs wie oben in Schritt 2 beschrieben.

Prüfen Sie die Apigee Adapter for Envoy-Logs und vergewissern Sie sich, dass die Meldung [permission denied] im Abschnitt Authenticate error angezeigt wird. Diese Meldung wird normalerweise angezeigt, nachdem der API-Schlüssel vom Adapter abgerufen wurde. Dies wird durch die Meldung fetchToken fetching: API_KEY angezeigt.

Beispiel für die Debug-Log-Ausgabe:

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 die Apigee Adapter for Envoy-Logs einen Logeintrag mit [permission denied] im Abschnitt Authenticate error enthalten, ist der als Teil der Anfrage übergebene API-Schlüssel ungültig und die Ursache des Problems. Wenn nicht, lesen Sie den Abschnitt Ursache: Der Apigee-Adapter für Envoy kann nicht mit dem API-Proxy des Remotedienstes kommunizieren.

Auflösung

Wenn die Meldung [permission denied] im Abschnitt Authenticate error in den Apigee Adapter for Envoy-Logs angezeigt wird, führen Sie die folgenden Schritte aus, um das Problem zu beheben:

Der in der API-Anfrage gesendete API-Schlüssel wird mit dem API-Schlüsselwert in der mit dem API-Produkt verbundenen Anwendung verglichen.
Wenn der vom Client verwendete API-Schlüssel ungültig ist, fordern Sie den Client auf, den gültigen API-Schlüssel zu senden.
Wenn der vom Client verwendete API-Schlüssel gültig ist und Sie weiterhin einen HTTP-403-Fehler sehen, wenden Sie sich bitte an den Apigee Edge-Support, um das Problem weiter zu untersuchen.

Ursache: Der Apigee-Adapter für Envoy kann nicht mit dem API-Proxy des Remotedienstes kommunizieren

Dieser Fehler tritt auf, wenn Apigee Adapter for Envoy nicht mit dem API-Proxy des Remote-Dienstes kommunizieren kann, weil der konfigurierte Host des Remote-Dienstes ungültig ist.

Diagnose

Führen Sie die folgenden Schritte aus, um das Problem zu diagnostizieren:

Aktivieren Sie Debug-Logs wie oben in Schritt 2 beschrieben.

Prüfen Sie die Logs von Apigee Adapter for Envoy und vergewissern Sie sich, dass die folgende Meldung angezeigt wird:

Error retrieving products: REQUEST_URI: no such host

Beispiel für die Debug-Log-Ausgabe:

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 für Envoy nicht mit dem API-Proxy für den Remote-Dienst kommunizieren, da der im API-Proxy-URL des Remote-Servers angegebene Hostname ungültig ist, wie durch den Fehler no such host angegeben .

Wenn die Logs von Apigee Adapter for Envoy einen Logeintrag mit der Meldung no such host enthalten, ist dies die Ursache des Problems. Falls nicht, lesen Sie den Abschnitt Ursache: Envoy-Proxy kann nicht mit dem Apigee-Adapter für Envoy kommunizieren.

Auflösung

Wenn die oben genannten Fehler in den Protokollen von Apigee Adapter for 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 vergewissern Sie sich, dass die angegebene API-Proxy-URL des Remote Service gültig ist.

Wenn nicht, beenden Sie den Apigee-Adapter für Envoy, korrigieren Sie die URL des Remote Service-API-Proxys in der Konfigurationsdatei, starten Sie den Apigee-Adapter für Envoy und senden Sie eine weitere API-Anfrage, um die Korrektur zu überprüfen.

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 remote-service-API-Proxy in der entsprechenden Edge-Umgebung bereitgestellt wird. Wenn nicht, stellen Sie den remote-service-API-Proxy in der entsprechenden Edge-Umgebung bereit und versuchen Sie es noch einmal.
Prüfen Sie die Netzwerkverbindung zwischen dem Apigee Adapter for Envoy und dem remote-service-API-Proxy-Endpunkt. Wenn Probleme mit der Netzwerkverbindung gefunden werden, wenden Sie sich an Ihr Netzwerkteam und versuchen Sie, das Problem zu beheben.

Ursache: Der Envoy-Proxy kann nicht mit dem 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, stoppen Sie Envoy und starten Sie es noch einmal, wobei Sie Debug-Logs aktivieren. Senden Sie dann eine weitere API-Anfrage.

Eigenständige Bereitstellungen:
```
envoy -c envoy-config.yaml -l debug
```
Kubernetes-/Istio-basierte 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 für Envoy und vergewissern Sie sich, dass ein Logeintrag mit der folgenden Meldung vorhanden ist:

connecting to APIGEE_ENVOY_ADAPTER_HOST:5000

Danach folgt:

upstream connect error or disconnect/reset before headers. reset reason: ACTUAL_REASON

Beispiel für die Debug-Log-Ausgabe:

[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 aufgrund des Grunds connection failure nicht mit dem Apigee-Adapter für Envoy kommunizieren konnte.

Die connection failure kann verschiedene Ursachen haben. Sehen wir uns die einzelnen Szenarien an.

Szenario 1: Der Adapterprozess wird nicht ausgeführt

Dieser Fehler kann auftreten, wenn der Apigee Adapter for Envoy-Prozess nicht ausgeführt wird.

Prüfen Sie mit dem folgenden Befehl, ob der Apigee-Adapter für Envoy ausgeführt wird. Wenn der Apigee-Adapter für Envoy-Prozess ausgeführt wird, sollte er im Ergebnis des folgenden Befehls aufgeführt sein.
```
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 ihn.
Stellen Sie eine weitere API-Anfrage und prüfen Sie, ob das Problem behoben wurde.

Szenario 2: Der Adapterprozess überwacht den angegebenen Port nicht.

Dieser Fehler kann auftreten, wenn der Apigee Adapter for Envoy-Prozess nicht auf dem angegebenen Port empfangsbereit ist.

Wenn der Prozess „Apigee Adapter for Envoy“ ausgeführt wird, prüfen Sie, ob ein Socket an Port 5000 überwacht wird: APIGEE_ENVOY_ADAPTER_HOST:5000. Sie können dies mit dem Befehl netstat überprüfen:

sudo netstat -lnp | grep 5000

Beispielausgabe:

sudo netstat -lnp | grep 5000

tcp6       0      0 :::5000                 :::*                    LISTEN      1596530/./apigee-re

Wenn kein Socket an Port 5000 überwacht wird, kann dies der Grund für das Problem sein.

Auflösung

Stoppen 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 for Envoy

Netzwerkverbindung zwischen Envoy und Apigee Adapter for Envoy prüfen:
```
ssh $ENVOY_HOST
telnet $APIGEE_ENVOY_ADAPTER_HOST 5000
```
Wenn Telnet eine TCP-Verbindung zum Apigee-Adapter für Envoy herstellen konnte, wird eine Ausgabe ähnlich der folgenden angezeigt:
```
telnet $APIGEE_ENVOY_ADAPTER_HOST 5000

Trying ::1...
Connected to localhost.
Escape character is '^]'.
```
Wenn Sie den Fehler Connection timed out mit Telnet beobachten, weist dies auf ein Problem mit der Netzwerkverbindung zwischen Envoy und dem Apigee-Adapter für Envoy hin.

Auflösung

Wenn Sie Probleme mit der Netzwerkverbindung zwischen Envoy und dem Apigee-Adapter für Envoy feststellen, wenden Sie sich an Ihr Netzwerkteam und versuchen Sie, das Problem zu beheben.

Wenn das Problem weiterhin besteht, gehen Sie zu Erfassen von Diagnoseinformationen erforderlich.

Erfassen von Diagnoseinformationen erforderlich

Wenn das Problem auch nach Befolgen der obigen Anweisungen weiterhin besteht, sammeln Sie die folgenden Diagnoseinformationen und wenden Sie sich dann an den Apigee Edge-Support:

Verwendetes Apigee-Produkt:

Beispiel:Apigee Edge Cloud, Apigee OPDK, Apigee Hybrid, Apigee X
Apigee-Organisation und -Umgebung

API-Produktdefinition, die mit der Edge API gelesen wird:

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 über die Apigee Edge-Benutzeroberfläche. Reproduzieren Sie das Problem und teilen Sie die XML-Datei der Trace-Sitzung.

Referenz: Trace-Tool verwenden | Apigee Edge

Apigee Adapter for Envoy-Logs (vollständige Logs für den angegebenen Zeitraum)

Eigenständige Bereitstellungen:

# by default Apigee Envoy write logs to stdout and stderr, check your deployment configuration and collect logs accordingly

Kubernetes-/Istio-basierte 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 curl-Befehls):
```
curl -v ENVOY_PROXY_ENDPOINT
```
Eine API-Anfrage, die mit einem curl-Befehl an den Zieldienst gesendet wird (die vollständige Ausgabe des curl-Befehls):
```
curl -v TARGET_SERVICE_ENDPOINT
```