Cette page a été traduite par l'API Cloud Translation.

504 Expiration du délai de la passerelle – Expiration du délai du routeur

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

Problème constaté

L'application cliente reçoit un code d'état HTTP 504 avec le message Gateway Timeout en réponse aux appels d'API.

Cette réponse d'erreur indique que le client n'a pas reçu de réponse en temps voulu d'Apigee Edge ou du serveur backend lors de l'exécution d'un appel d'API.

Message d'erreur

L'application cliente reçoit le code de réponse suivant:

HTTP/1.1 504 Gateway Time-out

Lorsque vous appelez ce proxy à l'aide de cURL ou d'un navigateur Web, l'erreur suivante peut se produire:

<!DOCTYPE html>
<html>
<head>
<title>Error</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>An error occurred.</h1>
<p>Sorry, the page you are looking for is currently unavailable.<br/>
Please try again later.</p>
</body>
</html>

Quelles sont les causes des délais d'inactivité ?

Le chemin typique d'une requête API via la plate-forme périphérique est Client > Routeur > Processeur de messages > Serveur backend, comme illustré dans la figure suivante:

Tous les composants du flux d'exécution d'Apigee Edge, y compris les clients, les routeurs, les processeurs de messages et les serveurs backend, sont configurés avec des valeurs de délai avant expiration par défaut appropriées afin que l'exécution des requêtes API ne prenne pas trop de temps. Si l'un des composants du flux ne reçoit pas la réponse du composant en amont dans le délai spécifié dans la configuration du délai avant expiration, le composant spécifique expire et renvoie généralement une erreur 504 Gateway Timeout.

Ce playbook explique comment résoudre une erreur 504 causée lorsque le routeur expire.

Délai d'inactivité du routeur

Le délai avant expiration par défaut configuré sur les routeurs dans Apigee Edge est de 57 secondes. Il s'agit de la durée maximale d'exécution d'un proxy d'API entre le moment où la demande API est reçue sur Edge et le renvoi de la réponse, y compris la réponse du backend et toutes les stratégies qui sont exécutées. Le délai avant expiration par défaut peut être ignoré sur les routeurs/hôtes virtuels, comme expliqué dans la section Configurer le délai avant expiration des E/S sur les routeurs.

Causes possibles

Dans Edge, les causes typiques de l'erreur 504 Gateway Timeout causée par l'expiration du délai du routeur sont les suivantes:

Cause	Description	Instructions de dépannage applicables
Configuration du délai avant expiration incorrecte sur le routeur	Cela se produit si le routeur est configuré avec un délai d'expiration des E/S incorrect.	Utilisateurs Edge Public and Private Cloud

Étapes de diagnostic courantes

Utilisez l'un des outils ou techniques suivants pour diagnostiquer cette erreur:

Surveillance des API
Journaux d'accès NGINX

Surveillance des API

Pour diagnostiquer l'erreur à l'aide de la surveillance des API:

Accédez à la page Analyze > API Monitoring > Investigate (Analyser > Surveillance des API > Enquêter).
Filtrez les erreurs 5xx et sélectionnez la période.
Représentez le code d'état par rapport à l'heure.
Cliquez sur la cellule spécifique affichant des erreurs 504 pour afficher plus de détails et afficher les journaux concernant ces erreurs, comme indiqué ci-dessous:

Exemple d'erreur 504
Dans le volet de droite, cliquez sur Afficher les journaux.

Dans la fenêtre Journaux de trafic, notez les détails suivants pour certaines erreurs 504:
- Requête:fournit la méthode de requête et l'URI utilisés pour effectuer les appels.
- Réponse Time (Temps de réponse) : indique le temps total écoulé pour la requête.
Dans cet exemple,
- La requête pointe vers GET /test-timeout.
- Le temps de réponse est de 57.001 secondes. Cela indique que le routeur a expiré avant que le processeur de messages puisse répondre, car la valeur est très proche du délai avant expiration des E/S par défaut défini sur le routeur, qui est de 57 secondes.
Vous pouvez également obtenir tous les journaux à l'aide de l'API GET logs de Monitoring. Par exemple, en interrogeant les journaux sur org, env, timeRange et status, vous pouvez télécharger tous les journaux des transactions pour lesquelles le client a expiré.

Étant donné que l'API Monitoring définit le proxy sur - (non défini) pour ces erreurs 504, vous pouvez utiliser l'API (API Logs) pour obtenir le proxy associé à l'hôte virtuel et au chemin d'accès.

For example :
```
curl "https://apimonitoring.enterprise.apigee.com/logs/apiproxies?org=ORG&env=ENV&select=https
```
Remarque:Les champs suivants afficheront la valeur pour cette erreur 504 :
- Source d'erreur
- Code d'erreur
- Flux de pannes
- Règlement en cas de défaut
- Proxy de défaut
Ces champs sont renseignés par le processeur de messages et ne seront définis avec les valeurs appropriées que si le routeur reçoit une réponse du processeur de messages. Dans ce cas, le routeur a expiré avant le processeur de messages, car il n'a pas répondu dans les délais. Cela oblige le routeur à définir le code d'état sur 504 et, par conséquent, tous les champs mentionnés ci-dessus s'affichent sous la forme -.
Examinez le temps de réponse pour identifier d'autres erreurs 504 et vérifiez si le temps de réponse est cohérent (la valeur du délai d'expiration des E/S est définie sur le routeur, à savoir 57 secondes) pour toutes les erreurs 504.

Journaux d'accès NGINX

Pour diagnostiquer l'erreur à l'aide des journaux d'accès NGINX, procédez comme suit:

Vérifiez les journaux d'accès NGINX:
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
Recherchez s'il existe des erreurs 504 pendant une durée spécifique (si le problème s'est déjà produit par le passé) ou si des requêtes échouent toujours avec 504.
Notez les informations suivantes pour certaines erreurs 504 :
- Temps de réponse
- URI de la requête
Dans cet exemple, nous voyons les informations suivantes:
- Temps de requête:57.001 secondes. Cela indique que le routeur a expiré au bout de 57.001 secondes.
  
  Remarque:Il s'agit du champ request_time dans les journaux NGINX. Il correspond au temps de traitement de la requête en secondes, à savoir le temps écoulé entre les premiers octets lus par le client et l'écriture du journal après l'envoi des derniers octets au client.
- Requête:GET /test-timeout
- Alias d'hôte: myorg-test.apigee.net
Remarque:Les champs suivants affichent la valeur - pour cette erreur 504:
- Source d'erreur
- Code d'erreur
- Flux de pannes
- Règlement en cas de défaut
- Proxy de défaut
Ces champs sont renseignés par le processeur de messages et ne seront définis avec les valeurs appropriées que si le routeur reçoit une réponse du processeur de messages. Dans ce cas, le routeur a expiré avant le processeur de messages, car il n'a pas répondu dans les délais. Cela oblige le routeur à définir le code d'état sur 504 et, par conséquent, tous les champs mentionnés ci-dessus affichent -.
Vérifiez que le temps de la requête est identique au délai avant expiration des E/S configuré sur le routeur/l'hôte virtuel. Si oui, cela signifie que le routeur a expiré avant que le processeur de messages n'ait répondu dans ce délai.

Dans l'exemple d'entrée du journal d'accès NGINX présenté ci-dessus, le temps de requête de 57.001 secondes est très proche du délai avant expiration des E/S par défaut défini sur le routeur. Cela indique clairement que le routeur a expiré avant que le processeur de messages puisse répondre.
Déterminez le proxy d'API pour lequel la requête a été effectuée en utilisant le chemin de base indiqué dans le champ Requête .

Cause: configuration du délai avant expiration incorrecte sur le routeur

Diagnostic

Déterminez si les erreurs 504 sont dues au fait que le routeur a expiré avant que le processeur de messages puisse répondre. Pour ce faire, vérifiez que le temps de réponse dans la surveillance de l'API/Temps de requête du routeur (les deux champs représentent les mêmes informations, mais sont appelés par des noms différents) est identique au délai d'expiration des E/S configuré sur le routeur ou l'hôte virtuel, et si les champs Source d'erreur, Proxy d'erreur et Code d'erreur sont définis sur - via le diagnostic des API ou NGINX, comme expliqué dans les étapes de diagnostic des API ou NGINX.
Vérifiez si le délai d'expiration des E/S configuré sur le routeur ou sur un hôte virtuel spécifique est inférieur à celui configuré sur le processeur de messages ou le proxy d'API spécifique.

Pour ce faire, suivez la procédure décrite dans cette section.

Vérifier le délai avant expiration des E/S sur des hôtes virtuels

Interface utilisateur périphérique

Pour vérifier le délai avant expiration de l'hôte virtuel à l'aide de l'interface utilisateur Edge, procédez comme suit:

Connectez-vous à l'interface utilisateur Edge.
Accédez à Admin > Virtual Hosts (Admin > Hôtes virtuels).
Sélectionnez l'environnement spécifique dans lequel vous rencontrez le problème de délai d'inactivité.
Sélectionnez l'hôte virtuel spécifique pour lequel vous souhaitez vérifier la valeur du délai avant expiration des E/S.
Sous Propriétés, affichez la valeur Délai de lecture du proxy en secondes.

Dans l'exemple ci-dessus, le délai d'expiration du délai de lecture du proxy est configuré avec la valeur 120. Cela signifie que le délai avant expiration des E/S configuré sur cet hôte virtuel est de 120 secondes.

Remarque:Si le délai d'expiration du délai de lecture du proxy n'est pas défini, cela signifie que la valeur par défaut de 57 secondes est configurée sur le routeur (sauf si le délai avant expiration des E/S est ignoré sur les instances du routeur).

API de gestion

Vous pouvez également vérifier le délai d'expiration de la lecture du proxy à l'aide des API de gestion suivantes:

Exécutez l'API Get virtual host (Obtenir l'hôte virtuel) pour obtenir la configuration virtualhost, comme indiqué ci-dessous:

Utilisateur du cloud public
```
curl -v -X GET https://api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/virtualhosts/VIRTUALHOST_NAME -u USERNAME
```
Utilisateur Private Cloud
```
curl -v -X GET http://MANAGEMENT_SERVER_HOST:PORT#/v1/organizations/ORGANIZATION_NAME/environments/v/virtualhosts/VIRTUALHOST_NAME -u USERNAME
```
Où :

ORGANIZATION_NAME est le nom de l'organisation.

ENVIRONMENT_NAME est le nom de l'environnement.

VIRTUALHOST_NAME est le nom de l'hôte virtuel.

Vérifier la valeur configurée pour la propriété proxy_read_timeout

Exemple de définition d'hôte virtuel

{
  "hostAliases": [
    "api.myCompany,com",
  ],
  "interfaces": [],
  "listenOptions": [],
  "name": "secure",
  "port": "443",
  "retryOptions": [],
  "properties": {
    "property": [
      {
        "name": "proxy_read_timeout",
        "value": "120"
      }
    ]
  },
  "sSLInfo": {
    "ciphers": [],
    "clientAuthEnabled": "false",
    "enabled": "true",
    "ignoreValidationErrors": false,
    "keyAlias": "myCompanyKeyAlias",
    "keyStore": "ref://myCompanyKeystoreref",
    "protocols": []
  },
  "useBuiltInFreeTrialCert": false
}

Dans l'exemple ci-dessus, proxy_read_timeout est configuré avec la valeur 120. Cela signifie que le délai avant expiration des E/S configuré sur cet hôte virtuel est de 120 secondes.

Remarque:Si la propriété proxy_read_timeout n'existe pas dans la sortie de l'API de gestion, cela signifie qu'elle prendra la valeur par défaut de 57 secondes (sauf si le délai d'expiration des E/S est ignoré sur les instances du routeur).

Vérifier le délai avant expiration des E/S dans le fichier router.properties

Se connecter à un routeur.
Recherchez la propriété proxy_read_timeout dans le répertoire /opt/nginx/conf.d et vérifiez si elle a été définie avec la nouvelle valeur, comme suit :
```
grep -ri "proxy_read_timeout" /opt/nginx/conf.d
```
Vérifiez la valeur définie pour la propriété proxy_read_timeout dans le fichier de configuration de l'hôte virtuel spécifique.

Exemple de résultat de la commande grep
```
/opt/nginx/conf.d/0-default.conf:proxy_read_timeout 57;
/opt/nginx/conf.d/0-edge-health.conf:proxy_read_timeout 1s;
```
Dans l'exemple de sortie ci-dessus, notez que la propriété proxy_read_timeout a été définie avec la nouvelle valeur 57 dans 0-default.conf, qui est le fichier de configuration de l'hôte virtuel par défaut. Cela indique que le délai avant expiration des E/S est configuré sur 57 secondes sur le routeur pour l'hôte virtuel par défaut. Si vous avez plusieurs hôtes virtuels, ces informations s'affichent pour chacun d'eux. Obtenez la valeur de proxy_read_timeout pour l'hôte virtuel spécifique que vous avez utilisé pour effectuer les appels d'API qui ont échoué avec des erreurs 504.

Vérifier le délai avant expiration des E/S dans le proxy d'API

Vous pouvez consulter le délai avant expiration des E/S de la façon suivante:

Point de terminaison cible du proxy d'API
Règle ServiceAppel du proxy d'API

Afficher le délai d'expiration des E/S dans le point de terminaison cible du proxy d'API

Dans l'interface utilisateur Edge, sélectionnez le proxy d'API spécifique dans lequel vous souhaitez afficher la valeur du délai avant expiration des E/S.
Sélectionnez le point de terminaison cible spécifique que vous souhaitez vérifier.
Consultez la propriété io.timeout.millis avec une valeur appropriée sous l'élément <HTTPTargetConnection> dans la configuration TargetEndpoint.
Par exemple, dans le code suivant, le délai avant expiration des E/S est défini sur 120 secondes:
```
<Properties>
  <Property name="io.timeout.millis">120000</Property>
</Properties>
```

Afficher le délai avant expiration des E/S dans la règle ServiceCallout du proxy d'API

Dans l'interface utilisateur Edge, sélectionnez le proxy d'API spécifique dans lequel vous souhaitez afficher la nouvelle valeur de délai d'expiration E/S pour la stratégie ServiceCallout.
Sélectionnez la règle ServiceCall spécifique que vous souhaitez vérifier.
Consultez l'élément <Timeout> avec une valeur appropriée dans la configuration <ServiceCallout>.

Par exemple, le délai avant expiration des E/S du code suivant sera de 120 secondes:
```
<Timeout>120000</Timeout>
```

Vérifier le délai avant expiration des E/S sur les processeurs de messages

Connectez-vous à la machine du processeur de messages.

Recherchez la propriété HTTPTransport.io.timeout.millis dans le répertoire /opt/apigee/edge-message-processor/conf à l'aide de la commande suivante:

grep -ri "HTTPTransport.io.timeout.millis" /opt/apigee/edge-message-processor/conf

Exemple de résultat

/opt/apigee/edge-message-processor/conf/http.properties:HTTPTransport.io.timeout.millis=55000

Dans l'exemple de sortie ci-dessus, notez que la propriété HTTPTransport.io.timeout.millis a été définie avec la valeur 55000 dans http.properties. Cela indique que le délai avant expiration des E/S est correctement configuré sur 55 secondes sur le processeur de messages.

Une fois que vous avez déterminé le délai avant expiration configuré sur le routeur et le processeur de messages, vérifiez si le routeur/l'hôte virtuel a été configuré avec une valeur de délai d'inactivité inférieure à celle du processeur de messages/proxy d'API.

Notez les valeurs définies sur tous les calques, comme indiqué dans le tableau ci-dessous:

Délai d'inactivité du routeur (en secondes)	Délai d'inactivité de l'hôte virtuel (secondes)	Délai d'inactivité du processeur de messages (en secondes)	Délai d'inactivité du proxy de l'API (en secondes)
57	-	55	120

Dans cet exemple,

La valeur par défaut de 57 secondes est configurée sur le routeur.
La valeur du délai avant expiration n'est pas définie sur l'hôte virtuel spécifique. Cela signifie qu'il utilisera la valeur par défaut de 57 secondes configurée sur le routeur lui-même.
Sur le processeur de messages, une valeur par défaut de 55 secondes est configurée.
Cependant, sur le proxy d'API spécifique, une valeur de 120 secondes est configurée.

Notez que la valeur de délai avant expiration la plus élevée n'est configurée que sur le proxy d'API, mais le routeur est toujours configuré avec 57 secondes. Par conséquent, le routeur expire au bout de 57 secondes pendant que le processeur de messages/le backend traite encore votre requête. Ainsi, le routeur répond avec l'erreur 504 Gateway Timeout à l'application cliente.

Résolution

Pour résoudre ce problème, procédez comme suit pour configurer le délai d'expiration d'E/S approprié sur le routeur et le processeur de messages.

Consultez les bonnes pratiques de configuration du délai avant expiration des E/S pour comprendre les valeurs de délai avant expiration à définir sur les différents composants impliqués dans le flux de requêtes API via Apigee Edge.
Dans l'exemple ci-dessus, si vous vous êtes assuré qu'une valeur de délai d'inactivité plus élevée doit être définie, car le serveur backend nécessite un temps plus long, et que vous avez augmenté la valeur du délai avant expiration du processeur de messages à 120 secondes, définissez une valeur plus élevée (par exemple, 123 seconds sur le routeur). Pour éviter d'affecter tous les proxys d'API en raison de la nouvelle valeur de délai d'expiration, définissez la valeur de 123 seconds uniquement sur l'hôte virtuel spécifique utilisé dans le proxy d'API spécifique.
Suivez les instructions de la section Configurer le délai avant expiration des E/S sur les routeurs pour définir le délai avant expiration sur l'hôte virtuel.