500 Erreur interne au serveur

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

Vidéos

Regardez les vidéos suivantes pour en savoir plus sur la résolution des erreurs 500 internes du serveur.

Vidéo Description
Introduction Cette page présente les erreurs internes du serveur 500 et les causes possibles. Affiche également une erreur de serveur interne 500 en temps réel, ainsi que les étapes à suivre pour résoudre l'erreur.
Gérer les erreurs d'appel de service et d'extraction de variable Cet exemple de code montre deux erreurs 500 internes du serveur causées par les stratégies d'appel de service et d'extraction de variable, et montre comment dépanner et résoudre ces erreurs.
Gérer les erreurs liées aux règles JavaScript Affiche une erreur interne du serveur 500 causée par une règle JavaScript, ainsi que la procédure à suivre pour résoudre cette erreur.
Gérer les défaillances des serveurs backend Affiche l'exemple 500 d'erreurs internes au serveur causées par une défaillance du serveur backend, ainsi que les étapes à suivre pour résoudre ces erreurs.

Problème constaté

L'application cliente reçoit un code d'état HTTP 500 et, en réponse aux appels d'API, le message "Internal Server Error". L'erreur interne du serveur 500 peut être causée par une erreur lors de l'exécution de toute stratégie dans Edge ou par une erreur sur le serveur cible/backend.

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

Le message d'erreur suivant peut s'afficher:

HTTP/1.1 500 Internal Server Error

Dans certains cas, un autre message d'erreur contenant plus de détails peut s'afficher. Voici un exemple de message d'erreur:

{
   "fault":{
      "detail":{
         "errorcode":"steps.servicecallout.ExecutionFailed"
      },
      "faultstring":"Execution of ServiceCallout callWCSAuthServiceCallout failed. Reason: ResponseCode 400 is treated as error"
   }
}

Causes possibles :

L'erreur interne du serveur 500 peut être générée pour différentes causes. Dans Edge, les causes peuvent être classées en deux catégories principales en fonction de l'endroit où l'erreur s'est produite:

Cause Détails Nous fournissons des étapes de dépannage détaillées
Erreur d'exécution dans une stratégie périphérique Une stratégie dans le proxy d'API peut échouer pour une raison quelconque. Utilisateurs de cloud privé et public Edge
Erreur sur le serveur backend Le serveur backend peut échouer pour une raison quelconque. Utilisateurs de cloud privé et public Edge

Erreur d'exécution dans une stratégie périphérique

Une stratégie dans le proxy d'API peut échouer pour une raison quelconque. Cette section explique comment résoudre le problème si l'erreur interne du serveur 500 se produit pendant l'exécution d'une stratégie.

Diagnostic

Étapes de diagnostic pour les utilisateurs de clouds privés et publics

Si vous disposez de la session d'UI Trace pour l'erreur, procédez comme suit:

  1. Vérifiez que l'erreur a été causée par l'exécution d'une stratégie. Pour en savoir plus, consultez la section Déterminer la source du problème.
  2. Si l'erreur s'est produite lors de l'exécution de la stratégie, continuez. Si l'erreur est causée par le serveur backend, consultez la section Erreur sur le serveur backend.
  3. Sélectionnez la requête API qui échoue avec l'erreur 500 (Erreur interne du serveur) dans la trace.
  4. Examinez la requête et sélectionnez la stratégie spécifique qui a échoué ou le flux nommé "Error" (Erreur) qui suit immédiatement la stratégie ayant échoué dans la trace.
  5. Pour en savoir plus sur l'erreur, consultez le champ "error" dans la section "Properties" (Propriétés) ou le contenu de l'erreur.
  6. À l'aide des informations que vous avez collectées sur l'erreur, essayez d'en déterminer la cause.

Étapes de diagnostic pour les utilisateurs de Private Cloud uniquement

Si vous ne disposez pas de la session d'UI Trace, procédez comme suit:

  1. Vérifiez que l'erreur s'est produite lors de l'exécution d'une stratégie. Pour en savoir plus, consultez la section Déterminer la source du problème.
  2. Si l'erreur a été causée par l'exécution de la stratégie, continuez. Si l'erreur s'est produite lors de l'exécution de la stratégie, continuez. Si l'erreur est causée par le serveur backend, consultez la section Erreur sur le serveur backend.
  3. Utilisez les journaux d'accès NGINX comme expliqué dans la section Déterminer la source du problème pour déterminer la règle ayant échoué dans le proxy d'API, ainsi que l'ID du message de requête unique.
  4. Consultez les journaux du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log) et recherchez-y l'ID unique du message de requête.
  5. Si vous trouvez l'ID unique du message de requête, essayez d'obtenir plus d'informations sur la cause de l'échec.

Résolution

Si vous avez déterminé la cause du problème avec la stratégie, essayez de le corriger en corrigeant la stratégie et en redéployant le proxy.

Les exemples suivants montrent comment déterminer la cause et comment résoudre différents types de problèmes.

Si vous avez besoin d'une aide supplémentaire pour dépanner l'erreur interne du serveur 500 ou si vous pensez qu'il s'agit d'un problème dans Edge, contactez l'assistance Apigee.

Exemple 1: Échec de la stratégie d'appel de service en raison d'une erreur sur le serveur backend

Si l'appel au serveur backend échoue dans la stratégie d'appel de service avec une erreur telle que 4XX ou 5XX, il est considéré comme une erreur interne du serveur 500.

  1. Voici un exemple de défaillance du service de backend avec une erreur 404 dans la stratégie d'appel de service. Le message d'erreur suivant est envoyé à l'utilisateur final : 
    {
"fault":
     { "detail":
           { "errorcode":"steps.servicecallout.ExecutionFailed"
           },"faultstring":"Execution of ServiceCallout service_callout_v3_store_by_lat_lon
 failed. Reason: ResponseCode 404 is treated as error"
          }
     }
}
  2. La session d'UI Trace suivante affiche le code d'état 500 causé par une erreur dans la règle d'appel de service:

  3. Dans cet exemple, la propriété "error" indique le motif de l'échec de la stratégie d'appel de service comme suit : "ResponseCode 404 is acheminé as error. Cette erreur peut se produire si la ressource accessible via l'URL du serveur backend dans la règle d'appel de service n'est pas disponible.
  4. Vérifiez la disponibilité de la ressource sur le serveur backend. Il se peut qu'elle ne soit pas disponible temporairement ou définitivement, ou qu'elle ait été déplacée vers un autre emplacement.

Résolution de l'exemple 1

  1. Vérifiez la disponibilité de la ressource sur le serveur backend. Il se peut qu'elle ne soit pas disponible temporairement ou définitivement, ou qu'elle ait été déplacée vers un autre emplacement.
  2. Corrigez l'URL du serveur backend dans la règle d'appel de service pour qu'elle pointe vers une ressource valide et existante.
  3. Si la ressource n'est que temporairement indisponible, essayez d'envoyer la requête API une fois la ressource disponible.

Exemple 2: Échec de la règle d'extraction des variables

Étudions maintenant un autre exemple, où l'erreur interne du serveur 500 est causée par une erreur dans la stratégie Extraire les variables, et voyons comment résoudre le problème.

  1. La trace suivante dans la session d'interface utilisateur affiche le code d'état 500 en raison d'une erreur dans la règle Extraire les variables:

  2. Sélectionnez la règle Extract Variables qui ne fonctionne pas, faites défiler la page vers le bas et consultez la section Error Content (Contenu d'erreur) pour en savoir plus:

  3. Le contenu de l'erreur indique que la variable "serviceCallout.oamCookieValidationResponse" n'est pas disponible dans la stratégie d'extraction des variables. Comme indiqué par le nom de la variable, elle doit contenir la réponse de la stratégie d'appel de service précédente.
  4. Sélectionnez la stratégie d'appel de service dans la trace. Il est possible que vous constatiez que la variable "serviceCallout.oamCookieValidationResponse" n'a pas été définie. Cela indique que l'appel au service de backend a échoué, ce qui génère une variable de réponse vide.
  5. Bien que la règle d'appel de service n'ait pas abouti, leur exécution se poursuit, car l'indicateur "continueOnError" de cette règle est défini sur "true", comme indiqué ci-dessous:

    <ServiceCallout async="false" continueOnError="true" enabled="true" name="Callout.OamCookieValidation">
  <DisplayName>Callout.OamCookieValidation</DisplayName>
  <Properties />
  <Request clearPayload="true" variable="serviceCallout.oamCookieValidationRequest">
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  </Request>
  <Response>serviceCallout.oamCookieValidationResponse</Response>
  <HTTPTargetConnection>
    <Properties />
    <URL>http://{Url}</URL>
  </HTTPTargetConnection>
</ServiceCallout>
  6. Notez l'ID de message unique "X-Apigee.Message-ID" pour cette requête API spécifique à partir de la trace, comme suit :
    1. Sélectionnez la phase "Données Analytics enregistrées" dans la demande.
    2. Faites défiler la page vers le bas et notez la valeur de X-Apigee.Message-ID.

  7. Affichez le journal du processeur de messages (/opt/apigee/var/log/edge-message-processor/system.log) et recherchez l'ID de message unique noté à l'étape 6. Le message d'erreur suivant a été observé pour la requête API spécifique : 
    2017-05-05 07:48:18,653 org:myorg env:prod api:myapi rev:834 messageid:rrt-04984fed9e5ad3551-c-wo-32168-77563  NIOThread@5 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[C:]@149081 useCount=1 bytesRead=0 bytesWritten=0 age=3002ms lastIO=3002ms .onConnectTimeout connectAddress=mybackend.domain.com/XX.XX.XX.XX:443 resolvedAddress=mybackend.domain.com/XX.XX.XX.XX

    L'erreur ci-dessus indique que la règle d'appel de service a échoué en raison d'une erreur de délai avant expiration de la connexion lors de la connexion au serveur backend.

  8. Pour déterminer la cause de l'erreur d'expiration de la connexion, il a exécuté la commande telnet sur le serveur backend à partir du ou des processeurs de messages. La commande telnet a renvoyé l'erreur "Connection timed out" (Expiration du délai de connexion), comme indiqué ci-dessous : 
    telnet mybackend.domain.com 443
Trying XX.XX.XX.XX...
telnet: connect to address XX.XX.XX.XX: Connection timed out

    En règle générale, cette erreur se produit dans les cas suivants:

    • Lorsque le serveur backend n'est pas configuré pour autoriser le trafic provenant des processeurs de messages Edge.
    • Si le serveur backend n'écoute pas sur le port spécifique.

    Dans l'exemple illustré ci-dessus, bien que la règle Extract Variables ait échoué, la cause réelle était que Edge n'était pas parvenu à se connecter au serveur backend dans la règle d'appel de service. La cause de cet échec était que le serveur final backend n'était pas configuré pour autoriser le trafic provenant des processeurs de messages Edge.

    Votre propre règle d'extraction des variables se comportera différemment et pourra échouer pour une raison différente. Pour résoudre le problème de manière appropriée en fonction de la cause de l'échec de votre règle Extract Variables, consultez le message dans la propriété error.

Résolution de l'exemple 2

  1. Corrigez correctement la cause d'erreur ou d'échec dans la stratégie Extraire les variables.
  2. Dans l'exemple illustré ci-dessus, la solution consistait à rectifier la configuration réseau pour autoriser le trafic provenant des processeurs de messages Edge vers votre serveur backend. Pour ce faire, il a ajouté les adresses IP des processeurs de messages à la liste d'autorisation sur le serveur backend spécifique. Par exemple, sous Linux, vous pouvez utiliser iptables pour autoriser le trafic provenant des adresses IP du processeur de messages sur le serveur backend.

Exemple 3: Échec de la règle JavaCallout

Examinons maintenant un autre exemple dans lequel l'erreur interne du serveur 500 est causée par une erreur dans la stratégie d'appel Java. Voyons comment résoudre le problème.

  1. La trace de l'interface utilisateur suivante affiche le code d'état 500 en raison d'une erreur dans la stratégie d'appel Java:

  2. Sélectionnez le flux nommé "Error" (Erreur) suivi de la stratégie d'appel Java ayant échoué pour obtenir les détails de l'erreur, comme illustré dans la figure ci-dessous:

  3. Dans cet exemple, la propriété "error" de la section "Properties" (Propriétés) révèle que l'échec est dû à l'utilisation d'un mot de passe expiré lors de la connexion à la base de données Oracle à partir de la stratégie JavaCallout. Votre propre accroche Java se comportera différemment et remplira un message différent dans la propriété error.
  4. Vérifiez le code de la règle JavaCallout et confirmez la configuration correcte à utiliser.

Résolution de l'exemple 3

Corrigez le code d'accroche ou la configuration Java de manière appropriée pour éviter l'exception d'exécution. Dans l'exemple d'échec d'appel Java illustré ci-dessus, il est nécessaire d'utiliser le mot de passe approprié pour se connecter à la base de données Oracle afin de résoudre le problème.

Erreur sur le serveur backend

Une erreur interne du serveur 500 peut également provenir du serveur backend. Cette section explique comment résoudre le problème si l'erreur provient du serveur backend.

Diagnostic

Procédure de diagnostic pour tous les utilisateurs

La cause des autres erreurs de backend peut varier considérablement. Vous devrez diagnostiquer chaque situation indépendamment.

  1. Vérifiez que l'erreur a été causée par le serveur backend. Pour en savoir plus, consultez la section Déterminer la source du problème.
  2. Si l'erreur a été causée par le serveur backend, continuez. Si l'erreur s'est produite lors de l'exécution de la stratégie, accédez à Erreur d'exécution dans la stratégie périphérique.
  3. Suivez les étapes ci-dessous selon que vous avez ou non accès à une session Trace pour l'API ayant échoué, ou selon que le backend est un serveur Node.js:

Si vous n'avez pas de session Trace pour l'appel d'API ayant échoué:

  1. Si la trace de l'interface utilisateur n'est pas disponible pour la requête en échec, consultez les journaux du serveur backend pour obtenir des informations sur l'erreur.
  2. Si possible, activez le mode débogage sur le serveur backend pour en savoir plus sur l'erreur et sa cause.

Si vous disposez d'une session de traçage pour l'appel d'API ayant échoué:

Si vous disposez d'une session Trace, les étapes suivantes vous aideront à diagnostiquer le problème.

  1. Dans l'outil Trace, sélectionnez la requête API qui a échoué avec le code d'erreur 500 (Erreur interne du serveur).
  2. Sélectionnez la phase Réponse reçue du serveur cible de la requête API ayant échoué, comme illustré dans la figure ci-dessous:

  3. Consultez la section Contenu de la réponse pour en savoir plus sur l'erreur.

  4. Dans cet exemple, le contenu de la réponse qui est une enveloppe SOAP affiche la chaîne d'erreur en tant que message "Non autorisé". La cause la plus probable de ce problème est que l'utilisateur ne transmet pas les bons identifiants (nom d'utilisateur/mot de passe, jeton d'accès, etc.) au serveur backend. Pour résoudre ce problème, transmettez les identifiants corrects au serveur backend.

Si le backend est un serveur Node.js:

  1. Si le backend est un serveur backend Node.js, vérifiez les journaux Node.js pour le proxy d'API spécifique dans l'interface utilisateur Edge (les utilisateurs des clouds publics et privés peuvent vérifier les journaux Node.js). Si vous êtes un utilisateur Edge Private Cloud, vous pouvez également consulter les journaux de votre processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log) pour plus de détails sur l'erreur.

    Option de journaux NodeJS dans l'interface utilisateur Edge - Onglet "Overview" (Aperçu) du proxy d'API

Solution

  1. Une fois que vous avez identifié la cause de l'erreur, corrigez-la sur votre serveur backend.
  2. S'il s'agit d'un serveur backend Node.js :
    1. Vérifiez si l'erreur provient de votre code personnalisé et corrigez le problème, si possible.
    2. Si l'erreur n'est pas générée à partir de votre code personnalisé ou si vous avez besoin d'aide, contactez l'assistance Apigee.

Si vous avez besoin d'une aide supplémentaire pour dépanner l'erreur interne du serveur 500 ou si vous pensez qu'il s'agit d'un problème dans Edge, contactez l'assistance Apigee.

Déterminer la source du problème

Utilisez l'une des procédures suivantes pour déterminer si l'erreur interne du serveur 500 a été générée lors de l'exécution d'une stratégie dans le proxy d'API ou par le serveur backend.

Utiliser Trace dans l'interface utilisateur

Remarque:Les étapes de cette section peuvent être effectuées par les utilisateurs de clouds publics et privés.

  1. Si le problème est toujours actif, activez la trace dans l'interface utilisateur pour l'API concernée.
  2. Une fois la trace capturée, sélectionnez la requête API dont le code de réponse est 500.
  3. Parcourez toutes les phases de la requête API ayant échoué et vérifiez quelle phase renvoie l'erreur interne du serveur 500 :
    1. Si l'erreur est générée lors de l'exécution d'une stratégie, passez à la section Erreur d'exécution dans une stratégie périphérique.
    2. Si le serveur backend a renvoyé la réponse "500 Internal Server" (Serveur interne), passez à la section Erreur sur le serveur backend.

Utiliser la surveillance des API

Remarque:Seuls les utilisateurs de cloud public peuvent effectuer les étapes décrites dans cette section.

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 le cas, par exemple, des applications pour développeurs, des proxys d'API, des cibles 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 de 500 codes d'état ou d'erreurs steps.servicecallout.ExecutionFailed dépasse un certain seuil.

Utiliser les journaux d'accès NGINX

Remarque:Les étapes décrites dans cette section sont réservées aux utilisateurs de cloud privé Edge.

Vous pouvez également vous référer aux journaux d'accès NGINX pour déterminer si le code d'état 500 a été généré lors de l'exécution d'une règle dans le proxy d'API ou 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 s'il existe des erreurs 500 pour le proxy d'API spécifique à la durée spécifiée.
  3. S'il existe des erreurs 500, vérifiez s'il s'agit d'une erreur liée aux règles ou au serveur cible, comme indiqué ci-dessous:

    Exemple d'entrée montrant une erreur liée aux règles

    Exemple d'entrée affichant une erreur du serveur cible

  4. Une fois que vous avez déterminé s'il s'agit d'une erreur liée aux règles ou au serveur cible :
    1. Passez à la section Erreur d'exécution dans une stratégie périphérique s'il s'agit d'une erreur de stratégie.
    2. Passez à la section Erreur sur le serveur backend s'il s'agit d'une erreur du serveur cible.