Cette page a été traduite par l'API Cloud Translation.

503 Service indisponible – NoActiveTargets – HealthCheckFailures

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 les erreurs 503:

Vidéo	Description
Résoudre le problème 503 Service indisponible – NoActiveCibles	Pour en savoir plus, consultez les informations suivantes : Importance des serveurs cibles et des systèmes de surveillance de l'état Dépannage et résolution d'une erreur 503 "Service non disponible" en temps réel - Erreur "NoActiveCibles" causée par un échec de la vérification de l'état

Problème constaté

L'application cliente reçoit le code d'état de réponse HTTP 503 avec le message Service non disponible et le code d'erreur NoActiveCibles pour les requêtes de proxy API.

Message d'erreur

Le message d'erreur suivant 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 Non disponible avec le code d'erreur NoActiveCibles est généralement observée lorsque vous utilisez un ou plusieurs serveurs cibles dans la configuration du point de terminaison cible de votre proxy d'API.

Ce playbook couvre l'indisponibilité du service 503 avec le code d'erreur NoActiveCibles causé par des échecs de vérification de l'état. Veuillez consulter ce playbook pour en savoir plus sur 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 moniteur d'état dans le cadre de la configuration de l'équilibrage de charge du serveur cible dans le point de terminaison cible de votre proxy d'API.

Lorsqu'un serveur cible échoue à 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 comme indiqué 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 de savoir quel serveur cible 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 tous les serveurs cibles configurés dans la configuration LoadBalancer ont atteint le nombre de MaxFailure, les requêtes API suivantes reçoivent le message d'erreur 503 Service AVAILABLE (Service non disponible) avec le code d'erreur NoActiveCibles.

L'utilisation du moniteur d'état permet à Apigee Edge d'inclure automatiquement un serveur cible dans la rotation lorsqu'il devient opérationnel, sans avoir à redéployer le proxy d'API.

Voici les causes possibles des échecs de vérification de l'état:

Cause	Description	Qui peut effectuer les étapes de dépannage
Erreur de délai avant expiration de connexion	Le processeur de messages ne peut pas se connecter au serveur cible dans le délai spécifié dans la configuration LoadBalancer.	Utilisateurs de cloud privé périphérique
Requête sécurisée sur un port non sécurisé	Si le serveur cible est défini comme un serveur sécurisé, mais qu'il est mal configuré avec un port non sécurisé. Si le serveur cible est défini comme un serveur sécurisé, mais que la surveillance de l'état est configurée pour effectuer des vérifications de l'état sur un port non sécurisé.	Utilisateurs de cloud privé périphérique
Requête non sécurisée sur le port sécurisé	Si le serveur cible est défini comme un serveur non sécurisé, mais qu'il est mal configuré avec un port sécurisé. Si le serveur cible est défini comme étant un serveur non sécurisé, mais que la surveillance de l'état est configurée pour effectuer des vérifications de l'état sur un port sécurisé.	Utilisateurs de cloud privé périphérique
L'API Health Check renvoie une erreur	Si l'API de vérification de l'état renvoie une erreur ou un code de réponse autre que celui spécifié dans l'élément SuccessResponse du moniteur d'état.	Utilisateurs de cloud privé périphérique

Étapes de diagnostic courantes

Déterminer l'ID du message de la requête ayant échoué

Outil de traçage

Pour déterminer l'ID de message de la requête ayant échoué à l'aide de l'outil Trace:

Activez la session de trace, effectuez l'appel d'API, puis reproduisez le problème 503 Service AVAILABLE (Service non disponible) avec le code d'erreur NoActiveCibles.
Sélectionnez l'une des requêtes ayant échoué.
Accédez à la phase AX et déterminez l'ID du message (X-Apigee.Message-ID) de la requête en faisant défiler la page vers le bas dans la section Phase Details (Détails de la phase), comme illustré dans la figure suivante.

Journaux d'accès NGINX

Pour déterminer l'ID de message de la requête ayant échoué à l'aide des journaux d'accès NGINX:

Vous pouvez également vous reporter aux journaux d'accès NGINX pour déterminer l'ID des messages des erreurs 503. 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:

Vérifiez les journaux d'accès NGINX: (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
Recherchez s'il existe des erreurs 503 pour le proxy d'API spécifique pendant une durée spécifique (si le problème s'est produit par le passé) ou si des requêtes échouent toujours avec l'erreur 503.
En cas d'erreurs 503 avec X-Apigee-fault-code Messaging.adaptors.http.flow.NoActiveCibles, notez l'ID du message pour une ou plusieurs requêtes de ce type, comme illustré dans l'exemple suivant:
Exemple d'entrée affichant l'erreur 503

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 se connecter au serveur backend, quelques messages d'erreur courants s'affichent dans les journaux du processeur de messages. Ces erreurs sont consignées après le message d'erreur ou d'erreur réel à l'origine de l'échec.

Les messages d'erreur courants observés dans les journaux du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log) pour l'état 503 Service AVAILABLE (Service non disponible) avec le code d'erreur NoActiveCibles sont les suivants:

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'un échec. Par conséquent, le processeur de messages envoie 503 Service AVAILABLE (Service non disponible) avec le code d'erreur NoActiveCibles comme réponse au client.

Cause: délai avant expiration de la connexion

Diagnostic

Déterminez l'ID du message de la requête ayant échoué.
Recherchez l'ID du message dans le journal du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log).
Les messages d'erreur courants correspondant à l'ID du message s'affichent. Toutefois, pour connaître la cause réelle des échecs de vérification de l'état, faites défiler la page au-dessus de ces messages d'erreur courants et recherchez d'éventuelles erreurs HEALTH MONITOR.
Par exemple, le message d'erreur HEALTH MONITOR suivant indique que le processeur de messages a échoué avec une erreur de délai de connexion expiré lors 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 MaxFailure fois, le moniteur de santé est configuré, 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 le nombre de MaxFailure a été atteint pour un serveur cible utilisé dans le proxy d'API spécifique pour lequel vous rencontrez le code de réponse 503 avec le code d'erreur NoActiveTargets.
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 à partir de chacun des processeurs de messages à l'aide de la commande telnet:

telnet <BackendServer-HostName> 443

Si vous pouvez vous connecter au serveur backend, un message du type Connecté au serveur backend peut s'afficher. Il peut s'agir d'un problème temporaire, qui peut être résolu ou intermittent. Répétez l'étape 4 plusieurs fois (10 fois ou plus) et vérifiez le résultat.

Si aucune erreur n'est détectée régulièrement avec la commande telnet, 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 rien d'autre à faire.
Si vous ne parvenez pas à vous connecter au serveur backend à l'aide de la commande telnet par intermittence, il est possible qu'il y ait un problème réseau ou que votre serveur backend soit occupé.

Si vous ne parvenez pas à vous connecter au serveur backend de manière cohérente à l'aide de la commande telnet, 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.

Résolution

Si l'erreur connection timed out est constamment observée, assurez-vous que le serveur backend n'est soumis à 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 des adresses IP du processeur de messages sur le serveur backend.

Si le problème persiste, contactez votre administrateur réseau pour l'identifier et le résoudre. 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

Déterminez l'ID du message de la requête ayant échoué.
Recherchez l'ID du message dans le journal du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log).

Les messages d'erreur courants correspondant à l'ID du message s'affichent. Toutefois, pour connaître la cause réelle des échecs de vérification de l'état, faites défiler la page au-dessus de ces messages d'erreur courants et recherchez d'éventuelles erreurs HEALTH MONITOR.

Par exemple, une erreur de surveillance de la santé 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 MaxFailure fois, le moniteur de santé a été configuré, 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 le nombre de MaxFailure a été atteint pour un serveur cible utilisé dans le proxy d'API spécifique pour lequel vous rencontrez le code de réponse 503 avec le code d'erreur NoActiveTargets.

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 que la cause de ce problème est qu'un appel sécurisé (HTTPS) a été effectué sur le port non sécurisé 80.

Cette erreur peut se produire dans les deux cas suivants:
- Serveur cible sécurisé défini avec un port non sécurisé
- Le serveur cible sécurisé est défini, mais le moniteur d'état est configuré avec un port non sécurisé
Port cible non sécurisé 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, cette erreur est renvoyée. Pour vérifier si c'est la cause du problème, procédez comme suit:
1. Vérifiez la définition du serveur cible utilisé dans la configuration du point de terminaison cible.
2. À présent, vérifiez la configuration du moniteur d'état pour le serveur cible dans la configuration du point de terminaison cible:
  Configuration du moniteur d'état
```
<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 la configuration du moniteur d'état ci-dessus. Dans ce cas, le processeur de messages 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. D'après les informations ci-dessus, cette erreur est due au fait que le serveur cible est défini comme un serveur sécurisé (le bloc SSLInfo étant activé), mais avec un port 80 non sécurisé.
Port HM cible sécurisé

Scénario 2: Un serveur cible sécurisé est défini, mais le moniteur d'état est configuré avec un port non sécurisé

Si vous avez défini un serveur cible sécurisé, mais que le moniteur d'état est configuré avec un port non sécurisé tel que 80, cette erreur est renvoyée. Suivez la procédure ci-dessous pour vérifier si elle est à l'origine du problème:
1. Vérifiez la définition du serveur cible utilisé dans la configuration du point de terminaison cible.
  Utilisez l'option Obtenir l'API TargetServer pour obtenir la définition du serveur cible.
  
  Sortie de la 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 montre que le serveur cible mocktarget est un serveur sécurisé, comme indiqué par le bloc SSLInfo.
2. Vérifiez ensuite la configuration du moniteur d'état pour le serveur cible dans la configuration du point de terminaison cible:
  Configuration du moniteur d'état
```
<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. D'après les informations ci-dessus, cette erreur est due au fait que le serveur cible est défini comme un serveur sécurisé (le bloc SSLInfo étant activé) et qu'il utilise le port sécurisé 443, mais que le moniteur d'état est configuré pour effectuer des vérifications d'état avec un port 80 non sécurisé (spécifié dans l'élément <Port>).
  Autrement dit, Edge effectue les API de vérification de l'état en tant qu'appel sécurisé avec le port non sécurisé 80 et échoue avec l'erreur mentionnée ci-dessus.
  
  Remarque:L'élément <Port> configuré dans le moniteur d'état est prioritaire sur le port utilisé dans la définition du serveur cible.

Résolution

Port cible non sécurisé sécurisé

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

Pour corriger cette erreur, mettez à jour la définition du serveur cible afin qu'il utilise un port sécurisé approprié.

Utilisez l'option Mettre à jour une API TargetServer pour mettre à jour la définition du serveur cible et vous assurer qu'un port sécurisé (par exemple: 443) est utilisé, comme illustré dans l'exemple ci-dessous:

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

Port HM cible sécurisé

Scénario 2: Un serveur cible sécurisé est défini, mais le moniteur d'état est configuré avec un port non sécurisé

Pour corriger cette erreur, procédez comme suit:

Modifiez la configuration du moniteur d'état pour utiliser un port sécurisé (par exemple: 443) afin d'effectuer des vérifications de l'état du serveur cible dans la configuration du point de terminaison cible du proxy d'API défaillant, comme indiqué ci-dessous :

<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>

Enregistrez les modifications apportées au proxy d'API.

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

Diagnostic

Déterminez l'ID du message de la requête ayant échoué.
Recherchez l'ID du message dans le journal du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log).

Par exemple, une erreur de surveillance de la santé 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 MaxFailure fois, le moniteur de santé a été configuré, 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}

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 que un appel non sécurisé (HTTP) a été effectué sur le port sécurisé 443.

Cette erreur peut se produire dans les deux cas suivants:
- Serveur cible non sécurisé défini avec un port sécurisé
- Serveur cible non sécurisé défini, mais le moniteur d'é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, cette erreur est renvoyée. Pour vérifier si c'est la cause du problème, procédez comme suit:
1. Vérifiez la définition du serveur cible utilisé dans la configuration du point de terminaison cible.
  Utilisez l'option Obtenir l'API TargetServer pour obtenir la définition du serveur cible.
  
  Sortie de la 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 montre que le serveur cible mocktarget est un serveur non sécurisé, car il n'y a pas de bloc SSLInfo. Cependant, il est mal configuré avec un port 443 sécurisé.
2. À présent, vérifiez la configuration du moniteur d'état pour le serveur cible dans la configuration du point de terminaison cible:
  Configuration du moniteur d'état
```
<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 la configuration du moniteur d'état ci-dessus. Dans ce cas, le processeur de messages Edge utilisera le port spécifié dans la définition du serveur cible qui est 443.
3. D'après les informations ci-dessus, cette erreur est due au fait que le serveur cible est défini comme un serveur non sécurisé (car 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 en tant qu'appel non sécurisé avec le port sécurisé 443 et échoue en générant l'erreur mentionnée ci-dessus.
Port HM cible non sécurisé

Scénario 2: Un serveur cible non sécurisé est défini, mais le moniteur d'état est configuré avec un port sécurisé

Si vous avez défini un serveur cible non sécurisé, mais que le moniteur d'état est configuré avec un port sécurisé tel que 443, cette erreur s'affiche. Pour vérifier si c'est la cause du problème, procédez comme suit:
1. Vérifiez la définition du serveur cible utilisé dans la configuration du point de terminaison cible.
  Utilisez l'option Obtenir l'API TargetServer pour obtenir la définition du serveur cible.
  
  Sortie de la 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 montre que le serveur cible mocktarget est un serveur non sécurisé (car il n'y a pas de bloc SSLInfo) configuré avec un port 80 non sécurisé correctement.
2. Vérifiez ensuite la configuration du moniteur d'état pour le serveur cible dans la configuration du point de terminaison cible:
  Configuration du moniteur d'état
```
<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 d'état est configuré avec un port 443 sécurisé, comme indiqué par l'élément <Port>.
3. D'après les informations ci-dessus, cette erreur est due au fait que le serveur cible est défini comme un serveur non sécurisé (le bloc SSLInfo n'étant pas défini) avec le port 80 non sécurisé correctement, mais que le moniteur d'état est configuré pour effectuer des vérifications d'état avec un port sécurisé 443 (spécifié dans l'élément <Port>).
  Autrement dit, Edge effectue les vérifications de l'état en tant qu'appel non sécurisé avec le port sécurisé 443 et échoue avec l'erreur mentionnée ci-dessus.

Résolution

Port sécurisé cible non sécurisé

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

Pour corriger cette erreur, mettez à jour la définition du serveur cible afin qu'il utilise un port sécurisé approprié.

Utilisez l'option Mettre à jour une API de serveur cible pour mettre à jour la définition du serveur cible et vous assurer qu'un port non sécurisé (par exemple: 80) est utilisé comme illustré dans l'exemple ci-dessous :

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

Port HM cible non sécurisé

Scénario 2: Un serveur cible non sécurisé est défini, mais le moniteur d'état est configuré avec un port sécurisé

Pour corriger cette erreur, procédez comme suit:

Supprimez l'élément <Port> de la configuration du moniteur d'état ou modifiez la configuration du moniteur d'état pour utiliser un port non sécurisé (par exemple: 80) afin d'effectuer des vérifications de l'état du serveur cible dans la configuration du point de terminaison cible du proxy d'API défaillant, comme indiqué ci-dessous :

<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>
</HealthMonitor>

Enregistrez les modifications apportées au proxy d'API.

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

Diagnostic

Déterminez l'ID du message de la requête ayant échoué.
Recherchez l'ID du message dans le journal du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log).
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, puis recherchez les erreurs ou avertissements liés à HEALTH MONITOR.
L'avertissement suivant peut s'afficher, par exemple:
```
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 MaxFailure fois, le moniteur de santé a été configuré, 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 le nombre de MaxFailure a été atteint pour un serveur cible utilisé dans le proxy d'API spécifique pour lequel vous rencontrez le code de réponse 503 avec le code d'erreur NoActiveTargets.
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 d'état était 200, mais que la réponse réelle reçue est 404. Par conséquent, cette opération est considérée comme un échec.
Avant d'examiner la cause de la réponse d'erreur de l'API de vérification de l'état, déterminez pourquoi Edge attend que le code de réponse 200 pour cette API. Pour ce faire, vérifiez la configuration du moniteur d'état du serveur cible dans la configuration du point de terminaison cible:
Configuration du moniteur d'état
```
<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 du moniteur d'état est définie 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.
Pour examiner la cause de la réponse d'erreur de l'API de vérification de l'état, procédez comme suit:

Consultez 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 d'état indiquée dans ce message.

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 donne 404, comme indiqué dans les journaux du processeur de messages:
```
< HTTP/2 404
          
```
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 faisant l'objet d'un accès n'est plus disponible.
Dans l'exemple d'API de vérification d'état fourni ci-dessus, le problème se produit parce qu'une URL incorrecte a été utilisée dans la configuration du moniteur d'état. L'URL correcte était https://mocktarget.apigee.net:443/statuscode/200 à partir de l'API cible fictive.

Si vous obtenez une autre réponse d'erreur, déterminez la cause de cette erreur en suivant les étapes ci-dessus. Si nécessaire, adressez-vous à votre équipe backend.

Résolution

Corrigez le problème lié à l'API de vérification de l'état sur votre serveur backend.
Pour résoudre le problème dans l'exemple ci-dessus:

Modifiez l'élément <Path> dans la configuration du moniteur d'état sur /statuscode/200, comme indiqué ci-dessous :
```
<Path>/statuscode/200</Path>
        
```
Enregistrez les modifications dans le proxy d'API.

Si le problème persiste, consultez Obtention des informations de diagnostic requis.

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

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 par exemple le cas 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 de 5xx avec vos API à l'aide de la surveillance des API. Par exemple, vous pouvez configurer une alerte pour être averti lorsque le nombre d'erreurs messaging.adaptors.http.flow.NoActiveTargets dépasse un seuil particulier.

Vous devez collecter des informations de diagnostic

Si le problème persiste même après avoir suivi les instructions ci-dessus, veuillez rassembler les informations de diagnostic suivantes. Contactez-les et partagez-les avec l'assistance Apigee:

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écuter la commande curl pour reproduire l'erreur
Fichier de suivi contenant les requêtes indiquant une erreur 503 "Service non disponible" avec le code d'erreur NoActiveCibles

Si vous êtes un utilisateur de cloud privé, fournissez les informations suivantes :
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 indiquant une erreur 503 "Service non disponible" avec le code d'erreur NoActiveCibles
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)