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

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

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

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

  1. Aktivieren Sie die Fehlerbehebungsprotokolle, wie in Schritt 2 oben beschrieben.
  2. 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.

  3. 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.
  4. Führen Sie die folgenden Schritte aus, um dies zu überprüfen:
    1. Melden Sie sich bei der Edge-UI an.
    2. 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.
    3. Prüfen Sie, ob die Umgebung, in der Sie die API-Anfragen senden, im API-Produkt aktiviert ist.
    4. Wenn die jeweilige Umgebung im API-Produkt nicht aktiviert ist, ist das die Ursache für das Problem.
  5. 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:

  1. Melden Sie sich bei der Edge-UI an.
  2. 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.
  3. Klicken Sie auf der Seite API-Produkte > Produktname auf Bearbeiten.
  4. Aktivieren Sie die Umgebung, in der Sie API-Anfragen stellen möchten, indem Sie das entsprechende Kästchen für die Umgebung anklicken.
  5. 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:

  1. Aktivieren Sie die Fehlerbehebungsprotokolle, wie in Schritt 2 oben beschrieben.

  2. 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-Produkt ENVOY-PRODUCT-1 nicht gefunden wurde.

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

  1. Melden Sie sich bei der Edge-UI an.
  2. 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.
  3. Klicken Sie auf der Seite API-Produkte > Produktname auf Bearbeiten.
  4. Fügen Sie im Bereich API-Ressourcen den URI der API-Anfrage zum API-Produkt hinzu.
  5. Ü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:

  1. Aktivieren Sie die Fehlerbehebungsprotokolle, wie in Schritt 2 oben beschrieben.

  2. 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-Produkt ENVOY-PRODUCT-1 gefunden wurde.

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

  1. Melden Sie sich bei der Edge-UI an.
  2. 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.
  3. Klicken Sie auf der Seite API-Produkte > Produktname auf Bearbeiten.

  4. 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": []
}
  5. Ü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:

  1. Aktivieren Sie die Fehlerbehebungsprotokolle, wie in Schritt 2 oben beschrieben.
  2. 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.

  3. Wenn Apigee Adapter for Envoy-Logs einen Logeintrag mit der Meldung [missing authentication] im Abschnitt Authenticate 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:

  1. 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-Header x-api-key zu senden.
  2. 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 Headers api-key übergeben.

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

  1. Aktivieren Sie die Fehlerbehebungsprotokolle, wie in Schritt 2 oben beschrieben.
  2. 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 Meldung fetchToken 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.

  3. Wenn Apigee Adapter for Envoy-Logs einen Logeintrag mit [permission denied] im Abschnitt Authenticate 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:

  1. 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.
  2. Wenn der vom Client verwendete API-Schlüssel ungültig ist, fordern Sie vom Client an, den gültigen API-Schlüssel zu senden.
  3. 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:

  1. Aktivieren Sie die Fehlerbehebungsprotokolle, wie in Schritt 2 oben beschrieben.

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

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

  1. 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
  2. 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-Proxy remote-service in der entsprechenden Edge-Umgebung bereit und versuchen Sie es noch einmal.
  3. 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:

  1. 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
  2. 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.

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

  1. 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
  2. Wenn sie nicht ausgeführt wird, ist das die Ursache des Problems.

Auflösung

  1. Wenn der Apigee Adapter for Envoy-Prozess nicht ausgeführt wird, starten Sie den Apigee Adapter for Envoy.
  2. 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

  1. Beenden Sie den Apigee-Adapter for Envoy und starten Sie ihn neu.
  2. 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

  1. 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 '^]'.
  2. 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:

  1. Verwendetes Apigee-Produkt:

    Beispiel: Apigee Edge Cloud, Apigee OPDK, Apigee Hybrid, Apigee X

  2. Apigee-Organisation und -Umgebung

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

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

  5. 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
  6. Eine API-Anfrage, die mit einem curl-Befehl an den Envoy-Proxy gesendet wurde (die vollständige Ausgabe des Befehls curl): 
    curl -v ENVOY_PROXY_ENDPOINT
  7. Eine API-Anfrage, die mit einem curl-Befehl (die vollständige Ausgabe des Befehls curl) an den Zieldienst gesendet wird: 
    curl -v TARGET_SERVICE_ENDPOINT