Le proxy Envoy échoue et renvoie une erreur HTTP 403 "Action interdite" dans l'adaptateur Apigee pour Envoy.

<ph type="x-smartling-placeholder"></ph> Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur Apigee X. En savoir plus

Symptôme

Le proxy Envoy échoue avec l'erreur HTTP 403 Forbidden lorsqu'il est appelé via Adapter Apigee pour Envoy

Message d'erreur

Le message d'erreur suivant s'affiche : 

HTTP/1.1 403 Forbidden
content-length: 19
content-type: text/plain
date: Tue, 03 Nov 2020 00:20:10 GMT
server: istio-envoy

Causes possibles

Le proxy Envoy génère une erreur HTTP 403 si l'une des conditions suivantes est remplie : se produire:

Cause Description Instructions de dépannage applicables
Le produit API n'est pas activé Le produit d'API n'est pas activé pour l'environnement spécifique. Utilisateurs Edge de cloud public et privé
Chemin d'URI du service cible manquant dans le produit API Le chemin de l'URI du service cible est manquant ou n'a pas été ajouté au produit d'API sous l'API. ressources. Utilisateurs Edge de cloud public et privé
Nom d'hôte manquant dans le produit API Le nom d'hôte indiqué dans la requête API cliente est manquant dans le produit d'API sous Apigee. cibles de services à distance. Utilisateurs Edge de cloud public et privé
Clé API manquante dans l'en-tête de la requête La clé API n'est pas transmise dans l'en-tête HTTP x-api-key. Utilisateurs Edge de cloud public et privé
Clé API non valide La clé API transmise dans la requête n'est pas valide. Utilisateurs Edge de cloud public et privé
L'adaptateur Apigee pour Envoy n'est pas en mesure de communiquer avec le proxy d'API du service à distance Apigee Adapter for Envoy ne peut pas communiquer avec le proxy de l'API du service distant. Utilisateurs Edge de cloud public et privé
Le proxy Envoy ne parvient pas à communiquer avec Apigee Adapter for Envoy Le proxy Envoy ne peut pas communiquer avec Apigee Adapter for Envoy Utilisateurs Edge de cloud public et privé

Avant de commencer

  1. Vérifiez que vous recevez le message de réponse 403 Forbidden du Proxy Envoy. Par exemple,
    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. Activez les journaux de débogage:

    Assurez-vous d'avoir activé les journaux de débogage dans Apigee Adapter for Envoy afin de capturer plus d'informations sur l'erreur. Si ce n'est pas le cas, arrêtez Apigee Adapter for Envoy et redémarrez-le, ce qui active les journaux de débogage. en exécutant la commande suivante: 

    apigee-remote-service-envoy -c config.yaml -l debug

Cause: le produit API n'est pas activé

Cette erreur se produit si le produit d'API spécifique utilisé par le proxy Envoy n'est pas activé dans le environnement spécifique dans lequel les appels d'API sont appelés.

Diagnostic

Pour diagnostiquer le problème, procédez comme suit:

  1. Activez les journaux de débogage comme expliqué à l'étape 2 ci-dessus.
  2. Consultez les journaux de l'adaptateur Apigee pour Envoy et vérifiez que le message suivant s'affiche dans la section Authorizing request: 
    product: API_PRODUCT_NAME not found

    Exemple de résultat du journal de débogage:

    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

    L'exemple ci-dessus montre que le produit API ENVOY-PRODUCT-1 est introuvable dans Apigee Adapter pour Envoy.

    Pour en savoir plus sur la journalisation Apigee Adapter pour Envoy, consultez Journalisation.

  3. Si ce message s'affiche lorsque vous autorisez la requête API, cela indique probablement que le produit d'API spécifique n'est pas activé pour un environnement spécifique dans lequel les appels d'API.
  4. Pour ce faire, procédez comme suit: <ph type="x-smartling-placeholder">
      </ph>
    1. Connectez-vous à l'interface utilisateur Edge.
    2. Sur la page Publier > Produits API, cliquez sur le produit API spécifique que vous utilisé pour configurer Apigee Adapter pour Envoy.
    3. Vérifiez que l'environnement spécifique dans lequel vous effectuez les requêtes API est dans le produit API.
    4. Si l'environnement spécifique n'est pas activé dans le produit d'API, cela explique pour ce problème.
  5. Si l'environnement spécifique est déjà activé, accédez à <ph type="x-smartling-placeholder"></ph> Cause: chemin d'URI du service cible manquant dans le produit API.

Solution

Si l'environnement spécifique n'est pas activé dans le produit d'API, procédez comme suit pour résoudre le problème:

  1. Connectez-vous à l'interface utilisateur Edge.
  2. Sur la page Publier > Produits d'API, cliquez sur le produit API que vous avez utilisé pour configurer Apigee Adapter pour Envoy.
  3. Sur la page Produits API > Nom du produit, cliquez sur Modifier.
  4. Activez l'environnement spécifique dans lequel vous souhaitez envoyer des requêtes API en sélectionnant en cochant la case correspondante.
  5. Cliquez sur Enregistrer.

Cause: chemin d'URI du service cible manquant dans le produit API

Cette erreur se produit si le chemin d'URI de la cible n'est pas spécifié dans le produit d'API spécifique utilisé. par le proxy Envoy.

Diagnostic

Pour diagnostiquer le problème, procédez comme suit:

  1. Activez les journaux de débogage comme expliqué à l'étape 2 ci-dessus.

  2. Consultez les journaux de l'adaptateur Apigee pour Envoy et vérifiez que le message suivant est affiché pour le produit d'API spécifique associé à une cible spécifique dans la section Authorizing request: 

    no path: REQUEST_URI_PATH

    Exemple de résultat du journal de débogage:

    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)

    L'exemple de résultat affiche le message suivant:

    no path: /echo1

    Indique que le chemin /echo1 est introuvable dans le produit d'API ENVOY-PRODUCT-1

  3. Si le message no path: REQUEST_URI_PATH s'affiche dans Les journaux de débogage Apigee Adapter for Envoy sont à l'origine du problème. Si ce n'est pas le cas, accédez à Cause: nom d'hôte manquant dans le produit d'API.

Solution

Si l'URI de la requête spécifique n'est pas ajouté au produit d'API pour la cible spécifique, alors procédez comme suit pour résoudre le problème:

  1. Connectez-vous à l'interface utilisateur Edge.
  2. Sur la page Publier > Produits API, cliquez sur le produit API spécifique que vous utilisé pour configurer Apigee Adapter pour Envoy.
  3. Sur la page Produits API > Nom du produit, cliquez sur Modifier.
  4. Dans le volet Ressources d'API, ajoutez l'URI de la requête API au produit d'API.
  5. Surveillez les journaux de l'adaptateur Apigee pour Envoy et attendez qu'il en soit récupère le produit API mis à jour. Envoyez ensuite une autre requête API pour vérifier le correctif.

Cause: nom d'hôte manquant dans le produit API

Cette erreur se produit si la combinaison nom d'hôte/port cible n'est pas ajoutée à la Produit d'API utilisé par le proxy Envoy.

Diagnostic

Pour diagnostiquer le problème, procédez comme suit:

  1. Activez les journaux de débogage comme expliqué à l'étape 2 ci-dessus.

  2. Consultez les journaux de l'adaptateur Apigee pour Envoy et vérifiez que le message suivant est affiché pour le produit d'API spécifique associé à une cible spécifique dans la section Authorizing request:

    no targets: HOSTNAME:PORT

    Exemple de résultat du journal de débogage:

    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)

    L'exemple ci-dessus montre que la combinaison nom d'hôte/port httpbin1:8080 est introuvable dans le produit API ENVOY-PRODUCT-1.

  3. Si les journaux Apigee Adapter for Envoy contiennent une entrée avec le message no targets: HOSTNAME:PORT lors de l'autorisation de la requête, il s'agit de la la cause du problème. Si ce n'est pas le cas, accédez à Cause: clé API manquante dans l'en-tête de la requête.

Solution

Si la combinaison nom d'hôte/port cible n'est pas ajoutée au produit API, exécutez la procédez comme suit pour résoudre le problème:

  1. Connectez-vous à l'interface utilisateur Edge.
  2. Sur la page Publier > Produits API, cliquez sur le produit API spécifique que vous utilisé pour configurer Apigee Adapter pour Envoy.
  3. Sur la page Produits API > Nom du produit, cliquez sur Modifier.

  4. Dans le volet Cibles de services distants Apigee, ajoutez le nom d'hôte cible et puis cliquez sur Enregistrer.

    Si vous ne voyez pas la section Cibles de services distants Apigee dans l'interface utilisateur, ajoutez un attribut personnalisé au produit API à l'aide du paramètre nommez apigee-remote-service-targets et ajoutez HOSTNAME:PORT à l'aide de l'API Edge. Exemple :

    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. Une fois la tâche ci-dessus terminée, surveillez les journaux de l'adaptateur Apigee pour Envoy et attendez que le message Apigee Adapter for Envoy récupère le produit d'API mis à jour. Envoyez ensuite une autre API pour vérifier la correction.

Cause: clé API manquante dans l'en-tête de la requête

Cette erreur se produit si la clé API n'est pas transmise dans les en-têtes de requête.

Diagnostic

Pour diagnostiquer le problème, procédez comme suit:

  1. Activez les journaux de débogage comme expliqué à l'étape 2 ci-dessus.
  2. Consultez les journaux de l'adaptateur Apigee pour Envoy et vérifiez que les [missing authentication] message sous Authenticate error .

    Exemple de résultat du journal de débogage:

    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

    L'exemple de résultat ci-dessus affiche le message [missing authentication]. Ce message indique que la clé API n'est pas transmise dans le cadre en-tête de requête.

  3. Si les journaux Apigee Adapter for Envoy contiennent une entrée de journal avec le message [missing authentication] dans la section Authenticate error , il s'agit de la cause du problème. Si ce n'est pas le cas, accédez à Cause: clé API non valide.

Solution

Si l'erreur [missing authentication] s'est affichée dans le Pour résoudre le problème, procédez comme suit pour les journaux Apigee Adapter for Envoy:

  1. Vérifiez si le client a envoyé la clé API à l'aide de l'en-tête HTTP x-api-key dans la requête API. Si ce n'est pas le cas, demandez au client d'envoyer la clé API dans l'en-tête HTTP. x-api-key
  2. Vérifiez le fichier de configuration de l'adaptateur Apigee pour Envoy et vérifiez que la clé API par défaut nom d'en-tête x-api-key a été modifié, par exemple: 
    apiVersion: v1
kind: ConfigMap
metadata:
  name: apigee-remote-service-envoy
  namespace: apigee
data:
  config.yaml: |
    global:
      tls:
        ...
    tenant:
      ...
    auth:
      target_header: api-key

    Dans l'exemple ci-dessus, le nom d'en-tête de clé API par défaut a été remplacé par api-key Dans ce cas, vous devez transmettre la clé API dans l'en-tête. api-key

  3. Si le nom de l'en-tête de clé API par défaut a été modifié, demandez au client d'utiliser l'en-tête mis à jour Nom d'en-tête de la clé API, puis envoyez une autre requête API et vérifiez si le problème est résolu.

Cause: clé API non valide

Cette erreur se produit si une clé API non valide est transmise dans l'en-tête de la requête.

Diagnostic

Pour diagnostiquer le problème, procédez comme suit:

  1. Activez les journaux de débogage comme expliqué à l'étape 2 ci-dessus.
  2. Consultez les journaux de l'adaptateur Apigee pour Envoy et vérifiez que le message s'affiche [permission denied] dans la section Authenticate error. Cela s'affiche généralement une fois que l'adaptateur a récupéré la clé API, ce qui est indiqué par le message fetchToken fetching: API_KEY.

    Exemple de résultat du journal de débogage:

    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)

    Dans cet exemple, la clé API envoyée dans la requête API n'était pas valide.

  3. Si les journaux Apigee Adapter for Envoy contiennent une entrée de journal avec le [permission denied] dans la section Authenticate error , cela indique que la clé API transmise dans la requête n'est pas valide et est à l'origine du problème. Si ce n'est pas le cas, accédez à Cause: Apigee Adapter for Envoy ne parvient pas à communiquer avec le proxy de l'API du service distant.

Solution

Si le message [permission denied] est observé dans la section Authenticate error des journaux Apigee Adapter for Envoy, procédez comme suit : pour résoudre le problème:

  1. Comparez la clé API envoyée dans la requête API à la valeur de clé API indiquée dans le l'application connectée au produit API.
  2. Si la clé API utilisée par le client n'est pas valide, demandez au client d'envoyer la clé API valide.
  3. Si la clé API utilisée par le client est valide et si un message HTTP 403, veuillez contacter l'assistance Apigee Edge pour examiner le problème plus en détail.

Cause: Apigee Adapter for Envoy ne parvient pas à communiquer avec le proxy d'API du service distant

Cette erreur se produit si Apigee Adapter for Envoy ne parvient pas à communiquer avec le contrôleur proxy d'API de service si l'hôte de service distant configuré n'est pas valide.

Diagnostic

Pour diagnostiquer le problème, procédez comme suit:

  1. Activez les journaux de débogage comme expliqué à l'étape 2 ci-dessus.

  2. Consultez les journaux de l'adaptateur Apigee pour Envoy et vérifiez que le message suivant s'affiche:

    Error retrieving products: REQUEST_URI: no such host

    Exemple de résultat du journal de débogage:

    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

    Dans cet exemple, Apigee Adapter for Envoy n'a pas pu communiquer avec le le proxy API du service distant, car le nom d'hôte fourni dans le proxy d'API du serveur distant L'URL n'est pas valide, comme indiqué par l'erreur no such host .

  3. Si les journaux Apigee Adapter for Envoy contiennent une entrée de journal avec le message no such host, c'est la cause du problème. Si ce n'est pas le cas, accédez à <ph type="x-smartling-placeholder"></ph> Cause: le proxy Envoy ne peut pas communiquer avec Apigee Adapter for Envoy.

Solution

Si les erreurs ci-dessus s'affichent dans les journaux Apigee Adapter for Envoy, procédez comme suit : procédure de résolution du problème:

  1. Consultez le fichier de configuration Apigee Adapter for Envoy et vérifiez que la valeur L'URL du proxy de l'API du service distant est valide.

    Si ce n'est pas le cas, arrêtez Apigee Adapter for Envoy et corrigez l'URL du proxy de l'API du service distant dans la fichier de configuration, démarrez Apigee Adapter for Envoy, puis envoyez une autre requête API et vérifier le correctif.

    Exemple de configuration:

    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. Vérifier que le proxy d'API remote-service est déployé dans l'appareil Edge approprié environnement. Si ce n'est pas le cas, déployez le proxy d'API remote-service dans l'appareil Edge approprié puis réessayez.
  3. Vérifiez la connectivité réseau entre l'adaptateur Apigee pour Envoy et le Point de terminaison du proxy d'API remote-service. Si une connectivité réseau est disponible les problèmes détectés, contactez votre équipe réseau et essayez de les résoudre.

Cause: le proxy Envoy ne parvient pas à communiquer avec Apigee Adapter for Envoy

Diagnostic

Pour diagnostiquer le problème, procédez comme suit:

  1. Assurez-vous d'avoir activé les journaux de débogage dans Envoy. Si ce n'est pas le cas, arrêtez Envoy, puis redémarrez-le. activer les journaux de débogage. Envoyez ensuite une autre requête API.

    Déploiements autonomes:

    envoy -c envoy-config.yaml -l debug

    Déploiements basés sur Kubernetes/Istio:

    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. Consultez les journaux de l'adaptateur Apigee pour Envoy et vérifiez qu'il existe une entrée de journal avec le message suivant: 
    connecting to APIGEE_ENVOY_ADAPTER_HOST:5000

    qui est ensuite suivie de:

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

    Exemple de résultat du journal de débogage:

    [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'

    L'exemple ci-dessus montre qu'Envoy n'a pas pu communiquer avec Apigee Adapter pour Envoy pour la raison suivante : connection failure.

  3. Le connection failure peut être dû à plusieurs raisons. Examinons chacun de ces scénarios.

Scénario 1: le processus de l'adaptateur ne s'exécute pas

Si le processus Apigee Adapter for Envoy n'est pas en cours d'exécution, cette erreur peut se produire.

  1. Vérifiez que le processus Apigee Adapter for Envoy est en cours d'exécution en exécutant la commande suivante : . Si le processus Apigee Adapter for Envoy est en cours d'exécution, le résultat suivant doit la lister. 
    ps -ef | grep apigee-remote-service-envoy
  2. S'il ne fonctionne pas, c'est la cause du problème.

Solution

  1. Si le processus Apigee Adapter for Envoy n'est pas en cours d'exécution, démarrez le Apigee Adapter pour Envoy.
  2. Envoyez une autre requête API et vérifiez si le problème a été résolu.

Scénario 2: Le processus de l'adaptateur n'écoute pas sur le port spécifique

Si le processus Apigee Adapter for Envoy n'écoute pas sur le port spécifique, alors cette erreur peut se produire.

Si le processus Apigee Adapter for Envoy est en cours d'exécution, vérifiez qu'un socket écoute sur port 5000: APIGEE_ENVOY_ADAPTER_HOST:5000. Vous pouvez exécuter la netstat pour le vérifier:

sudo netstat -lnp | grep 5000

Exemple de résultat :

sudo netstat -lnp | grep 5000

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

Si aucun socket n'écoute sur le port 5000, cela peut être la cause du problème.

Solution

  1. Arrêtez l'adaptateur Apigee pour Envoy, puis redémarrez-le.
  2. Envoyez une autre requête API et vérifiez si le problème a été résolu.

Scénario 3: Connectivité réseau entre Envoy et Apigee Adapter pour Envoy

  1. Vérifiez la connectivité réseau entre Envoy et Apigee Adapter for Envoy: 
    ssh $ENVOY_HOST
telnet $APIGEE_ENVOY_ADAPTER_HOST 5000

    Si telnet pouvait établir une connexion TCP avec Apigee Adapter for Envoy un résultat semblable à celui-ci s'affiche:

    telnet $APIGEE_ENVOY_ADAPTER_HOST 5000

Trying ::1...
Connected to localhost.
Escape character is '^]'.
  2. Si vous observez l'erreur Connection timed out avec telnet, cela indique il y a un problème de connectivité réseau entre Envoy et Apigee Adapter for Envoy.

Solution

Si vous constatez des problèmes de connectivité réseau entre Envoy et Apigee Adapter for Envoy, veuillez faire participer votre équipe de réseautage et essayer de résoudre le problème.

Si le problème persiste, accédez à Obligation de recueillir des informations de diagnostic.

Vous devez collecter des informations de diagnostic

Si le problème persiste après avoir suivi les instructions ci-dessus, rassemblez les données de diagnostic suivantes d'assistance, puis contactez l'assistance Apigee Edge:

  1. Produit Apigee utilisé:

    Exemples:Apigee Edge Cloud, Apigee OPDK, Apigee hybrid, Apigee X

  2. Organisation et environnement Apigee

  3. Lecture de la définition du produit d'API à l'aide de l'API Edge:

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

    Référence:API Apigee Edge

  4. Démarrez une session de trace dans le proxy d'API remote-service à l'aide de la Interface utilisateur d'Apigee Edge Reproduisez le problème et partagez le fichier XML de la session Trace.

    Référence: Utiliser l'outil Trace | Apigee Edge

  5. Journaux Apigee Adapter for Envoy (journaux complets liés à la période donnée)

    Déploiements autonomes:

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

    Déploiements basés sur Kubernetes/Istio:

    kubectl -n=apigee get pods
kubectl -n=apigee logs APIGEE_REMOTE_SERVICE_ENVOY_POD_NAME > apigee-remote-service-envoy.log
  6. Requête API envoyée au proxy Envoy à l'aide d'une commande curl (résultat complet de la commande curl): 
    curl -v ENVOY_PROXY_ENDPOINT
  7. Une requête API envoyée au service cible à l'aide d'une commande curl (complète sortie de la commande curl): 
    curl -v TARGET_SERVICE_ENDPOINT