503 Service indisponible - Fermeture prématurée par serveur backend.

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

Problème constaté

L'application cliente obtient l'état de réponse HTTP 503 avec le message Service Unavailable après un appel de proxy d'API.

Message d'erreur

L'application cliente obtient le code de réponse suivant:

HTTP/1.1 503 Service Unavailable

De plus, le message d'erreur suivant peut s'afficher:

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

Causes possibles :

Cause	Description	Instructions de dépannage applicables
Le serveur cible ferme prématurément la connexion	Le serveur cible met fin prématurément à la connexion pendant que le processeur de messages continue d'envoyer la charge utile de la requête.	Utilisateurs Edge Public and Private Cloud

Étapes de diagnostic courantes

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

Cause: le serveur cible ferme prématurément la connexion

Diagnostic

1. Si vous êtes un utilisateur du cloud public ou du cloud privé :
   1. Utilisez l'outil Trace (comme expliqué dans la section Étapes de diagnostic courantes) et vérifiez que les deux ensembles suivants sont définis dans le volet Données analytiques enregistrées :
      • X-Apigee.fault-code: messaging.adaptors.http.flow.ServiceUnavailable
      • X-Apigee.fault-source: target

      

   2. Utilisez l'outil Trace (comme expliqué dans la section Étapes de diagnostic courantes) et vérifiez que les deux éléments suivants sont définis dans le volet Error (Erreur), juste après la propriété state TARGET_REQ_FLOW :
      • error.class::com.apigee.errors.http.server.ServiceUnavailableException
      • error.cause::Broken pipe

      

   3. Pour en savoir plus, consultez Utiliser tcpdump.
2. Si vous utilisez un cloud privé :
   • Déterminez l'ID du message de la requête ayant échoué.
   • Recherchez l'ID du message dans le journal du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log).
   • L'une des exceptions suivantes s'affiche:

     Exception n° 1: java.io.IOException: Canal endommagé lors de l'écriture sur le canal ClientOutputChannel

     2021-01-30 15:31:14,693 org:anotherorg env:prod api:myproxy
     rev:1 messageid:myorg-opdk-test-1-30312-13747-1  NIOThread@1
     INFO  HTTP.SERVICE - ExceptionHandler.handleException() :
     Exception java.io.IOException: Broken pipe occurred while writing to channel
     ClientOutputChannel(ClientChannel[Connected:
     Remote:IP:PORT Local:0.0.0.0:42828]@8380 useCount=1
     bytesRead=0 bytesWritten=76295 age=2012ms  lastIO=2ms  isOpen=false)
     

     ou

     Exception n° 2: exception onExceptionWrite: {}
     java.io.IOException: Canal endommagé

     2021-01-31 15:29:37,438 org:anotherorg env:prod api:503-test
     rev:1 messageid:leonyoung-opdk-test-1-18604-13978-1
     NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$2.onException() :
     ClientChannel[Connected: Remote:IP:PORT
     Local:0.0.0.0:57880]@8569 useCount=1 bytesRead=0 bytesWritten=76295 age=3180ms  lastIO=2
     ms  isOpen=false.onExceptionWrite exception: {}
     java.io.IOException: Broken pipe
     

   • Ces deux exceptions indiquent que même si le processeur de messages écrivait encore la charge utile de la requête sur le serveur backend, la connexion a été fermée prématurément par le serveur backend. Par conséquent, le processeur de messages génère l'exception java.io.IOException: Broken pipe.
   • Le champ Remote:IP:PORT indique l'adresse IP et le numéro de port du serveur backend résolu.
   • L'attribut bytesWritten=76295 dans le message d'erreur ci-dessus indique que le processeur de messages a envoyé une charge utile de 76295 octets au serveur backend lorsque la connexion a été fermée prématurément.
   • L'attribut bytesRead=0 indique que le processeur de messages n'a reçu aucune donnée (réponse) du serveur backend.
   • Pour approfondir l'analyse du problème, rassemblez un tcpdump sur le serveur backend ou sur le processeur de messages, puis analysez-le comme expliqué ci-dessous.

Utiliser tcpdump

1. Capturez un tcpdump sur le serveur backend ou sur le processeur de messages à l'aide des commandes suivantes:

   Commande permettant de rassembler tcpdump sur le serveur backend:

   tcpdump -i any -s 0 host MP_IP_ADDRESS -w FILE_NAME
   

   Commande permettant de rassembler tcpdump sur le processeur de messages:

   tcpdump -i any -s 0 host BACKEND_HOSTNAME -w FILE_NAME
   

2. Analysez la tcpdump capturée:

   Exemple de sortie tcpdump (recueillie sur le processeur de messages):

   

   Dans la tcpdump ci-dessus, vous pouvez voir ce qui suit:

   1. Dans le paquet 4, le processeur de messages a envoyé une requête POST au serveur backend.
   2. Dans les paquets 5, 8, 9, 10 et 11, le processeur de messages a continué à envoyer la charge utile de la requête au serveur backend.
   3. Dans les paquets 6 et 7,le serveur backend a répondu avec ACK pour une partie de la charge utile de la requête reçue du processeur de messages.
   4. Toutefois, dans le paquet 12, au lieu de répondre avec un ACK pour les paquets de données d'application reçus, puis de répondre avec la charge utile de réponse, le serveur backend répond à la place avec un FIN ACK lançant la fermeture de la connexion.
   5. Cela montre clairement que le serveur backend ferme la connexion prématurément alors que le processeur de messages continuait à envoyer la charge utile de la requête.
   6. Cela permet au processeur de messages d'enregistrer une erreur IOException: Broken Pipe et de renvoyer un 503 au client.

Résolution

1. Collaborez avec l'une ou l'autre des équipes chargées des applications et du réseau, ou les deux, pour analyser et résoudre le problème lié aux déconnexions prématurées côté serveur backend.
2. Assurez-vous que l'application du serveur backend n'expire pas ou ne réinitialise pas la connexion avant de recevoir l'intégralité de la charge utile de la requête.
3. Si vous disposez d'un appareil ou d'une couche réseau intermédiaire entre Apigee et le serveur backend, assurez-vous qu'ils n'expirent pas avant de recevoir l'ensemble de la charge utile de la requête.

Si le problème persiste, consultez la page Vous devez collecter des informations de diagnostic.

Vous devez collecter des informations de diagnostic

Si le problème persiste même après avoir suivi les instructions ci-dessus, rassemblez les informations de diagnostic suivantes, puis contactez l'assistance Apigee Edge:

Si vous êtes un utilisateur de cloud public, fournissez les informations suivantes:

• Le nom de l'organisation.
• Nom de l'environnement
• Nom du proxy d'API
• Exécutez la commande curl pour reproduire l'erreur 503.
• Fichier de suivi contenant la requête avec l'erreur 503 Service Unavailable
• Si les erreurs 503 ne se produisent pas actuellement, indiquez la période avec les informations de fuseau horaire lorsque des erreurs 503 se sont produites.

Si vous êtes un utilisateur du Private Cloud, fournissez les informations suivantes:

• Message d'erreur complet observé pour les requêtes ayant échoué
• Organisation, nom de l'environnement et nom du proxy d'API pour lesquels vous observez des erreurs 503
• Groupe de proxys d'API
• Fichier de suivi contenant les requêtes avec l'erreur 503 Service Unavailable
• Journaux d'accès NGINX
  /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
• Journaux du processeur de messages
  /opt/apigee/var/log/edge-message-processor/logs/system.log
• Période contenant le fuseau horaire au cours de laquelle les erreurs 503 se sont produites
• Tcpdumps collectée sur les processeurs de messages et le serveur backend lorsque l'erreur s'est produite