Erreur de serveur interne 500 – Serveur backend

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

Vidéos

Vidéo Description
500 Erreur interne du serveur : causée par le backend Présente un 500 Internal Server Error en temps réel causé par le serveur backend, ainsi que les étapes à suivre pour résoudre le problème.

Problème constaté

L'application cliente reçoit un code d'état HTTP 500 avec le message Internal Server Error en réponse aux appels d'API.

Le code d'état HTTP 500 est une réponse d'erreur générique. Cela signifie que le serveur a rencontré une condition inattendue qui l'a empêché de traiter la requête. Cette erreur est généralement renvoyée par le serveur lorsqu'aucun autre code d'erreur n'est approprié.

Messages d'erreur

L'application cliente reçoit le code de réponse suivant : 

HTTP/1.1 500 Internal Server Error

De plus, vous pouvez observer un message d'erreur semblable à celui présenté ci-dessous :

Exemple 1

Exemple de réponse du serveur backend 1

{"errorMessage":"Sorry either your e-mail or password didn't match.",
"errorParameters":"{}",
"errorCode":"500",
"errorKey":"INVALID_EMAILPASSWORD"}

Exemple 2

Exemple de réponse du serveur backend 2

<Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
   <Body>
      <Error>
         <code>500</code>
         <message xml:lang="en-US">Not Authorised(e4138fa0-ec57).</message>
      </Error>
   </Body>
</Envelope>

Causes possibles

L'500 Internal Server Error peut être renvoyée par le serveur backend pour plusieurs raisons. Ce guide explique comment résoudre ce problème en suivant des étapes courantes, quelle que soit sa cause.

Les causes possibles de ce problème sont les suivantes :

Cause Description Instructions de dépannage applicables
Erreur dans le serveur backend Le serveur backend peut échouer pour une raison quelconque. Utilisateurs d'Edge Private Cloud et Public Cloud

Étapes de diagnostic courantes

Utilisez l'un des outils/techniques suivants pour diagnostiquer cette erreur :

Surveillance des API

Procédure 1 : Utiliser la surveillance des API

Pour diagnostiquer l'erreur à l'aide de la surveillance des API :

  1. Connectez-vous à l'interface utilisateur Apigee Edge en tant qu'utilisateur disposant d'un rôle approprié.

  2. Basculez vers l'organisation dans laquelle vous souhaitez examiner le problème.

  3. Accédez à la page Analyze > API Monitoring > Investigate (Analyser > Surveillance des API > Examiner).
  4. Sélectionnez la période spécifique au cours de laquelle vous avez observé les erreurs.

  5. Tracez le code d'erreur par rapport à l'heure.

  6. Sélectionnez une cellule contenant le code d'erreur messaging.adaptors.http.flow.ErrorResponseCode comme illustré ci-dessous :

    ( Agrandir l'image)

  7. Les informations sur le code d'erreur messaging.adaptors.http.flow.ErrorResponseCode s'affichent comme suit :

    ( Agrandir l'image)

  8. Cliquez sur View logs (Afficher les journaux), puis développez la ligne de la requête ayant échoué.

    ( Agrandir l'image)

  9. Dans la fenêtre Logs (Journaux), notez les informations suivantes :
    • ID du message de requête
    • Code d'état : 500
    • Source de l'erreur : target
    • Code d'erreur : messaging.adaptors.http.flow.ErrorResponseCode

Trace

Procédure 2 : Utiliser l'outil Trace

Pour diagnostiquer l'erreur à l'aide de l'outil Trace :

  1. Activez la session de trace et
    • attendez que l'erreur 500 Internal Server Error avec le code d'erreur messaging.adaptors.http.flow.ErrorResponseCode se produise, ou
    • si vous pouvez reproduire le problème, effectuez l'appel d'API pour reproduire le problème 500 Internal Server Error

  2. Assurez-vous que l'option Show all FlowInfos (Afficher toutes les informations de flux) est activée :

  3. Sélectionnez l'une des requêtes ayant échoué et examinez la trace.
  4. Parcourez les différentes phases de la trace et identifiez l'endroit où l'échec s'est produit.

  5. L'erreur se trouve généralement dans un flux après la phase Response received from target server (Réponse reçue du serveur cible), comme illustré ci-dessous :

    ( Agrandir l'image)

  6. Accédez à la phase AX (Données d'analyse enregistrées) de la trace, puis cliquez dessus.

  7. Faites défiler la page jusqu'à la section Phase Details Response Headers (En-têtes de réponse des détails de la phase), puis déterminez les valeurs de X-Apigee-fault-code , X-Apigee-fault-source et X-Apigee-Message-ID , comme illustré ci-dessous :

    ( Agrandir l'image)

  8. Notez les valeurs de X-Apigee-fault-code, X-Apigee-fault-source, et X-Apigee-Message-ID :
    9. En-têtes de réponse Valeur
    X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode
    X-Apigee-fault-source target
    X-Apigee-Message-ID MESSAGE_ID

NGINX

Procédure 3 : Utiliser les journaux d'accès NGINX

Pour diagnostiquer l'erreur à l'aide des journaux d'accès NGINX :

  1. Si vous êtes un utilisateur de Private Cloud, vous pouvez utiliser les journaux d'accès NGINX pour déterminer les informations clés sur l'erreur HTTP 500 Internal Server Error.

  2. Consultez les journaux d'accès NGINX :

    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

  3. Recherchez les erreurs 500 avec le code d'erreur messaging.adaptors.http.flow.ErrorResponseCode pendant une durée spécifique (si le problème s'est produit dans le passé) ou si des requêtes échouent toujours avec 500.

  4. Si vous trouvez des erreurs 500 avec le X-Apigee-fault-code correspondant à la valeur messaging.adaptors.http.flow.ErrorResponseCode, déterminez la valeur de X-Apigee-fault-source.

    Exemple d'erreur 500 dans le journal d'accès NGINX :

    ( Agrandir l'image)

    L'entrée d'exemple ci-dessus du journal d'accès NGINX comporte les valeurs suivantes pour X-Apigee-fault-code et X-Apigee-fault-source :

    En-têtes Valeur
    X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode
    X-Apigee-fault-source target

Cause : erreur dans le serveur backend

Diagnostic

L'500 Internal Server Error renvoyée par le serveur backend peut être due à plusieurs raisons. Vous devrez diagnostiquer chaque situation indépendamment.

  1. Déterminez le code d'erreur et la source de l'erreur pour l'erreur observée à l'aide de la surveillance des API, de l'outil Trace ou des journaux d'accès NGINX, comme expliqué dans la section Étapes de diagnostic courantes.
  2. Si la source de l'erreur est target et que le code d'erreur est messaging.adaptors.http.flow.ErrorResponseCode, cela indique que l'erreur est renvoyée par le serveur backend.
  3. Vous pouvez suivre l'une des étapes suivantes pour diagnostiquer la cause du problème :

    Trace

    Utiliser Trace :

    Si vous disposez d'une session de trace pour l'échec, procédez comme suit :

    1. Dans la trace, sélectionnez la requête d'API qui a échoué avec 500 Internal Server Error.

    2. Sélectionnez la phase Response received from target server (Réponse reçue du serveur cible) de la requête d'API ayant échoué comme illustré dans la figure ci-dessous :

      ( Agrandir l'image)

    3. Faites défiler la page jusqu'à la section Phase Details (Détails de la phase), puis vérifiez le contenu de la réponse, qui contient la réponse du serveur backend.

      Exemple de contenu de réponse :

      <Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
   <Body>
      <Error>
         <code>500</code>
         <message xml:lang="en-US">Not Authorised(e4138fa0-ec57).</message>
      </Error>
   </Body>
</Envelope>

      Dans la réponse ci-dessus, notez que le message d'erreur du serveur backend est Non autorisé. Cela indique que l'utilisateur a peut-être transmis des identifiants non valides et que c'est pourquoi il reçoit cette erreur.

    Appeler le serveur backend

    Effectuer un appel direct au serveur backend :

    Vous pouvez effectuer un appel direct au serveur backend et :

    • vérifier si vous obtenez la même 500 Internal Server Error réponse que celle reçue lorsque la requête a été effectuée via Apigee Edge ;
    • vérifier le message d'erreur (réponse) reçu du serveur backend.

    Pour effectuer l'appel direct au serveur backend, procédez comme suit :

    1. Assurez-vous de disposer de tous les en-têtes, paramètres de requête et identifiants requis qui doivent être transmis au serveur backend dans le cadre de la requête.
    2. Si le service de backend est accessible publiquement, vous pouvez utiliser la curl commande, 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 la commande curl, Postman ou tout autre client REST, et appeler directement l'API du serveur backend à partir du processeur de messages.

    4. Vérifiez si le service de backend renvoie bien 500 Internal Server Error, puis examinez le message d'erreur (réponse) renvoyé par le serveur backend et déterminez la cause de cette erreur.

    Journaux du serveur backend

    Utiliser les journaux du serveur backend

    1. Consultez les journaux du serveur backend et essayez d'obtenir plus de détails sur l'erreur et sa cause.
    2. Si possible, activez le mode débogage sur le serveur backend pour obtenir plus de détails sur l'erreur et sa cause.

  4. Vérifiez si vous utilisez le chaînage de proxy dans le point de terminaison cible spécifique du proxy d'API défaillant, c'est-à-dire si le serveur cible/point de terminaison cible appelle un autre proxy dans Apigee Edge. Pour le déterminer :

    1. Si vous disposez de la trace de la requête ayant échoué, accédez à la phase Request sent to target server (Requête envoyée au serveur cible), puis cliquez sur Show Curl (Afficher Curl).

    2. La fenêtre Curl for Request Sent to Target Server (Curl pour la requête envoyée au serveur cible) s'ouvre. Vous pouvez y déterminer l'alias d'hôte du serveur cible.
    3. Examinez le point de terminaison cible de votre proxy d'API et vérifiez si l'URL du serveur backend ou le nom d'hôte du serveur cible pointe vers un autre proxy ou vers votre propre serveur backend.
    4. 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 chaîné jusqu'à ce que vous déterminiez la cause réelle de la 500 Internal Server Error. Dans ces cas, 500 Internal Server Error peut se produire dans d'autres proxys chaînés à d'autres étapes, qui peuvent être diagnostiqués et résolus à l'aide des instructions fournies dans ce guide ou dans le guide 500 Erreur interne du serveur.
    5. Si l'alias d'hôte du serveur cible pointe vers votre serveur backend, passez à la section Solution.

Solution

S'il est établi que l'erreur 500 provient du serveur backend, alors collaborez avec votre équipe de serveur backend pour résoudre le problème de manière appropriée.

Dans l'exemple ci-dessus, vous devrez peut-être demander aux utilisateurs de transmettre des identifiants valides pour résoudre ce problème.

Points importants à retenir

  1. Le message d'erreur réel renvoyé par le serveur backend pour 500 Internal Server Error ne peut être affiché que si vous avez capturé la session de trace pour les requêtes ayant échoué.
  2. La réponse du serveur backend ne sera pas enregistrée dans la surveillance des API, les journaux d'accès NGINX ni les journaux du processeur de messages pour des raisons de sécurité.
  3. Vous pouvez consulter les journaux du serveur backend ou activer le mode débogage sur le backend pour obtenir plus de détails sur le 500 Internal Server Error et/ou afficher le message d'erreur renvoyé par le serveur backend.

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 et contactez l'assistance Apigee Edge.

Si vous êtes un utilisateur de Public Cloud, fournissez les informations suivantes :

  • Nom de l'organisation
  • Nom de l'environnement
  • Nom du proxy d'API
  • Commande curl complète pour reproduire l'erreur 500
  • Fichier de trace contenant les requêtes avec 500 Internal Server Error
  • Si les erreurs 500 ne se produisent pas actuellement, indiquez la période avec les informations de fuseau horaire au cours de laquelle les erreurs 500 se sont produites dans le passé.

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

  • Message d'erreur complet observé pour les requêtes ayant échoué
  • Nom de l'organisation, de l'environnement et du proxy d'API pour lesquels vous observez 500 erreurs
  • Bundle de proxy d'API
  • Fichier de trace contenant les requêtes avec 500 Internal Server Error
  • Journaux d'accès NGINX /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

    Où : ORG, ENV, et PORT# sont remplacés par des valeurs réelles.

  • Journaux système du processeur de messages /opt/apigee/var/log/edge-message-processor/logs/system.log
  • Période avec les informations de fuseau horaire au cours de laquelle les erreurs 500 se sont produites.