Équilibrage de charge sur les serveurs de backend

Cette page s'applique à Apigee et à Apigee hybrid.

Consultez la documentation d'Apigee Edge.

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

Les TargetServers dissocient les URL de point de terminaison concrètes des configurations TargetEndpoint. Au lieu de définir une URL concrète dans la configuration, vous pouvez configurer un ou plusieurs TargetServers nommés. Ensuite, chaque TargetServer est référencé par son nom dans la configuration HTTPConnection d'un TargetEndpoint.

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

À propos de la configuration TargetServer

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

Le code suivant fournit un exemple de configuration TargetServer :

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

Pour en savoir plus sur l'API TargetServers, consultez la page organizations.environments.targetservers.

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

Créer des TargetServers

Créez des TargetServers à l'aide de l'UI ou de l'API Apigee, comme décrit dans les sections suivantes.

Apigee dans la console Cloud

Pour créer des TargetServers à l'aide d'Apigee dans la console Cloud, procédez comme suit:

Connectez-vous à l'interface utilisateur Apigee dans la console Cloud.
Sélectionnez Gestion > Environnements > TargetServers.
Sélectionnez l'environnement dans lequel vous souhaitez définir un nouveau TargetServer.
Cliquez sur Serveurs cibles en haut du volet.
Cliquez sur + Créer un serveur cible.
Saisissez un nom, un hôte, un protocole et un port dans les champs fournis. Les options de protocole sont les suivantes : HTTP pour les serveurs cibles basés sur REST et gRPC - Cible pour les serveurs cibles basés sur gRPC, ou gRPC - Appel externe. Consultez la page Créer des proxys d'API gRPC pour en savoir plus sur la compatibilité des proxys gRPC.
Vous pouvez éventuellement sélectionner Activer SSL. Consultez la page Présentation des certificats SSL.
Cliquez sur Créer.

Apigee classique

Pour créer des TargetServers en utilisant l'interface utilisateur classique d'Apigee, procédez comme suit :

Connectez-vous à l'UI Apigee.
Sélectionnez Admin > Environments > TargetServers (Administration > Environnements > TargetServers).
Dans la liste déroulante Environment (Environnement), sélectionnez l'environnement dans lequel vous souhaitez définir un nouveau TargetServer.
L'UI Apigee affiche la liste des TargetServers actuels dans l'environnement sélectionné :
Cliquez sur +Target server (+ Serveur cible) pour ajouter un nouveau TargetServer dans l'environnement sélectionné.
La boîte de dialogue Ajouter un serveur cible s'affiche :
Cliquez sur Enabled (Activé) pour activer le nouveau TargetServer. Définissez-le dès sa création.
Saisissez un nom, un hôte, un protocole et un port dans les champs fournis. Les options de protocole sont HTTP et GRPC.

Vous pouvez éventuellement cocher la case SSL. Pour en savoir plus sur ces champs, regardez la vidéo sur les TargetServers de la série "Quatre minutes de vidéo pour les développeurs" (4MV4D).
Cliquez sur Add (Ajouter).
Apigee crée la nouvelle définition du TargetServer.
Après avoir créé un TargetServer, vous pouvez modifier votre proxy d'API ainsi que l'élément <HTTPTargetConnection> pour référencer la nouvelle définition.

API Apigee

Les sections suivantes fournissent des exemples d'utilisation de l'API Apigee pour créer et répertorier des TargetServers.

Créer un TargetServer dans un environnement à l'aide de l'API
Répertorier les TargetServers d'un environnement à l'aide de l'API

Pour plus d'informations, consultez la page sur l'API TargetServers.

Créer un TargetServer dans un environnement à l'aide de l'API

Pour créer un TargetServer nommé target1 qui se connecte à 1.mybackendservice.com sur le port 80, utilisez l'appel d'API suivant :

curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \
  -X POST \
  -H "Content-Type:application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '
  {
  "name": "target1",
  "host": "1.mybackendservice.com",
  "protocol": "http",
  "port": "80",
  "isEnabled": "true",
  }'

Où $TOKEN est défini sur votre jeton d'accès OAuth 2.0, comme décrit dans la section Obtenir un jeton d'accès OAuth 2.0. Pour en savoir plus sur les options curl utilisées dans cet exemple, consultez la section Utiliser curl. Pour obtenir une description des variables d'environnement utilisées, consultez la section Définir des variables d'environnement pour les requêtes API Apigee.

Voici un exemple de réponse :

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

Créez un deuxième TargetServer à l'aide de l'appel d'API suivant. En définissant deux TargetServers, vous fournissez deux URL qu'un TargetEndpoint peut utiliser pour l'équilibrage de charge :

curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \
  -X POST \
  -H "Content-Type:application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '
  {
  "name": "target2",
  "host": "2.mybackendservice.com",
  "protocol": "http",
  "port": "80",
  "isEnabled": "true",
  }'

Voici un exemple de réponse :

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

Répertorier les TargetServers d'un environnement à l'aide de l'API

Pour répertorier les TargetServers dans un environnement, utilisez l'appel d'API suivant :

curl https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers \
  -H "Authorization: Bearer $TOKEN"

Voici un exemple de réponse :

[ "target2", "target1" ]

Deux TargetServers sont désormais disponibles et utilisables par les proxys d'API déployés dans l'environnement 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.

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. 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 de backend s'alternent à tour de rôle entre target1 et target2.

L'élément <Path> constitue le chemin de base de l'URI TargetEndpoint pour tous les TargetServers. Il n'est utilisé que lorsque <LoadBalancer> est utilisé. Sinon, il est ignoré. Dans l'exemple ci-dessus, une requête adressées à target1 se présente au format http://target1/test, et ainsi de suite pour d'autres TargetServers.

Pour en savoir plus, consultez la section Point de terminaison cible.

Configurer les options de l'équilibreur de charge

Vous pouvez ajuster la disponibilité en configurant les options d'équilibrage de charge et de basculement au niveau de l'équilibreur de charge et du TargetServer, comme décrit dans les sections suivantes.

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é répartit les requêtes dans vos TargetServers proportionnellement à la pondération de chaque TargetServer. 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 acheminées vers target2 pour chaque requête acheminé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.

Une réponse en échec signifie qu'Apigee ne reçoit aucune réponse d'un TargetServer. Lorsque cela se produit, le compteur d'échecs augmente d'une unité.

Toutefois, lorsque Apigee reçoit une réponse d'une cible, même s'il s'agit d'une erreur HTTP (par exemple, une erreur 500), celle-ci est comptabilisée comme une réponse du TargetServer, et le compteur d'échecs est réinitialisé. Pour vous assurer que les réponses HTTP incorrectes (telles que les erreurs 500) incrémentent également le compteur d'échecs visant à retirer dès que possible un serveur non opérationnel de la rotation d'équilibrage de charge, vous pouvez ajouter l'élément <ServerUnhealthyResponse> avec des éléments enfants <ResponseCode> à la configuration de votre équilibreur de charge. Apigee comptabilise alors comme des échecs les réponses comportant ces codes.

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

<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 qu'Apigee tente toujours de se connecter à la cible pour chaque requête et ne supprime jamais le TargetServer 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 la configurez sur une valeur supérieure à 0, le TargetServer est supprimé de la rotation lorsque la cible échoue le nombre de fois que vous avez indiqué. Lorsqu'un HealthMonitor est en place, Apigee replace automatiquement le TargetServer en rotation une fois que la cible est à nouveau opérationnelle, en fonction de la configuration de cet HealthMonitor. Pour en savoir plus, consultez la section Surveillance d'état.

Si vous configurez une valeur MaxFailures supérieure à 0 et que vous ne configurez pas d'objet HealthMonitor, Apigee désactive automatiquement la rotation du TargetServer lorsque la première défaillance est détectée. Apigee vérifie l'état du TargetServer toutes les cinq minutes et le renvoie à la rotation lorsqu'il répond normalement.

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 target1 et target2 jusqu'à ce que target1 et target2 deviennent indisponibles. Lorsque target1 et target2 sont indisponibles, tout le trafic est acheminé vers target3.

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 TargetServer 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 du TargetServer pour les protocoles TLS/SSL unidirectionnels, où Apigee envoie des requêtes HTTPS au service de backend :

{
  "name": "target1",
  "host": "mocktarget.apigee.net",
  "protocol": "http",
  "port": "443",
  "isEnabled": "true",
  "sSLInfo": {
    "enabled": "true"
  }
}

Remarque : Si vous définissez le bloc sSLInfo dans les définitions du TargetEndpoint et du TargetServer, celle du TargetServer est prioritaire.

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 :

{
  "name": "TargetServer 1",
  "host": "www.example.com",
  "protocol": "http",
  "port": "443",
  "isEnabled": "true",
  "sSLInfo": {
    "enabled": "true",
    "clientAuthEnabled": "true",
    "keyStore": "keystore-name",
    "keyAlias": "keystore-alias",
    "trustStore": "truststore-name",
    "ignoreValidationErrors": "false",
    "ciphers": []
  }
}

Pour créer un TargetServer avec SSL à l'aide d'un appel d'API :

curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \
  -X POST \
  -H "Content-Type:application/json"  \
  -H "Authorization: Bearer $TOKEN" \
  -d '
  {
    "name": "TargetServer 1",
    "host": "www.example.com",
    "protocol": "http",
    "port": 443,
    "isEnabled": true,
    "sSLInfo":
    {
      "enabled":true,
      "clientAuthEnabled":true,
      "keyStore":"keystore-name",
      "keyAlias":"keystore-alias",
      "ciphers":[],
      "protocols":[],
      "clientAuthEnabled":true,
      "ignoreValidationErrors":false,
      "trustStore":"truststore-name"
    }
  }'

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, les TargetServers inaccessibles ou renvoyant une réponse d'erreur sont marqués comme non opérationnels. Un TargetServer en échec est automatiquement renvoyé en rotation lorsque l'objet HealthMonitor détermine que le TargetServer est actif. Aucun redéploiement de proxy n'est requis.

Vous devez définir une valeur <MaxFailures> supérieure à 0 lorsque vous utilisez l'objet HealthMonitor. Si la valeur <MaxFailures> est définie sur 0, Apigee tente toujours de se connecter à la cible pour chaque requête et ne supprime jamais le TargetServer de la rotation.

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, Apigee commence à envoyer des vérifications d'état à votre serveur cible. Une vérification d'état est une requête envoyée au TargetServer, 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 :

Succès : le TargetServer est considéré comme opérationnel lorsqu'une vérification d'état réussit. Cela se produit généralement dans l'un ou plusieurs des cas suivants :
- Le TargetServer 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 TargetServer contient Connection: close.
- Le TargetServer répond à une requête de vérification d'état avec un code 200 (OK) ou un autre code d'état HTTP que vous déterminez comme acceptable.
- Le TargetServer répond à une requête de vérification d'état avec un corps de message qui correspond à celui attendu.
Lorsqu'Apigee détermine qu'un serveur est opérationnel, Apigee continue ou reprend l'envoi de requêtes à ce serveur.
Échec : le TargetServer peut échouer à une vérification d'état de différentes manières, en fonction du type de vérification. Un échec peut être enregistré lorsque le TargetServer :
- refuse la connexion d'Apigee au port de la vérification d'état ;
- ne répond pas à une requête de vérification d'état dans le délai spécifié ;
- renvoie un code d'état HTTP inattendu ;
- répond avec un corps de message qui ne correspond pas à celui attendu.
Lorsqu'un TargetServer est défaillant lors d'une vérification de l'état, Apigee incrémente le nombre d'échecs associé au serveur. Si le nombre d'échecs de ce serveur atteint ou dépasse un seuil prédéfini (<MaxFailures>), Apigee interrompt l'envoi de 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. Au lieu de cela, vous créez une configuration de proxy puis vous l'importez dans Apigee en tant que fichier ZIP. 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. La valeur <MaxFailures> est définie par défaut sur 0, ce qui signifie qu'Apigee 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>
</TargetEndpoint>

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.	faux	No
`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	No

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, cet objet n'est pas compatible avec le protocole HTTPS bidirectionnel, également appelé protocole TLS/SSL bidirectionnel, ou avec des 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é.

    <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>
          <HTTPMonitor>
            <Request>
              <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>
      </HTTPTargetConnection>
    </TargetEndpoint>

Éléments de configuration <HTTPMonitor>

Le tableau suivant décrit les éléments de configuration <HTTPMonitor> de premier niveau :

Nom	Description	Par défaut	Obligatoire ?
`IsEnabled`	Valeur booléenne qui active ou désactive HealthMonitor.	faux	No
`IntervalInSec`	Intervalle de temps, en secondes, entre chaque requête sondant le service.	0	Oui

Éléments de configuration <HTTPMonitor>/<Request>

Options de configuration pour le message de requête sortant envoyé par l'objet HealthMonitor aux TargetServers figurant dans la rotation. Notez que <Request> est un élément obligatoire.

Nom	Description	Par défaut	Requis ?
`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	No
`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	No
`Port`	Port sur lequel est établie la connexion HTTP au service de backend.	Port du serveur cible	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. Notez que l'élément `Path` n'est pas compatible avec les variables.	N/A	No
`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`	faux	No
`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`.	Non disponible	Non

Éléments de configuration <HTTPMonitor>/<SuccessResponse>

(Facultatif) 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.

Nom	Description	Par défaut	Requis ?
`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	No
`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	No