Erreur de serveur interne 500 – Serveur backend

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

Vidéos

Vidéo Description
500 Erreur interne du serveur : cause du backend Montre un 500 Internal Server Error en temps réel causé par le serveur backend, ainsi que les étapes à suivre pour résoudre l'erreur.

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 ne convient.

Messages d'erreur

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

HTTP/1.1 500 Internal Server Error

En outre, un message d'erreur semblable à celui présenté ci-dessous peut s'afficher:

Exemple 1

Exemple de réponse n° 1 du serveur backend

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

Exemple 2

Exemple de réponse n° 2 du serveur backend

<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

Le 500 Internal Server Error peut être renvoyé par le serveur backend pour plusieurs raisons. Ce playbook explique comment résoudre ces erreurs en suivant les étapes courantes et quelle qu'en soit la cause.

Voici les causes possibles de ce problème:

Cause Description Instructions de dépannage applicables
Erreur sur le serveur backend Le serveur backend peut échouer pour une raison quelconque. Utilisateurs de cloud privé et public Edge

Étapes de diagnostic courantes

Utilisez l'un des outils ou 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 du rôle approprié.

  2. Accédez à l'organisation dans laquelle vous souhaitez examiner le problème.

  3. Accédez à la page Analyze > API Monitoring > Investigate (Analyser > Surveillance des API > Enquêter).
  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 indiqué ci-dessous:

    ( Afficher l'image plus grande)

  7. Les informations sur le code d'erreur messaging.adaptors.http.flow.ErrorResponseCode s'affichent comme indiqué ci-dessous:

    ( Afficher l'image plus grande)

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

    ( Afficher l'image plus grande)

  9. Dans la fenêtre Journaux, notez les détails suivants :
    • 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, puis effectuez l'une des opérations suivantes :
    • 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 le reproduire. 500 Internal Server Error

  2. Assurez-vous que l'option Show all FlowInfos (Afficher tous les FlowInfos) 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 localisez l'origine de l'échec.

  5. L'erreur se produit généralement dans un flux après la phase Réponse reçue du serveur cible, comme indiqué ci-dessous:

    ( Afficher l'image plus grande)

  6. Accédez à la phase AX (Données analytiques enregistrées) dans la trace et cliquez dessus.

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

    ( Afficher l'image plus grande)

  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 n° 3: Utiliser les journaux d'accès NGINX

Pour diagnostiquer l'erreur à l'aide des journaux d'accès NGINX, procédez comme suit:

  1. Si vous êtes un utilisateur du cloud privé, vous pouvez utiliser les journaux d'accès NGINX pour déterminer les informations clés concernant HTTP 500 Internal Server Error.

  2. Vérifiez les journaux d'accès NGINX:

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

  3. Recherchez s'il existe des 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 par 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 de X-Apigee-fault-code , déterminez la valeur de la source X-Apigee-fault-code .

    Exemple d'erreur 500 du journal d'accès NGINX:

    ( Afficher l'image plus grande)

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

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

Cause: erreur sur le serveur backend

Diagnostic

La réponse 500 Internal Server Error du serveur backend peut avoir plusieurs causes. Vous devrez diagnostiquer chaque situation indépendamment.

  1. Déterminez le code d'erreur, la source de l'erreur de l'erreur observée à l'aide de la surveillance d'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 d'erreur est target et que le code d'erreur est messaging.adaptors.http.flow.ErrorResponseCode, cela signifie que l'erreur est renvoyée par le serveur backend.
  3. Vous pouvez suivre l'une des procédures ci-dessous pour déterminer la cause du problème:

    Trace

    Utiliser Trace:

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

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

    2. Sélectionnez la phase Réponse reçue du serveur cible à partir de la requête API ayant échoué, comme illustré dans la figure ci-dessous:

      ( Afficher l'image plus grande)

    3. Faites défiler la page vers le bas jusqu'à la section Phase Details (Détails de la phase) et vérifiez le champ Response Content (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 Not Allowed (Non autorisé). Cela indique que l'utilisateur a peut-être transmis des identifiants non valides, ce qui explique pourquoi il reçoit cette erreur.

    Appeler le serveur backend

    Effectuer un appel direct au serveur backend:

    Vous pouvez appeler directement le serveur backend et:

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

    Pour appeler directement le serveur backend, procédez comme suit:

    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, puis 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 si le service de backend renvoie effectivement l'erreur 500 Internal Server Error, puis vérifiez 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, puis essayez d'obtenir plus d'informations sur l'erreur et sa cause.
    2. Si possible, activez le mode débogage sur le serveur backend pour en savoir plus sur l'erreur et sa cause.

  4. Vérifiez si vous utilisez un chaînage de proxy dans le point de terminaison cible spécifique du proxy d'API défaillant, c'est-à-dire si le serveur/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 en échec, accédez à la phase Request sent to target server (Requête envoyée au serveur cible), puis cliquez sur Show Curl (Afficher l'URL).

    2. La fenêtre Curl for Request Sent to Target Server (Curl de la requête envoyée au serveur cible) s'ouvre. Elle vous permet de déterminer l'alias de l'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 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 en chaîne jusqu'à ce que vous déterminiez la cause effective de l'erreur 500 Internal Server Error. Dans ce cas, 500 Internal Server Error peut se produire dans d'autres proxys en chaîne à d'autres étapes, qui peuvent être diagnostiqués et résolus à l'aide des instructions fournies dans ce playbook ou dans le playbook 500 sur les erreurs internes du serveur.
    5. Si l'alias de l'hôte du serveur cible pointe vers votre serveur backend, passez à la section Résolution.

Résolution

S'il est certain que l'erreur 500 provient du serveur backend, collaborez avec l'équipe du serveur backend pour résoudre le problème en conséquence.

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

Points clés à noter

  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. Pour des raisons de sécurité, la réponse du serveur backend n'est pas consignée dans les journaux de surveillance des API, les journaux d'accès NGINX ou les journaux du processeur de messages.
  3. Vous pouvez consulter les journaux du serveur backend ou activer le mode débogage sur le backend pour obtenir plus d'informations sur 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 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 500.
  • Fichier de suivi contenant les requêtes avec 500 Internal Server Error
  • Si les erreurs 500 ne se produisent pas actuellement, indiquez la période avec le fuseau horaire lorsque des erreurs 500 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 de l'API pour lesquels vous observez des erreurs 500
  • Groupe de proxys d'API
  • Fichier de suivi 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 contenant le fuseau horaire au moment où les erreurs 500 se sont produites.