504 Expiration du délai de la passerelle

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 tant que réponse aux appels d'API.

Le code d'état HTTP : l'erreur 504 Gateway Timeout indique que le client n'a pas reçu de réponse en temps voulu de la passerelle Edge ou du serveur backend lors de l'exécution d'une API.

Messages d'erreur

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

HTTP/1.1 504 Gateway Timeout

Dans certains cas, le message d'erreur suivant peut également s'afficher:

{
   "fault": {
      "faultstring": "Gateway Timeout",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.GatewayTimeout"
       }
    }
}

Quelles sont les causes des délais d'inactivité de la passerelle ?

Le chemin d'accès 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 ci-dessous:

L'application cliente, les routeurs et les processeurs de messages de la plate-forme périphérique sont configurés avec des valeurs de délai d'expiration appropriées. La plate-forme Edge s'attend à ce qu'une réponse soit envoyée dans un certain laps de temps pour chaque requête API en fonction des valeurs de délai d'expiration. Si vous n'obtenez pas de réponse dans le délai spécifié, 504 Gateway Timeout Error est renvoyé.

Le tableau suivant fournit plus de détails sur les cas où les délais d'inactivité peuvent se produire dans Edge:

Occurrence de délai d'inactivité Détails
Le délai d'inactivité se produit sur le processeur de messages
  • Le serveur backend ne répond pas au processeur de messages dans un délai d'expiration spécifié sur celui-ci.
  • Le processeur de messages expire et envoie l'état de la réponse 504 Gateway Timeout au routeur.
Le délai a expiré sur le routeur
  • Le processeur de messages ne répond pas au routeur dans le délai d'expiration spécifié sur le routeur.
  • Le routeur expire et envoie l'état de réponse 504 Gateway Timeout à l'application cliente.
Le délai avant expiration se produit sur l'application cliente
  • Le routeur ne répond pas à l'application cliente dans le délai d'expiration spécifié sur le routeur.
  • L'application cliente expire et met fin à l'état de la réponse 504 Gateway Timeout pour l'utilisateur final.

Causes possibles

Dans Edge, les causes typiques de l'erreur 504 Gateway Timeout sont les suivantes:

Cause Détails Pas donnés pour
Serveur backend lent Le serveur backend qui traite la requête API est trop lent en raison d'une charge élevée ou de performances médiocres. Utilisateurs des clouds publics et privés
Le traitement lent des requêtes API par Edge Edge prend beaucoup de temps pour traiter la requête API en raison d'une charge élevée ou de mauvaises performances.

Serveur backend lent

Si le serveur backend est très lent ou met beaucoup de temps à traiter la requête API, une erreur 504 Gateway Timeout est générée. Comme expliqué dans la section ci-dessus, le délai avant expiration peut se produire dans l'un des scénarios suivants:

  1. Le processeur de messages expire avant que le serveur backend ne réponde.
  2. Le routeur expire avant que le processeur de messages/le serveur backend ne réponde.
  3. L'application cliente expire avant que le routeur/le processeur de messages/le serveur backend ne réponde.

Les sections suivantes décrivent comment diagnostiquer et résoudre le problème dans chacun de ces scénarios.

Scénario 1 : le traitement des messages expire avant que le serveur backend ne réponde

Diagnostic

Vous pouvez suivre les procédures suivantes pour déterminer si l'erreur 504 Gateway Timeout s'est produite en raison de la lenteur du serveur backend.

Procédure 1 avec Trace

Si le problème est toujours actif (504 erreurs se produisent toujours), suivez les étapes ci-dessous:

  1. Tracez l'API concernée dans l'interface utilisateur Edge. Attendez que l'erreur se produise ou, si vous disposez d'un appel d'API, effectuez des appels d'API et reproduisez l'erreur 504 Gateway Timeout.
  2. Une fois l'erreur survenue, examinez la requête spécifique dont le code de réponse est 504.
  3. Vérifiez le temps écoulé à chaque phase et notez la phase au cours de laquelle le plus de temps est passé.
  4. Si vous observez l'erreur avec le temps le plus long immédiatement après l'une des phases suivantes, cela signifie que le serveur backend est lent ou que le traitement de la requête prend beaucoup de temps :
    • Requête envoyée au serveur cible
    • Règle ServiceCallout

Vous trouverez ci-dessous un exemple de trace montrant que le serveur backend n'a pas répondu, même après 55 secondes, ce qui a entraîné une erreur 504 Gateway Timeout:

Dans la trace ci-dessus, le processeur de messages expire après 55 002 ms, car le serveur backend ne répond pas.

Procédure 2 : utilisation des journaux du processeur de messages

  1. Vérifier le journal du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log)

  2. Si vous trouvez des erreurs Gateway Timeout et onTimeoutRead pour la requête de proxy d'API spécifique à un moment précis, cela signifie que le processeur de messages a expiré.

    Exemple de journal du processeur de messages affichant l'erreur de délai d'inactivité de la passerelle

    2015-09-29 20:16:54,340 org:myorg env:staging api:profiles rev:13 NIOThread@1
ERROR ADAPTORS.HTTP.FLOW - AbstractResponseListener.onException() :
AbstractResponseListener.onError(HTTPResponse@4d898cf1, Gateway
Timeout)
2015-09-29 20:16:57,361 org:myorg env:staging api:profileNewsletters rev:8
NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onTimeout() :
SSLClientChannel[C:XX.XX.XX.XX:443 Remote
host:192.168.38.54:38302]@120171 useCount=2 bytesRead=0
bytesWritten=824 age=55458ms lastIO=55000ms .onTimeoutRead

    Dans le journal du processeur de messages ci-dessus, vous remarquez que le serveur backend désigné par l'adresse IP XX.XX.XX.XX n'a pas répondu même après 55 secondes (lastIO=55000ms). Par conséquent, le processeur de messages a expiré et a envoyé l'erreur 504 Gateway Timeout.

    Vérifiez comment le délai d'inactivité est contrôlé sur le processeur de messages.

    • Comment le délai d'inactivité est-il contrôlé sur le processeur de messages ? Les processeurs de messages sont généralement définis avec une valeur de délai avant expiration par défaut de 55 secondes) via la propriété HTTPTransport.io.timeout.millis. Cette valeur de délai avant expiration est applicable à tous les proxys d'API appartenant à une organisation desservie par ce processeur de messages.
      • Si le serveur backend ne répond pas dans un délai de 55 secondes, le processeur de messages expire et envoie l'erreur 504 Gateway Timeout au client.
    • La valeur du délai avant expiration spécifiée dans le processeur de messages peut être remplacée par la propriété io.timeout.millis spécifiée dans le proxy d'API. Cette valeur de délai d'expiration est applicable à un proxy d'API spécifique dans lequel la propriété mentionnée ci-dessus est spécifiée. Par exemple, si io.timeout.millis est défini sur 10 secondes dans le proxy d'API, la valeur du délai avant expiration de 10 secondes sera utilisée pour ce proxy d'API spécifique.
      • Si le serveur backend ne répond pas dans les 10 secondes pour le proxy d'API spécifique, le processeur de messages expire et envoie l'erreur 504 Gateway Timeout au client.

Résolution

  1. Vérifiez pourquoi le serveur backend prend plus de 55 secondes et voyez s'il peut être corrigé/optimisé pour répondre plus rapidement.
  2. S'il n'est pas possible de corriger/d'optimiser le serveur backend ou si vous savez que le serveur backend prend plus de temps que le délai avant expiration configuré, augmentez la valeur du délai avant expiration sur le routeur et le processeur de messages sur une valeur appropriée.

Scénario 2 : Le routeur expire avant que le processeur de messages/le serveur backend ne réponde

Vous pouvez obtenir des erreurs 504 Gateway Timeout si le routeur expire avant que le processeur de messages/le serveur backend ne réponde. Cette situation peut se produire dans les cas suivants:

  • La valeur du délai avant expiration définie sur le routeur est inférieure à celle définie sur le processeur de messages. Par exemple, supposons que le délai avant expiration sur le routeur soit de 50 secondes, tandis que le processeur de messages est de 55 secondes.
    Délai d'inactivité du routeur Délai d'inactivité du processeur de messages
    50 secondes 55 secondes
  • La valeur du délai avant expiration sur le processeur de messages est remplacée par une valeur de délai plus élevée à l'aide de la propriété io.timeout.millis définie dans la configuration du point de terminaison cible du proxy d'API:

    Par exemple, si les valeurs de délai avant expiration suivantes sont définies:

    Délai d'inactivité du routeur Délai d'inactivité du processeur de messages Délai d'inactivité dans le proxy d'API
    57 secondes 55 secondes 120 secondes

    Cependant, io.timeout.millis est défini sur 120 secondes dans le proxy d'API:

    <HTTPTargetConnection>
     <Properties>
          <Property name="io.timeout.millis">120000</Property>
      </Properties>
      <URL>http://www.apigee.com</URL>
</HTTPTargetConnection>

    Ainsi, le processeur de messages n'expirera pas au bout de 55 secondes, même si sa valeur (55 secondes) est inférieure à la valeur du délai avant expiration du routeur (57 secondes). En effet, la valeur du délai avant expiration de 55 secondes sur le processeur de messages est remplacée par la valeur de 120 secondes définie dans le proxy d'API. Ainsi, la valeur du délai avant expiration du processeur de messages pour ce proxy d'API spécifique sera de 120 secondes.

    Étant donné que le routeur a une valeur de délai d'inactivité inférieure (57 secondes) à 120 secondes définie dans le proxy d'API, le routeur expire si le serveur backend ne répond pas au bout de 57 secondes.

Diagnostic

  1. Vérifier le journal d'accès NGINX (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)

  2. Si le routeur expire avant le processeur de messages, l'état 504 s'affiche dans les journaux d'accès NGINX pour la requête API spécifique. L'état message id du processeur de messages est défini sur -. En effet, le routeur n'a reçu aucune réponse du processeur de messages dans le délai d'inactivité défini sur le routeur.

    Exemple d'entrée de journal NGINX affichant 504 en raison de l'expiration du routeur

  3. Dans l'exemple ci-dessus, notez l'état de 504 sur NGINX, l'ID de message du processeur de messages est - et le temps total écoulé est de 57,001 secondes. En effet, le routeur a expiré au bout de 57 001 secondes et nous n'avons reçu aucune réponse du processeur de messages.
  4. Dans ce cas, des exceptions Broken Pipe s'affichent dans les journaux du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log). 
    2017-06-09 00:00:25,886 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-mp01-18869-23151-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel(ClientChannel[A:XX.XX.XX.XX:8998 Remote host:YY.YY.YY.YY:51400]@23751 useCount=1 bytesRead=0 bytesWritten=486 age=330465ms  lastIO=0ms )
2017-06-09 00:00:25,887  org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-mp01-18869-23151-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace:
java.io.IOException: Broken pipe
        at com.apigee.nio.channels.ClientOutputChannel.writePending(ClientOutputChannel.java:51) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.onWrite(OutputChannel.java:116) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.write(OutputChannel.java:81) ~[nio-1.0.0.jar:na]
         … <snipped>

Cette erreur s'affiche, car une fois que le routeur expire, il ferme la connexion au processeur de messages. Une fois le traitement des messages terminé, le processeur de messages tente d'écrire la réponse sur le routeur. Comme la connexion au routeur est déjà fermée, vous obtenez le Broken Pipe exception sur le processeur de messages.

Cette exception devrait se produire dans les circonstances décrites ci-dessus. Par conséquent, la cause réelle de l'erreur 504 Gateway Timeout est toujours que le serveur backend met encore plus de temps à répondre, ce qui vous oblige à résoudre ce problème.

Résolution

  1. S'il s'agit d'un serveur backend personnalisé :
    1. Vérifiez pourquoi le serveur backend met beaucoup de temps à répondre et voyez s'il peut être corrigé/optimisé pour répondre plus rapidement.
    2. Si vous ne pouvez pas corriger/optimiser le serveur backend ou s'il est connu que le serveur backend prend beaucoup de temps, augmentez la valeur du délai avant expiration sur le routeur et le processeur de messages.

      Idée: définissez la valeur du délai avant expiration sur les différents composants dans l'ordre suivant:

      Délai d'inactivité sur le client > Délai d'inactivité sur le routeur > Délai d'inactivité sur le processeur de messages > Délai d'inactivité dans le proxy d'API
  2. S'il s'agit d'un serveur backend NodeJS :
    1. Vérifiez si le code NodeJS appelle d'autres serveurs backend et s'il prend beaucoup de temps pour renvoyer une réponse. Vérifiez pourquoi les serveurs backend prennent plus de temps et corrigez le problème si nécessaire.
    2. Vérifiez si les processeurs de messages utilisent beaucoup le processeur ou la mémoire :
      1. Si l'un des processeurs de messages utilise considérablement le processeur, générez trois vidages de thread toutes les 30 secondes à l'aide de la commande suivante : 
        JAVA_HOME/bin/jstack -l PID > FILENAME
      2. Si l'un des processeurs de messages utilise beaucoup de mémoire, générez une empreinte de la mémoire à l'aide de la commande suivante : 
        sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
      3. Redémarrez le processeur de messages à l'aide de la commande ci-dessous. Le processeur et la mémoire devraient être réduits : 
        /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
      4. Surveillez les appels d'API pour vérifier si le problème persiste.
      5. Contactez l'assistance Apigee Edge et fournissez-lui les journaux d'empreinte de thread, d'empreinte de la mémoire et de processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log) pour vous aider à identifier la cause de l'utilisation intensive du processeur/de la mémoire).

Vérifiez comment le délai d'inactivité est contrôlé pour les serveurs backend NodeJS sur un processeur de messages.

  • Le serveur backend NodeJS s'exécute dans le processus JVM du processeur de messages. La valeur du délai avant expiration pour les serveurs backend NodeJS est contrôlée via la propriété http.request.timeout.seconds dans le fichier nodejs.properties. Cette propriété est définie sur 0 par défaut, c'est-à-dire que le délai avant expiration est désactivé par défaut pour tous les proxys d'API appartenant à une organisation desservie par ce processeur de messages. Ainsi, même si un serveur backend NodeJS prend beaucoup de temps, le processeur de messages n'expirera pas.
  • Toutefois, si le serveur backend NodeJS prend beaucoup de temps et que la requête API prend plus de 57 secondes, le routeur expirera et enverra l'erreur 504 Gateway Timeout au client.

Scénario 3 : Une application cliente expire avant que le routeur, le processeur de messages ou le serveur backend ne réponde

Vous pouvez obtenir des erreurs 504 Gateway Timeout si l'application cliente expire avant que le serveur backend ne réponde. Cette situation peut se produire dans les cas suivants:

  1. La valeur du délai avant expiration définie sur l'application cliente est inférieure à celle définie sur le routeur et le processeur de messages:

    Par exemple, si les valeurs de délai avant expiration suivantes sont définies:

    Expiration du délai d'attente du client Délai d'inactivité du routeur Délai d'inactivité du processeur de messages
    50 secondes 57 secondes 55 secondes

    Dans ce cas, le temps total disponible pour obtenir une réponse à une requête API via Edge est inférieur ou égal à 50 secondes. Cela inclut le temps nécessaire pour effectuer une requête API, la requête en cours de traitement par Edge (routeur, processeur de messages), la requête envoyée au serveur backend (le cas échéant), le traitement backend de la demande et l'envoi de la réponse, Edge traite la réponse et la renvoie finalement au client.

    Si le routeur ne répond pas au client dans les 50 secondes, le client expire et ferme la connexion avec le routeur. Le client obtient le code de réponse 504.

    NGINX est alors chargé de définir le code d'état 499, qui indique que le client a fermé la connexion.

Diagnostic

  1. Si l'application cliente expire avant d'obtenir une réponse du routeur, elle met fin à la connexion avec le routeur. Dans ce cas, le code d'état 499 s'affiche dans les journaux d'accès NGINX pour la requête API concernée.

    Exemple d'entrée de journal NGINX affichant le code d'état 499

  2. Dans l'exemple ci-dessus, notez que l'état de 499 sur NGINX et que le temps total écoulé est de 50,001 secondes. Cela indique que le client a expiré après 50 001 secondes.
  3. Dans ce cas, vous verrez Broken Pipe Exceptions dans les journaux du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log).
    2017-06-09 00:00:25,886 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-1-11193-11467656-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel(ClientChannel[A:XX.XX.XX.XX:8998 Remote host:YY.YY.YY.YY:51400]@23751 useCount=1 bytesRead=0 bytesWritten=486 age=330465ms  lastIO=0ms )
2017-06-09 00:00:25,887  org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-1-11193-11467656-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace:
java.io.IOException: Broken pipe
        at com.apigee.nio.channels.ClientOutputChannel.writePending(ClientOutputChannel.java:51) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.onWrite(OutputChannel.java:116) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.write(OutputChannel.java:81) ~[nio-1.0.0.jar:na]
         … <snipped>
    ).
  4. Une fois que le routeur a expiré, il met fin à la connexion au processeur de messages. Une fois le traitement terminé, le processeur de messages tente d'écrire la réponse sur le routeur. Comme la connexion au routeur est déjà fermée, vous obtenez le Broken Pipe exception sur le processeur de messages.
  5. Cette exception est attendue dans les circonstances décrites ci-dessus. La cause réelle de l'erreur 504 Gateway Timeout est donc toujours que le serveur backend met beaucoup de temps à répondre, ce qui vous oblige à résoudre ce problème.

Résolution

  1. S'il s'agit de votre serveur backend personnalisé :
    1. Vérifiez le serveur backend pour déterminer pourquoi le délai est supérieur à 57 secondes et voir s'il peut être corrigé/optimisé pour répondre plus rapidement.
    2. Si vous ne pouvez pas corriger/optimiser le serveur backend ou si vous savez que cela prendra beaucoup de temps, augmentez la valeur du délai avant expiration sur le routeur et le processeur de messages.

      Idée: définissez la valeur du délai avant expiration sur les différents composants dans l'ordre suivant:

      Délai d'inactivité sur le client > Délai d'inactivité sur le routeur > Délai d'inactivité sur le processeur de messages > Délai d'inactivité dans le proxy d'API
  2. S'il s'agit d'un backend NodeJS :
    1. Vérifiez si le code NodeJS appelle d'autres serveurs backend et si le retour prend beaucoup de temps. Découvrez pourquoi ces serveurs backend prennent plus de temps.
    2. Vérifiez si les processeurs de messages utilisent beaucoup le processeur ou la mémoire :
      1. Si un processeur de messages utilise beaucoup le processeur, générez trois vidages de thread toutes les 30 secondes à l'aide de la commande suivante : 
        JAVA_HOME/bin/jstack -l PID > FILENAME
      2. Si un processeur de messages utilise beaucoup de mémoire, générez une empreinte de la mémoire à l'aide de la commande suivante : 
        sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
      3. Redémarrez le processeur de messages à l'aide de la commande ci-dessous. Cela devrait réduire le processeur et la mémoire : 
        /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
      4. Surveillez les appels d'API pour vérifier si le problème persiste.
      5. Contactez l'assistance Apigee Edge et fournissez-lui les journaux d'empreinte de thread, d'empreinte de la mémoire et de processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log)pour les aider à rechercher la cause de l'utilisation intensive du processeur/de la mémoire).

Augmenter la valeur du délai avant expiration sur le routeur et le processeur de messages

Choisissez soigneusement les valeurs de délai avant expiration à définir sur le routeur et le processeur de messages en fonction de vos besoins. Ne définissez pas de valeurs de délai d'expiration trop élevées. Si vous avez besoin d'aide, contactez l'assistance Apigee Edge.

Routeur

chown apigee:apigee /opt/apigee/customer/application/router.properties
  1. S'il n'existe pas déjà, créez le fichier /opt/apigee/customer/application/router.properties sur la machine routeur.
  2. Ajoutez la ligne suivante à ce fichier : 
    conf_load_balancing_load.balancing.driver.proxy.read.timeout=TIME_IN_SECONDS

    Par exemple, si vous souhaitez définir la valeur du délai avant expiration sur 120 secondes, définissez-la comme suit:

    conf_load_balancing_load.balancing.driver.proxy.read.timeout=120
  3. Assurez-vous que ce fichier appartient à apigee:
  4. Redémarrez le routeur : 
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart
  5. Si vous avez plusieurs routeurs, répétez les étapes ci-dessus sur chacun d'eux.

Processeur de messages

  1. Si ce n'est pas déjà fait, créez un fichier /opt/apigee/customer/application/message-processor.properties sur la machine de traitement des messages.
  2. Ajoutez la ligne suivante à ce fichier : 
    conf_http_HTTPTransport.io.timeout.millis=TIME_IN_MILLISECONDS

    Par exemple, si vous souhaitez définir la valeur du délai avant expiration sur 120 secondes, définissez-la comme suit:

    conf_http_HTTPTransport.io.timeout.millis=120000
  3. Assurez-vous que ce fichier appartient à Apigee : 
    chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
  4. Redémarrez le processeur de messages : 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  5. Si vous disposez de plusieurs processeurs de messages, répétez les étapes ci-dessus sur chacun d'eux.

Idée: définissez la valeur du délai d'expiration sur les différents composants dans l'ordre suivant:

Délai d'inactivité sur le client > Délai d'inactivité sur le routeur > Délai d'inactivité sur le processeur de messages > Délai d'inactivité dans le proxy d'API

Lenteur du traitement des requêtes API par Edge

Si Edge est très lent et/ou prend beaucoup de temps pour traiter la requête API, vous obtiendrez une erreur 504 Gateway Timeout.

Diagnostic

  1. Tracez l'API concernée dans l'interface utilisateur Edge.
  2. Attendez que l'erreur se produise ou, si vous disposez d'un appel d'API, effectuez des appels d'API et reproduisez l'erreur 504 Gateway Timeout.
  3. Notez que dans ce cas, une réponse indiquant que l'opération a réussi peut s'afficher dans la trace.
    1. Le routeur/client expire, car le processeur de messages ne répond pas dans le délai d'expiration spécifié sur le routeur/client (selon le délai d'expiration le plus faible). Cependant, le processeur de messages continue de traiter la requête et peut se terminer correctement.
    2. De plus, la valeur HTTPTransport.io.timeout.millis définie sur le processeur de messages ne se déclenche que si celui-ci communique avec un serveur backend HTTP/HTTPS. En d'autres termes, ce délai d'expiration n'est pas déclenché lorsqu'une règle (autre que la règle ServiceCallout) dans le proxy d'API prend beaucoup de temps.
  4. Lorsque l'erreur s'est produite, examinez la requête spécifique dont le temps écoulé est le plus long.
  5. Vérifiez le temps écoulé à chaque phase et notez la phase au cours de laquelle vous avez passé le plus de temps.
  6. Si vous observez le temps écoulé le plus long dans l'une des stratégies autres que la stratégie d'appel de service, cela signifie que le traitement de la requête par Edge prend beaucoup de temps.
  7. Voici un exemple de trace d'interface utilisateur montrant un temps écoulé très élevé pour la règle JavaScript:

  8. Dans l'exemple ci-dessus, vous remarquez que la règle JavaScript prend un temps anormalement long (environ 245 secondes).

Résolution

  1. Vérifiez si la règle a pris beaucoup de temps à répondre et si le traitement d'un code personnalisé pourrait prendre beaucoup de temps. S'il existe un tel code, essayez de le corriger ou de l'optimiser.
  2. Si aucun code personnalisé ne peut entraîner un temps de traitement élevé, vérifiez si les processeurs de messages utilisent beaucoup le processeur ou la mémoire :
    1. Si l'un des processeurs de messages utilise considérablement le processeur, générez trois vidages de thread toutes les 30 secondes à l'aide de la commande suivante : 
      JAVA_HOME/bin/jstack -l PID > FILENAME
    2. Si l'un des processeurs de messages utilise beaucoup de mémoire, générez une empreinte de la mémoire à l'aide de la commande suivante : 
      sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
    3. Redémarrez le processeur de messages à l'aide de la commande ci-dessous. Le processeur et la mémoire devraient alors être réduits. 
      /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
    4. Surveillez les appels d'API et vérifiez si le problème persiste.
    5. Contactez l'assistance Apigee Edge et fournissez-lui les journaux d'empreinte de thread, d'empreinte de la mémoire et de processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log)pour l'aider à identifier la cause de l'utilisation intensive du processeur/de la mémoire).

Diagnostiquer les problèmes à l'aide de la surveillance des API

La surveillance des API vous permet d'isoler rapidement les problèmes afin de diagnostiquer les problèmes d'erreur, de performances et de latence, ainsi que leur source. C'est le cas, par exemple, des applications pour développeurs, des proxys d'API, des cibles backend ou de la plate-forme d'API.

Suivez un exemple de scénario qui montre comment résoudre les problèmes 5xx avec vos API à l'aide de la surveillance des API. Par exemple, vous pouvez configurer une alerte pour être averti lorsque le nombre de codes d'état 504 dépasse un seuil spécifique.