Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

503 Service indisponible – NoActiveTargets – HealthCheckFailures

Vous consultez la documentation Apigee Edge.
Accédez à la documentation Apigee X.

Vidéos

Pour en savoir plus sur les erreurs 503, regardez les vidéos suivantes :

Vidéo	Description
Dépanner et résoudre l'erreur 503 "Service indisponible" - NoActiveTargets	Découvrez les points suivants : Importance des serveurs cibles et des vérifications de l'état Résoudre une erreur en temps réel "503 : Service Unavailable - NoActiveTargets" 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 Unavailable (Service indisponible) et le code d'erreur NoActiveTargets pour les requêtes de proxy d'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 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 de votre proxy d'API.

Ce playbook traite de l'erreur 503 Service Unavailable avec le code d'erreur NoActiveTargets, qui se produit en raison d'échecs de vérification de l'état. Pour en savoir plus sur les autres causes de cette erreur, consultez ce playbook.

É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 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 associé à ce serveur. Si le nombre d'échecs de vérification de l'état de ce serveur atteint le seuil prédéfini (<MaxFailures>), le processeur de messages enregistre 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 aide à comprendre quel serveur cible a atteint le nombre MaxFailure :

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

Edge cesse ensuite d'envoyer d'autres requêtes à ce serveur spécifique. Une fois que tous les serveurs cibles configurés dans la configuration LoadBalancer ont atteint le nombre MaxFailure, les requêtes API suivantes sont traitées avec le code d'erreur 503 Service Unavailable et le code d'erreur NoActiveTargets.

L'utilisation de HealthMonitor permet à Apigee Edge d'inclure automatiquement un serveur cible dans la rotation lorsqu'il redevient 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 la procédure de dépannage ?
Erreur de délai d'inactivité de la connexion	Le processeur de messages ne parvient pas à se connecter au serveur cible dans le délai avant expiration spécifié dans la configuration de l'équilibreur de charge.	Utilisateurs du cloud privé Edge
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 l'objet HealthMonitor est configuré pour effectuer des vérifications de l'état sur un port non sécurisé.	Utilisateurs du cloud privé Edge
Requête non sécurisée sur un 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 un serveur non sécurisé, mais que l'objet HealthMonitor est configuré pour effectuer des vérifications de l'état sur un port sécurisé.	Utilisateurs du cloud privé Edge
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 contrôleur d'état.	Utilisateurs du cloud privé Edge

Étapes de diagnostic courantes

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

Outil Trace

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

Activez la session de trace, effectuez l'appel d'API et reproduisez le problème 503 Service Unavailable avec le code d'erreur NoActiveTargets.
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 demande en faisant défiler la page vers le bas dans la section Détails de la phase, comme illustré dans la figure suivante.

Journaux d'accès NGINX

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

Vous pouvez également consulter les journaux d'accès NGINX pour déterminer l'ID de message des erreurs 503. Ceci est particulièrement utile si le problème est survenu par le passé ou s'il est intermittent, et que vous ne parvenez pas à capturer la trace dans l'interface utilisateur. Pour obtenir ces informations à partir des journaux d'accès NGINX, procédez comme suit :

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 dans le passé) ou si des requêtes échouent toujours avec l'erreur 503.
Si des erreurs 503 s'affichent avec le message X-Apigee-fault-code messaging.adaptors.http.flow.NoActiveTargets, notez l'ID de message d'une ou plusieurs de ces requêtes, comme indiqué 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 pendant que le processeur de message tente de se connecter au serveur backend, vous verrez quelques messages d'erreur courants dans les journaux du processeur de message. Ces erreurs sont consignées après le message d'exception/d'erreur réel qui a entraîné l'échec.

Voici 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'erreur 503 Service Unavailable avec le code d'erreur NoActiveTargets :

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 le code d'erreur 503 Service Unavailable avec le code d'erreur NoActiveTargets en réponse au client.

Cause : Délai de connexion expiré

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 les 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 dépassé 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 MaxFailure fois (nombre configuré dans le Health Monitor), 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 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 pouvez vous connecter au serveur de backend spécifique directement à partir de chacun des processeurs de messages à l'aide de la commande telnet :

telnet <BackendServer-HostName> 443

Si vous parvenez à vous connecter au serveur de backend, un message tel que Connecté au serveur de backend peut s'afficher. Il s'agit peut-être d'un problème temporaire qui a été résolu ou qui est intermittent. Répétez l'étape 4 plusieurs fois (au moins 10 fois) et vérifiez le résultat.

Si la commande telnet ne génère 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 ont cessé. Si c'est le cas, vous n'avez rien d'autre à faire.
Si vous ne parvenez pas à vous connecter au serveur de backend avec la commande telnet de manière intermittente, il peut s'agir d'un problème de réseau ou de serveur de backend surchargé.

Si vous ne parvenez pas à vous connecter au serveur de backend avec la commande telnet de manière cohérente, cela peut être dû au fait que le trafic n'est pas autorisé à partir des processeurs de messages sur le serveur de backend spécifique.

Solution

Si l'erreur connection timed out est observée de manière constante, assurez-vous que le serveur backend ne présente aucune restriction de pare-feu et qu'il 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'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 d'état, faites défiler la page au-dessus de ces messages d'erreur courants et recherchez les erreurs HEALTH MONITOR.

Par exemple, vous pouvez voir une erreur HEALTH MONITOR comme indiqué 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 (nombre configuré dans le Health Monitor), 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 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 ce problème est dû au fait 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é
- Serveur cible sécurisé défini, mais moniteur d'intégrité configuré avec un port non sécurisé
Sécuriser un port cible non sécurisé

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

Cette erreur se produit si vous avez défini un serveur cible sécurisé, mais avec un port non sécurisé tel que 80. Pour vérifier si tel est le cas, procédez comme suit :
1. Vérifiez la définition du serveur cible utilisé dans la configuration du point de terminaison cible.
2. Vérifiez maintenant la configuration du moniteur d'intégrité pour le serveur cible dans la configuration du point de terminaison cible :
  Configuration de HealthMonitor
  <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 contrôleur d'é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. D'après les informations ci-dessus, l'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 80 non sécurisé.
Sécuriser le port HM non sécurisé de la cible

Scénario 2 : Serveur cible sécurisé défini, mais Health Monitor configuré avec un port non sécurisé

Cette erreur se produit 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 le port 80. Pour vérifier si tel est le cas, procédez comme suit :
1. Vérifiez la définition du serveur cible utilisé dans la configuration du point de terminaison cible.
  Utilisez l' API Get 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. Ensuite, vérifiez la configuration du moniteur d'intégrité pour le serveur cible dans la configuration du point de terminaison cible :
  Configuration de HealthMonitor
  <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 vérificateur d'état est configuré avec un port 80 non sécurisé, comme indiqué par l'élément <Port>.
3. D'après les informations ci-dessus, l'erreur est due au fait que le serveur cible est défini comme un serveur sécurisé (le bloc SSLInfo est activé) et utilise le port sécurisé 443, mais que le moniteur d'intégrité est configuré pour effectuer des vérifications de l'état avec un port non sécurisé 80 (spécifié dans l'élément <Port>).
  Dans ce cas, Edge effectue les appels d'API de vérification de l'état en tant qu'appels sécurisés avec le port 80 non sécurisé et échoue avec l'erreur mentionnée ci-dessus.
  
  Remarque : L'élément <Port> configuré dans le moniteur d'intégrité est prioritaire par rapport au port utilisé dans la définition du serveur cible.

Solution

Sécuriser un port cible non sécurisé

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

Pour résoudre ce problème, mettez à jour la définition du serveur cible afin d'utiliser un port sécurisé approprié.

Utilisez l' API Update a TargetServer pour mettre à jour la définition du serveur cible et vous assurer qu'un port sécurisé (par exemple, le port 443) est utilisé, comme indiqué 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>

Sécuriser le port HM non sécurisé de la cible

Scénario 2 : Serveur cible sécurisé défini, mais Health Monitor configuré avec un port non sécurisé

Pour résoudre cette erreur, procédez comme suit :

Modifiez la configuration du moniteur d'intégrité pour utiliser un port sécurisé (par exemple, le port 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, vous pouvez voir une erreur HEALTH MONITOR comme indiqué 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 (nombre configuré dans le Health Monitor), 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 ce problème est dû à un appel non sécurisé (HTTP) 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é
- Un serveur cible non sécurisé est défini, mais HealthMonitor 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é

Cette erreur se produit si vous avez défini un serveur cible non sécurisé, mais avec un port sécurisé tel que 443. Pour vérifier si tel est le cas, procédez comme suit :
1. Vérifiez la définition du serveur cible utilisé dans la configuration du point de terminaison cible.
  Utilisez l' API Get 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. Toutefois, il est mal configuré avec un port 443 sécurisé.
2. Vérifiez maintenant la configuration du moniteur d'intégrité pour le serveur cible dans la configuration du point de terminaison cible :
  Configuration de HealthMonitor
  <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 contrôleur d'état ci-dessus. Dans ce cas, le processeur de messages d'Edge utilisera le port spécifié dans la définition du serveur cible, à savoir 443.
3. D'après les informations ci-dessus, l'erreur est due au fait que le serveur cible est défini comme un serveur non sécurisé (le bloc SSLInfo n'est pas défini), mais avec un port sécurisé 443.
  En d'autres termes, 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.
Port HM sécurisé cible non sécurisé

Scénario 2 : Serveur cible non sécurisé défini, mais vérification de l'état configurée avec un port sécurisé

Cette erreur se produit si vous avez défini un serveur cible non sécurisé, mais que le HealthMonitor est configuré avec un port sécurisé tel que 443. Pour vérifier si tel est le cas, procédez comme suit :
1. Vérifiez la définition du serveur cible utilisé dans la configuration du point de terminaison cible.
  Utilisez l' API Get 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 non sécurisé 80 correctement.
2. Ensuite, vérifiez la configuration du moniteur d'intégrité pour le serveur cible dans la configuration du point de terminaison cible :
  Configuration de HealthMonitor
  <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 contrôleur 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 serveur non sécurisé (le bloc SSLInfo n'est pas défini) avec le port non sécurisé 80 correctement, mais que le contrôleur d'état est configuré pour effectuer des vérifications d'état avec un port sécurisé 443 (spécifié dans l'élément <Port>).
  Dans ce cas, 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.

Solution

Port sécurisé cible non sécurisé

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

Pour résoudre ce problème, mettez à jour la définition du serveur cible afin d'utiliser un port sécurisé approprié.

Utilisez l' API de mise à jour d'un 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 indiqué dans l'exemple ci-dessous :

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

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

Scénario 2 : Serveur cible non sécurisé défini, mais vérification de l'état configurée avec un port sécurisé

Pour résoudre cette erreur, procédez comme suit :

Supprimez l'élément <Port> de la configuration du moniteur d'intégrité ou modifiez-la 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 répond avec 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 vérification d'état, faites défiler la page au-dessus de ces messages d'erreur courants et recherchez les erreurs/avertissements du HEALTH MONITOR.
Par exemple, un avertissement HEALTH MONITOR peut s'afficher, comme indiqué ci-dessous :
```
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 (nombre configuré dans le contrôleur d'état), 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 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 de l'état était 200, mais que le code de réponse réel reçu est 404. Par conséquent, il est considéré comme un échec.
Avant d'enquêter sur la cause de la réponse d'erreur de l'API de vérification de l'état, déterminez pourquoi Edge s'attend à ce que le code de réponse soit 200 pour l'API de vérification de l'état. Pour ce faire, vérifiez la configuration du moniteur d'état pour le serveur cible dans la configuration du point de terminaison cible :
Configuration de HealthMonitor
```
<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 l'objet HealthMonitor est définie avec le code de réponse 200 sous l'élément <SuccessResponse>. Cela signifie que si Edge reçoit 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 le nombre d'échecs sera incrémenté.
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 qui précède 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 la vérification d'état indiquée dans ce message.

Vous pouvez appeler directement cette URL depuis le processeur de messages et vérifier la réponse réelle.
```
curl -i https://mocktarget.apigee.net:443/status/200
          
```
La réponse de l'appel ci-dessus renvoie 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 à laquelle elle donne accès n'est plus disponible.
Dans l'exemple d'API de vérification de l'état fourni ci-dessus, le problème se produit, car une URL incorrecte a été utilisée dans la configuration du contrôleur d'état. L'URL correcte est https://mocktarget.apigee.net:443/statuscode/200 à partir de l'API de simulation cible.

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

Solution

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

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

Si le problème persiste, consultez la page Vous devez collecter des informations de diagnostic.

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

API Monitoring vous permet d'isoler rapidement les zones à problèmes pour diagnostiquer les problèmes d'erreur, de performances et de latence ainsi que leur source, tels que les applications de développeur, les proxys d'API, les cibles backend ou la plate-forme d'API.

Parcourez un exemple de scénario qui montre comment résoudre les problèmes 5xx avec vos API à l'aide d'API Monitoring. Par exemple, vous pouvez configurer une alerte pour être averti lorsque le nombre de défaillances 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 l'assistance Apigee et partagez-les :

Si vous êtes un utilisateur du cloud public, fournissez les informations suivantes :

Nom de l'organisation
Nom de l'environnement
Nom du proxy d'API
Commande curl complète pour reproduire l'erreur
Fichier de trace contenant les requêtes avec le code d'erreur 503 ServiceUnavailable et NoActiveTargets

Si vous êtes un utilisateur du cloud privé, fournissez les informations suivantes :
1. Message d'erreur complet observé
2. Nom de l'environnement
3. Bundle de proxy d'API
4. Fichier de trace contenant les requêtes avec le code d'erreur 503 ServiceUnavailable et 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)