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

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

<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

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 rapide d'Apigee Edge ou le serveur backend pendant 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, 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 classique d'une requête API via la plate-forme Edge est Client > Routeur > Envoyer un message Processeur > 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 et les serveurs backend sont configurés avec des valeurs de délai d'expiration par défaut appropriées afin de s'assurer que le traitement des requêtes API ne prend pas trop de temps. Si l'un des composants du ne reçoivent pas la réponse du composant en amont dans le délai spécifié dans le la configuration du délai avant expiration, le composant spécifique expire et renvoie généralement 504 Gateway Timeout.

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

Délai d'inactivité 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 du nombre maximal durée pendant laquelle un proxy d'API peut s'exécuter entre le moment où la demande API est reçue sur Edge et La réponse est renvoyée, y compris la réponse du backend et toutes les stratégies exécutées. Le délai avant expiration par défaut peut être ignoré sur les routeurs/hôtes virtuels, comme expliqué dans <ph type="x-smartling-placeholder"></ph> 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 le Le délai avant expiration du routeur est le suivant:

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 avant expiration des E/S incorrect.	Utilisateurs Edge de cloud public et privé

Étapes de diagnostic courantes

Utilisez l'une des techniques ou l'un des outils suivants pour diagnostiquer ce problème:

Surveillance des API
Journaux d'accès NGINX

Surveillance des API

Pour diagnostiquer l'erreur à l'aide de l'API Monitoring, procédez comme suit:

Accédez à Analyser > Surveillance des API > Examiner.
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 qui affiche 504 erreurs pour afficher plus de détails les journaux concernant ces erreurs, comme indiqué ci-dessous:

Exemple illustrant les erreurs 504
Dans le volet de droite, cliquez sur Afficher les journaux.

Dans la fenêtre Traffic Logs (Journaux de trafic), notez les détails suivants pour certaines erreurs 504:
- Request:fournit la méthode de requête et l'URI utilisés pour effectuer les appels.
- Response 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 ne puisse répondre, car la valeur est très proche au délai avant expiration d'E/S par défaut défini sur le routeur, soit 57 secondes.
Vous pouvez également obtenir tous les journaux en utilisant l'API Monitoring GET logs. Par exemple, en interrogeant les journaux sur org, env, timeRange, et status, vous pourrez télécharger tous les journaux des transactions où le client a expiré.

Étant donné que API Monitoring définit le proxy sur - (non défini) pour ces 504 erreurs, vous pouvez utiliser l'API (les journaux API) 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
```
<ph type="x-smartling-placeholder">
</ph> Remarque:Les champs suivants afficheront la valeur de cette erreur 504:
- Source de l'erreur
- Code d'erreur
- Flux de pannes
- Règle en cas d'erreur
- Proxy de pannes
Ces champs sont remplis par le processeur de messages et seront définis avec les valeurs appropriées uniquement 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 celui-ci n'a pas répondu à temps. Cela oblige le routeur à définir le code d'état sur 504 et, par conséquent, tous les les champs mentionnés ci-dessus s'affichent sous la forme -.
Examinez le temps de réponse pour voir si d'autres erreurs 504 se sont produites, puis vérifiez pour voir si le temps de réponse est cohérent (valeur du délai d'expiration d'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
Effectuez une recherche pour voir s'il existe des erreurs 504 pendant une durée spécifique (si le problème s'est produit dans le passé) ou si des requêtes échouent encore avec 504
Notez les informations suivantes pour certaines erreurs 504: <ph type="x-smartling-placeholder">
- Temps de réponse
- URI de la demande
Cet exemple présente les informations suivantes:
- Durée de la requête:57.001 secondes. Cela indique que le Le délai d'attente du routeur a expiré au bout de 57.001 secondes.
  <ph type="x-smartling-placeholder">
  </ph> Remarque:Cela représente le champ request_time dans les journaux NGINX. Il s'agit du temps de traitement de la requête, exprimé en secondes. temps écoulé entre la première octets lus à partir du client et l'écriture dans le 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 cet élément 504. erreur:
- Source de l'erreur
- Code d'erreur
- Flux de pannes
- Règle en cas d'erreur
- Proxy de pannes
Ces champs sont remplis par le processeur de messages et seront définis avec les valeurs appropriées uniquement si le routeur reçoit une réponse du processeur de messages. Dans ce cas, le routeur a chronométré devant le processeur de messages, car il n'a pas répondu dans les meilleurs délais. Cela oblige au routeur de définir le code d'état sur 504 et, par conséquent, toutes les actions mentionnées ci-dessus. s'affichent sous la forme -.
Vérifiez si la valeur du champ Request Time (Temps de la requête) est identique au délai d'expiration des E/S. configurés sur le routeur/l'hôte virtuel. Si c'est le cas, cela signifie que le routeur a expiré avant que le Le processeur de messages n'a pas répondu dans ce délai.

Dans l'exemple d'entrée de journal d'accès NGINX présenté ci-dessus, la propriété Request La durée 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 message Le processeur pourrait 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 Request (Requête).

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

Diagnostic

Déterminez si les erreurs 504 sont dues au dépassement du délai d'attente du routeur le processeur de messages pourrait répondre. Pour ce faire, vérifiez Temps de réponse dans la surveillance de l'API/Temps de la requête dans le routeur (les deux champs représentent les mêmes informations,mais sont appelées avec des noms différents) est identique au Délai d'expiration des E/S configuré sur le routeur/l'hôte virtuel et les champs Source de la défaillance, Défaut Le proxy et le code d'erreur sont définis sur - à l'aide de la surveillance de l'API ou de l'accès NGINX comme expliqué dans la section Étapes de diagnostic courantes.
Vérifiez si la valeur du délai d'expiration d'E/S configurée sur le routeur ou l'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 d'expiration des E/S sur les hôtes virtuels

Interface utilisateur périphérique

Pour vérifier le délai d'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 l'environnement dans lequel vous rencontrez le problème de délai avant expiration.
Sélectionnez l'hôte virtuel spécifique pour lequel vous souhaitez vérifier la valeur du délai d'expiration des E/S.
Sous Properties (Propriétés), affichez la valeur Proxy Read Timeout (Délai de lecture du proxy) en secondes.

Dans l'exemple ci-dessus, le délai avant expiration 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 aucune valeur n'est définie pour le Délai de lecture du proxy, cela signifie que le paramètre valeur par défaut de 57 secondes configurée sur le routeur (sauf si le délai avant expiration des E/S est 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 la <ph type="x-smartling-placeholder"></ph> Obtenez l'API d'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é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 le résultat de la commande par défaut, elle utilise l'adresse IP par défaut de 57 secondes (sauf si le délai avant expiration des E/S est ignoré sur les instances de routeur).

Vérifier le délai d'expiration des E/S sur le fichier router.properties

Connectez-vous à un routeur.
Recherchez la propriété proxy_read_timeout dans /opt/nginx/conf.d et vérifiez s'il a été défini 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 l'instance de configuration d'hôte.

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 a été définie avec la nouvelle valeur 57 dans 0-default.conf, qui correspond au de configuration Terraform pour 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 default. Si vous avez plusieurs hôtes virtuels, vous verrez ces informations pour chacun d'eux. Obtenez la valeur de proxy_read_timeout pour l'hôte virtuel spécifique que vous avez utilisé pour créer l'API appels ayant échoué avec 504 erreurs.

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

Vous pouvez afficher le délai avant expiration des E/S de la manière suivante:

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

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

Dans l'interface utilisateur Edge, sélectionnez le proxy API spécifique dans lequel vous souhaitez afficher les E/S délai avant expiration.
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 la propriété Élément <HTTPTargetConnection> dans TargetEndpoint configuration.
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 d'expiration des E/S dans la stratégie ServiceAccroche du proxy d'API

Dans l'interface utilisateur Edge, sélectionnez le proxy API spécifique dans lequel vous souhaitez afficher les nouvelles E/S valeur de délai avant expiration de la règle ServiceAccroche.
Sélectionnez la règle ServiceAccroche spécifique que vous souhaitez vérifier.
Affichez l'élément <Timeout> avec une valeur appropriée sous la section Configuration de <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'expiration des E/S sur les processeurs de messages

Connectez-vous à la machine de traitement des messages.

Recherchez la propriété HTTPTransport.io.timeout.millis dans /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éfini avec la valeur 55000 dans http.properties Cela indique que le délai avant expiration des E/S est correctement configuré pour 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 Le routeur/l'hôte virtuel a été configuré avec une valeur de délai avant expiration 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 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 (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.
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 est configurée uniquement sur le proxy d'API, mais le routeur est toujours configuré en 57 secondes. Par conséquent, le routeur expire au bout de 57 secondes tandis que le message Le sous-traitant/backend est toujours en train de traiter votre demande. Cela amène le routeur à répondre avec Erreur 504 Gateway Timeout à l'application cliente.

Solution

Procédez comme suit pour configurer le délai d'expiration d'E/S approprié sur le routeur et les messages Processeur pour résoudre ce problème.

Consultez <ph type="x-smartling-placeholder"></ph> Bonnes pratiques de configuration du délai d'expiration des E/S pour comprendre les valeurs de délai avant expiration doit être défini sur les différents composants impliqués dans le flux de requêtes API via Apigee Edge.
Dans l'exemple ci-dessus, si vous êtes certain 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é le délai avant expiration du processeur de messages sur 120 secondes, puis définissez une valeur de délai d'expiration plus élevée pour exemple: 123 seconds sur le routeur. Pour éviter d'affecter tous les proxys d'API en raison de la nouvelle valeur du délai avant expiration, définissez la valeur de 123 seconds uniquement sur le hôte virtuel spécifique utilisé dans le proxy d'API spécifique.
Suivez les instructions fournies dans l'article <ph type="x-smartling-placeholder"></ph> configurer le délai d'expiration des E/S sur les routeurs pour définir le délai avant expiration sur l'hôte virtuel.