503 Service indisponible – Serveur backend

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

Vidéos

Regardez la vidéo suivante pour en savoir plus sur la résolution des erreurs 503 de service non disponible.

Vidéo Description
Erreur 503 : service non disponible sur le serveur backend Pour en savoir plus, consultez les informations suivantes :
  • Introduction à l'erreur 503 Service indisponible dans Apigee Edge
  • Dépannage et résolution d'un service 503 en temps réel non disponible sur le serveur backend

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

L'un des messages d'erreur suivants peut s'afficher:

HTTP/1.1 503 Service Unavailable

HTTP/1.1 503 Service Unavailable: Back-end server is at capacity

Un message d'erreur semblable au suivant peut également s'afficher dans la réponse HTTP:

The server is temporarily unable to service your request due to
maintenance downtime or capacity problems. Please try again later.

Remarque:Le code de réponse et le message d'erreur ci-dessus ne sont que des exemples. Dans certains cas, vous ne recevrez que le code de réponse d'erreur, sans aucun message d'erreur. Le format et le contenu du code de réponse d'erreur et du message d'erreur peuvent varier en fonction de la mise en œuvre du serveur backend.

Causes

Le code d'état HTTP 503 signifie que le serveur n'est actuellement pas en mesure de gérer les requêtes entrantes. En général, cette erreur se produit lorsque le serveur est trop occupé ou temporairement indisponible pour cause de maintenance.

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

Cause Description Personnes pouvant effectuer les étapes de dépannage
Serveur surchargé Le serveur backend est surchargé ou dépasse sa capacité et ne peut pas gérer de nouvelles requêtes client entrantes. Utilisateurs Edge Public and Private Cloud
Serveur en cours de maintenance Le serveur backend est peut-être temporairement en maintenance. Utilisateurs Edge Public and Private Cloud

Cause: serveur/serveur surchargé en maintenance

Dans Apigee Edge, l'erreur 503 d'indisponibilité du service peut être renvoyée par un serveur backend dans les cas suivants:

  • Un serveur backend est surchargé/occupé et ne peut plus gérer de nouvelles requêtes.
  • Le serveur backend est temporairement indisponible en raison d'opérations de maintenance.

Diagnostic

Pour diagnostiquer l'erreur, vous pouvez utiliser l'une des trois méthodes suivantes:

  • Outil de traçage
  • Journaux d'accès NGINX
  • Appel direct au serveur backend

Pour en savoir plus sur chaque méthode, cliquez sur les onglets ci-dessous.

Outil de traçage

  1. Activez la session de trace, puis effectuez l'appel d'API pour reproduire le problème : 503 Service non disponible.
  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, le serveur cible est à l'origine de l'erreur 503.

    Voici un exemple de capture d'écran de trace montrant la réponse "503 Service indisponible" reçue du serveur cible:

  5. Cliquez sur la phase Response received from target server (Réponse reçue du serveur cible), puis parcourez les sections "Response Headers" (En-têtes de réponse) et "Response Content" (Contenu de la réponse) pour voir si elles contiennent des informations utiles :
    • Les en-têtes de réponse peuvent contenir l'en-tête "Server" qui indique la provenance de la réponse d'erreur.
    • Le contenu de la réponse peut contenir des informations supplémentaires sur la raison pour laquelle le serveur cible a envoyé le code de réponse 503.
  6. Vérifiez que l'erreur 503 provient du serveur cible en vérifiant les valeurs de X-Apigee-fault-source et X-Apigee-fault-code dans la phase AX (données analytiques enregistrées) de la trace en suivant les étapes ci-dessous :
    1. Cliquez sur AX (Analytics Data Recorded) Phase, comme illustré dans la capture d'écran ci-dessous :
    2. Faites défiler la page jusqu'à la section "Response Headers" (Détails de la phase) jusqu'à la section "Response Headers" (En-têtes de réponse), puis déterminez les valeurs de X-Apigee-fault-code et de 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 affichées dans le tableau ci-dessous, vous pouvez confirmer que l'erreur 503 provient du 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 appelle un autre proxy dans Apigee. Pour le déterminer :
    1. Revenez à la phase Request sent to target server (Requête envoyée au serveur cible), cliquez sur le bouton Show Curl (Afficher l'URL), puis déterminez l'alias de l'hôte du serveur cible.
    2. Si l'alias d'hôte du serveur cible pointe vers un alias d'hôte virtuel, il s'agit d'un chaînage de proxy. Dans ce cas, vous devez répéter toutes les étapes ci-dessus pour le proxy en chaîne jusqu'à ce que vous déterminiez la cause de l'erreur 503 Service indisponible. Dans ce cas, le message 503 "Service indisponible" peut se produire dans d'autres proxys en chaîne à d'autres étapes, ce qui peut être diagnostiqué à l'aide de ce playbook.
    3. Si l'alias de l'hôte du serveur cible pointe vers votre serveur backend, passez à la section Résolution.

Journaux d'accès NGINX

Vous pouvez également consulter les journaux lccess de 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 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 toutes les erreurs 503 pour le proxy d'API spécifique pendant une durée spécifique (si le problème s'est produit dans le passé) ou toutes les requêtes ayant échoué avec l'erreur 503.
  3. S'il existe des erreurs 503, vérifiez si elles proviennent du serveur backend. Si les valeurs de X-Apigee-fault-source et X-Apigee-fault-code correspondent aux valeurs indiqué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 d'utiliser un chaînage de proxy, c'est-à-dire si le serveur/point de terminaison cible n'appelle pas d'autre proxy dans Apigee. Si vous utilisez un chaînage de proxy, vous devez répéter toutes les étapes ci-dessus pour le proxy en chaîne jusqu'à ce que vous déterminiez la cause de l'erreur 503 Service non disponible. Dans ce cas, l'erreur 503 Service indisponible peut également se produire dans d'autres proxys en chaîne à d'autres étapes, ce 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, accédez à Résolution.

Appel au serveur backend

Vous pouvez appeler directement le serveur backend et vérifier que vous obtenez la même réponse 503 "Service non disponible" que celle reçue lorsque la requête a été effectuée via Apigee Edge.

  1. Assurez-vous de disposer de tous les en-têtes, paramètres de requête et identifiants qui doivent être transmis au serveur backend dans le cadre de la requête.
  2. Si le service de backend est accessible au public, 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 que depuis les processeurs de messages, vous pouvez utiliser la commande curl, Postman ou tout autre client REST, et appeler l'API du serveur backend directement à partir du processeur de messages.
  4. Vérifiez que le service de backend renvoie bien l'erreur 503 "Service non disponible".

Résolution

Si vous vérifiez que l'erreur 503 provient du serveur backend, vous pouvez procéder comme suit pour résoudre le problème:

  • Si le problème est dû au fait que le serveur backend est arrêté pour cause de maintenance, vous pouvez le remettre en ligne après la période de maintenance.
  • Si le problème est dû à une surcharge du serveur backend, corrigez-le si vous avez accès au serveur backend. Sinon, vous devrez peut-être contacter l'équipe du serveur backend pour résoudre le problème.

Diagnostiquer les problèmes à l'aide de la 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 par exemple le cas des applications de développement, des proxys d'API, des cibles de 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.ErrorResponseCode dépasse un certain seuil.

Vous devez collecter des informations de diagnostic

Si le problème persiste même après avoir suivi les instructions ci-dessus, veuillez rassembler les informations de diagnostic suivantes, puis contacter l'assistance Apigee.

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

  • 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 les requêtes avec l'erreur 503 "Service non disponible"
  • Si les erreurs 503 ne se produisent pas actuellement, indiquez la période avec le fuseau horaire lorsque des erreurs 503 se sont produites par le passé.

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

  • Message d'erreur complet observé pour les requêtes ayant échoué.
  • Organisation, nom de l'environnement et nom du proxy de l'API pour lesquels vous observez des erreurs 503.
  • API Proxy Bundle.
  • Fichier de suivi contenant les requêtes générant l'erreur 503 Service non disponible.
  • 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 moment où les erreurs 503 se sont produites.