Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

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

Vous consultez la documentation Apigee Edge.
Accédez à la documentation Apigee X.

Problème constaté

Le proxy Envoy échoue avec une erreur HTTP 403 Forbidden lorsqu'il est appelé via l'adaptateur 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 se produit :

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 du cloud public et privé Edge
Chemin d'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 sous Ressources d'API.	Utilisateurs du cloud public et privé Edge
Nom d'hôte manquant dans le produit d'API	Le nom d'hôte indiqué dans la requête d'API client est manquant dans le produit d'API sous les cibles de service distant Apigee.	Utilisateurs du cloud public et privé Edge
Clé API manquante dans l'en-tête de requête	La clé API n'est pas transmise dans l'en-tête HTTP `x-api-key`.	Utilisateurs du cloud public et privé Edge
Clé API non valide	La clé API transmise dans la requête n'est pas valide.	Utilisateurs du cloud public et privé Edge
Apigee Adapter for Envoy ne parvient pas à communiquer avec le proxy d'API de service à distance	Apigee Adapter for Envoy ne parvient pas à communiquer avec le proxy d'API du service distant.	Utilisateurs du cloud public et privé Edge
Le proxy Envoy ne parvient pas à communiquer avec Apigee Adapter for Envoy	Le proxy Envoy ne parvient pas à communiquer avec Apigee Adapter for Envoy	Utilisateurs du cloud public et privé Edge

Avant de commencer

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

Activez les journaux de débogage :

Assurez-vous d'avoir activé les journaux de débogage dans Apigee Adapter for Envoy pour obtenir plus d'informations sur l'erreur. Si ce n'est pas le cas, arrêtez Apigee Adapter for Envoy et 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 d'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 invoqués.

Diagnostic

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

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

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 d'API ENVOY-PRODUCT-1 n'a pas été trouvé dans Apigee Adapter for Envoy.

Pour en savoir plus sur la journalisation de l'adaptateur Apigee pour Envoy, consultez Journalisation.

Si ce message s'affiche lorsque vous autorisez la requête API, cela signifie très probablement que le produit API spécifique n'est pas activé pour un environnement spécifique dans lequel vous effectuez les appels d'API.
Pour vérifier cela, 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 effectuez les requêtes API est activé dans le produit API.
4. Si l'environnement spécifique n'est pas activé dans le produit d'API, il s'agit de la cause de ce problème.
Si l'environnement spécifique est déjà activé, passez à 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 API, procédez comme suit pour résoudre le problème :

Connectez-vous à l'interface utilisateur Edge.
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.
Sur la page Produits d'API > Nom du produit, cliquez sur Modifier.
Cochez la case de l'environnement dans lequel vous souhaitez envoyer des requêtes d'API.
Cliquez sur Enregistrer.

Cause : Chemin d'accès à 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 :

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

Consultez les journaux de l'adaptateur Apigee pour 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 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

Cela indique que le chemin d'accès /echo1 n'a pas été trouvé dans le produit d'API ENVOY-PRODUCT-1.

Si le message no path: REQUEST_URI_PATH s'affiche dans les journaux de débogage de l'adaptateur Apigee pour Envoy, cela signifie que c'est la cause de ce problème. Sinon, accédez à Cause : nom d'hôte manquant dans le produit d'API.

Solution

Si l'URI de la demande 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 :

Connectez-vous à l'interface utilisateur Edge.
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.
Sur la page Produits d'API > Nom du produit, cliquez sur Modifier.
Dans le volet Ressources d'API, ajoutez l'URI de la demande d'API au produit d'API.
Surveillez les journaux Apigee Adapter for Envoy et attendez qu'Apigee Adapter for Envoy récupère le produit d'API mis à jour. Ensuite, envoyez une autre requête API pour vérifier la correction.

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

Cette erreur se produit si la combinaison du nom d'hôte et du port cibles 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 :

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

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 et port httpbin1:8080 n'a pas été trouvée dans le produit d'API ENVOY-PRODUCT-1.

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, cela signifie que le problème est dû à cette entrée. Si ce n'est pas le cas, consultez Cause : clé API manquante dans l'en-tête de la requête.

Solution

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

Connectez-vous à l'interface utilisateur Edge.
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.
Sur la page Produits d'API > Nom du produit, cliquez sur Modifier.

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

Si la section Cibles de services distants Apigee ne s'affiche pas dans l'interface utilisateur, ajoutez un attribut personnalisé au produit d'API avec le nom apigee-remote-service-targets et 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": []
}

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 API mis à jour. Ensuite, envoyez une autre requête 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 :

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

Consultez les journaux de l'adaptateur Apigee pour Envoy et vérifiez que le message [missing authentication] s'affiche dans la section 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 contient le message [missing authentication]. Ce message indique que la clé API n'est pas transmise dans l'en-tête de la requête.

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

Solution

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

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. Dans le cas contraire, demandez au client d'envoyer la clé API dans l'en-tête HTTP x-api-key.
Consultez le fichier de configuration de l'adaptateur Apigee pour 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 de l'en-tête de clé API par défaut a été modifié en api-key. Dans ce cas, vous devez transmettre la clé API dans l'en-tête api-key.
Si le nom d'en-tête de clé API par défaut a été modifié, demandez au client d'utiliser le nouveau nom d'en-tête de clé API, puis d'envoyer une autre requête API pour vérifier 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 requête.

Diagnostic

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

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

Consultez les journaux de l'adaptateur Apigee pour Envoy et vérifiez que le message [permission denied] s'affiche dans la section Authenticate error. Ce message s'affiche généralement après que l'adaptateur a récupéré la clé API, comme 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.

Si les journaux de l'adaptateur Apigee pour Envoy contiennent une entrée de journal avec [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. Sinon, consultez Cause : Apigee Adapter for Envoy ne parvient pas à communiquer avec le proxy d'API remote-service.

Solution

Si le message [permission denied] s'affiche dans la section Authenticate error des journaux de l'adaptateur Apigee pour Envoy, procédez comme suit pour résoudre le problème :

Vérifiez que la clé API envoyée dans la requête API correspond à la valeur de la clé API figurant dans l'application connectée au produit d'API.
Si la clé API utilisée par le client n'est pas valide, demandez-lui de vous en envoyer une valide.
Si la clé API utilisée par le client est valide et que vous continuez à voir une erreur HTTP 403, veuillez contacter l'assistance Apigee Edge pour obtenir de l'aide.

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

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

Diagnostic

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

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

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 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 proxy d'API remote-service, car le nom d'hôte fourni dans l'URL du proxy d'API du serveur distant n'est pas valide, comme indiqué par l'erreur no such host .

Si les journaux Apigee Adapter for Envoy contiennent une entrée de journal avec le message no such host, cela signifie que le problème est dû à cette entrée. Sinon, accédez à Cause : le proxy Envoy ne parvient pas à communiquer avec l'adaptateur Apigee pour Envoy.

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 :

Vérifiez le fichier de configuration d'Apigee Adapter for Envoy et assurez-vous que l'URL du proxy d'API de service distant indiquée est valide.

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

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
      
```
Vérifiez que le proxy d'API remote-service est déployé dans l'environnement Edge concerné. Si ce n'est pas le cas, déployez le proxy d'API remote-service dans l'environnement Edge concerné, puis réessayez.
Vérifiez la connectivité réseau entre l'adaptateur Apigee pour 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 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 :

Assurez-vous d'avoir activé les journaux de débogage dans Envoy. Si ce n'est pas le cas, arrêtez Envoy et redémarrez-le en activant 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
```

Consultez les journaux Apigee Adapter for 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 for Envoy en raison de connection failure.

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

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

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

Vérifiez que le processus de l'adaptateur Apigee pour 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 devrait le lister.
```
ps -ef | grep apigee-remote-service-envoy
```
Si ce n'est pas le cas, il s'agit de la cause du problème.

Solution

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

Cette erreur peut se produire si le processus Apigee Adapter for Envoy n'écoute pas sur le port spécifique.

Si le processus Apigee Adapter for Envoy est en cours d'exécution, vérifiez qu'un socket est à l'é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

Le fait qu'aucun socket n'écoute sur le port 5000 peut être la cause de ce problème.

Solution

Arrêtez Apigee Adapter for Envoy, puis redémarrez-le.
Effectuez 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

Vérifiez la connectivité réseau entre Envoy et Apigee Adapter for Envoy :
```
ssh $ENVOY_HOST
telnet $APIGEE_ENVOY_ADAPTER_HOST 5000
```
Si telnet a pu établir une connexion TCP à l'adaptateur Apigee pour Envoy, un résultat semblable au suivant s'affiche :
```
telnet $APIGEE_ENVOY_ADAPTER_HOST 5000

Trying ::1...
Connected to localhost.
Escape character is '^]'.
```
Si l'erreur Connection timed out s'affiche avec telnet, cela indique qu'il existe un problème de connectivité réseau entre Envoy et l'adaptateur Apigee pour Envoy.

Solution

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

Si le problème persiste, consultez la page Vous devez collecter 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 informations de diagnostic suivantes, puis contactez l'assistance Apigee Edge :

Produit Apigee utilisé :

Exemple : Apigee Edge Cloud, Apigee OPDK, Apigee hybrid, Apigee X
Organisation et environnement Apigee

Définition du produit d'API lue à 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

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

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

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

Requête API envoyée au proxy Envoy à l'aide d'une commande curl (sortie complète de la commande curl) :
```
curl -v ENVOY_PROXY_ENDPOINT
```
Requête d'API envoyée au service cible à l'aide d'une commande curl (sortie complète de la commande curl) :
```
curl -v TARGET_SERVICE_ENDPOINT
```