503 Service indisponible.

Vous consultez la documentation d'Apigee Edge.
Consultez la documentation Apigee X.
en savoir plus

Vidéos

Regardez les vidéos suivantes pour en savoir plus sur les erreurs 503:

Vidéo Description
Résoudre l'erreur 503 "Service non disponible" en raison d'un problème DNS Pour en savoir plus, consultez les informations suivantes :
  • Erreur 503 "Service non disponible" causée par la résolution DNS et des problèmes liés au réseau dans Apigee Edge
  • Dépanner et résoudre une erreur 503 de service non disponible en temps réel causée par un problème de résolution DNS
Résoudre l'erreur 503 "Service non disponible" en raison d'un problème de réseau Dépanner et résoudre une erreur 503 d'indisponibilité de service en temps réel causée par un problème de réseau dans Apigee Edge

Problème constaté

L'application cliente reçoit une réponse HTTP d'état 503 avec le message Service non disponible après un appel de proxy d'API.

Messages d'erreur

Le message d'erreur suivant peut s'afficher:

HTTP/1.1 503 Service Unavailable
      

Le message d'erreur suivant apparaît également dans la réponse HTTP:

Service indisponible

{
   "fault": {
      "faultstring": "The Service is temporarily unavailable",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.ServiceUnavailable"
       }
    }
}
      

Causes possibles

La réponse HTTP 503 Service Non disponible avec le code d'erreur messaging.adaptors.http.flow.ServiceUnavailable se produit si le processeur de messages d'Apigee Edge rencontre des erreurs en raison d'un délai de connexion écoulé, d'un nom d'hôte incorrect ou d'échecs de handshake SSL lors de la communication avec le serveur backend.

Les causes possibles de la réponse 503 Service non disponible sont les suivantes:

Cause Description Qui peut effectuer les étapes de dépannage
Erreurs de connexion dues à une résolution DNS incorrecte La résolution DNS du serveur cible entraînait des adresses IP incorrectes, ce qui a entraîné des erreurs de connexion. Utilisateurs de cloud privé périphérique
Erreurs de connexion Des problèmes de réseau ou de connectivité empêchent le client de se connecter au serveur. Utilisateurs de cloud privé périphérique
Nom d'hôte du serveur cible incorrect L'hôte du serveur cible spécifié est incorrect ou comporte des caractères indésirables (un espace, par exemple). Utilisateurs Edge Public and Private Cloud
Échecs du handshake SSL Le handshake TLS/SSL a échoué entre le client et le serveur. (Le dépannage de cette catégorie de problème est abordé dans un autre sujet.) Utilisateurs Edge Public and Private Cloud

Étapes de diagnostic courantes

Déterminer l'ID du message de la requête ayant échoué

Outil de traçage

Pour déterminer l'ID de message de la requête ayant échoué à l'aide de l'outil Trace:

  1. Si le problème est toujours actif, activez la session de suivi pour l'API concernée.
  2. Effectuez l'appel d'API et reproduisez le problème : 503 Service non disponible avec le code d'erreur messaging.adaptors.http.flow.ServiceUnavailable.
  3. Sélectionnez l'une des requêtes ayant échoué.
  4. Accédez à la phase AX et déterminez l'ID du message (X-Apigee.Message-ID) de la requête en faisant défiler la page vers le bas dans la section Phase Details (Détails de la phase), comme illustré dans la figure suivante.

    ID du message dans la section "Détails de la phase"

Journaux d'accès NGINX

Pour déterminer l'ID de message de la requête ayant échoué à l'aide des journaux d'accès NGINX:

Vous pouvez également vous reporter aux journaux d'accès NGINX pour déterminer l'ID des messages des erreurs 503. Cela est particulièrement utile si le problème s'est déjà produit par le passé ou s'il est intermittent et que vous ne parvenez pas à capturer la trace dans l'interface utilisateur. Procédez comme suit pour déterminer ces informations à partir des journaux d'accès NGINX:

  1. Vérifiez les journaux d'accès NGINX: (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
  2. Recherchez s'il existe des erreurs 503 pour le proxy d'API spécifique pendant une durée spécifique (si le problème s'est produit par le passé) ou si des requêtes échouent toujours avec l'erreur 503.
  3. S'il existe des erreurs 503 avec X-Apigee-fault-code Messaging.adaptors.http.flow.ServiceAvailability, notez l'ID de message d'une ou plusieurs requêtes de ce type, comme indiqué dans l'exemple suivant:

    Exemple d'entrée affichant l'erreur 503

    Exemple d&#39;entrée affichant le code d&#39;état, l&#39;identifiant du message, la source de l&#39;erreur et le code d&#39;erreur

Erreurs de connexion dues à une résolution DNS incorrecte

Diagnostic

  1. Déterminez l'ID du message de la requête ayant échoué.
  2. Recherchez l'ID du message de requête spécifique dans le journal du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log). Les erreurs suivantes peuvent se produire:

    Une erreur onConnectTimeout indique que le processeur de messages n'a pas pu se connecter au serveur backend au cours du délai d'expiration de connexion prédéfini (par défaut: 3 secondes).
    2019-08-14 09:11:49,314 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[Connected:]@164162 useCount=1 bytesRead=0 bytesWritten=0 age=3001ms lastIO=3001ms .onConnectTimeout connectAddress=www.abc.com/11.11.11.11  resolvedAddress=www.abc.com/22.22.22.22
    
    2019-08-14 09:11:49,333 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onTimeout() : RequestWriteListener.onTimeout(HTTPRequest@6b393600)
          
  3. Notez l'adresse IP résolue dans l'erreur onConnectTimeout, puis vérifiez si elle est valide pour votre serveur backend. Si l'adresse IP est valide, accédez à Erreurs de connexion.
  4. Si l'adresse IP n'est pas valide, cela peut être dû à des problèmes de résolution DNS.
  5. Répétez les étapes 3 et 4 pour d'autres requêtes API ayant échoué, puis vérifiez si vous voyez la même adresse IP ou d'autres non valides.
  6. Recherchez les messages contenant le mot clé DNS Refresh dans le journal du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log). Vérifiez si des adresses IP incorrectes ou non valides sont ajoutées de temps en temps au cache DNS sur le processeur de messages.
    2019-08-14 09:11:49,314 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@0 INFO c.a.p.h.d.DNSCachedAddress - DNSCachedAddress.reportDifferences() : DNS Refresh for host: apitarget-uat.schemeweb.co.uk:4436. Added 2 IPs [www.abc.com/22.22.22.22, www.abc.com/33.33.33.33] Removed 1 IPs [www.abc.com/11.11.11.11]
          
  7. Ce problème peut se produire en cas de problème avec les serveurs DNS primaires ou les serveurs de noms configurés dans /etc/resolv.conf.

    Généralement, un ou plusieurs serveurs DNS primaires peuvent être configurés pour effectuer la résolution DNS. S'il n'existe aucun serveur DNS faisant autorité, il reviendra à la configuration de configuration dans /etc/resolv.conf et effectuera la résolution DNS si nécessaire. Par exemple, si /etc/resolv.conf est configuré pour utiliser des serveurs de noms spécifiques, ceux-ci seront utilisés pour effectuer la résolution DNS.
  8. En cas de problème avec les serveurs DNS primaires ou les serveurs de noms spécifiés dans /etc/resolv.conf, les noms d'hôte du serveur backend sont résolus en adresses IP incorrectes/non valides. Les adresses IP incorrectes/non valides seront ensuite stockées dans le cache DNS du processeur de messages.
    1. Si le problème lié aux serveurs DNS primaires ou aux serveurs de noms spécifiés dans /etc/resolv.conf est persistant, les adresses IP incorrectes/non valides resteront dans le cache DNS du processeur de messages. Tant que les adresses IP incorrectes sont stockées dans le cache DNS du processeur de messages, les requêtes de toutes ces API utilisant le serveur backend spécifique échoueront et renverront une erreur 503.
    2. Si le problème avec les serveurs DNS primaires ou les serveurs de noms spécifiés dans /etc/resolv.conf est intermittent, les adresses IP correctes et incorrectes sont stockées par intermittence dans le cache DNS. Dans ce cas, des erreurs 503 s'afficheront par intermittence pour toutes ces API utilisant le serveur backend spécifique.
  9. Si le problème avec les serveurs DNS est persistant, vous constaterez des défaillances continues. Si le problème avec les serveurs DNS est intermittent, vous verrez des défaillances intermittentes. C'est-à-dire que chaque fois que le nom d'hôte du serveur backend est résolu en adresses IP incorrectes, des erreurs 503 se produisent. Une fois que les noms d'hôte du serveur backend seront résolus en bonnes adresses IP, vous verrez des réponses indiquant que l'opération a réussi.

Résolution

Veuillez contacter l'administrateur de votre système d'exploitation pour résoudre les problèmes liés aux serveurs DNS.

  1. En cas de problème avec vos serveurs DNS primaires ou vos serveurs de noms spécifiés dans /etc/resolv.conf, corrigez le problème avec le serveur approprié.
  2. En cas de problème de configuration dans /etc/resolv.conf sur les systèmes dotés de processeurs de messages, corrigez-le.

Erreurs de connexion

Une erreur de connexion se produit lorsqu'un processeur de messages Apigee Edge tente de se connecter à un serveur backend et que l'un des problèmes suivants se produit:

  • Le processeur de messages ne peut pas se connecter pendant le délai d'expiration de connexion prédéfini. (Par défaut: 3 secondes)
  • Le serveur backend refuse la connexion.

Diagnostic

  1. Déterminez l'ID du message de la requête ayant échoué.
  2. Recherchez l'ID du message de requête spécifique dans le journal du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log). Les erreurs suivantes peuvent se produire :
    1. Une erreur onConnectTimeout indique que le processeur de messages n'a pas pu se connecter au serveur backend dans le délai d'expiration de connexion prédéfini.
      2016-06-23 09:11:49,314 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@2 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[C:]@10 useCount=1 bytesRead=0 bytesWritten=0 age=3001ms lastIO=3001ms .onConnectTimeout connectAddress=www.abc.com/11.11.11.11:80 resolvedAddress=www.abc.com/11.11.11.11
      2016-06-23 09:11:49,333 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@2 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onTimeout() : RequestWriteListener.onTimeout(HTTPRequest@6b393600)
      
    2. Une erreur java.net.ConnectException: Connection refuséeed indique que la connexion a été refusée par le serveur backend.
      14:40:16.531 +0530
      2016-06-17 09:10:16,531 org:myorg env:prod api:www.abc.com rev:1 rrt07eadn-22739-40983870-15 NIOThread@2 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() : connect to www.abc.com:11.11.11.11:443 failed with exception {}
      java.net.ConnectException: Connection refused
      at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) ~[na:1.7.0_75]
      at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:739) ~[na:1.7.0_75]
      at com.apigee.nio.ClientChannel.finishConnect(ClientChannel.java:121) ~[nio-1.0.0.jar:na]
      at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:108) ~[nio-1.0.0.jar:na]
      
  3. Vérifiez si vous êtes en mesure de vous connecter au serveur backend spécifique directement depuis chacun des processeurs de messages à l'aide de la commande telnet :
    1. Si le serveur backend correspond à une seule adresse IP, utilisez la commande suivante :
      telnet BackendServer-IPaddress 443
                
    2. Si le serveur backend correspond à plusieurs adresses IP, utilisez le nom d'hôte du serveur backend dans la commande telnet, comme indiqué ci-dessous :
      telnet BackendServer-HostName 443
                
  4. Si vous parvenez à vous connecter au serveur backend, un message tel que Connected to backend-server peut s'afficher. Si vous ne parvenez pas à vous connecter au serveur backend, cela peut être dû au fait que les adresses IP des processeurs de messages ne figurent pas sur la liste d'autorisation du serveur backend spécifique.

Résolution

Accordez l'accès aux adresses IP du processeur de messages sur le serveur backend spécifique pour permettre au trafic provenant des processeurs de messages Edge d'accéder à votre serveur backend. Par exemple, sous Linux, vous pouvez utiliser iptables pour autoriser le trafic provenant des adresses IP du processeur de messages sur le serveur backend.

Si le problème persiste, contactez votre administrateur réseau pour déterminer et résoudre le problème. Si vous avez besoin d'une aide supplémentaire d'Apigee, contactez l'assistance Apigee.

Nom d'hôte du serveur cible incorrect

Diagnostic

Si le nom d'hôte spécifié dans le serveur cible est incorrect, vous pouvez obtenir la réponse 503 Service AVAILABLE (Service non disponible) avec le code d'erreur messaging.adaptors.http.flow.ServiceUnavailable..

Outil de traçage

Pour diagnostiquer à l'aide de l'outil Trace:

  1. Si le problème est toujours actif, activez la session de suivi pour l'API concernée.
  2. Effectuez l'appel d'API et reproduisez le problème : 503 Service non disponible avec le code d'erreur messaging.adaptors.http.flow.ServiceUnavailable.
  3. Sélectionnez l'une des requêtes ayant échoué.
  4. Parcourez les différentes phases de la trace et localisez l'origine de l'échec.
  5. Sélectionnez le FlowInfo qui contient l'erreur. Vous trouverez peut-être d'autres informations dans le champ error.cause, qui peuvent vous indiquer la cause de l'échec, comme illustré dans l'exemple suivant:

    Exemple de requête affichant error.cause dans la trace

    Exemple de requête affichant error.cause dans la trace
  6. Si vous remarquez que error.cause affiche Host not reachable, l'une des causes probables est l'une des suivantes :
    • Le nom d'hôte spécifié dans la configuration du serveur cible/du point de terminaison cible est incorrect, ou comporte des espaces ou des caractères spéciaux indésirables.

      Par exemple, le nom d'hôte comporte un espace indésirable:
      "demo-target.apigee.net "
                        
    • Le nom d'hôte écrasé par la variable target.url dans le proxy d'API à l'aide de la règle AssignMessage ou JavaScript est incorrect, ou contient un espace ou tout autre caractère spécial indésirable.
  7. Vérifiez la configuration du point de terminaison cible et/ou la définition du serveur cible pour vous assurer que le nom d'hôte du serveur cible est incorrect, ou qu'il comporte des espaces ou des caractères spéciaux indésirables.
  8. Si l'hôte du serveur cible est créé dynamiquement, vérifiez la règle appropriée (par exemple, la règle AssignMessage/JavaScript) utilisée pour le créer. Vérifiez que le nom d'hôte du serveur cible est incorrect, ou qu'il comporte des espaces ou des caractères spéciaux indésirables.
  9. Une fois que vous avez déterminé le nom d'hôte du serveur cible, exécutez la commande nslookup/dig sur le nom d'hôte pour voir s'il peut être résolu.

    Par exemple, l'exécution de la commande nslookup sur le nom d'hôte avec un espace indésirable renvoie le résultat suivant:

    nslookup "demo-target.apigee.net "
    Server:	49.205.75.2
    Address:	49.205.75.2#53
    
    ** server can't find demo-target.apigee.net\032: NXDOMAIN
    
  10. Si la commande du système d'exploitation nslookup ne parvient pas non plus à résoudre le nom d'hôte, cela signifie que le nom d'hôte utilisé pour le serveur cible est incorrect.

    Accédez à Résolution.

Journaux du processeur de messages

Pour effectuer un diagnostic à l'aide des journaux du processeur de messages:

  1. Déterminez l'ID du message de la requête ayant échoué.
  2. Recherchez l'ID du message dans le journal du processeur de messages. (/opt/apigee/var/log/edge-message-processor/logs/system.log)
  3. Si les messages d'avertissement/d'erreur suivants s'affichent, le processeur de messages n'a pas pu résoudre le nom d'hôte. Le message va être mis en attente. Il se peut donc qu'il ne s'affiche pas pour tous les ID/requêtes de message.
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 WARN S.HTTPCLIENTSERVICE - DNSCache$2.failed() : Failed to resolve hostname www.somehost.com . Reason mocktarget.apigee.net : Name or service not known. This log message will snooze for 2 hours
        
  4. S'ensuit un message d'avertissement indiquant que le processeur de messages supprime l'adresse du cache DNS, car l'hôte du serveur cible est inaccessible.
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid> NIOThread@0 WARN  c.a.p.h.d.DNSCachedAddress - DNSCachedAddress.addressNotReachable() : The last address has been removed from Address list null refreshing
        
  5. Vous verrez peut-être un message indiquant que le processeur de messages échoue, avec l'exception "Hôte inaccessible". Le nom d'hôte peut parfois s'afficher dans le message d'erreur :
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to demo-target.apigee.net  failed with exception {}
    java.lang.RuntimeException: Host not reachable
    	at com.apigee.protocol.http.HTTPClient$Context.initConnect(HTTPClient.java:704)
    	at com.apigee.protocol.http.HTTPClient$Context.send(HTTPClient.java:675)
    	at com.apigee.messaging.adaptors.http.flow.data.TargetRequestSender.sendRequest(TargetRequestSender.java:234)
    	…<snipped>
        
  6. Il peut parfois apparaître comme null, car le nom d'hôte ne peut pas être résolu ni accessible, comme indiqué ci-dessous :
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to null failed with exception {}
    java.lang.RuntimeException: Host not reachable
    	at com.apigee.protocol.http.HTTPClient$Context.initConnect(HTTPClient.java:704)
    	at com.apigee.protocol.http.HTTPClient$Context.send(HTTPClient.java:675)
    	at com.apigee.messaging.adaptors.http.flow.data.TargetRequestSender.sendRequest(TargetRequestSender.java:234)
    	…<snipped>
        
  7. L'erreur Host not reachable se produit généralement dans l'un des cas suivants :
    • Le nom d'hôte spécifié dans la configuration du serveur cible/du point de terminaison cible est incorrect, ou comporte des espaces ou des caractères spéciaux indésirables.

      Par exemple, le nom d'hôte "demo-target.apigee.net" contient un espace indésirable dans le message d'erreur suivant :
      NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to demo-target.apigee.net  failed with exception
              
    • Le nom d'hôte remplacé par la variable target.url dans le proxy d'API avec la règle AssignMessage ou JavaScript est incorrect, ou comporte un espace ou tout autre caractère spécial indésirable.
  8. Déterminez le nom d'hôte du serveur cible auquel le processeur de messages tente de communiquer en utilisant l'une des options suivantes:
    1. Examinez attentivement le message d'erreur contenant Host not reachable .
    2. Si le message d'erreur affiche le nom d'hôte, copiez-le en incluant les espaces et les caractères spéciaux.
    3. Si le message d'erreur affiche la valeur null pour le nom d'hôte, comme illustré dans le message d'erreur suivant,
      org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to null failed with exception {}
              
      1. Déterminez le nom d'hôte en vérifiant la définition du serveur cible utilisée dans le proxy d'API défaillant.
      2. Si l'hôte du serveur cible est créé dynamiquement, vérifiez la règle appropriée (par exemple, AssignMessage/JavaScript policy) utilisée pour le créer.
  9. Une fois que vous avez déterminé le nom d'hôte du serveur cible, exécutez la commande nslookup/dig sur le nom d'hôte et vérifiez s'il peut être résolu.

    Par exemple, exécutez la commande nslookup sur le nom d'hôte qui inclut un espace

    nslookup "demo-target.apigee.net "
    Server:	49.205.75.2
    Address:	49.205.75.2#53
    
    ** server can't find demo-target.apigee.net\032: NXDOMAIN
          
  10. Si la commande nslookup du système d'exploitation ne parvient pas non plus à résoudre le nom d'hôte, le problème vient d'un nom d'hôte incorrect pour le serveur cible.

Résolution

  1. Assurez-vous que le nom d'hôte du serveur cible spécifié dans la configuration du point de terminaison cible ou dans la définition du serveur cible est correct, et qu'il ne contient pas d'espaces ni de caractères spéciaux indésirables.
  2. Si vous utilisez une règleAssignMessage/JavaScript pour générer dynamiquement le nom d'hôte du serveur cible, examinez la définition de la règle et le code, et assurez-vous que le nom d'hôte du serveur cible est généré correctement.

Échecs du handshake SSL

Un playbook complet de dépannage est consacré aux erreurs de handshake TLS/SSL. Consultez la page Échecs de handshake SSL.

Déterminer la source du problème

Certains types d'erreurs peuvent se produire sur la connexion entrante (vers le nord) ou sortante (direction sud). Une erreur entrante (limitée au nord) se produit entre l'application cliente et Edge. Une erreur sortante (limitée au sud) se produit entre Edge et le serveur cible backend. Pour diagnostiquer ce type de problèmes, votre première tâche consiste à déterminer si l'erreur se produit sur la connexion nord ou sud.

Comprendre les connexions "nord" et "sud"

Dans Edge, vous pouvez rencontrer une erreur 503 Service non disponible sur la connexion entrante ou sortante:

  • Connexion entrante (ou orientée vers le nord) : connexion entre l'application cliente et le routeur périphérique. Le routeur est le composant d'Apigee Edge qui gère les requêtes entrantes adressées au système.
  • Connexion sortante (ou "direction sud") : connexion entre le processeur de messages Edge et le serveur backend. Le processeur de messages est un composant d'Apigee Edge qui sert de proxy pour les requêtes API aux serveurs cibles backend.

Si vous êtes un utilisateur de Edge Public Cloud, vous n'avez probablement pas connaissance des composants internes tels que le routeur ou le processeur de messages. Ces composants internes ne sont pas visibles ni accessibles aux utilisateurs du cloud public. Lorsque cela est possible, nous proposons d'autres méthodes pour examiner le problème qui ne nécessitent pas d'accès direct à ces composants.

La figure suivante illustre les connexions nord et sud pour Apigee Edge.

Flux de l&#39;application cliente (connexion vers le nord) via le serveur périphérique vers le serveur backend (connexion en direction du sud)

Déterminer où l'erreur 503 Service indisponible s'est produite

Utilisez l'une des procédures suivantes pour déterminer si l'erreur 503 "Service non disponible" s'est produite au niveau de la connexion nord ou sud.

Trace dans l'interface utilisateur

Pour déterminer où l'erreur s'est produite à l'aide de la trace de l'interface utilisateur, procédez comme suit:

  1. Si le problème est toujours actif, activez la trace de l'UI pour l'API concernée.
  2. Si la trace de l'interface utilisateur de la requête API ayant échoué indique que l'erreur 503 "Service non disponible" se produit pendant le flux de requêtes cible ou est envoyée par le serveur backend, le problème est sud (entre le processeur de messages et le serveur backend).
  3. Si vous n'obtenez pas de trace pour l'appel d'API spécifique, cela signifie que le problème se situe en direction du nord, entre l'application cliente et le routeur.

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 d'erreurs messaging.adaptors.http.flow.ServiceUnavailable dépasse un seuil particulier.

Journaux d'accès NGINX

Pour déterminer où l'erreur s'est produite à l'aide de la trace de l'interface utilisateur, procédez comme suit:

Si le problème s'est déjà produit par le passé ou s'il est intermittent et que vous ne parvenez pas à capturer la trace, procédez comme suit:

  1. Vérifiez les journaux d'accès NGINX (/opt/apigee/var/log/edge-router/nginx/ org-env.port_access_log).
  2. Recherchez s'il existe des erreurs 503 pour un proxy d'API spécifique.
  3. Si vous parvenez à identifier des erreurs 503 pour l'API spécifique à un moment donné, le problème s'est produit au niveau de la connexion southbound (entre le processeur de messages et le serveur backend).
  4. Si ce n'est pas le cas, le problème est survenu au niveau de la connexion Nord (entre l'application cliente et le routeur).