503 Service indisponible – Serveur backend

Outil Trace

1. Activez la session de trace. et effectuez l'appel d'API pour reproduire le problème - 503 Service Unavailable.
2. Sélectionnez l'une des requêtes ayant échoué et examinez la trace.
3. Parcourez les différentes phases de la trace et localisez l'origine de l'échec.
4. Si vous constatez que l'erreur 503 est renvoyée en tant que réponse du serveur cible, la cause de l'erreur 503 est le serveur cible.

   Voici un exemple de capture d'écran de trace montrant la réponse 503 Service Unavailable (Service non disponible) reçue. à partir du serveur cible:

   
5. Cliquez sur la phase Réponse reçue du serveur cible, puis suivez les En-têtes de réponse et "Contenu de la réponse" pour vérifier s'ils contiennent des informations utiles: <ph type="x-smartling-placeholder">
   </ph>
   • Les en-têtes de réponse peuvent contenir l'en-tête Serveur, qui indique d'où provient la réponse d'erreur.
   • Le contenu de la réponse peut contenir des informations supplémentaires expliquant pourquoi le serveur cible a envoyé le code de réponse 503.
   
6. Confirmez que l'erreur 503 provient du serveur cible en vérifiant les valeurs de X-Apigee-fault-source et X-Apigee-fault-code dans le AX (Données analytiques enregistrées) Phase dans la trace en suivant les étapes ci-dessous: <ph type="x-smartling-placeholder">
   </ph>
   1. Cliquez sur la phase AX (Analytics Data Recorded) Phase, comme illustré dans la capture d'écran ci-dessous:
   2. Faites défiler Phase Details (Détails de la phase) vers le bas jusqu'à la section Response Headers (En-têtes de réponse) et déterminez les valeurs. de X-Apigee-fault-code et X-Apigee-fault-source, comme indiqué ci-dessous:
   3. Si les valeurs de X-Apigee-fault-source et X-Apigee-fault-code correspondent aux valeurs dans le tableau ci-dessous, vous pouvez vérifier que l'erreur 503 provient bien serveur cible:

      En-têtes de réponse	Valeur
      X-Apigee-fault-source	cible
      X-Apigee-fault-code	messaging.adaptors.http.flow.ErrorResponseCode

7. Vérifiez si vous utilisez un chaînage de proxy, c'est-à-dire si le serveur/point de terminaison cible est en appelant un autre proxy dans Apigee. Pour déterminer cela: <ph type="x-smartling-placeholder">
   </ph>
   1. Revenez à la phase Request sent to target server (Requête envoyée au serveur cible). cliquez sur le bouton Show Curl (Afficher le curseur) et déterminez l'alias de l'hôte du serveur cible.
   2. Si l'alias hôte du serveur cible pointe vers un alias d'hôte virtuel, il est via un chaînage de proxy. Dans ce cas, vous devez répéter toutes les étapes ci-dessus pour l'ensemble de données jusqu'à ce que vous déterminiez ce qui cause réellement l'erreur 503 Service indisponible. Dans ces cas-là, le message 503 Service non disponible peut se produire dans d'autres proxys enchaînés dans d'autres qui peut être diagnostiquée à l'aide ce playbook.
   3. Si l'alias d'hôte du serveur cible pointe vers votre serveur backend, accédez à Résolution.

Journaux d'accès NGINX

Vous pouvez également consulter les journaux lccess NGINX pour déterminer si le code d'état 503 a été envoyé. par le serveur backend. Cela est particulièrement utile si le problème s'est produit par le passé ou si le problème se produit par intermittence et que vous ne parvenez pas à capturer la trace dans l'UI. Procédez comme suit pour obtenir 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. Rechercher les erreurs 503 pour le proxy d'API spécifique pendant une durée déterminée (si le problème s'est produit dans le passé) ou si les requêtes échouent toujours avec le code 503.
3. En cas d'erreurs 503, vérifiez si l'erreur provient du serveur backend. Si les valeurs de X-Apigee-fault-source et X-Apigee-fault-code correspondent à la valeurs affichées dans le tableau ci-dessous, l'erreur 503 provient du serveur backend:

   En-têtes de réponse	Valeur
   X-Apigee-fault-source	cible
   X-Apigee-fault-code	messaging.adaptors.http.flow.ErrorResponseCode

   Voici un exemple d'entrée illustrant l'erreur 503 causée par le serveur cible:

   
4. Examinez le proxy d'API spécifique et assurez-vous que vous utilisez chaînage de proxy, si le serveur/point de terminaison cible n'appelle pas un autre proxy dans Apigee. Si vous utilisez vous devez répéter toutes les étapes ci-dessus pour le chaînage de proxy jusqu'à vous déterminez ce qui cause réellement l'erreur 503 Service non disponible. Dans ces cas, Le code 503 Service non disponible peut également se produire dans d'autres proxys en chaîne à d'autres étapes, que vous pouvez diagnostiquer à l'aide de ce playbook.
5. Si vous confirmez que vous n'utilisez pas de chaînage de proxy et que l'erreur 503 provient de votre serveur backend, puis accédez à Résolution.

Appel au serveur backend

Vous pouvez appeler directement le serveur backend et vérifier que vous obtenez les mêmes Réponse 503 Service indisponible telle que reçue lorsque la demande a été effectuée via Apigee Edge.

1. Assurez-vous de disposer de tous les en-têtes et paramètres de requête requis, ainsi que de tous les identifiants doivent être transmises au serveur backend dans la requête.
2. Si le service de backend est accessible publiquement, vous pouvez utiliser la commande curl, Postman ou tout autre client REST et appeler directement l'API du serveur backend.
3. Si le serveur backend n'est accessible qu'à partir des processeurs de messages, vous pouvez utiliser le curl, Postman ou tout autre client REST et appeler directement l'API du serveur backend. du processeur de messages.
4. Vérifiez que le service de backend renvoie bien l'erreur 503 Service indisponible.