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

Vous consultez la documentation d'Apigee Edge.
Consultez la documentation Apigee X. en savoir plus

Problème constaté

Le proxy Envoy échoue avec une erreur HTTP 403 Forbidden lorsqu'il est appelé via Apigee Adapter for 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:

Cause Description Instructions de dépannage applicables
Le produit d'API n'est pas activé Le produit d'API n'est pas activé pour l'environnement spécifique. Utilisateurs Edge Public and Private Cloud
Chemin d'accès de l'URI du service cible manquant dans le produit d'API Le chemin d'URI du service cible est manquant ou n'a pas été ajouté au produit d'API dans les ressources d'API. Utilisateurs Edge Public and Private Cloud
Nom d'hôte manquant dans le produit d'API Le nom d'hôte indiqué dans la requête d'API cliente est manquant dans le produit d'API sous les cibles de service à distance Apigee. Utilisateurs Edge Public and Private Cloud
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 Public and Private Cloud
Clé API non valide La clé API transmise dans la requête n'est pas valide. Utilisateurs Edge Public and Private Cloud
Apigee Adapter for Envoy ne parvient pas à communiquer avec le proxy d'API de service distant Apigee Adapter for Envoy ne peut pas communiquer avec le proxy d'API du service distant. Utilisateurs Edge Public and Private Cloud
Le proxy Envoy ne peut pas communiquer avec Apigee Adapter for Envoy Le proxy Envoy ne parvient pas à communiquer avec Apigee Adapter for Envoy Utilisateurs Edge Public and Private Cloud

Avant de commencer

  1. Vérifiez que vous recevez le message de réponse 403 Forbidden du proxy Envoy. 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 pour capturer plus d'informations sur l'erreur. Si ce n'est pas le cas, arrêtez Apigee Adapter for Envoy, puis redémarrez-le, en activant les journaux de débogage à l'aide de 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 l'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. Vérifiez les journaux Apigee Adapter for Envoy et vérifiez que le message suivant s'affiche dans la section Authorizing request : 
    product: API_PRODUCT_NAME not found

    Exemple de sortie 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 d'API ENVOY-PRODUCT-1 est introuvable dans Apigee Adapter for Envoy.

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

  3. Si ce message s'affiche lorsque vous autorisez la requête API, cela signifie probablement que le produit d'API concerné n'est pas activé pour l'environnement spécifique dans lequel vous effectuez les appels d'API.
  4. Pour le vérifier, procédez comme suit :
    1. Connectez-vous à l'interface utilisateur Edge.
    2. Sur la page Publier > Produits d'API, cliquez sur le produit d'API spécifique que vous avez utilisé pour configurer Apigee Adapter for Envoy.
    3. Vérifiez que l'environnement spécifique dans lequel vous envoyez les requêtes API est activé dans le produit d'API.
    4. Si l'environnement spécifique n'est pas activé dans le produit d'API, c'est la cause de ce problème.
  5. Si l'environnement spécifique est déjà activé, consultez la section Cause: chemin d'accès de l'URI du service cible manquant dans le produit d'API.

Ré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 d'API spécifique que vous avez utilisé pour configurer Apigee Adapter for Envoy.
  3. Sur la page Produits d'API > Nom du produit, cliquez sur Modifier.
  4. Activez l'environnement spécifique dans lequel vous souhaitez envoyer des requêtes API en cochant la case correspondant à l'environnement approprié.
  5. Cliquez sur Enregistrer.

Cause: chemin d'accès de l'URI du service cible manquant dans le produit d'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. Vérifiez les journaux Apigee Adapter for Envoy et vérifiez que le message suivant s'affiche pour le produit d'API spécifique associé à une cible spécifique dans la section Authorizing request: 

    no path: REQUEST_URI_PATH

    Exemple de sortie 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

    Cela indique que le chemin d'accès /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, c'est la cause du problème. Si ce n'est pas le cas, consultez Cause: nom d'hôte manquant dans le produit d'API.

Résolution

Si l'URI de requête spécifique n'est pas ajouté au produit d'API pour la cible spécifique, 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 d'API spécifique que vous avez utilisé pour configurer Apigee Adapter for Envoy.
  3. Sur la page Produits d'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 Apigee Adapter for Envoy et attendez qu'Apigee Adapter for Envoy récupère le produit d'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 au 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. Vérifiez les journaux Apigee Adapter for Envoy et vérifiez que le message suivant s'affiche pour le produit d'API spécifique associé à une cible spécifique dans la section Authorizing request:

    no targets: HOSTNAME:PORT

    Exemple de sortie 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 d'API ENVOY-PRODUCT-1.

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

Résolution

Si la combinaison nom d'hôte/port cible n'est pas ajoutée au 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 d'API spécifique que vous avez utilisé pour configurer Apigee Adapter for Envoy.
  3. Sur la page Produits d'API > Nom du produit, cliquez sur Modifier.

  4. Dans le volet Cibles de service à distance Apigee, ajoutez le nom d'hôte et le port cibles, puis cliquez sur Enregistrer.

    Si la section Cibles de service à distance Apigee ne s'affiche pas dans l'interface utilisateur, ajoutez un attribut personnalisé au produit d'API avec le nom apigee-remote-service-targets, puis ajoutez la valeur 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": []
}
  5. Une fois la tâche ci-dessus terminée, surveillez les journaux Apigee Adapter for Envoy et attendez qu'Apigee Adapter for Envoy récupère le produit d'API mis à jour. Envoyez ensuite une autre requête API pour vérifier le correctif.

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 Apigee Adapter for Envoy et vérifiez que le message [missing authentication] s'affiche dans la section Authenticate error.

    Exemple de sortie 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 contient le message [missing authentication]. Ce message indique que la clé API n'est pas transmise dans l'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 , c'est la cause du problème. Si ce n'est pas le cas, consultez Cause: clé API non valide.

Résolution

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

  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. Consultez le fichier de configuration Apigee Adapter for Envoy et vérifiez que le nom d'en-tête de clé API par défaut 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 par défaut de la clé API 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 d'en-tête de clé API par défaut a été modifié, demandez au client d'utiliser le nouveau nom, 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 Apigee Adapter for Envoy et vérifiez que le message [permission denied] s'affiche dans la section Authenticate error. Il s'affiche généralement après la récupération de la clé API par l'adaptateur, comme indiqué par le message fetchToken fetching: API_KEY.

    Exemple de sortie 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'est pas valide.

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

Ré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 trouvée dans l'application connectée au produit d'API.
  2. Si la clé API utilisée par le client n'est pas valide, demandez-lui d'envoyer la clé API valide.
  3. Si la clé API utilisée par le client est valide et si vous rencontrez toujours une erreur HTTP 403, veuillez contacter l'assistance Apigee Edge pour étudier le problème.

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

Cette erreur se produit si Apigee Adapter for Envoy ne parvient pas à communiquer avec le proxy d'API du service distant 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 Apigee Adapter for Envoy et vérifiez que le message suivant s'affiche:

    Error retrieving products: REQUEST_URI: no such host

    Exemple de sortie 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 proxy de l'API du service distant, car le nom d'hôte fourni dans l'URL du proxy de l'API du serveur distant 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, consultez Cause: le proxy Envoy ne parvient pas à communiquer avec Apigee Adapter for Envoy.

Résolution

Si les erreurs ci-dessus s'affichent dans les journaux Apigee Adapter for Envoy, procédez comme suit pour résoudre le problème:

  1. Vérifiez le fichier de configuration Apigee Adapter for Envoy et vérifiez que l'URL du proxy de l'API du service distant donnée est valide.

    Si ce n'est pas le cas, arrêtez Apigee Adapter for Envoy, corrigez l'URL du proxy de l'API du service distant dans le fichier de configuration, démarrez Apigee Adapter for Envoy, envoyez une autre requête API et vérifiez 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érifiez que le proxy d'API remote-service est déployé dans l'environnement périphérique approprié. Si ce n'est pas le cas, déployez le proxy d'API remote-service dans l'environnement périphérique approprié, puis réessayez.
  3. Vérifiez la connectivité réseau entre Apigee Adapter for Envoy et le point de terminaison du proxy d'API remote-service. Si des problèmes de connectivité réseau sont détectés, contactez votre équipe réseau pour tenter 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. Vérifiez que vous avez activé les journaux de débogage dans Envoy. Si ce n'est pas le cas, arrêtez Envoy, puis redémarrez-le, ce qui active 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. Vérifiez les journaux Apigee Adapter for Envoy et vérifiez qu'il existe une entrée de journal avec le message :
    connecting to APIGEE_ENVOY_ADAPTER_HOST:5000

    qui est ensuite suivie par:

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

    Exemple de sortie 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 for Envoy pour la raison suivante : connection failure.

  3. Le connection failure peut avoir plusieurs causes. Examinons chacun de ces scénarios.

Scénario 1: le processus de l'adaptateur n'est pas en cours d'exécution

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 de la commande suivante doit le répertorier. 
    ps -ef | grep apigee-remote-service-envoy
  2. Si ce n'est pas le cas, alors c'est la cause du problème.

Résolution

  1. Si le processus Apigee Adapter for Envoy n'est pas en cours d'exécution, démarrez-le.
  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, cette erreur peut se produire.

Si le processus Apigee Adapter for Envoy est en cours d'exécution, vérifiez qu'il existe un socket qui écoute sur le port 5000: APIGEE_ENVOY_ADAPTER_HOST:5000. Vous pouvez exécuter la commande 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 raison du problème.

Résolution

  1. Arrêtez Apigee Adapter for 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 for 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 peut établir une connexion TCP à 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 un problème de connectivité réseau entre Envoy et Apigee Adapter for Envoy.

Résolution

Si vous constatez des problèmes de connectivité réseau entre Envoy et Apigee Adapter for Envoy, veuillez contacter votre équipe de mise en réseau pour tenter de résoudre le problème.

Si le problème persiste, consultez Recueil d'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 informations de diagnostic suivantes, 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 de 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 traçage dans le proxy d'API remote-service à l'aide de l'interface utilisateur Apigee Edge. Reproduisez le problème et partagez le fichier XML de la session de trace.

    Référence: Utiliser l'outil de traçage | Apigee Edge

  5. Journaux Apigee Adapter for Envoy (complet les journaux associé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. Requête API envoyée au service cible à l'aide d'une commande curl (résultat complet de la commande curl) : 
    curl -v TARGET_SERVICE_ENDPOINT