503 Service indisponible – NoActiveTargets – HealthCheckFailures

<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

Regardez les vidéos suivantes pour en savoir plus sur les erreurs 503:

Symptôme

L'application cliente reçoit le code d'état de réponse HTTP 503 avec le paramètre le message Service Unavailable et le code d'erreur NoActiveTargets pour les requêtes de proxy d'API.

Message d'erreur

La réponse d'erreur suivante s'affiche:

HTTP/1.1 503 Service Unavailable
  

Le message d'erreur suivant s'affiche dans la réponse HTTP:

{
   "fault": {
      "faultstring": "The Service is temporarily unavailable",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.NoActiveTargets"
       }
    }
}
  

Causes possibles

La réponse HTTP 503 Service Unavailable avec le code d'erreur NoActiveTargets est généralement observée. lorsque vous utilisez un ou plusieurs serveurs cibles dans la configuration du point de terminaison cible dans votre proxy d'API.

Ce playbook couvre l'erreur 503 Service non disponible avec le code d'erreur. NoActiveTargets causées par des échecs de la vérification de l'état. Veuillez consulter ce guide pour connaître les autres causes de cette erreur.

Échecs de la vérification de l'état

Les échecs de vérification de l'état ne seront observés que si vous avez configuré un <ph type="x-smartling-placeholder"></ph> Surveillance de l'état dans le cadre de la configuration de l'équilibrage de charge du serveur cible sur le point de terminaison cible de votre proxy d'API.

Lorsqu'un serveur cible échoue lors d'une vérification de l'état, Edge incrémente le nombre d'échecs de ce serveur. Si le nombre d'échecs de vérification d'état pour ce serveur atteint le seuil prédéfini (<MaxFailures>), Le processeur de messages consigne le message d'avertissement ci-dessous dans son fichier journal:

Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget2{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
    

Le message d'avertissement fournit les informations suivantes. Cela vous permet d'identifier le serveur cible qui a atteint le nombre de MaxFailure:

• Nom du serveur cible
• Noms des organisations et des environnements
• Nom du proxy d'API
• Nom du point de terminaison cible

Par la suite, Edge cesse d'envoyer toute autre requête à ce serveur spécifique. Une fois que la cible serveurs configurés dans la configuration LoadBalancer atteignent le nombre MaxFailure, la valeur Les requêtes API reçoivent la réponse 503 Service Unavailable avec le code d'erreur NoActiveTargets.

L'utilisation de la surveillance de l'état permet à Apigee Edge d'inclure automatiquement un serveur cible dans le lorsqu'il est opérationnel, sans avoir à redéployer le proxy d'API.

Voici les causes possibles de l'échec de la vérification de l'état:

Étapes de diagnostic courantes

Déterminer l'ID de message de la requête en échec

Messages d'erreur fréquents

Lorsque des serveurs cibles sont utilisés et qu'une erreur se produit alors que le processeur de messages tente de vous connecter au serveur backend, des messages d'erreur courants apparaissent dans la Journaux du processeur de messages. Ces erreurs sont consignées après le message d'erreur/d'exception réel. qui a conduit à l'échec.

Messages d'erreur courants observés dans les journaux du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log) pour 503 Service indisponible avec le code d'erreur NoActiveTargets sont les suivantes:

org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 INFO  ADAPTORS.HTTP.FLOW - LBTargetRequestSender.sendRequest() : Failed to send request to target servers : [demo-target] for default{Organization=myorgEnvironment=prod,Application=TestTargetServer__2}

org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - LBTargetRequestSender.sendRequest() : No Active Target server Found for default{Organization=myorgEnvironment=prod,Application=TestTargetServer__2}

org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - LBTargetRequestSender.sendRequest() : Unexpected error while sending request
com.apigee.errors.http.server.ServiceUnavailableException: The Service is temporarily unavailable
	at com.apigee.messaging.adaptors.http.flow.data.LBTargetRequestSender.sendRequest(LBTargetRequestSender.java:299)
	at com.apigee.messaging.adaptors.http.flow.data.LBTargetRequestSender.access$400(LBTargetRequestSender.java:57)
	…<snipped>

Ces messages d'erreur indiquent que la requête n'a pas pu être envoyée au serveur backend en raison d'une l'échec. Par conséquent, le processeur de messages envoie 503 Service Unavailable avec le code d'erreur NoActiveTargets dans sa réponse au client.

Cause: délai avant expiration de la connexion

Diagnostic

1. Déterminez l'ID du message de la requête qui échoue.
2. Recherchez l'ID du message dans le journal du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. Le bouton messages d'erreur courants correspondant à l'ID du message. Toutefois, pour connaître la cause réelle des échecs de la vérification de l'état, faites défiler la page au-dessus messages d'erreur courants et vérifiez s'il y a des erreurs HEALTH MONITOR.

   Par exemple, le message d'erreur HEALTH MONITOR suivant indique que le processeur de messages a échoué avec l'erreur "Connection timed out" (Expiration du délai de connexion) lors de l'envoi de la requête API de vérification de l'état:

   Apigee-Timer-6 ERROR SERVICES.HEALTH_MONITOR - HTTPMonitor.getResponseFromCache() : Error sending request Request URL : https://<BackendServer-Hostname>:443/status
   java.net.ConnectException: Connection timed out (Connection timed out)
   	at java.net.PlainSocketImpl.socketConnect(Native Method)
   	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
   	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
   …<snipped>
           

   Si cette erreur se répète jusqu'à MaxFailure fois la configuration dans le Moniteur de santé, un message d'avertissement semblable à celui-ci s'affiche:

   Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget2{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
           

   Lisez attentivement les informations fournies dans le message d'avertissement. Assurez-vous que MaxFailure a été atteint pour un serveur cible utilisé dans le proxy d'API spécifique pour lequel vous rencontrer le code de réponse 503 avec le code d'erreur NoActiveTargets.

4. Dans l'exemple ci-dessus, la vérification de l'état a échoué avec l'erreur connection timed out. Vérifiez si vous êtes en mesure de vous connecter au serveur backend spécifique directement depuis chacune des Processeurs de messages à l'aide de la commande telnet:

telnet <BackendServer-HostName> 443
      

5. Si vous parvenez à vous connecter au serveur backend, un message du type Connecté au backend-server. Il peut s'agir d'un problème temporaire et il peut être résolu ou est un problème temporaire. Répétez l'étape 4 plusieurs fois. (plus de 10 fois) et vérifiez le résultat.
1. Si la commande telnet ne présente aucune erreur de manière cohérente, le problème est résolu. Vérifiez à nouveau si les échecs de vérification de l'état se sont arrêtés. Si c'est le cas, vous n'avez pas à le faire autre chose.
2. Si vous ne parvenez pas à vous connecter au serveur backend à l'aide de la commande telnet par intermittence, il se peut qu'il y ait un problème de réseau ou que votre serveur backend soit occupé.
6. Si vous ne parvenez pas à vous connecter au serveur backend avec la commande telnet de manière cohérente, cela peut être dû au fait que le trafic n'est pas autorisé en provenance des processeurs de messages sur le serveur backend spécifique.

Solution

Si l'erreur connection timed out est systématiquement observée, assurez-vous que le backend n'a aucune restriction de pare-feu et autorise le trafic provenant des processeurs de messages Apigee Edge. Par exemple, sous Linux, vous pouvez utiliser iptables pour autoriser le trafic provenant du Adresses IP du processeur de messages sur le serveur backend.

Si le problème persiste, adressez-vous à votre administrateur réseau pour déterminer et résoudre le problème. Si vous avez besoin d'une aide supplémentaire d'Apigee, contactez l'assistance Apigee.

Cause: requête sécurisée sur un port non sécurisé

Diagnostic

1. Déterminez l'ID du message de la requête qui échoue.
2. Recherchez l'ID du message dans le journal du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. Les messages d'erreur courants correspondant à l'ID du message s'affichent. Toutefois, pour connaître la cause réelle des échecs de la vérification de l'état, faites défiler la page au-dessus de ces messages d'erreur courants et vérifiez s'il y a des erreurs HEALTH MONITOR.

   Par exemple, l'erreur HEALTH MONITOR peut s'afficher, comme illustré ci-dessous:

   Apigee-Timer-1 ERROR SERVICES.HEALTH_MONITOR - HTTPMonitor.getResponseFromCache() : Error sending request Request URL : https://mocktarget.apigee.net:80/status
   javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
           at sun.security.ssl.InputRecord.handleUnknownRecord(InputRecord.java:710)
           at sun.security.ssl.InputRecord.read(InputRecord.java:527)
           at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:983)
           at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)
           at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413)
           at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397)
   …<snipped>
           

   Si cette erreur se répète plusieurs fois MaxFailure fois configuré dans le moniteur de santé, un message d'avertissement semblable à celui-ci s'affiche:

   Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
           

   Lisez attentivement les informations fournies dans le message d'avertissement. Assurez-vous que MaxFailure a été atteint pour un serveur cible utilisé dans le proxy d'API spécifique pour lequel vous rencontrer le code de réponse 503 avec le code d'erreur NoActiveTargets.

4. La vérification de l'état a échoué avec l'erreur suivante:

   Error sending request Request URL : https://mocktarget.apigee.net:80/statuscode/200
   javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
         

   Le message d'erreur et l'URL indiquent la cause de ce problème : Un appel sécurisé (HTTPS) a été effectué sur le port non sécurisé 80.

   Cette erreur peut se produire dans les deux scénarios suivants:

   • Serveur cible sécurisé défini avec un port non sécurisé
   • Serveur cible sécurisé défini, mais configuration de la surveillance de l'état sur un port non sécurisé

   Port cible sécurisé non sécurisé

   Scénario 1: Serveur cible sécurisé défini avec un port non sécurisé

   Si vous avez défini un serveur cible sécurisé, mais avec un port non sécurisé tel que 80, vous obtenez cette erreur. Suivez les étapes ci-dessous pour vérifier si cela est la cause de ce problème:

   1. Vérifiez la définition du serveur cible utilisé dans la configuration du point de terminaison cible.

   Utilisez le Obtenir l'API TargetServer pour obtenir la définition du serveur cible.

   Sortie de définition du serveur cible

   <TargetServer name="mocktarget">
     <Host>mocktarget.apigee.net</Host>
     <Port>80</Port>
     <IsEnabled>true</IsEnabled>
     <SSLInfo>
         <Enabled>true</Enabled>
     </SSLInfo>
   </TargetServer>
             

   Dans l'exemple ci-dessus, la définition montre que le serveur cible mocktarget est un serveur sécurisé comme indiqué par le bloc SSLInfo. Cependant, il est configuré avec un port 80 non sécurisé.

   2. À présent, vérifiez la configuration de la surveillance de l'état du serveur cible dans la configuration du point de terminaison cible:

      Configuration du moniteur de santé

      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <HTTPMonitor>
          <Request>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
            <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
      </HealthMonitor>
                

      Notez qu'aucun élément <Port> n'est spécifié dans Configuration de la surveillance de l'état ci-dessus. Dans ce cas, le processeur de messages d'Edge utilise le port spécifié dans la définition du serveur cible (80) pour effectuer des appels d'API de vérification de l'état.

   3. Compte tenu des informations ci-dessus, cette erreur est due au fait que le serveur cible est défini comme un serveur sécurisé (le bloc SSLInfo est activé), mais avec un port non sécurisé 80.

   Port HM non sécurisé cible sécurisé

   Scénario 2: Serveur cible sécurisé défini, mais configuration du contrôle de l'état sur un port non sécurisé

   Si vous avez défini un serveur cible sécurisé, mais que le contrôle de l'état est configuré avec un non sécurisé tel que 80, vous obtenez cette erreur. Suivez les étapes ci-dessous pour le vérifier si c'est la cause du problème:

   1. Vérifiez la définition du serveur cible utilisé dans la configuration du point de terminaison cible.

      Utilisez le Obtenez l'API TargetServer pour obtenir la définition du serveur cible.

      Sortie de définition du serveur cible

      <TargetServer name="mocktarget">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
        <SSLInfo>
            <Enabled>true</Enabled>
        </SSLInfo>
      </TargetServer>
              

      Dans l'exemple ci-dessus, la définition indique que le serveur cible mocktarget est un serveur sécurisé, comme indiqué par le bloc SSLInfo.

   2. Vérifiez ensuite la configuration de la surveillance de l'état du serveur cible dans la configuration du point de terminaison cible:

      Configuration du moniteur de santé

      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <HTTPMonitor>
          <Request>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
         	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
            <Port>80</Port>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
              

      Dans l'exemple ci-dessus, le moniteur de santé est configuré avec un port 80 non sécurisé, comme indiqué par l'élément <Port>.

   3. Compte tenu des informations ci-dessus, cette erreur s'explique par le fait que le serveur cible est défini en tant que serveur sécurisé (si le bloc SSLInfo est activé) et qu'il utilise le port sécurisé 443, mais l'outil de contrôle de l'état est configuré pour effectuer des vérifications de l'état sur un port non sécurisé 80 (spécifié dans l'élément <Port>).

      C'est-à-dire, dans ce cas, Edge effectue les API de vérification de l'état comme un appel sécurisé avec des le port 80 et échoue avec l'erreur mentionnée ci-dessus.

Solution

<TargetServer name="mocktarget">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo>
      <Enabled>true</Enabled>
  </SSLInfo>
</TargetServer>
    

Cause: requête non sécurisée sur un port sécurisé

Diagnostic

1. Déterminez l'ID du message de la requête qui échoue.
2. Recherchez l'ID du message dans le journal du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. Le bouton messages d'erreur courants correspondant à l'ID du message. Toutefois, pour connaître la cause réelle des échecs de la vérification de l'état, faites défiler la page au-dessus de ces messages d'erreur courants et vérifiez s'il y a des erreurs HEALTH MONITOR.

   Par exemple, l'erreur HEALTH MONITOR peut s'afficher, comme illustré ci-dessous:

   Apigee-Timer-2 ERROR SERVICES.HEALTH_MONITOR - HTTPMonitor.getResponseFromCache() : Error sending request Request URL : http://mocktarget.apigee.net:443/status
   java.net.SocketException: Unexpected end of file from server
   	at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:851)
   	at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:678)
   	at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:848)
   	at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:678)
   	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1587)
   …<snipped>
             

   Si cette erreur se répète plusieurs fois MaxFailure fois configuré dans le moniteur de santé, un message d'avertissement semblable à celui-ci s'affiche:

   Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
             

   Lisez attentivement les informations fournies dans le message d'avertissement. Assurez-vous que MaxFailure a été atteint pour un serveur cible utilisé dans le proxy d'API spécifique pour lequel vous rencontrer le code de réponse 503 avec le code d'erreur NoActiveTargets.

4. La vérification de l'état a échoué avec l'erreur suivante:

   Error sending request Request URL : http://mocktarget.apigee.net:443/status
   java.net.SocketException: Unexpected end of file from server
         

   Le message d'erreur et l'URL indiquent la cause de ce problème : Un appel non sécurisé (HTTP) a été effectué sur le port sécurisé 443.

   Cette erreur peut se produire dans les deux scénarios suivants:

   • Serveur cible non sécurisé défini avec un port sécurisé
   • Le serveur cible non sécurisé est défini, mais le contrôle de l'état est configuré avec un port sécurisé

   Port sécurisé cible non sécurisé

   Scénario 1: Serveur cible non sécurisé défini avec un port sécurisé

   Si vous avez défini un serveur cible non sécurisé, mais avec un port sécurisé tel que 443, vous obtenez cette erreur. Suivez les étapes ci-dessous pour vérifier si cela est la cause de ce problème:

   1. Vérifiez la définition du serveur cible utilisé dans la configuration du point de terminaison cible.

      Utilisez le Obtenez l'API TargetServer pour obtenir la définition du serveur cible.

      Sortie de définition du serveur cible

      <TargetServer name="mocktarget">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
      </TargetServer>
                    

      Dans l'exemple ci-dessus, la définition indique que le serveur cible mocktarget est un serveur non sécurisé, car il n'y a pas de bloc SSLInfo. Cependant, il n'est pas correct configurés avec un port sécurisé 443.

   2. À présent, vérifiez la configuration de la surveillance de l'état du serveur cible dans la configuration du point de terminaison cible:

      Configuration du moniteur de santé

      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <HTTPMonitor>
          <Request>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
            <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
      </HealthMonitor>
                      

      Notez qu'aucun élément <Port> n'est spécifié dans le moniteur de santé. configuration ci-dessus. Dans ce cas, le processeur de messages de Edge utilise le port spécifié dans la définition du serveur cible qui est 443.

   3. Compte tenu des informations ci-dessus, cette erreur s'explique par le fait que le serveur cible est défini en tant que serveur non sécurisé (le bloc SSLInfo n'est pas défini), mais avec un port sécurisé 443.

      Autrement dit, Edge effectue les vérifications de l'état comme un appel non sécurisé avec le port sécurisé 443 et échoue avec l'erreur mentionnée ci-dessus.

   Port HM sécurisé cible non sécurisé

   Scénario 2: Serveur cible non sécurisé défini, mais contrôle de l'état configuré avec un port sécurisé

   Si vous avez défini un serveur cible non sécurisé, mais que le contrôle de l'état est configuré avec un port sécurisé tel que 443, vous obtenez cette erreur. Suivez les étapes ci-dessous pour vérifier si cela est la cause de ce problème:

   1. Vérifiez la définition du serveur cible utilisé dans la configuration du point de terminaison cible.

      Utilisez le Obtenez l'API TargetServer pour obtenir la définition du serveur cible.

      Sortie de définition du serveur cible

      <TargetServer name="mocktarget">
        <Host>mocktarget.apigee.net</Host>
        <Port>80</Port>
        <IsEnabled>true</IsEnabled>
      </TargetServer>
              

      Dans l'exemple ci-dessus, la définition indique que le serveur cible mocktarget est un serveur non sécurisé (en l'absence de bloc SSLInfo) configuré avec un port 80 non sécurisé correctement.

   2. Vérifiez ensuite la configuration de la surveillance de l'état du serveur cible dans la configuration du point de terminaison cible:

      Configuration du moniteur de santé

      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <HTTPMonitor>
          <Request>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
         	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
            <Port>443</Port>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
      </HealthMonitor>
            

      Dans l'exemple ci-dessus, le moniteur de santé est configuré avec un port 443 sécurisé, comme indiqué par l'élément <Port>.

   3. Compte tenu des informations ci-dessus, cette erreur s'explique par le fait que le serveur cible est défini comme Un serveur non sécurisé (car le bloc SSLInfo n'est pas défini) avec le port 80 non sécurisé Toutefois, la fonctionnalité de contrôle de l'état est configurée pour effectuer les vérifications de l'état avec un port sécurisé 443 (spécifié dans l'élément <Port>).

      Autrement dit, dans ce cas, Edge effectue les vérifications de l'état comme un appel non sécurisé avec le port sécurisé 443 et échoue avec l'erreur mentionnée ci-dessus.

Solution

<TargetServer name="mocktarget">
  <Host>mocktarget.apigee.net</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer>
              

Cause: l'API de vérification de l'état renvoie une erreur

Diagnostic

1. Déterminez l'ID du message de la requête qui échoue.
2. Recherchez l'ID du message dans le journal du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. Les messages d'erreur courants correspondant à l'ID du message s'affichent. Toutefois, pour connaître la cause réelle des échecs de la vérification de l'état, faites défiler la page au-dessus de ces messages d'erreur courants et vérifiez les erreurs/avertissements de HEALTH MONITOR.

   Par exemple, l'avertissement suivant peut s'afficher:

   Apigee-Timer-7 INFO  SERVICES.HEALTH_MONITOR - HTTPMonitor.sendRequest() : HTTPMonitor.monitor() : Connecting to https://mocktarget.apigee.net:443/status/200
   Apigee-Timer-7 WARN  SERVICES.HEALTH_MONITOR - HTTPMonitor.monitor() : HTTP response code from health monitoring service does not match.Expected response code : [200]. Received response code : 404
           

   Si cette erreur se répète plusieurs fois MaxFailure fois configuré dans le moniteur de santé, un message d'avertissement semblable à celui-ci s'affiche:

   Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
           

   Lisez attentivement les informations fournies dans le message d'avertissement. Assurez-vous que MaxFailure a été atteint pour un serveur cible utilisé dans le proxy d'API spécifique pour lequel vous rencontrer le code de réponse 503 avec le code d'erreur NoActiveTargets.

4. La vérification de l'état a renvoyé le message d'avertissement suivant:

   HTTP response code from health monitoring service does not match.Expected response code : [200]. Received response code : 404
         

   Le message d'avertissement ci-dessus indique que le code de réponse attendu pour l'API de vérification de l'état était 200, alors que la réponse réelle reçue est 404. Par conséquent, cela est traité comme un échec.

5. Avant d'examiner la cause d'une réponse d'erreur de l'API de vérification de l'état, déterminez pourquoi Edge attend le code de réponse 200 pour l'API de vérification de l'état. Pour cela, consultez le moniteur de santé du serveur cible dans la configuration du point de terminaison cible:

   Configuration du moniteur de santé

   <HealthMonitor>
     <IsEnabled>true</IsEnabled>
     <IntervalInSec>5</IntervalInSec>
     <HTTPMonitor>
       <Request>
         <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
      	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
         <Port>443</Port>
         <Verb>GET</Verb>
         <Path>/status/200</Path>
       </Request>
       <SuccessResponse>
         <ResponseCode>200</ResponseCode>
       </SuccessResponse>
     </HTTPMonitor>
   </HealthMonitor>
           

   Notez que la configuration de la surveillance de l'état est configurée avec le code de réponse 200 sous l'élément <SuccessResponse>. Cela signifie que si Edge obtient un code de réponse (tel que 400, 401, 404, 500) autre que 200 de l'API de vérification de l'état, il sera traité comme une erreur et incrémentera le nombre d'échecs.

6. Pour déterminer la cause d'une réponse d'erreur de l'API de vérification de l'état, procédez comme suit:
1. Examinez le message précédant le message d'avertissement dans le journal du processeur de messages.

   Apigee-Timer-7 INFO  SERVICES.HEALTH_MONITOR - HTTPMonitor.sendRequest() : HTTPMonitor.monitor() : Connecting to https://mocktarget.apigee.net:443/status/200
             

   Notez l'URL de vérification de l'état qui figure dans ce message.

2. Vous pouvez appeler directement cette URL à partir du processeur de messages et vérifier la réponse réelle

   curl -i https://mocktarget.apigee.net:443/status/200
             

   La réponse à l'appel ci-dessus renvoie 404, comme indiqué dans les journaux du processeur de messages:

   < HTTP/2 404
             

3. Cela montre que même l'appel direct à l'URL de vérification de l'état échoue avec le même code de réponse 404. Cela signifie que l'URL de vérification de l'état est peut-être incorrecte ou que la ressource accessible via l'URL n'est plus disponible.
4. Dans l'exemple d'API de vérification de l'état fourni ci-dessus, le problème est dû au fait qu'une URL incorrecte a été utilisée dans la configuration du moniteur de santé. Nous avons constaté que l'URL correcte était https://mocktarget.apigee.net:443/statuscode/200 de API cible fictive.
7. Si vous obtenez une autre erreur de réponse, déterminez-en la cause en suivant la les étapes ci-dessus. Si nécessaire, contactez votre équipe backend.

Solution

1. Corrigez le problème lié à l'API de vérification de l'état sur votre serveur backend.
2. Pour résoudre le problème dans l'exemple décrit ci-dessus, procédez comme suit:
1. Dans la configuration du moniteur de santé, définissez l'élément <Path> sur /statuscode/200, comme indiqué ci-dessous:

   <Path>/statuscode/200</Path>
           

2. Enregistrez les modifications dans le proxy d'API.

Si le problème persiste, accédez à Obligation de recueillir des informations de diagnostic.

Diagnostiquer les problèmes à l'aide de la surveillance des API

La surveillance des API vous permet d'isoler les problèmes pour diagnostiquer rapidement les problèmes d'erreurs, de performances et de latence, ainsi que leur origine, comme les problèmes applications, proxys d'API, cibles de backend ou plate-forme d'API.

Examiner un exemple de scénario qui montre comment résoudre les problèmes 5xx de vos API à l'aide de la surveillance des API. Par exemple : vous pouvez configurer une alerte pour être averti lorsque le nombre de messaging.adaptors.http.flow.NoActiveTargets les erreurs de configuration dépassent un seuil particulier.

Vous devez collecter des informations de diagnostic

Si le problème persiste alors que vous avez suivi les instructions ci-dessus, veuillez rassembler les informations suivantes : des informations de diagnostic. Contactez-les et partagez-les avec l'assistance Apigee:

1. Si vous êtes un utilisateur de cloud public, fournissez les informations suivantes:
1. Nom de l'organisation
2. Nom de l'environnement
3. Nom du proxy d'API
4. Exécutez la commande curl pour reproduire l'erreur
5. Fichier de suivi contenant les requêtes avec l'erreur 503 Service non disponible avec le code d'erreur NoActiveTargets
2. Si vous êtes un utilisateur de Private Cloud, fournissez les informations suivantes: <ph type="x-smartling-placeholder">
   </ph>
   1. Message d'erreur complet observé
   2. Nom de l'environnement
   3. Groupe de proxys d'API
   4. Fichier de suivi contenant les requêtes avec l'erreur 503 Service non disponible avec le code d'erreur NoActiveTargets
   5. Journaux d'accès NGINX

      (/opt/apigee/var/log/edge-router/nginx/<org>~<env>.<port#>_access_log)

   6. Journaux du processeur de messages

      (/opt/apigee/var/log/edge-message-processor/logs/system.log)