Équilibrage de charge sur les serveurs de backend

Vous consultez la documentation Apigee Edge.
Accéder à la documentation d'Apigee X en savoir plus

Apigee Edge améliore la disponibilité de votre API en fournissant une compatibilité intégrée avec l'équilibrage de charge et le basculement sur plusieurs instances de serveur backend.

Les configurations TargetServer dissocient les URL de point de terminaison concrètes des configurations de TargetEndpoint. Chaque TargetServer est référencé par son nom dans une connexion HTTPTargetEndpoint. Au lieu de définir une URL concrète dans la configuration, vous pouvez configurer un ou plusieurs serveurs cibles nommés, comme décrit dans la section TargetEndpoint.

Une définition TargetServer se compose d'un nom, d'un hôte et d'un port, avec un élément supplémentaire permettant d'indiquer si le TargetServer est activé ou désactivé.

Vidéos

Regardez les vidéos suivantes pour en savoir plus sur le routage des API et l'équilibrage de charge à l'aide de serveurs cibles.

Vidéo	Description
Équilibrage de charge à l'aide de serveurs cibles	Équilibrer la charge des API sur plusieurs serveurs cibles.
Routage d'une API basé sur l'environnement à l'aide de serveurs cibles	Routage d'une API vers un serveur cible différent en fonction de l'environnement
Routage d'API et équilibrage de charge à l'aide de serveurs cibles (Edge classique)	Acheminez une API vers un autre serveur cible en fonction de l'environnement et équilibrez la charge de votre API sur les serveurs cibles de l'interface utilisateur Classic Edge.

Exemple de configuration TargetServer

Le code suivant définit un serveur cible:

<TargetServer  name="target1">
  <Host>1.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >

Éléments de configuration de TargetServer

Le tableau suivant décrit les éléments utilisés pour créer et configurer un TargetServer:

Nom	Description	Par défaut	Requis ?
name	Nom de la configuration du serveur cible, qui doit être unique au sein de l'environnement. Le nom TargetServer ne peut contenir que des caractères alphanumériques.	N/A	Oui
Host	URL d'hôte du service de backend (sans le protocole).	N/A	Oui
Port	Port sur lequel le service de backend écoute	N/A	Oui
IsEnabled	Booléen qui indique si la configuration TargetServer est activée ou désactivée. Cela vous permet d'arrêter la rotation des TargetServers sans modifier la configuration du proxy d'API. Une utilisation courante consiste à écrire une application ou un script qui active ou désactive automatiquement TargetServers en fonction des exigences de capacité attendues, des calendriers de maintenance, etc.	true	Oui

Gérer les serveurs cibles à l'aide de l'interface utilisateur

Gérez les serveurs cibles, comme décrit ci-dessous.

Gérer les serveurs cibles à l'aide de l'API

Vous pouvez utiliser l'API Edge pour créer, supprimer, mettre à jour, obtenir et répertorier les serveurs cibles. Pour en savoir plus, consultez la section TargetServers.

Utilisez l'appel d'API suivant pour créer un serveur cible:

$ curl -H "Content-Type:text/xml" -X POST -d \
'<TargetServer name="target1">
   <Host>1.mybackendservice.com</Host>
   <Port>80</Port>
   <IsEnabled>true</IsEnabled>
 </TargetServer>' \
-u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

Exemple de réponse :

{
  "host" : "1.mybackendservice.com",
  "isEnabled" : true,
  "name" : "target1",
  "port" : 80
}

Après avoir créé le premier TargetServer, utilisez l'appel d'API suivant pour créer un second TargetServer. En définissant deux TargetServers, vous fournissez deux URL qu'un TargetEndpoint peut utiliser pour l'équilibrage de charge :

$ curl -H "Content-type:text/xml" -X POST -d \
'<TargetServer  name="target2">
  <Host>2.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >' \
-u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

Exemple de réponse :

{
  "host" : "2.mybackendservice.com",
  "isEnabled" : true,
  "name" : "target2",
  "port" : 80
}

Utilisez l'appel d'API suivant pour récupérer la liste des serveurs cibles d'un environnement:

$ curl -u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

Exemple de réponse :

[ "target2", "target1" ]

Deux serveurs cibles peuvent désormais être utilisés par les proxys d'API déployés dans l'environnement de test. Pour équilibrer la charge du trafic entre ces TargetServers, vous configurez la connexion HTTP dans le point de terminaison cible d'un proxy d'API afin qu'elle utilise ces TargetServers.

Il existe une limite de 500 TargetServers par environnement, comme indiqué dans la rubrique Limites.

Configurer un TargetEndpoint de manière à effectuer un équilibrage de charge sur des TargetServers nommés

Maintenant que deux TargetServers sont disponibles, vous pouvez modifier le paramètre de connexion HTTP de TargetEndpoint pour référencer ces deux TargetServers par leur nom :

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Server name="target1" />
      <Server name="target2" />
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

La configuration ci-dessus est la configuration d'équilibrage de charge la plus basique possible. L'équilibreur de charge accepte trois algorithmes d'équilibrage de charge : Round robin (à tour de rôle), Weighted (pondération) et Least Connection (plus faible nombre de requêtes). Round robin est l'algorithme par défaut. Étant donné qu'aucun algorithme n'est spécifié dans la configuration ci-dessus, les requêtes sortantes du proxy d'API vers les serveurs backend alternent, une pour un, entre les cibles 1 et 2.

L'élément <Path> constitue le chemin de base de l'URI TargetEndpoint pour tous les serveurs cibles. Il n'est utilisé que lorsque <LoadBalancer> est utilisé. Sinon, il est ignoré. Dans l'exemple ci-dessus, une requête atteignant "target1" sera http://target1/test, et donc pour les autres serveurs cibles.

Définir les options de l'équilibreur de charge

Vous pouvez ajuster la disponibilité à l'aide d'options d'équilibrage de charge et de basculement au niveau de l'équilibreur de charge et du serveur cible. Cette section décrit ces options.

Algorithme

Définit l'algorithme utilisé par <LoadBalancer>. Les algorithmes disponibles sont RoundRobin, Weighted et LeastConnections. Ils sont décrits ci-dessous.

Round robin (à tour de rôle)

L'algorithme par défaut Round robin transfère une requête à chaque TargetServer, dans l'ordre dans lequel les serveurs sont répertoriés dans la connexion HTTP du point de terminaison cible. Exemple :

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Weighted

L'algorithme d'équilibrage de charge Weighted vous permet de configurer des charges de trafic proportionnelles pour vos TargetServers. L'équilibreur de charge pondéré distribue la requête à vos serveurs TargetServer en proportion directe de la pondération de chacun d'eux. Par conséquent, l'algorithme Weighted vous oblige à définir un attribut weight pour chaque TargetServer. Exemple :

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Algorithm>Weighted</Algorithm>
      <Server name="target1">
        <Weight>1</Weight>
      </Server>
      <Server name="target2">
        <Weight>2</Weight>
      </Server>
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Dans cet exemple, deux requêtes seront routées vers "target2" pour chaque requête routée vers "target1".

Least Connection

Les équilibreurs de charge configurés avec l'algorithme Least Connection routent les requêtes sortantes vers le TargetServer qui compte le plus petit nombre de connexions HTTP ouvertes. Exemple :

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>LeastConnections</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
  </HTTPTargetConnection>
  <Path>/test</Path>
</TargetEndpoint>

Nombre maximal d'échecs

Nombre maximal de requêtes en échec entre le proxy d'API et le TargetServer, ayant pour effet de rediriger la requête vers un autre TargetServer.

Un échec de réponse signifie qu'Apigee ne reçoit aucune réponse d'un serveur cible. Lorsque cela se produit, le compteur d'échecs augmente d'une unité.

Toutefois, lorsqu'Apigee reçoit une réponse d'une cible, même si la réponse est une erreur HTTP (telle que 500), elle est comptabilisée comme une réponse du serveur cible, et le compteur d'échecs est réinitialisé. Pour vous assurer que les réponses HTTP incorrectes (telles que 500) augmentent également le compteur d'échecs afin de retirer au plus vite un serveur défaillant de la rotation de l'équilibrage de charge, vous pouvez ajouter l'élément <ServerUnhealthyResponse> avec des éléments enfants <ResponseCode> à la configuration de votre équilibreur de charge. Edge comptabilisera également les réponses avec ces codes comme des échecs.

Dans l'exemple suivant, target1 sera supprimé de la rotation après cinq requêtes ayant échoué, y compris certaines réponses 5XX du serveur cible.

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
        <ServerUnhealthyResponse>
            <ResponseCode>500</ResponseCode>
            <ResponseCode>502</ResponseCode>
            <ResponseCode>503</ResponseCode>
        </ServerUnhealthyResponse>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Par défaut, le nombre maximal d'échecs est défini sur 0. Cela signifie que Edge tente toujours de se connecter à la cible pour chaque requête et ne supprime jamais le serveur cible de la rotation.

Il est préférable d'utiliser une valeur MaxFailures (nombre maximal d'échecs) supérieure à 0 avec un HealthMonitor. Si vous configurez MaxFailures > 0, TargetServer est supprimé de la rotation lorsque la cible échoue le nombre de fois que vous indiquez. Lorsqu'un HealthMonitor est en place, Apigee rétablit automatiquement le serveur cible en rotation une fois que la cible est de nouveau opérationnelle, en fonction de la configuration de ce HealthMonitor. Pour plus d'informations, consultez la page Surveillance de l'état.

Si vous configurez une valeur MaxFailures supérieure à 0 et que vous ne configurez pas d'objet HealthMonitor, Apigee ne réinclut pas le TargetServer dans la rotation automatiquement une fois qu'Apigee a détecté un échec. Dans ce cas, vous devez redéployer le proxy d'API avant qu'Apigee ne replace le TargetServer en rotation. Consultez la page Déployer un proxy d'API.

Réessayer

Si les nouvelles tentatives sont activées, une requête fera l'objet d'une nouvelle tentative en cas d'échec de réponse (erreur d'E/S ou expiration du délai HTTP) ou si la réponse correspond à une valeur définie par <ServerUnhealthyResponse>. Pour en savoir plus sur la définition de <ServerUnhealthyResponse>, consultez la section Nombre maximal d'échecs ci-dessus.

Par défaut, <RetryEnabled> est défini sur true. Définissez la valeur sur false pour désactiver les nouvelles tentatives. Exemple :

<RetryEnabled>false</RetryEnabled>

IsFallback

Un (et un seul) TargetServer peut être défini comme serveur "de remplacement". Le TargetServer de remplacement n'est pas inclus dans les routines d'équilibrage de charge tant que tous les autres TargetServers ne sont pas identifiés comme étant indisponibles par l'équilibreur de charge. Lorsque l'équilibreur de charge détermine que tous les TargetServers sont indisponibles, tout le trafic est routé vers le serveur de remplacement. Exemple :

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <Server name="target3">
          <IsFallback>true</IsFallback>
        </Server>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

La configuration ci-dessus entraîne un équilibrage de charge de type Round robin entre les cibles 1 et 2 jusqu'à ce qu'elles deviennent indisponibles. Lorsque les cibles 1 et 2 ne sont pas disponibles, l'intégralité du trafic est routé vers la cible 3.

Chemin

Le chemin définit un fragment d'URI qui sera ajouté à toutes les requêtes émises par le TargetServer au serveur de backend.

Cet élément accepte un chemin sous forme de chaîne littérale ou un modèle de message. Un modèle de message vous permet de remplacer une chaîne de variable au moment de l'exécution. Par exemple, dans la définition de point de terminaison cible suivante, la valeur de {mypath} est utilisée pour le chemin :

<HTTPTargetConnection>
    <SSLInfo>
      <Enabled>true</Enabled>
    </SSLInfo>
    <LoadBalancer>
      <Server name="testserver"/>
    </LoadBalancer>
    <Path>{mypath}</Path>
</HTTPTargetConnection>

Configurer un serveur cible pour TLS/SSL

Si vous utilisez un TargetServer pour définir le service de backend et que celui-ci nécessite une connexion au protocole HTTPS, vous devez activer TLS/SSL dans la définition du TargetServer. Cette opération est nécessaire, car le tag <Host> ne vous permet pas de spécifier le protocole de connexion. Vous trouverez ci-dessous la définition TargetServer du protocole TLS/SSL unidirectionnel où Edge envoie des requêtes HTTPS au service de backend:

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

Si le service de backend requiert une approche bidirectionnelle, ou mutuelle, pour les protocoles TLS/SSL, configurez le TargetServer à l'aide des mêmes paramètres de configuration TLS/SSL que ceux des TargetEndpoints :

<TargetServer  name="TargetServer 1">
    <IsEnabled>true</IsEnabled>
    <Host>www.example.com</Host>
    <Port>443</Port>
    <SSLInfo>
        <Ciphers/>
        <ClientAuthEnabled>true</ClientAuthEnabled>
        <Enabled>true</Enabled>
        <IgnoreValidationErrors>false</IgnoreValidationErrors>
        <KeyAlias>keystore-alias</KeyAlias>
        <KeyStore>keystore-name</KeyStore>
        <Protocols/>
        <TrustStore>truststore-name</TrustStore>
    </SSLInfo>
</TargetServer >

Pour en savoir plus sur les propriétés <SSLInfo>, telles que <Ciphers> et <ClientAuthEnabled>, consultez les informations sur la définition de ces propriétés pour un hôte virtuel dans la section Configurer l'accès TLS à une API pour le cloud privé.

Pour obtenir des instructions complètes sur la configuration du protocole TLS/SSL sortant, consultez la section Configurer TLS de Edge vers le backend (Cloud et cloud privé).

Schéma TargetServer

Consultez le schéma de TargetServer et d'autres entités sur GitHub.

Surveillance d'état

Cette fonctionnalité vous permet d'améliorer les configurations de l'équilibrage de charge en interrogeant activement les URL du service de backend définies dans les configurations TargetServer. Lorsque la surveillance de l'état est activée, un TargetServer en échec est automatiquement renvoyé en rotation lorsque l'objet HealthMonitor détermine que le TargetServer est actif.

La surveillance de l'état fonctionne avec le paramètre <MaxFailures>. Lorsque la surveillance de l'état est activée, <MaxFailures> spécifie le nombre de requêtes en échec entre le proxy d'API et le TargetServer qui a pour effet de rediriger la requête vers un autre TargetServer. Le TargetServer en échec est ensuite supprimé de la rotation jusqu'à ce que vous redéployiez le proxy.

Lorsque la surveillance de l'état est activée, un TargetServer défaillant est automatiquement renvoyé en rotation et aucun redéploiement de proxy n'est requis.

L'objet HealthMonitor agit comme un client simple qui appelle un service de backend via TCP ou HTTP :

• Un client TCP garantit simplement qu'un socket peut être ouvert.
• Vous devez configurer le client HTTP pour qu'il envoie une requête HTTP valide au service de backend. Vous pouvez définir des opérations HTTP GET, PUT, POST ou DELETE. La réponse de l'appel de surveillance HTTP doit correspondre aux paramètres configurés dans le bloc <SuccessResponse>.

Succès et échecs

Lorsque vous activez la surveillance de l'état, Edge commence à envoyer des vérifications de l'état à votre serveur cible. Une vérification d'état est une requête envoyée au serveur cible qui détermine si celui-ci est opérationnel ou non.

Une vérification d'état peut générer l'un des deux résultats suivants :

• Réussite:le serveur cible est considéré comme opérationnel lorsqu'une vérification de l'état réussit. Cela se produit généralement dans l'un ou plusieurs des cas suivants :
  • Le serveur cible accepte une nouvelle connexion au port spécifié, répond à une requête sur ce port, puis ferme le port dans le délai spécifié. La réponse du serveur cible contient "Connection: close".
  • Le serveur cible répond à une requête de vérification d'état avec un code d'état HTTP 200 (OK) ou tout autre code d'état HTTP que vous jugez acceptable.
  • Le serveur cible répond à une requête de vérification d'état avec un corps de message qui correspond à celui attendu.

  Lorsque Edge détermine qu'un serveur est sain, Edge continue ou reprend l'envoi de requêtes à celui-ci.

• Échec:le serveur cible peut échouer à une vérification de l'état de différentes manières, en fonction du type de vérification. Une défaillance peut être consignée lorsque le serveur cible :
  • Refuse une connexion depuis Edge vers le port de vérification de l'état.
  • Ne répond pas à une requête de vérification d'état dans un délai spécifié.
  • Renvoie un code d'état HTTP inattendu.
  • La réponse est envoyée avec un corps de message qui ne correspond pas à celui attendu.

  Lorsqu'un serveur cible échoue à une vérification de l'état, Edge incrémente le nombre d'échecs du serveur. Si le nombre d'échecs pour ce serveur atteint ou dépasse un seuil prédéfini (<MaxFailures>), Edge cesse d'envoyer des requêtes à ce serveur.

Activer un objet HealthMonitor

Pour créer un objet HealthMonitor, ajoutez l'élément <HealthMonitor> à la configuration HTTPConnection du TargetEndpoint correspondant à un proxy. Vous ne pouvez pas réaliser cette opération dans l'interface utilisateur. À la place, vous créez une configuration de proxy et la téléchargez en tant que fichier ZIP sur Edge. Une configuration de proxy est une description structurée de l'ensemble des aspects d'un proxy d'API. Les configurations de proxy sont constituées de fichiers XML organisés une structure de répertoires prédéfinie. Pour plus d'informations, consultez la documentation de référence sur la configuration des proxys d'API.

Un HealthMonitor simple définit un paramètre IntervalInSec avec un TCPMonitor ou un HTTPMonitor. L'élément <MaxFailures> spécifie le nombre de requêtes en échec entre le proxy d'API et le TargetServer qui a pour effet de rediriger la requête vers un autre TargetServer. Par défaut, <MaxFailures> est défini sur 0, ce qui signifie qu'Edge n'effectue aucune action corrective. Lors de la configuration d'un HealthMonitor, veillez à définir <MaxFailures> sur une valeur non nulle dans le tag <HTTPTargetConnection> du tag <TargetEndpoint>.

TCPMonitor

La configuration ci-dessous définit un objet HealthMonitor qui interroge chaque TargetServer en ouvrant une connexion sur le port 80 toutes les cinq secondes. (Le port est facultatif. S'il n'est pas spécifié, le port TCPMonitor est le port du TargetServer.)

• Si la connexion échoue ou prend plus de 10 secondes, le nombre d'échecs augmente d'une unité pour ce TargetServer.
• Si la connexion réussit, le nombre d'échecs pour le TargetServer est réinitialisé à zéro.

Vous pouvez ajouter un HealthMonitor en tant qu'enfant de l'élément HTTPTargetConnetion du TargetEndpoint, comme illustré ci-dessous :

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
      </LoadBalancer>
      <Path>/test</Path>
      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <TCPMonitor>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
            <Port>80</Port>
        </TCPMonitor>
      </HealthMonitor>
  </HTTPTargetConnection>
. . .

HealthMonitor avec les éléments de configuration TCPMonitor

Le tableau suivant décrit les éléments de configuration TCPMonitor :

Nom	Description	Par défaut	Obligatoire ?
IsEnabled	Valeur booléenne qui active ou désactive HealthMonitor.	false	Non
IntervalInSec	Intervalle de temps, en secondes, entre chaque requête TCP sondant le service.	0	Oui
ConnectTimeoutInSec	Intervalle pendant lequel la connexion au port TCP doit être établie pour être considérée comme un succès. L'échec de la connexion dans l'intervalle spécifié compte comme un échec et a pour effet d'augmenter le nombre d'échecs de l'équilibreur de charge pour le TargetServer.	0	Oui
Port	Facultatif. Port sur lequel la connexion TCP est établie. S'il n'est pas spécifié, le port TCPMonitor est le port du TargetServer.	0	Non

HTTPMonitor

Un exemple d'objet HealthMonitor utilisant HTTPMonitor envoie une requête GET au service de backend toutes les cinq secondes. L'exemple ci-dessous ajoute un en-tête d'autorisation HTTP de base (Basic Authorization) au message de la requête. La configuration de la réponse définit les paramètres qui seront comparés à la réponse réelle du service de backend. Dans l'exemple ci-dessous, la réponse attendue est un code de réponse HTTP 200 et un en-tête HTTP personnalisé ImOK dont la valeur est YourOK. Si la réponse ne correspond pas, la requête est alors traitée comme un échec par la configuration de l'équilibreur de charge.

HTTPMonitor est compatible avec les services de backend configurés pour utiliser les protocoles HTTP et HTTPS unidirectionnels. Toutefois, elle n'accepte pas les éléments suivants:

• HTTPS bidirectionnel (également appelé TLS/SSL bidirectionnel)
• Certificats autosignés

Notez que tous les paramètres de requête et de réponse d'un objet HTTPMonitor sont spécifiques au service de backend qui doit être appelé.

    <HealthMonitor>
      <IsEnabled>true</IsEnabled>
      <IntervalInSec>5</IntervalInSec>
      <HTTPMonitor>
        <Request>
          <IsSSL>true</IsSSL>
          <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
          <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
          <Port>80</Port>
          <Verb>GET</Verb>
          <Path>/healthcheck</Path>
          <Header name="Authorization">Basic 12e98yfw87etf</Header>
          <IncludeHealthCheckIdHeader>true</IncludeHealthCheckIdHeader>
        </Request>
        <SuccessResponse>
          <ResponseCode>200</ResponseCode>
          <Header name="ImOK">YourOK</Header>
        </SuccessResponse>
      </HTTPMonitor>
    </HealthMonitor>
    

HealthMonitor avec les éléments de configuration HTTPMonitor

Le tableau suivant décrit les éléments de configuration HTTPMonitor :

Nom	Description	Par défaut	Obligatoire ?
IsEnabled	Valeur booléenne qui active ou désactive HealthMonitor.	false	Non
IntervalInSec	Intervalle de temps, en secondes, entre chaque requête sondant le service.	0	Oui
Request	Options de configuration pour le message de requête sortant envoyé par l'objet HealthMonitor aux TargetServers figurant dans la rotation. Le chemin n'accepte pas les variables.	N/A	Oui
IsSSL	Spécifie si le protocole HTTPS (HTTP sécurisé) doit être utilisé pour surveiller les connexions. Valeurs potentielles : true: HTTPS est utilisé. false: le protocole HTTP est utilisé. Non spécifié: utilise la configuration du serveur cible.	false	Non
ConnectTimeoutInSec	Intervalles, en secondes, pendant lequel le handshake de connexion TCP au service HTTP doit être réalisé pour être considéré comme un succès. L'échec de la connexion dans l'intervalle spécifié compte comme un échec et a pour effet d'augmenter le nombre d'échecs de l'équilibreur de charge pour le TargetServer.	0	Non
SocketReadTimeoutInSec	Intervalle, en secondes, pendant lequel les données doivent être lues à partir du service HTTP pour que la lecture soit considérée comme un succès. L'échec de la lecture dans l'intervalle spécifié compte comme un échec et a pour effet d'augmenter le nombre d'échecs de l'équilibreur de charge pour le TargetServer.	0	Non
Port	Port sur lequel est établie la connexion HTTP au service de backend.	N/A	Non
Verb	Verbe HTTP utilisé pour chaque requête HTTP d'interrogation envoyée au service de backend.	N/A	No
Path	Chemin ajouté à l'URL définie dans le TargetServer. Utilisez l'élément Path pour configurer un "point de terminaison d'interrogation" sur votre service HTTP.	N/A	Non
IncludeHealthCheckIdHeader	Permet de suivre les requêtes de vérification d'état sur les systèmes en amont. Le paramètre IncludeHealthCheckIdHeader prend une valeur booléenne et la valeur par défaut false. Si vous le définissez sur true, un Header nommé X-Apigee-Healthcheck-Id est injecté dans la requête de vérification d'état. La valeur de l'en-tête est attribuée de manière dynamique et se présente sous la forme ORG/ENV/SERVER_UUID/N, où ORG est le nom de l'organisation et ENV est le nom de l'environnement, SERVER_UUID est un ID unique identifiant le processeur de messages, et N correspond au nombre de millisecondes écoulées depuis le 1er janvier 1970. Exemple d'en-tête de requête obtenu : X-Apigee-Healthcheck-Id: orgname/envname/E8C4D2EE-3A69-428A-8616-030ABDE864E0/1586802968123	false	Non
Payload	Corps HTTP généré pour chaque requête HTTP d'interrogation. Notez que cet élément n'est pas exigé pour les requêtes GET.	N/A	Non
SuccessResponse	Options de correspondance pour le message de réponse HTTP entrant généré par le service de backend interrogé. Les réponses qui ne correspondent pas incrémentent le nombre d'échecs de 1.	N/A	Non
ResponseCode	Code de réponse HTTP attendu en provenance du TargetServer interrogé. Un code différent du code spécifié constitue un échec, et le nombre d'échecs est incrémenté pour le service de backend interrogé. Vous pouvez définir plusieurs éléments ResponseCode.	N/A	Non
Headers	Liste d'un ou plusieurs en-têtes et valeurs HTTP attendus en provenance du service de backend interrogé. Tout en-tête ou valeur HTTP de réponse qui diffère des éléments spécifiés ici entraîne un échec, et le décompte est incrémenté de 1 pour le TargetServer interrogé. Vous pouvez définir plusieurs éléments d'en-tête.	N/A	Non