503 Service indisponible.

Vous consultez la documentation Apigee Edge.
Accédez à la documentation Apigee X.

Vidéos

Pour en savoir plus sur les erreurs 503, regardez les vidéos suivantes :

Problème constaté

L'application cliente reçoit un code d'état de réponse HTTP 503 avec le message Service Unavailable (Service indisponible) suite à un appel de proxy d'API.

Messages d'erreur

Le message d'erreur suivant s'affiche :

HTTP/1.1 503 Service Unavailable
      

Le message d'erreur suivant peut également s'afficher 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 Unavailable 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 dépassé, d'un nom d'hôte incorrect ou d'échecs de handshake SSL lors de la communication avec le serveur de backend.

Voici les causes possibles de la réponse 503 Service Unavailable :

Étapes de diagnostic courantes

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

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 s'afficher :
   
   Une erreur onConnectTimeout indique que le processeur de messages n'a pas pu se connecter au serveur backend dans le délai 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 et vérifiez si elle est valide pour votre serveur de backend. Si l'adresse IP est valide, accédez à Erreurs de connexion.
4. Si l'adresse IP n'est pas valide, cela est probablement dû à des problèmes de résolution DNS.
5. Répétez les étapes 3 et 4 pour quelques requêtes API en échec supplémentaires, et vérifiez si vous voyez les mêmes adresses IP non valides ou d'autres.
6. Recherchez dans le journal du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log) les messages contenant le mot clé DNS Refresh. Vérifiez si des adresses IP incorrectes ou non valides sont ajoutées de temps en temps au cache DNS du 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 survenir en cas de problème avec les serveurs DNS faisant autorité ou les serveurs de noms configurés dans /etc/resolv.conf.
   
   En règle générale, un ou plusieurs serveurs DNS faisant autorité peuvent être configurés pour effectuer la résolution DNS. S'il n'y a pas de serveurs DNS faisant autorité, il reviendra à la configuration définie dans /etc/resolv.conf et effectuera la résolution DNS de manière appropriée. Par exemple, si /etc/resolv.conf est configuré pour utiliser des serveurs de noms spécifiques, ces serveurs de noms seront utilisés pour effectuer la résolution DNS.
8. En cas de problème avec les serveurs DNS faisant autorité ou les serveurs de noms spécifiés dans /etc/resolv.conf, les noms d'hôte du serveur backend seront résolus en adresses IP incorrectes/non valides. Les adresses IP incorrectes/non valides sont ensuite stockées dans le cache DNS du processeur de messages.
   1. Si le problème lié aux serveurs DNS faisant autorité ou aux serveurs de noms spécifiés dans /etc/resolv.conf persiste, 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 pour toutes les API utilisant le serveur backend spécifique échoueront avec une erreur 503.
   2. Si le problème lié aux serveurs DNS faisant autorité ou aux serveurs de noms spécifiés dans /etc/resolv.conf est intermittent, les adresses IP correctes et incorrectes seront stockées de manière intermittente dans le cache DNS. Dans ce cas, des erreurs 503 s'afficheront par intermittence pour toutes les API utilisant le serveur de backend spécifique.
9. Si le problème lié aux serveurs DNS persiste, des échecs continus s'affichent. Si le problème lié aux serveurs DNS est intermittent, des échecs intermittents s'affichent. En d'autres termes, chaque fois que le nom d'hôte du serveur backend est résolu en adresses IP incorrectes, des erreurs 503 se produisent. Lorsque les noms d'hôte du serveur backend sont résolus en adresses IP valides, vous obtenez des réponses positives.

Solution

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

1. Si un problème survient avec vos serveurs DNS faisant autorité ou les serveurs de noms spécifiés dans /etc/resolv.conf, résolvez-le avec le serveur approprié.
2. Si la configuration de /etc/resolv.conf pose problème sur les systèmes disposant de processeurs de messages, corrigez-la.

Erreurs de connexion

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

• Le Processeur de messages n'a pas pu se connecter dans le délai 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 de message de la 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 s'afficher :
   1. Une erreur onConnectTimeout indique que le processeur de messages n'a pas pu se connecter au serveur backend dans le délai 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 refused 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 pouvez vous connecter au serveur de backend spécifique directement à partir de chacun des processeurs de messages à l'aide de la commande telnet :
   1. Si le serveur de backend est résolu en une seule adresse IP, utilisez la commande suivante :

      telnet BackendServer-IPaddress 443
                

   2. Si le serveur backend est résolu en 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 de 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 sont pas ajoutées à la liste d'autorisation sur le serveur backend spécifique.

Solution

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

Si le problème persiste, contactez votre administrateur réseau pour l'identifier et le résoudre. Si vous avez besoin d'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 une réponse 503 Service Unavailable avec le code d'erreur messaging.adaptors.http.flow.ServiceUnavailable..

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 ne comporte pas d'espace ni de caractères spéciaux indésirables.
2. Si vous utilisez une règle AssignMessage/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 guide de dépannage complet est consacré aux erreurs de handshake TLS/SSL. Consultez Échecs du handshake SSL.

Déterminer la source du problème

Certains types d'erreurs peuvent se produire sur la connexion entrante (Northbound) ou sortante (Southbound). Une erreur entrante (vers le nord) se produit entre l'application cliente et Edge. Une erreur sortante (vers le sud) se produit entre Edge et le serveur cible de backend. Pour diagnostiquer ce type de problème, vous devez d'abord déterminer si l'erreur se produit sur la connexion Northbound ou Southbound.

Comprendre les connexions Northbound et Southbound

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

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

Si vous êtes un utilisateur Edge Public Cloud, vous n'êtes probablement pas au courant 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. Dans la mesure du possible, nous vous proposons d'autres méthodes pour examiner le problème sans avoir besoin d'accéder directement à ces composants.

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

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

Suivez l'une des procédures ci-dessous pour déterminer si l'erreur "Service indisponible" 503 s'est produite au niveau de la connexion nord ou sud.