Erreur de serveur interne 500 – Serveur backend

<ph type="x-smartling-placeholder"></ph> Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur Apigee X. En savoir plus

Vidéos

Vidéo Description
Erreur interne du serveur 500 - causée par le backend Cet exemple de code montre une erreur 500 Internal Server Error en temps réel causée par le serveur backend, ainsi que la procédure à suivre pour dépanner et résoudre l'erreur.

Symptôme

L'application cliente reçoit le 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 rencontré une condition inattendue qui l'a empêché de répondre à la demande. Cette erreur est généralement renvoyés 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 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>
<ph type="x-smartling-placeholder">

Causes possibles

Le message 500 Internal Server Error a pu être renvoyé par le serveur backend en raison d'une erreur un certain nombre de causes. Ce playbook explique comment résoudre le problème à l'aide 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 sur le serveur backend Le serveur backend peut tomber en panne pour une raison quelconque. Utilisateurs de cloud privé et public Edge

Étapes de diagnostic courantes

Utilisez l'une des techniques ou l'un des outils suivants pour diagnostiquer ce problème:

Surveillance des API

Procédure n° 1: Utiliser la surveillance des API

<ph type="x-smartling-placeholder">

Pour diagnostiquer l'erreur à l'aide de l'API Monitoring, procédez comme suit:

  1. <ph type="x-smartling-placeholder"></ph> Connectez-vous à l'interface utilisateur d'Apigee Edge en tant qu'utilisateur disposant d'un rôle approprié.

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

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

  5. Représentez le code d'erreur par rapport à l'heure.

    <ph type="x-smartling-placeholder">

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

    ( Agrandir l'image)

  7. Informations sur le code d'erreur messaging.adaptors.http.flow.ErrorResponseCode s'affiche sous la forme comme indiqué ci-dessous:

    ( Agrandir l'image)

  8. Cliquez sur Afficher les journaux et développez la ligne correspondant à la requête ayant échoué.

    ( Agrandir l'image)

  9. Dans la fenêtre Journaux, notez les détails suivants: <ph type="x-smartling-placeholder">
      </ph>
    • Demander un ID de message
    • Code d'état:500
    • Source de l'erreur:target
    • Code d'erreur: messaging.adaptors.http.flow.ErrorResponseCode

Trace

Procédure n° 2: Utiliser l'outil Trace

<ph type="x-smartling-placeholder">

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

  1. Activez la session de trace, puis <ph type="x-smartling-placeholder">
      </ph>
    • Attendez l'erreur 500 Internal Server Error avec le code d'erreur messaging.adaptors.http.flow.ErrorResponseCode ne doit pas avoir lieu, 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 toutes les informations 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. Vous trouverez l'erreur généralement dans un flux après la réponse reçue du serveur cible. comme indiqué ci-dessous:

    ( Agrandir l'image)

  6. Accédez à la phase AX (Données analytiques enregistrées) dans 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) et déterminez les valeurs de X-Apigee-fault-code et X-Apigee-fault-source, et X-Apigee-Message-ID, comme indiqué 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 n° 3: Utiliser les journaux d'accès NGINX

<ph type="x-smartling-placeholder">

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

  1. Si vous êtes un utilisateur Private Cloud, 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

    <ph type="x-smartling-placeholder">
  3. Effectuez une recherche pour voir s'il existe des erreurs 500 avec un code d'erreur messaging.adaptors.http.flow.ErrorResponseCode pendant une durée spécifique (si le problème est survenu pendant ou si des requêtes échouent toujours avec 500.

  4. Si vous trouvez des erreurs 500 avec la correspondance X-Apigee-fault-code la valeur de messaging.adaptors.http.flow.ErrorResponseCode, puis déterminer la valeur de X-Apigee-fault-source..

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

    ( Agrandir l'image)

    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 être en raison d'un certain nombre de raisons. Vous devrez diagnostiquer chaque situation indépendamment.

  1. Déterminez le code d'erreur, source de l'erreur pour l'erreur observée à l'aide de l'API Monitoring, l'outil Trace ou les 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 indique que l'erreur est renvoyée par le serveur backend.
  3. Pour identifier la cause du problème, procédez de l'une des manières suivantes:

    Trace

    Utiliser Trace:

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

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

    2. Sélectionnez la phase Response received from target server (Réponse du serveur cible) dans le champ en échec, 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) et cochez la case Le contenu de la réponse,qui contient la réponse du serveur backend.

      Exemple de contenu de la 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 erreurs à l'aide d'identifiants de connexion.

    <ph type="x-smartling-placeholder">

    Appeler le serveur backend

    Effectuer un appel direct au serveur backend:

    Vous pouvez effectuer un appel direct vers le serveur backend et:

    • Vérifiez si vous obtenez le même 500 Internal Server Error Réponse 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 effectuer l'appel direct vers le serveur backend, procédez comme suit:

    1. Assurez-vous de disposer de tous les en-têtes et paramètres de requête requis, ainsi que 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 curl, Postman ou tout autre client REST, puis appelez l'API du serveur backend.

    3. Si le serveur backend n'est accessible qu'à partir des processeurs de messages, vous pouvez utilisez la commande curl, Postman ou tout autre client REST, et appelez la méthode l'API du serveur backend directement à partir du processeur de messages.

      <ph type="x-smartling-placeholder">
    4. Vérifiez si le service de backend renvoie effectivement 500 Internal Server Error et vérifiez le message d'erreur (réponse) renvoyé par le serveur backend. déterminer la cause de cette erreur.

    Journaux du serveur backend

    Utiliser les journaux du serveur backend

    1. Examinez les journaux du serveur backend et essayez d'en savoir plus sur l'erreur. 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 <ph type="x-smartling-placeholder"></ph> un chaînage de proxy dans le point de terminaison cible spécifique du proxy d'API en échec c'est-à-dire, si le serveur/point de terminaison cible appelle un autre proxy dans Apigee Edge. Pour déterminer cela:

    1. Si vous disposez de la trace de la requête ayant échoué, accédez à la section Request sent à la phase du serveur cible, puis cliquez sur Show Curl (Afficher le curl).

    2. La fenêtre Curl for Request Sent to Target Server (Curl pour la requête envoyée au serveur cible) qui s'ouvre, peut déterminer l'alias hôte du serveur cible.
    3. Examinez le point de terminaison cible de votre proxy d'API et vérifiez si le serveur backend L'URL ou le nom d'hôte sur le serveur cible pointe vers un autre proxy ou vers le vôtre à votre serveur backend.
    4. Si l'alias hôte du serveur cible pointe vers un alias d'hôte virtuel, il est le chaînage de proxy. Dans ce cas, vous devez répéter toutes les étapes ci-dessus pour la jusqu'à ce que vous déterminiez la cause réelle de l'500 Internal Server Error. Dans ce cas, 500 Internal Server Error peut se produire dans d’autres proxies en chaîne à d’autres étapes également qui peuvent être diagnostiquées et résolu en suivant les instructions fournies dans ce guide ou dans le Playbook 500 sur les erreurs internes du serveur.
    5. Si l'alias d'hôte du serveur cible pointe vers votre serveur backend, accédez à Résolution.

Solution

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

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

Points clés à noter

  1. Le message d'erreur réel renvoyé par le serveur backend pour 500 Internal Server Error n'est visible que si vous avez capturé la session de trace pour l'activité défaillante. requêtes.
  2. La réponse du serveur backend ne sera pas enregistrée dans la surveillance des API, les journaux d'accès NGINX ou 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 des détails 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 alors que vous avez suivi les instructions ci-dessus, rassemblez les informations suivantes : les informations de diagnostic et contactez l'assistance Apigee Edge.

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 500.
  • Fichier de suivi contenant les requêtes avec 500 Internal Server Error
  • Si les erreurs 500 ne se produisent pas actuellement, indiquez l'heure période avec les informations de fuseau horaire lorsque des erreurs 500 se sont produites dans le passé.

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

  • Message d'erreur complet observé pour les requêtes en échec
  • Nom de l'organisation, de l'environnement et du proxy d'API que vous observez 500 erreur
  • 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ées 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.