504 Expiration du délai de la passerelle

Vous consultez la documentation d'Apigee Edge.
Accédez à la documentation sur Apigee X. info

Symptôme

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

L'erreur de code d'état HTTP 504 Gateway Timeout indique que le client n'a pas reçu de réponse rapide du Edge Gateway 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 type d'une requête API via la plate-forme Edge est Client -> Routeur -> Message Processor -> Serveur backend, comme illustré dans la figure ci-dessous:

L'application cliente, les routeurs et les processeurs de messages de la plate-forme Edge sont configurés avec des valeurs de délai avant expiration appropriées. La plate-forme Edge s'attend à ce qu'une réponse soit envoyée dans un certain délai pour chaque requête API en fonction des valeurs de délai avant 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 d'informations sur les cas de dépassement du délai dans Edge:

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

Causes possibles

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

Cause Détails Étapes fournies pour
Serveur backend lent Le serveur backend qui traite la requête de l'API est trop lent en raison d'une charge élevée ou de performances médiocres. Utilisateurs de cloud public et privé
Traitement lent des requêtes API par Edge Edge prend beaucoup de temps à traiter la requête API en raison d'une charge élevée ou de performances médiocres.

Serveur backend lent

Si le serveur backend est très lent ou prend beaucoup de temps pour traiter la requête API, une erreur 504 Gateway Timeout est renvoyé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 délai avant expiration du processeur de messages est dépassé 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 ou 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 délai avant expiration du processeur de messages expire avant que le serveur backend ne réponde

Diagnostic

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

Procédure n° 1 avec Trace

Si le problème est toujours actif (des erreurs 504 se produisent toujours), procédez comme suit:

  1. Suivez l'API concernée dans l'interface utilisateur Edge. Attendez que l'erreur se produise ou, si vous disposez de l'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 qui affiche le code de réponse 504.
  3. Vérifiez le temps écoulé à chaque phase et notez la phase qui prend le plus de temps.
  4. Si vous observez l'erreur avec le temps écoulé 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 :
    • Demande 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 au bout de 55 secondes, ce qui a entraîné une erreur 504 Gateway Timeout:

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

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

  1. Vérifiez 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 à l'heure spécifique, cela signifie que le processeur de messages a expiré.

    Exemple de journal du processeur de messages indiquant une erreur de délai avant expiration 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é une erreur 504 Gateway Timeout.

    Consultez cet article: Comment le délai avant expiration est-il contrôlé sur le processeur de messages ?

    • Comment le délai avant expiration est-il contrôlé sur le processeur de messages ? Les processeurs de messages sont généralement définis avec une valeur par défaut de délai avant expiration de 55 secondes via la propriété HTTPTransport.io.timeout.millis. Cette valeur de délai avant expiration s'applique à 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 une erreur 504 Gateway Timeout au client.
    • La valeur de délai avant expiration spécifiée dans le processeur de messages peut être remplacement par la propriété io.timeout.millis spécifiée dans le proxy d'API. Cette valeur de délai avant expiration s'applique à 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 est 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 une erreur 504 Gateway Timeout au client.

Solution

  1. Vérifiez pourquoi le serveur backend prend plus de 55 secondes et déterminez s'il peut être corrigé/optimisé pour répondre plus rapidement.
  2. Si vous ne parvenez pas à corriger/optimiser le serveur backend ou si vous savez qu'il 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 à une valeur appropriée.

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

Vous pouvez recevoir des erreurs 504 Gateway Timeout si le routeur expire avant que le processeur de messages/serveur backend ne réponde. Cela peut se produire dans l'une des situations suivantes:

  • La valeur de délai d'inactivité définie sur le routeur est plus courte que celle définie sur le processeur de messages. Par exemple, supposons que le délai avant expiration du routeur soit de 50 secondes, tandis que celui du processeur de messages est de 55 secondes.
    Délai d'inactivité sur le routeur Expiration du processeur de messages
    50 secondes 55 secondes
  • La valeur de délai avant expiration du processeur de messages est remplacée par une valeur de délai avant expiration 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é sur le routeur Expiration du processeur de messages Délai avant expiration dans le proxy d'API
    57 secondes 55 secondes 120 secondes

    Toutefois, 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>

    Le processeur de messages n'expirera alors pas au bout de 55 secondes, même si sa valeur de délai avant expiration (55 secondes) est inférieure à celle du routeur (57 secondes). En effet, la valeur de 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. Par conséquent, 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 avant expiration inférieure (57 secondes) par rapport à 120 secondes définies dans le proxy d'API, le routeur expire si le serveur backend ne répond pas au bout de 57 secondes.

Diagnostic

  1. Vérifiez 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, et le 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'expiration 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 écoulé total 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 le routeur expiré, il ferme la connexion avec le processeur de messages. Lorsque le processeur de messages a terminé son traitement, il tente d'écrire la réponse sur le routeur. Étant donné que la connexion au routeur est déjà fermée, vous obtenez Broken Pipe exception sur le processeur de messages.

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

Solution

  1. S'il s'agit d'un serveur backend personnalisé :
    1. Vérifiez pourquoi le serveur backend met autant de temps à répondre et voyez s'il peut être corrigé/optimisé pour répondre plus rapidement.
    2. S'il n'est pas possible de réparer/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 met beaucoup de temps à 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 présentent une utilisation élevée du processeur ou de la mémoire :
      1. Si un processeur de messages enregistre une utilisation élevée du processeur, générez trois dumps de threads toutes les 30 secondes à l'aide de la commande suivante : 
        JAVA_HOME/bin/jstack -l PID > FILENAME
      2. Si un processeur de messages consomme 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 l'utilisation du processeur et de 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 les vidages de threads, le vidage de tas et les journaux du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log)) pour identifier la cause de l'utilisation élevée du processeur/de la mémoire.

Vérifiez ceci: Comment le délai avant expiration est-il contrôlé pour les serveurs backend NodeJS sur le 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. Par conséquent, même si un serveur backend NodeJS prend beaucoup de temps, le processeur de messages ne sera pas mis en veille.
  • Toutefois, si le serveur backend NodeJS prend du temps et si le temps de la requête API est supérieur à 57 secondes, le routeur expire et envoie une erreur 504 Gateway Timeout au client.

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

Des erreurs 504 Gateway Timeout peuvent se produire si l'application cliente expire avant que le serveur backend ne réponde. Cela 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 sur le client Délai d'inactivité sur le routeur Expiration 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 d'API via Edge est inférieur ou égal à 50 secondes. Cela inclut le temps nécessaire pour envoyer 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 backend qui traite la demande et l'envoi de la réponse, le traitement par Edge de la réponse et enfin, son renvoi 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 recevra le code de réponse 504.

    NGINX définira alors un code d'état 499, indiquant que le client a fermé la connexion.

Diagnostic

  1. Si l'application cliente expire avant de recevoir une réponse du routeur, elle ferme la connexion avec le routeur. Dans ce cas, un code d'état 499 s'affiche dans les journaux d'accès NGINX pour la requête API spécifique.

    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 le temps total écoulé est de 50,001 secondes. Cela indique que le client a expiré au bout de 50,001 secondes.
  3. Dans ce cas, vous verrez les exceptions Broken Pipe 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 le délai d'inactivité du routeur écoulé, il ferme la connexion avec le processeur de messages. Lorsque le processeur de messages termine son traitement, il tente d'écrire la réponse sur le routeur. Étant donné que la connexion au routeur est déjà fermée, vous obtenez Broken Pipe exception sur le processeur de messages.
  5. Cette exception est attendue dans les circonstances expliquées 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, et vous devez résoudre ce problème.

Solution

  1. S'il s'agit de votre serveur backend personnalisé :
    1. Vérifiez le serveur backend pour déterminer pourquoi il met plus de 57 secondes et voir s'il peut être corrigé/optimisé pour répondre plus rapidement.
    2. Si vous ne parvenez pas à corriger/optimiser le serveur backend ou si vous savez qu'il 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 avant expiration sur le client > Délai d'inactivité sur le routeur > Délai d'inactivité sur le processeur de messages > Délai avant expiration 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 délai de réponse est long. Vérifiez pourquoi ces serveurs backend prennent plus de temps.
    2. Vérifiez si les processeurs de messages présentent une utilisation élevée du processeur ou de la mémoire :
      1. Si un processeur de messages enregistre une utilisation élevée du processeur, générez trois dumps de threads 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 les vidages de threads, le vidage de tas et les journaux du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log)) pour l'aider à identifier la cause de l'utilisation élevée 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 exigences. Ne définissez pas de valeurs de délai avant expiration arbitrairement élevées. Si vous avez besoin d'aide, contactez l'assistance Apigee Edge.

Routeur

chown apigee:apigee /opt/apigee/customer/application/router.properties
  1. Créez le fichier /opt/apigee/customer/application/router.properties sur la machine du routeur, s'il n'existe pas déjà.
  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 possédez plusieurs routeurs, répétez les étapes ci-dessus sur chacun d'eux.

Processeur de messages

  1. Créez le fichier /opt/apigee/customer/application/message-processor.properties sur la machine de traitement des messages, s'il n'existe pas déjà.
  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 de délai avant expiration sur 120 secondes, procédez 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 avez plusieurs processeurs de messages, répétez la procédure ci-dessus pour chacun d'eux.

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

Lenteur du traitement des requêtes API par Edge

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

Diagnostic

  1. Tracez l'API concernée dans l'interface utilisateur Edge.
  2. Attendez que l'erreur se produise ou, si vous disposez de l'appel d'API, effectuez quelques appels d'API et reproduisez l'erreur 504 Gateway Timeout.
  3. Notez que dans ce cas, vous pouvez voir une réponse de réussite 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 court). Cependant, le processeur de messages continue de traiter la requête et peut aboutir.
    2. De plus, la valeur HTTPTransport.io.timeout.millis définie sur le processeur de messages ne se déclenche que si le processeur de messages communique avec un serveur backend HTTP/HTTPS. En d'autres termes, ce délai avant expiration ne se déclenchera pas lorsqu'une règle (autre que la règle ServiceCallout) du proxy d'API prend beaucoup de temps.
  4. Une fois l'erreur survenue, examinez la requête spécifique qui a la durée la plus longue.
  5. Vérifiez le temps écoulé à chaque phase et notez la phase qui prend le plus de temps.
  6. Si vous observez le temps écoulé le plus long dans l'une des règles autres que la règle Service Callout (Appel de service), cela indique que Edge prend beaucoup de temps à traiter la requête.
  7. Voici un exemple de trace de l'interface utilisateur montrant un temps écoulé très élevé pour une stratégie JavaScript:

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

Solution

  1. Vérifiez si la règle a mis beaucoup de temps à répondre et s'il existe du code personnalisé dont le traitement pourrait prendre beaucoup de temps. Si tel est le cas, essayez de corriger/optimiser le code identifié.
  2. Si aucun code personnalisé ne peut entraîner un temps de traitement élevé, vérifiez si les processeurs de messages présentent une utilisation élevée du processeur ou de la mémoire :
    1. Si un processeur de messages est soumis à une utilisation élevée du processeur, générez trois dump de threads 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 un dump de tas à 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 l'utilisation du processeur et de la mémoire. 
      /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 les vidages de threads, le vidage de tas et les journaux du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log)) pour l'aider à identifier la cause de l'utilisation élevée du processeur/de la mémoire.

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

API Monitoring vous permet d'isoler rapidement les zones à problèmes pour diagnostiquer les problèmes d'erreur, de performances et de latence et leur source, tels que les applications de développeur, les proxys d'API, les cibles backend ou 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 particulier.