504 Expiration du délai de la passerelle

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.

Le code d'état HTTP 504 Gateway Timeout indique que le client n'a pas reçu de réponse du serveur Edge Gateway ou de backend dans les délais impartis 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 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 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 d'inactivité 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 ne recevez 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 où des délais d'attente peuvent se produire dans Edge :

Causes possibles

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

Serveur backend lent

Si le serveur backend est très lent ou met beaucoup de temps à traiter la requête API, vous recevrez une erreur 504 Gateway Timeout. Comme expliqué dans la section ci-dessus, le délai d'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 ou le serveur backend ne répondent.
3. L'application cliente expire avant que le routeur, le processeur de messages ou le serveur backend ne répondent.

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

Scénario 1 : Le 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 de la lenteur du serveur backend.

Procédure 1 : Utiliser Trace

Si le problème persiste (des erreurs 504 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 de l'appel d'API, effectuez quelques 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 celle où vous passez le plus de temps.
4. Si vous constatez l'erreur avec le temps écoulé le plus long immédiatement après l'une des phases suivantes, cela indique que le serveur backend est lent ou qu'il met beaucoup de temps à traiter la requête :
   • 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 : Utiliser les journaux du processeur de messages

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

2. Si vous rencontrez des erreurs Gateway Timeout et onTimeoutRead pour la requête de proxy d'API spécifique à l'heure spécifique, cela indique que le processeur de message a expiré.

   Exemple de journal du processeur de messages affichant 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 remarquerez que le serveur backend indiqué 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.

   Consultez "Comment le délai avant expiration est-il 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 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 les 55 secondes, le processeur de messages expire et envoie une 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 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 le io.timeout.millis est défini sur 10 secondes dans le proxy d'API, cette valeur de délai avant expiration 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.

Solution

1. Vérifiez pourquoi le serveur de backend met plus de 55 secondes à répondre 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 s'il est connu 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 à une valeur appropriée.

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

Vous pouvez recevoir des erreurs 504 Gateway Timeout si le routeur expire avant que le processeur de messages ou le serveur backend ne répondent. Cela peut se produire dans les cas suivants :

• La valeur du délai d'inactivité 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 du routeur soit de 50 secondes, tandis que celui du processeur de messages soit de 55 secondes.

  Délai avant expiration sur le routeur	Délai d'expiration 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 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 avant expiration sur le routeur	Délai d'expiration du processeur de messages	Délai avant expiration dans le proxy d'API
  57 secondes	55 secondes	120 secondes

  Toutefois, le 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 ne dépassera alors pas le délai d'inactivité de 55 secondes, même si cette valeur est inférieure à celle 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. La valeur du délai avant expiration du processeur de messages pour ce proxy d'API spécifique sera donc de 120 secondes.

  Étant donné que le routeur a une valeur de délai avant expiration inférieure (57 secondes) à celle de 120 secondes définie dans le proxy d'API, le routeur expirera 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 d'API spécifique, et la valeur message id du processeur de messages est définie sur -. En effet, le routeur n'a reçu aucune réponse du processeur de messages dans le délai imparti défini sur le routeur.

   Exemple d'entrée de journal NGINX montrant un code 504 en raison du délai avant expiration du routeur

   

3. Dans l'exemple ci-dessus, notez l'état 504 sur NGINX.L'ID du 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 le délai du routeur expiré, il ferme la connexion avec le processeur de messages. Une fois le traitement terminé, le processeur de messages tente d'écrire la réponse sur le routeur. Étant donné que la connexion au routeur est déjà fermée, vous obtenez le code d'erreur Broken Pipe exception sur le processeur de messages.

Cette exception est censée se produire dans les circonstances expliquées ci-dessus. La cause réelle de l'erreur 504 Gateway Timeout est toujours le temps de réponse plus long du serveur backend. Vous devez résoudre ce problème.

Solution

1. S'il s'agit d'un serveur backend personnalisé, alors
   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 corriger/optimiser le serveur backend ou s'il est connu que le serveur backend prend beaucoup de temps, augmentez la valeur du délai d'inactivité 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é du client > Délai d'inactivité du routeur > Délai d'inactivité du processeur de messages > Délai d'inactivité dans le proxy d'API

2. S'il s'agit d'un serveur backend NodeJS, procédez comme suit :
   1. Vérifiez si le code NodeJS effectue des appels à d'autres serveurs de backend et si le délai de réponse est long. Vérifiez pourquoi les serveurs de backend mettent plus de temps à répondre et résolvez le problème, le cas échéant.
   2. Vérifiez si les processeurs de messages utilisent beaucoup de processeur ou de mémoire :
      1. Si un processeur de messages connaît une utilisation élevée du processeur, générez trois dumps 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 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. Il 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 thread, l'empreinte de la mémoire et les journaux du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log)) pour nous aider à identifier la cause de l'utilisation élevée du processeur/de la mémoire.

Scénario 3 : Le délai d'expiration de l'application cliente est dépassé avant que le routeur, le processeur de messages ou le serveur de backend ne répondent

Vous pouvez recevoir des erreurs 504 Gateway Timeout 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 d'inactivité définie dans l'application cliente est inférieure à celle définie dans le routeur et le processeur de messages :

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

   Délai avant expiration du client	Délai avant expiration sur le routeur	Délai d'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 API via Edge est inférieur ou égal à 50 secondes. Cela inclut le temps nécessaire pour effectuer une requête API, le temps de traitement de la requête par Edge (routeur, processeur de messages), le temps d'envoi de la requête au serveur de backend (le cas échéant), le temps de traitement de la requête par le backend et d'envoi de la réponse, le temps de traitement de la réponse par Edge et, enfin, le temps d'envoi de la réponse 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, le code d'état 499 s'affiche dans les journaux d'accès NGINX pour la requête d'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é sont de 50,001 secondes. Cela indique que le client a expiré après 50,001 secondes.
3. Dans ce cas, vous verrez des 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. Une fois le traitement terminé, le processeur de messages tente d'écrire la réponse au routeur. Étant donné que 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 expliquées ci-dessus. La cause réelle de l'erreur 504 Gateway Timeout est toujours que le serveur backend met beaucoup de temps à répondre. Vous devez résoudre ce problème.

Solution

1. S'il s'agit de votre serveur backend personnalisé :
   1. Vérifiez le serveur de backend pour déterminer pourquoi il met plus de 57 secondes à répondre et voyez s'il peut être corrigé/optimisé pour répondre plus rapidement.
   2. S'il n'est pas possible de corriger/optimiser le serveur backend ou si vous savez que le serveur backend prendra beaucoup de temps, augmentez la valeur du délai d'inactivité 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é du client > Délai d'inactivité du routeur > Délai d'inactivité du processeur de messages > Délai d'inactivité dans le proxy d'API

2. Si vous utilisez un backend NodeJS :
   1. Vérifiez si le code NodeJS appelle d'autres serveurs backend et si le retour prend beaucoup de temps. Vérifiez pourquoi ces serveurs de backend mettent plus de temps.
   2. Vérifiez si les processeurs de messages utilisent beaucoup de processeur ou de mémoire :
      1. Si un processeur de messages connaît une utilisation élevée du 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 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-lui les vidages de thread, l'empreinte de la mémoire 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 d'inactivité sur le routeur et le processeur de messages

Choisissez soigneusement les valeurs de délai d'inactivité à définir sur le routeur et le processeur de messages en fonction de vos besoins. 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 avez 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 Processeur de 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 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 avez plusieurs processeurs de messages, répétez les étapes ci-dessus sur tous les processeurs de messages.

Traitement lent des requêtes d'API par Edge

Si Edge est très lent et/ou met beaucoup de temps à 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 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 indiquant que l'opération a réussi dans la trace.
   1. Le routeur/client arrive à expiration, car le processeur de messages ne répond pas dans le délai d'expiration spécifié sur le routeur/client (celui qui a le délai d'expiration le plus court). Toutefois, le processeur de messages continue de traiter la requête et peut l'exécuter correctement.
   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 d'expiration ne sera pas déclenché lorsqu'une règle (autre que la règle ServiceCallout) dans le proxy d'API prend beaucoup de temps.
4. Une fois l'erreur survenue, examinez la requête spécifique qui présente le temps écoulé le plus long.
5. Vérifiez le temps écoulé à chaque phase et notez celle qui prend le plus de temps.
6. Si vous constatez le temps écoulé le plus long dans l'une des règles autres que la règle Service Callout, cela indique qu'Edge met beaucoup de temps à traiter la requête.
7. Voici un exemple de trace d'UI montrant un temps écoulé très élevé sur la règle JavaScript :

   

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

Solution

1. Vérifiez si la stratégie a mis longtemps à répondre et s'il existe un code personnalisé qui pourrait nécessiter un long temps de traitement. Si tel est le cas, essayez de corriger/optimiser le code identifié.
2. S'il n'existe aucun code personnalisé susceptible d'entraîner un temps de traitement élevé, vérifiez si les processeurs de messages connaissent une utilisation élevée du processeur ou de la mémoire :
   1. Si un processeur de messages connaît une utilisation élevée du processeur, générez trois dumps 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 un vidage du 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 thread, l'empreinte de la mémoire et les journaux du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log)) pour les 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 ainsi que leur source, comme les applications de développeur, les proxys d'API, les cibles de backend ou la plate-forme d'API.

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