503 Service indisponible.

<ph type="x-smartling-placeholder"></ph> Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur Apigee X. En savoir plus

Vidéos

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

Vidéo	Description
Dépanner et résoudre l'erreur 503 Service indisponible en raison d'un problème DNS	Apprenez-en plus sur les points suivants: <ph type="x-smartling-placeholder"> </ph> Erreur 503 Service non disponible causée par la résolution DNS et les problèmes liés au réseau dans Apigee Edge Dépannage et résolution d'une erreur 503 Service indisponible en temps réel causée par un problème de résolution DNS
Dépanner et résoudre l'erreur 503 Service indisponible en raison d'un problème réseau	Dépannage et résolution d'une erreur 503 Service indisponible en temps réel causée par un problème réseau dans Apigee Edge

Symptôme

L'application cliente reçoit une réponse HTTP 503 avec le message Service Unavailable. 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 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 dues à un délai d'attente de connexion, des erreurs le nom d'hôte ou les échecs de handshake SSL lors de la communication avec le serveur backend.

Causes possibles de la réponse 503 Service Unavailable:

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 a généré des adresses IP incorrectes entraînant des erreurs de connexion.	Utilisateurs de cloud privé Edge
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é Edge
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 (comme un espace).	Utilisateurs Edge de cloud public et privé
Échecs du handshake SSL	Le handshake TLS/SSL a échoué entre le client et le serveur. (Dépannage pour ce type de est abordé dans une autre section.)	Utilisateurs Edge de cloud public et privé

Étapes de diagnostic courantes

Déterminer l'ID de message de la requête en échec

Erreurs de connexion dues à une résolution DNS incorrecte

Diagnostic

1. Déterminez l'ID de message de la requête en échec.
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). Vous pouvez rencontrer les erreurs suivantes:
   
   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 (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, consultez la section Erreurs de connexion.
4. Si l'adresse IP n'est pas valide, le problème est probablement dû à la résolution DNS.
5. Répétez les étapes 3 et 4 pour quelques requêtes API ayant échoué, et vérifiez si vous voyez des adresses IP identiques ou 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 incorrectes 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 faisant autorité ou les serveurs de noms configurés dans /etc/resolv.conf.
   
   En règle générale, il peut y avoir un ou plusieurs serveurs DNS faisant autorité configurés pour effectuer la résolution DNS. S'il n'y a pas de serveurs DNS faisant autorité, la configuration est rétablie dans /etc/resolv.conf et la résolution DNS est effectuée le cas échéant. 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èmes 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 ou non valides. Les adresses IP incorrectes/non valides seront alors stockées dans le cache DNS du processeur de messages.
   1. Si le problème avec les serveurs DNS primaires ou les serveurs de noms spécifiés dans /etc/resolv.conf est persistant, les adresses IP incorrectes/non valides continueront d'être conservées 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 ces API utilisant le serveur backend spécifique échoueront avec 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 se produit par intermittence, les adresses IP correctes et incorrectes sont stockées par intermittence dans le cache DNS. Dans ce cas, des erreurs 503 s'affichent par intermittence pour toutes les API utilisant le serveur backend concerné.
9. Si le problème avec les serveurs DNS persiste, vous verrez des échecs continus. Si le problème avec les serveurs DNS est intermittent, vous verrez des échecs intermittents. Autrement dit, chaque fois que le nom d'hôte du serveur backend est résolu en adresses IP incorrectes, vous observez des erreurs 503. Et lorsque les noms d'hôte du serveur backend seront résolus en adresses IP correctes, vous verrez des réponses positives.

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 faisant autorité 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 disposant de processeurs de messages, corrigez le problème de configuration.

Erreurs de connexion

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

• Le processeur de messages ne parvient pas à se connecter pendant le délai de connexion prédéfini. (Valeur par défaut: 3 secondes)
• Le serveur backend refuse la connexion.

Diagnostic

1. Déterminez l'ID de message de la requête en échec.
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). Vous pouvez rencontrer les erreurs suivantes: <ph type="x-smartling-placeholder">
   </ph>
   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. L'erreur java.net.ConnectException: Connection refused indique que la connexion a bien été établie. 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 chacune des Processeurs de messages à l'aide de la commande telnet: <ph type="x-smartling-placeholder">
   </ph>
   1. Si le serveur backend résout une adresse IP unique, utilisez la commande suivante:

      telnet BackendServer-IPaddress 443
                

   2. Si le serveur backend est associé à plusieurs adresses IP, utilisez le nom d'hôte de 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 du type Connected to backend-server peut s'afficher. Si vous ne parvenez pas à vous connecter au serveur backend, cela peut être dû à car les processeurs de messages Les adresses IP ne sont pas ajoutées à la liste d'autorisation sur le backend concerné Google Cloud.

Solution

Accordez l'accès aux adresses IP du processeur de messages sur le serveur backend spécifique pour autoriser le trafic en provenance des processeurs de messages périphériques pour 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, adressez-vous à votre administrateur réseau pour déterminer et résoudre 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é sur le serveur cible est incorrect, vous pouvez obtenir la 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 le serveur cible est correcte et ne comporte aucun espace ni caractère spécial superflu.
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 de handshake SSL

Un playbook de dépannage complet 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 au niveau du réseau entrant (direction nord) ou sortant (direction sud). . Une erreur entrante (limite nord) se produit entre l'application cliente et Edge. Une une erreur sortante (direction sud) se produit entre Edge et le serveur cible backend. Pour diagnostiquer votre première tâche consiste à déterminer si l'erreur se produit dans la direction nord en direction du sud.

Comprendre les connexions reliant le nord et le sud

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

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

Si vous êtes un utilisateur de cloud public Edge, vous ignorez probablement les composants internes tels que le routeur ou le processeur de messages. Ces composants internes ne sont ni visibles, ni accessibles aux Utilisateurs de cloud public. Dans la mesure du possible, nous proposons d'autres méthodes pour étudier le problème n'ont pas besoin d'un accès direct à ces composants.

La figure suivante illustre des connexions direction nord et sud pour Apigee Périphérie.

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

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