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.

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

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

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 à temps d'Apigee Edge ou du serveur de 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 un tel proxy à l'aide de cURL ou d'un navigateur Web, vous pouvez obtenir l'erreur suivante :

<!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 Edge est Client > Routeur > Processeur de messages > Serveur de backend, comme illustré dans la figure suivante :

Tous les composants du flux d'exécution 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 d'attente par défaut appropriées afin de garantir que les requêtes API ne prennent pas trop de temps à se terminer. Si l'un des composants du flux ne reçoit pas de 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 guide explique comment résoudre une erreur 504 qui se produit lorsque le routeur expire.

Délai avant expiration sur le 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 pendant laquelle un proxy d'API peut s'exécuter à partir du moment où la requête API est reçue sur Edge jusqu'à ce que la réponse soit renvoyée, y compris la réponse du backend et toutes les règles exécutées. Le délai avant expiration par défaut peut être remplacé sur les routeurs/hôtes virtuels, comme expliqué dans 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 due au délai d'expiration du routeur sont les suivantes :

Cause	Description	Instructions de dépannage applicables
Configuration incorrecte du délai avant expiration sur le routeur	Cela se produit si le routeur est configuré avec une période de délai d'E/S incorrecte.	Utilisateurs du cloud public et privé Edge

Étapes de diagnostic courantes

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

Surveillance des API
Journaux d'accès NGINX

Surveillance des API

Pour diagnostiquer l'erreur à l'aide d'API Monitoring :

Accédez à la page Analyser > API Monitoring > Examiner.
Filtrez les erreurs 5xx et sélectionnez la période.
Représentez graphiquement Code d'état par rapport à Heure.
Cliquez sur la cellule spécifique affichant des erreurs 504 pour en savoir plus et afficher les journaux d'erreurs, comme indiqué ci-dessous :

Exemple d'erreurs 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.
- Temps de réponse : indique le temps total écoulé pour la requête.
Dans cet exemple,
- La demande 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 d'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 d'API Monitoring. Par exemple, en interrogeant les journaux pour org, env, timeRange et status, vous pourrez télécharger tous les journaux des transactions pour lesquelles le client a expiré.

Étant donné qu'API Monitoring définit le proxy sur - (not set) 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 de l'erreur
- Code d'erreur
- Flux d'erreur
- Règle d'erreur
- Proxy de défaut
Ces champs sont renseignés par le processeur de messages et ne sont définis avec des 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 à temps. Cela force le routeur à définir le code d'état sur 504. Par conséquent, tous les champs mentionnés ci-dessus s'affichent sous la forme -.
Examinez le temps de réponse pour détecter d'autres erreurs 504 et vérifiez si le temps de réponse est cohérent (valeur du délai d'inactivité des E/S définie sur le routeur, soit 57 secondes) pour toutes les erreurs 504.

Journaux d'accès NGINX

Pour diagnostiquer l'erreur à l'aide des journaux d'accès NGINX :

Vérifiez les journaux d'accès NGINX :
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
Recherchez les éventuelles erreurs 504 survenues pendant une période spécifique (si le problème s'est produit dans le passé) ou les requêtes qui échouent encore avec 504.
Notez les informations suivantes pour certaines erreurs 504 :
- Temps de réponse
- URI de la demande
Dans cet exemple, les informations suivantes s'affichent :
- Temps de réponse : 57.001 secondes. Cela indique que le routeur a expiré après 57,001 secondes.
  
  Remarque : Cela représente le champ request_time dans les journaux NGINX. Il s'agit du temps de traitement de la requête en secondes, c'est-à-dire le temps écoulé entre la lecture des premiers octets du 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 afficheront la valeur - pour cette erreur 504 :
- Source de l'erreur
- Code d'erreur
- Flux d'erreur
- Règle d'erreur
- Proxy de défaut
Ces champs sont renseignés par le processeur de messages et ne sont définis avec des 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 à temps. Cela force le routeur à définir le code d'état sur 504. Par conséquent, tous les champs mentionnés ci-dessus s'affichent sous la forme -.
Vérifiez si le délai de la requête est identique au délai d'inactivité des E/S configuré sur le routeur/l'hôte virtuel. Si c'est le cas, cela signifie que le routeur a expiré avant que le processeur de messages ne réponde dans ce délai.

Dans l'exemple d'entrée du journal d'accès NGINX ci-dessus, le temps de requête de 57.001 secondes est très proche du délai avant expiration d'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 dans le champ Requête .

Cause : configuration incorrecte du délai avant expiration 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 si le temps de réponse dans API Monitoring/temps de requête dans le routeur (les deux champs représentent les mêmes informations, mais sont appelés différemment) est identique au délai d'E/S configuré sur le routeur/l'hôte virtuel, et si les champs Source de l'erreur, Proxy de l'erreur et Code d'erreur sont définis sur - à l'aide d'API Monitoring ou des journaux d'accès NGINX, comme expliqué dans Étapes de diagnostic courantes.
Vérifiez si la valeur du délai d'inactivité des E/S configurée sur le routeur ou l'hôte virtuel spécifique est inférieure à celle configurée sur le processeur de messages ou le proxy d'API spécifique.

Pour ce faire, suivez les étapes décrites dans cette section.

Vérifier le délai d'attente des E/S sur les hôtes virtuels

Interface utilisateur Edge

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 > Hôtes virtuels.
Sélectionnez un environnement spécifique dans lequel vous rencontrez le problème de délai d'expiration.
Sélectionnez l'hôte virtuel spécifique pour lequel vous souhaitez vérifier la valeur du délai d'attente des E/S.
Sous Propriétés, consultez la valeur Délai avant expiration de lecture du proxy en secondes.

Dans l'exemple ci-dessus, le 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 la valeur Délai avant expiration de lecture du proxy est vide, la valeur par défaut de 57 secondes configurée sur le routeur sera utilisée (sauf si le délai avant expiration d'E/S est remplacé sur les instances de routeur).

API de gestion

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

Exécutez l'API Get virtual host 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 du 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érifiez 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 Management, cela signifie qu'elle prendra la valeur par défaut de 57 secondes (sauf si le délai d'inactivité d'E/S est remplacé sur les instances de routeur).

Vérifier le délai d'attente des E/S dans le fichier router.properties

Connectez-vous à une machine 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 résultat 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'afficheront 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 ayant échoué avec des erreurs 504.

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

Vous pouvez afficher le délai d'attente des E/S dans les éléments suivants :

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

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

Dans l'UI Edge, sélectionnez le proxy d'API spécifique dans lequel vous souhaitez afficher la valeur du délai d'inactivité d'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, le délai avant expiration des E/S dans le code suivant est défini sur 120 secondes :
```
<Properties>
  <Property name="io.timeout.millis">120000</Property>
</Properties>
```

Afficher le délai d'attente d'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'attente d'E/S pour la règle ServiceCallout.
Sélectionnez la règle ServiceCallout spécifique que vous souhaitez vérifier.
Consultez l'élément <Timeout> avec une valeur appropriée sous 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 d'attente 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 résultat 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 d'E/S a bien été configuré sur 55 secondes sur le processeur de messages.

Une fois que vous avez déterminé le délai d'inactivité 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 toutes les couches, comme indiqué dans le tableau ci-dessous :

Délai avant expiration sur le routeur (en secondes)	Délai avant expiration sur l'hôte virtuel (en secondes)	Délai avant expiration du processeur de messages (en secondes)	Délai avant expiration du proxy d'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.
Toutefois, une valeur de 120 secondes est configurée sur le proxy d'API spécifique.

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

Solution

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

Consultez Bonnes pratiques pour configurer le délai d'attente d'E/S pour comprendre les valeurs de délai d'attente à 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 constatez qu'une valeur de délai avant expiration plus élevée doit être définie, car le serveur backend nécessite plus de temps, et que vous avez augmenté la valeur de délai avant expiration du processeur de messages à 120 secondes, définissez une valeur de délai avant expiration plus élevée (par exemple, 123 seconds) sur le routeur. Pour éviter d'impacter tous les proxys d'API en raison de la nouvelle valeur de délai avant 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 d'attente des E/S sur les routeurs pour définir le délai d'attente sur l'hôte virtuel.