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

<ph type="x-smartling-placeholder"></ph> Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur Apigee X-Dokumentation. Weitere Informationen

Symptom

Envoy-Proxy schlägt mit dem HTTP-Fehler 403 Forbidden fehl, wenn über Apigee-Adapter für Envoy.

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 löst den HTTP-Fehler 403 aus, wenn eine der folgenden Bedingungen auftreten:

Ursache Beschreibung Anleitungen zur Fehlerbehebung gelten für
API-Produkt ist nicht aktiviert Das API-Produkt ist für die jeweilige Umgebung nicht aktiviert. Edge-Nutzer von öffentlichen und privaten Clouds
Fehlender URI-Pfad des Zieldienstes im API-Produkt Der URI-Pfad des Zieldienstes fehlt oder wurde dem API-Produkt unter „API“ nicht hinzugefügt Ressourcen. Edge-Nutzer von öffentlichen und privaten Clouds
Fehlender Hostname im API-Produkt Der in der Client-API-Anfrage angegebene Hostname fehlt im API-Produkt unter Apigee Remote-Dienstziele. Edge-Nutzer von öffentlichen und privaten Clouds
Fehlender API-Schlüssel im Anfrageheader Der API-Schlüssel wird nicht im HTTP-Header x-api-key übergeben. Edge-Nutzer von öffentlichen und privaten Clouds
Ungültiger API-Schlüssel Der als Teil der Anfrage übergebene API-Schlüssel ist ungültig. Edge-Nutzer von öffentlichen und privaten Clouds
Apigee-Adapter for Envoy kann nicht mit dem Remote-Dienst-API-Proxy kommunizieren Der Apigee-Adapter for Envoy kann nicht mit dem Remote-Dienst-API-Proxy kommunizieren. Edge-Nutzer von öffentlichen und privaten Clouds
Envoy-Proxy kann nicht kommunizieren mit Apigee Adapter for Envoy Der Envoy-Proxy kann nicht mit dem Apigee-Adapter for Envoy kommunizieren Edge-Nutzer von öffentlichen und privaten Clouds

Hinweis

  1. Prüfen Sie, ob Sie die Antwortnachricht 403 Forbidden von der Envoy-Proxy. 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. Aktivieren Sie die Fehlerbehebungsprotokolle:

    Achten Sie darauf, dass Sie Fehlerbehebungslogs im Apigee-Adapter für Envoy aktiviert haben, um weitere Details zu erfassen. Fehler. Wenn nicht, beenden Sie Apigee Adapter for Envoy und starten Sie ihn neu, um Fehlerbehebungslogs zu aktivieren 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 Spezifische Umgebung, in der die API-Aufrufe aufgerufen werden.

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 in den Apigee-Adapter für Envoy-Logs, ob die folgende Meldung angezeigt wird im Abschnitt Authorizing request: 
    product: API_PRODUCT_NAME not found

    Beispiel für die Ausgabe des Debug-Logs:

    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 Beispiel oben zeigt, dass das API-Produkt ENVOY-PRODUCT-1 in Apigee-Adapter für Envoy

    Weitere Informationen zum Apigee-Adapter für Envoy-Logging finden Sie unter Logging:

  3. Wenn diese Meldung beim Autorisieren der API-Anfrage angezeigt wird, deutet sie höchstwahrscheinlich darauf hin, dass das API-Produkt nicht für eine bestimmte Umgebung aktiviert ist, in der Sie die API-Aufrufe durchführt.
  4. Führen Sie die folgenden Schritte aus, um dies zu überprüfen: <ph type="x-smartling-placeholder">
      </ph>
    1. Melden Sie sich bei der Edge-Benutzeroberfläche an.
    2. Wählen Sie im Menü Veröffentlichen > API-Produkte auf das spezifische API-Produkt, das Sie zum Konfigurieren des Apigee-Adapters für Envoy.
    3. Prüfen Sie, ob die 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 das der Grund für dieses Problem.
  5. Wenn die jeweilige Umgebung bereits aktiviert ist, gehen Sie zu <ph type="x-smartling-placeholder"></ph> Ursache: Fehlender Zieldienst-URI-Pfad im API-Produkt.

Auflösung

Wenn die jeweilige Umgebung im API-Produkt nicht aktiviert ist, führen Sie die folgenden Schritte aus, um So beheben Sie das Problem:

  1. Melden Sie sich bei der Edge-Benutzeroberfläche an.
  2. Wählen Sie im Menü Veröffentlichen > API-Produkte auf das von Ihnen verwendete API-Produkt. zum Konfigurieren des Apigee-Adapters für Envoy.
  3. Klicken Sie auf der Seite API-Produkte > auf der Seite "Produktname" auf Bearbeiten.
  4. Aktivieren Sie die Umgebung, in der Sie API-Anfragen stellen möchten. Wählen Sie dazu das entsprechende Kontrollkästchen.
  5. Klicken Sie auf Speichern.

Ursache: Fehlender Zieldienst-URI-Pfad im API-Produkt

Dieser Fehler tritt auf, wenn der URI-Pfad des Ziels nicht im verwendeten API-Produkt angegeben ist durch den Envoy-Proxy.

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 in den Apigee-Adapter für Envoy-Logs, ob die folgende Nachricht lautet: die für das spezifische API-Produkt angezeigt werden, das mit einem bestimmten Ziel im Abschnitt verknüpft ist Authorizing request: 

    no path: REQUEST_URI_PATH

    Beispiel für die Ausgabe des Debug-Logs:

    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 weist darauf hin, dass der Pfad /echo1 im API-Produkt nicht gefunden wurde. ENVOY-PRODUCT-1.

  3. Wenn Sie die Meldung no path: REQUEST_URI_PATH in der Apigee-Adapter für Envoy-Debug-Logs, dann ist das die Ursache des Problems. Falls nicht, gehen Sie zu Ursache: Hostname fehlt im API-Produkt.

Auflösung

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

  1. Melden Sie sich bei der Edge-Benutzeroberfläche an.
  2. Wählen Sie im Menü Veröffentlichen > API-Produkte auf das spezifische API-Produkt, das Sie zum Konfigurieren des Apigee-Adapters für Envoy.
  3. Klicken Sie auf der Seite API-Produkte > auf der Seite "Produktname" auf Bearbeiten.
  4. Fügen Sie im Bereich API-Ressourcen den API-Anfrage-URI zum API-Produkt hinzu.
  5. Apigee-Adapter für Envoy-Logs überwachen und auf den Apigee-Adapter für Envoy warten ruft das aktualisierte API-Produkt ab. Senden Sie anschließend eine weitere API-Anfrage, um die Korrektur zu prüfen.

Ursache: Hostname im API-Produkt fehlt

Dieser Fehler tritt auf, wenn die Kombination aus Zielhostname und -port nicht zur spezifischen Vom Envoy-Proxy verwendetes API-Produkt.

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 in den Apigee-Adapter für Envoy-Logs, ob die folgende Nachricht lautet: die für das spezifische API-Produkt angezeigt werden, das mit einem bestimmten Ziel im Abschnitt verknüpft ist Authorizing request:

    no targets: HOSTNAME:PORT

    Beispiel für die Ausgabe des Debug-Logs:

    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 obige Beispiel zeigt, dass die Kombination aus Hostname und Port httpbin1:8080 wurde im API-Produkt ENVOY-PRODUCT-1 nicht gefunden.

  3. Wenn die Apigee Adapter for Envoy-Logs bei der Autorisierung der Anfrage einen Eintrag mit der Nachricht no targets: HOSTNAME:PORT enthalten, ist dies der Ursache des Problems. Falls nicht, gehen Sie zu Ursache: Fehlender API-Schlüssel im Anfrageheader

Auflösung

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

  1. Melden Sie sich bei der Edge-Benutzeroberfläche an.
  2. Wählen Sie im Menü Veröffentlichen > API-Produkte auf das spezifische API-Produkt, das Sie zum Konfigurieren des Apigee-Adapters für Envoy.
  3. Klicken Sie auf der Seite API-Produkte > auf der Seite "Produktname" auf Bearbeiten.

  4. Fügen Sie im Bereich Apigee remote service targets den Zielhostnamen und und klicken Sie auf Speichern.

    Wenn Sie in der Benutzeroberfläche den Abschnitt Apigee Remote Service Goals nicht sehen, gehen Sie so vor: Hinzufügen eines benutzerdefinierten Attributs zum API-Produkt mit der apigee-remote-service-targets benennen und den HOSTNAME:PORT-Wert mithilfe der Edge API. 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": []
}
    <ph type="x-smartling-placeholder">
  5. Sobald die obige Aufgabe abgeschlossen ist, überwachen Sie die Apigee Adapter for Envoy-Logs und warten Sie, bis der Der Apigee-Adapter for Envoy ruft das aktualisierte API-Produkt ab. Senden Sie anschließend eine weitere API, um die Fehlerbehebung 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. Prüfen Sie in den Apigee-Adapter für Envoy-Logs, ob das Symbol [missing authentication]-Nachricht unter Authenticate error .

    Beispiel für die Ausgabe des Debug-Logs:

    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 hat die Nachricht [missing authentication]. Diese Meldung gibt an, dass der API-Schlüssel nicht als Teil des Anfrageheader.

  3. Wenn die Apigee Adapter for Envoy-Logs einen Logeintrag mit der Nachricht [missing authentication] im Abschnitt Authenticate error enthalten, ist dies um die Ursache des Problems zu finden. Falls nicht, gehen Sie zu Ursache: Ungültiger API-Schlüssel.

Auflösung

Wurde der Fehler [missing authentication] im Apigee Adapter for Envoy-Logs führen Sie die folgenden Schritte aus, um das Problem zu beheben:

  1. Prüfen Sie, ob der Client den API-Schlüssel mit dem HTTP-Header x-api-key in der API-Anfrage. Falls nicht, fordern Sie den Client an, den API-Schlüssel im HTTP-Header zu senden x-api-key
  2. Prüfen Sie die Konfigurationsdatei des Apigee-Adapters für Envoy und stellen Sie sicher, dass der Standard-API-Schlüssel Der Headername x-api-key wurde geändert. Hier ein 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 Standardname des API-Schlüssel-Headers geändert zu api-key In diesem Fall müssen Sie den API-Schlüssel als Teil des Headers api-key

  3. Wenn der Standardheadername des API-Schlüssels geändert wurde, fordern Sie den Client an, die aktualisierte Name des API-Schlüssel-Headers und senden Sie eine weitere API-Anfrage. Prüfen Sie, ob das Problem dadurch behoben wurde.

Ursache: Ungültiger API-Schlüssel

Dieser Fehler tritt auf, wenn ein ungültiger API-Schlüssel als Teil des Anfrage-Headers ü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 in den Apigee-Adapter für Envoy-Logs, ob die Meldung angezeigt wird [permission denied] im Abschnitt Authenticate error. Dies wird normalerweise angezeigt, nachdem der API-Schlüssel vom Adapter abgerufen wurde. Dies wird durch die Nachricht fetchToken fetching: API_KEY.

    Beispiel für die Ausgabe des Debug-Logs:

    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 die Apigee Adapter for Envoy-Logs einen Logeintrag mit dem [permission denied] im Abschnitt Authenticate error enthalten, bedeutet dies, dass Der als Teil der Anfrage übergebene API-Schlüssel ist ungültig und verursacht das Problem. Falls nicht, gehen Sie zu Ursache: Apigee-Adapter für Envoy kann nicht mit dem Remote-Dienst-API-Proxy kommunizieren.

Auflösung

Wenn im Abschnitt Authenticate error der Logs des Apigee-Adapters für Envoy die Meldung [permission denied] angezeigt wird, führen Sie die folgenden Schritte aus um das Problem zu beheben:

  1. Vergleichen Sie den API-Schlüssel in der API-Anfrage mit dem API-Schlüsselwert aus der Anwendung, die mit dem API-Produkt verbunden ist.
  2. Wenn der vom Client verwendete API-Schlüssel ungültig ist, fordern Sie den Client an, einen gültigen API-Schlüssel zu senden.
  3. Wenn der vom Client verwendete API-Schlüssel gültig ist und immer noch ein HTTP-Statuscode 403 Fehler. Wenden Sie sich an den Apigee Edge-Support, um diesen Fehler weiter zu untersuchen.

Ursache: Der Apigee-Adapter für Envoy kann nicht mit dem API-Proxy für den Remote-Dienst kommunizieren.

Dieser Fehler tritt auf, wenn der Apigee-Adapter for Envoy nicht mit der Remote-Verbindung kommunizieren kann Dienst-API-Proxy, 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 in den Logs des Apigee-Adapters für Envoy, dass die folgende Meldung angezeigt wird:

    Error retrieving products: REQUEST_URI: no such host

    Beispiel für die Ausgabe des Debug-Logs:

    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-Service-API-Proxy, da der Hostname im API-Proxy des Remote-Servers angegeben ist Die URL ist nicht gültig, wie durch den Fehler no such host gekennzeichnet .

  3. Wenn die Apigee Adapter for Envoy-Logs einen Logeintrag mit der Nachricht no such host enthalten, ist dies die Problemursache. Falls nicht, gehen Sie zu <ph type="x-smartling-placeholder"></ph> Ursache: Der Envoy-Proxy kann nicht mit dem Apigee-Adapter for Envoy kommunizieren.

Auflösung

Wenn die oben genannten Fehler in den Apigee Adapter for Envoy-Logs angezeigt werden, führen Sie Folgendes aus: um das Problem zu beheben:

  1. Prüfen Sie die Konfigurationsdatei des Apigee-Adapters für Envoy und stellen Sie sicher, dass die angegebene Proxy-URL der Remote-Service-API ist gültig.

    Beenden Sie andernfalls den Apigee-Adapter for Envoy und korrigieren Sie die URL des Remote-Dienst-API-Proxys in der Konfigurationsdatei, starten Sie Apigee Adapter for Envoy und senden Sie eine weitere API-Anfrage und und prüfen Sie, ob das Problem behoben wurde.

    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 im relevanten Edge bereitgestellt wird zu verbessern. Wenn nicht, stellen Sie den API-Proxy remote-service im relevanten Edge bereit. und versuchen Sie es noch einmal.
  3. Prüfen Sie die Netzwerkverbindung zwischen dem Apigee-Adapter for Envoy und dem API-Proxy-Endpunkt remote-service. Ob eine Netzwerkverbindung besteht Probleme gefunden haben, wenden Sie sich an Ihr Netzwerkteam und versuchen Sie, das Problem zu lösen.

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:

  1. Achten Sie darauf, dass Sie Fehlerbehebungslogs in Envoy aktiviert haben. Falls nicht, beenden Sie Envoy und starten Sie es neu. Fehlerbehebungsprotokolle. 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
  2. Prüfen Sie die Logs des Apigee-Adapters für Envoy und stellen Sie sicher, dass ein Logeintrag mit der 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 die Ausgabe des Debug-Logs:

    [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 nicht mit Apigee-Adapter für Envoy aus dem Grund connection failure.

  3. Das connection failure kann verschiedene Gründe haben. 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, ob der Apigee-Adapter for Envoy-Prozess ausgeführt wird. Führen Sie dazu den folgenden Befehl aus: . Wenn der Apigee Adapter for Envoy-Prozess ausgeführt wird, führt dies zu folgendem Ergebnis: sollte sie aufgelistet werden. 
    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 für Envoy
  2. Senden 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 den bestimmten Port nicht überwacht, kann dieser Fehler auftreten.

Wenn der Apigee Adapter for Envoy-Prozess ausgeführt wird, prüfen Sie, ob ein Socket überwacht wird Port 5000: APIGEE_ENVOY_ADAPTER_HOST:5000. Sie können den netstat, um dies zu prüfen:

sudo netstat -lnp | grep 5000

Beispielausgabe:

sudo netstat -lnp | grep 5000

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

Wenn kein Socket Port 5000 überwacht, könnte dies der Grund für dieses Problem sein.

Auflösung

  1. Beenden Sie den Apigee-Adapter for Envoy und starten Sie ihn neu.
  2. Senden 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 Netzwerkkonnektivität zwischen Envoy und Apigee-Adapter for Envoy: 
    ssh $ENVOY_HOST
telnet $APIGEE_ENVOY_ADAPTER_HOST 5000

    Wenn Telnet eine TCP-Verbindung zum Apigee-Adapter für Envoy herstellen kann wird eine Ausgabe angezeigt, die in etwa so aussieht:

    telnet $APIGEE_ENVOY_ADAPTER_HOST 5000

Trying ::1...
Connected to localhost.
Escape character is '^]'.
  2. Wenn bei Telnet der Fehler Connection timed out auftritt, bedeutet das, Es gibt ein Problem mit der Netzwerkverbindung zwischen Envoy und dem Apigee Adapter for Envoy.

Auflösung

Wenn Sie Netzwerkverbindungsprobleme zwischen Envoy und Apigee Adapter for Envoy feststellen, wenden Sie sich an Ihr Netzwerkteam, um das Problem zu lösen.

Wenn das Problem weiterhin besteht, gehe zu Diagnoseinformationen müssen erfasst werden.

Erfassen von Diagnoseinformationen erforderlich

Wenn das Problem weiterhin besteht, nachdem Sie die Schritte oben ausgeführt haben, führen Sie folgende Diagnosen aus: Informationen und wenden Sie sich dann 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 mithilfe der Edge API:

    curl -i -u $USER:$PASSWORD $MANAGEMENT_SERVER_ENDPOINT/v1/organizations/$ORGANIZATION/apiproducts/$API_PRODUCT

    Referenz: Apigee Edge-APIs

  4. Starten Sie mit dem API-Proxy remote-service eine Trace-Sitzung über die Apigee Edge-Benutzeroberfläche Reproduzieren Sie das Problem und geben Sie die XML-Datei der Trace-Sitzung frei.

    Referenz: Das Trace-Tool verwenden | Apigee Edge

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