Balanceo de cargas entre servidores de backend

Apigee mejora la disponibilidad de tu API, ya que proporciona compatibilidad integrada para el balanceo de cargas y la conmutación por error en varias instancias del servidor de backend.

TargetServers desvincula las URL de extremo concretas de las configuraciones de TargetEndpoint. En lugar de definir una URL concreta en la configuración, puedes configurar uno o más nombres TargetServers. Luego, se hace referencia a cada TargetServer por nombre en un HHTPConnection de TargetEndpoint.

Videos

Mira los siguientes videos para obtener más información sobre el enrutamiento de API y el balanceo de cargas mediante servidores de destino

Video Descripción
Balanceo de cargas con servidores de destino API de balanceo de cargas en servidores de destino.
Enrutamiento de API según el entorno mediante servidores objetivo Dirige una API a un servidor de destino diferente según el entorno.

Acerca de la configuración TargetServer

Una configuración de TargetServer consta de un nombre, un host y un puerto, con un elemento adicional para indicar si TargetServer está habilitado o inhabilitado.

El siguiente código proporciona un ejemplo de una configuración de TargetServer:

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

En la siguiente tabla, se describen los elementos usados para configurar un TargetServer:

Nombre Descripción Predeterminada ¿Es obligatorio?
name Nombre de la configuración de TargetServer, que debe ser única en el entorno y contener solo caracteres alfanuméricos. N/A
Host URL del host del servicio de backend (sin el protocolo) N/A
Port Puerto en el que escucha el servicio de backend N/A
IsEnabled Indicador que especifica si la configuración TargetServer está habilitada o inhabilitada. Con esta marca, puedes quitar TargetServers de rotación sin modificar la configuración del proxy de la API. Un uso común sería escribir una app o una secuencia de comandos que habilite o inhabilite TargetServers automáticamente en función de los requisitos de capacidad esperados, los programas de mantenimiento, etcétera. true

Consulta el esquema de TargetServer y otras entidades en GitHub.

Crea TargetServers

Crea TargetServers con la IU o API de Apigee como se describe en las siguientes secciones.

IU de Apigee

Para crear TargetServers con la IU de Apigee, sigue estos pasos:

  1. Accede a la IU de Apigee.
  2. Selecciona Administrador > Entornos > TargetServers.
  3. En la lista desplegable Entorno, selecciona el entorno para el que deseas definir un servidor de destino nuevo.

    La IU de Apigee muestra una lista de TargetServers actuales en el entorno seleccionado:

  4. Haz clic en +Servidor de destino para agregar un TargetServer nuevo al entorno seleccionado.

    Aparecerá el cuadro de diálogo Agregar servidor de destino:

  5. Haz clic en Habilitado para habilitar el nuevo TargetServer. definición inmediatamente después de crearla.
  6. Ingresa un nombre, un host y un puerto en los campos proporcionados. Selecciona la casilla de verificación SSL de forma opcional. Para obtener más información sobre estos campos, consulta TargetServers (video de MV4D).
  7. Haga clic en Add.

    Apigee crea la nueva definición de TargetServer.

  8. Después de crear un nuevo servidor de destino, puedes editar el proxy de API y cambiar el elemento <HTTPTargetConnection> para hacer referencia a la nueva definición.

API de Apigee

En las siguientes secciones, se proporcionan ejemplos sobre el uso de la API de Apigee para crear y enumerar servidores TargetServers.

Para obtener más información, consulta la API de TargetServers.

Crea un TargetServer en un entorno mediante la API

Para crear un TargetServer llamado target1 que se conecta a 1.mybackendservice.com en el puerto 80, usa la siguiente llamada a la API:

curl "https://apigee.googleapis.com/v1/organization/$ORG/environments/$ENV/targetservers" \
  -X POST \
  -H "Content-Type:text/xml" \
  -d '
  <TargetServer name="target1">
   <Host>1.mybackendservice.com</Host>
   <Port>80</Port>
   <IsEnabled>true</IsEnabled>
 </TargetServer>' \
  -H "Authorization: Bearer $TOKEN"
 

En el ejemplo anterior, $TOKEN está configurado como tu token de acceso de OAuth 2.0, como se describe en Obtén un token de acceso de OAuth 2.0. Para obtener información sobre las opciones de curl que se usan en este ejemplo, consulta Usa curl. Si deseas obtener una descripción de las variables de entorno que se usaron, consulta Configura variables de entorno para solicitudes a la API de Apigee.

A continuación, se proporciona un ejemplo de la respuesta.

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

Crea un segundo TargetServer con la siguiente llamada a la API. Cuando defines dos TargetServers, proporcionas dos URL que un TargetEndpoint puede usar para el balanceo de cargas:

curl https://apigee.googleapis.com/v1/organization/$ORG/environments/$ENV/targetservers \
  -X POST \
  -H "Content-type:text/xml" \
  -d '<TargetServer  name="target2">
    <Host>2.mybackendservice.com</Host>
    <Port>80</Port>
    <IsEnabled>true</IsEnabled>
  </TargetServer >' \
  -H "Authorization: Bearer $TOKEN"

A continuación, se proporciona un ejemplo de la respuesta.

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

Enumera los TargetServers en un entorno con la API

Para enumerar los TargetServers en un entorno, usa la siguiente llamada a la API:

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

A continuación, se proporciona un ejemplo de la respuesta.

[ "target2", "target1" ]

Ahora hay dos TargetServers disponibles para que los proxies de API los implementen en el entorno de test. Para balancear las cargas de tráfico en estos TargetServers, configura la conexión HTTP en el extremo de destino de un proxy de API para usar los TargetServers.

Configura un TargetEndpoint para balancear las cargas en todos los TargetServers con nombre

Ahora que tienes dos TargetServers disponibles, puedes modificar la configuración de la conexión HTTP de TargetEndpoint para hacer referencia a esos dos TargetServers por nombre:

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

La configuración anterior es la configuración de balanceo de cargas más básica. El balanceador de cargas admite tres algoritmos de balanceo de cargas, Round Robin, Pondered y Least Connection. Round Robin es el algoritmo predeterminado. Debido a que no se especifica ningún algoritmo en la configuración anterior, las solicitudes salientes del proxy de API a los servidores de backend se alternarán, una a una, entre target1 y target2.

El elemento <Path> forma la ruta base del URI TargetEndpoint para todos los TargetServers. Solo se usa cuando se usa <LoadBalancer>. De lo contrario, se ignora. En el ejemplo anterior, una solicitud que alcanza “target1” será http://target1/test y así para otros TargetServers.

Para obtener más información, consulta TargetEndpoint.

Configura las opciones del balanceador de cargas

Puedes ajustar la disponibilidad mediante la configuración de las opciones de balanceo de cargas y conmutación por error a nivel del balanceador de cargas y TargetServer como se describe en las siguientes secciones.

Algoritmo

Configura el algoritmo que usa <LoadBalancer>. Los algoritmos disponibles son RoundRobin, Weighted y LeastConnections, cada uno de los cuales se documenta a continuación.

Turnos rotativos

El algoritmo predeterminado, round robin, reenvía una solicitud a cada TargetServer en el orden en que los servidores aparecen en la conexión HTTP del extremo de destino. Por ejemplo:

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

Peso

El algoritmo de balanceo de cargas ponderado te permite configurar cargas de tráfico proporcionales para tus TargetServers. El LoadBalancer ponderado distribuye la solicitud a tus TargetServers directamente en el peso de cada TargetServer. Por lo tanto, el algoritmo ponderado requiere que establezcas un atributo weight para cada TargetServer. Por ejemplo:

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

En este ejemplo, dos solicitudes se enrutarán a target2 para cada una de las solicitudes enrutadas a target1.

Conexión mínima

Los LoadBalancers configurados para usar las solicitudes de salida de algoritmo de conexión mínimos para TargetServer con menos conexiones HTTP abiertas Por ejemplo:

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

Cantidad máxima de fallas

La cantidad máxima de solicitudes fallidas del proxy de API a TargetServer, que da como resultado la solicitud a otro TargetServer.

Un error de respuesta significa que Apigee no recibe ninguna respuesta de un TargetServer. Cuando esto sucede, el contador de fallas aumenta de a uno.

Sin embargo, cuando Apigee recibe una respuesta de un objetivo, incluso si la respuesta es un error de HTTP (como 500), se cuenta como una respuesta de TargetServer y el contador de fallas se restablece. Para ayudar a garantizar que las respuestas HTTP incorrectas (como 500) también aumenten el contador de fallas a fin de eliminar un servidor en mal estado de la rotación del balanceo de cargas lo antes posible, puedes agregar el elemento <ServerUnhealthyResponse> con elementos secundarios <ResponseCode> en la configuración de tu balanceador de cargas. Apigee también contará las respuestas con esos códigos como fallas.

En el siguiente ejemplo, target1 se quitará de la rotación después de cinco solicitudes fallidas, incluidas algunas respuestas 5XX del 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>

El valor predeterminado de MaxFails es 0. Esto significa que Apigee siempre intenta conectarse al objetivo de cada solicitud y nunca quita TargetServer de la rotación.

Reintentar

Si se habilita un reintento, se reintentará una solicitud cada vez que se produzca un error de respuesta (error de E/S o tiempo de espera HTTP) o la respuesta recibida coincida con un valor establecido por <ServerUnhealthyResponse>. Consulta la sección Cantidad máxima de errores que se encuentra más arriba para obtener más información sobre la configuración de <ServerUnhealthyResponse>.

De forma predeterminada, <RetryEnabled> se configura como true. Configúralo como false para inhabilitar el reintento. Por ejemplo:

<RetryEnabled>false</RetryEnabled>

IsFallback

Un (y solo uno) TargetServer se puede establecer como el servidor de reserva. El TargetServer de resguardo no se incluye en las rutinas de balanceo de cargas hasta que el balanceador de cargas identifique todos los demás TargetServers. Cuando el balanceador de cargas determina que todos los TargetServers no están disponibles, todo el tráfico se enruta al servidor de resguardo. Por ejemplo:

<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 configuración anterior da como resultado el balanceo de cargas round robin entre objetivos 1 y 2 hasta que ambos objetivos 1 y 2 no estén disponibles. Cuando los objetivos 1 y 2 no están disponibles, todo el tráfico se enruta al objetivo 3.

Ruta

La ruta de acceso define un fragmento de URI que se agregará a todas las solicitudes que envía TargetServer al servidor de backend.

Este elemento acepta una ruta de acceso de string literal o una plantilla de mensaje. Una plantilla de mensaje te permite realizar sustituciones de strings variables en el entorno de ejecución. Por ejemplo, en la siguiente definición de extremo de destino, el valor de {mypath} se usa para la ruta:

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

Configura un TargetServer para TLS/SSL

Si usas un TargetServer para definir el servicio de backend y este requiere la conexión para usar el protocolo HTTPS, debes habilitar TLS/SSL en la definición de TargetServer. Esto es necesario porque la etiqueta <Host> no te permite especificar el protocolo de conexión. A continuación, se muestra la definición TargetServer para TLS/SSL unidireccional, en la que Apigee realiza solicitudes HTTPS al servicio de backend:

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

Si el servicio de backend requiere bidireccionalidad o TLS/SSL, configura el TargetServer con la misma configuración de TLS/SSL que 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 >

Supervisión del estado

La supervisión del estado te permite mejorar las opciones de configuración de balanceo de cargas mediante un sondeo activo de las URL del servicio de backend definidas en las configuraciones de TargetServer. Cuando la supervisión de estado está habilitada, un TargetServer con error vuelve a colocar automáticamente la rotación cuando HealthMonitor determina que TargetServer está activo.

La supervisión del estado funciona con <MaxFailures>. Sin la supervisión de estado habilitada, <MaxFailures> especifica la cantidad de solicitudes fallidas del proxy de API al TargetServer, que da como resultado la solicitud a otro TargetServer. Luego, el TargetServer con errores se elimina de la rotación hasta que vuelvas a implementar el proxy.

Cuando la supervisión de estado está habilitada, un TargetServer con errores vuelve a colocar automáticamente la rotación y no es necesario volver a implementar el proxy.

HealthMonitor actúa como un cliente simple que invoca un servicio de backend mediante TCP o HTTP:

  • Un cliente TCP simplemente garantiza que se pueda abrir un socket.
  • Configura el cliente HTTP para que envíe una solicitud HTTP válida al servicio de backend. Puedes definir operaciones HTTP GET, PUT, POST o DELETE. La respuesta de la llamada al monitor HTTP debe coincidir con la configuración establecida en el bloque <SuccessResponse>.

Éxitos y fallas

Cuando habilitas la supervisión de estado, Apigee comienza a enviar verificaciones de estado a tu servidor de destino. Una verificación de estado es una solicitud que se envía al TargetServer y que determina si el TargetServer está en buen estado o no.

Una verificación de estado puede tener uno de dos resultados posibles:

  • Correcto: TargetServer se considera en buen estado cuando se produce una verificación de estado exitosa. Por lo general, este es el resultado de uno o más de los siguientes pasos:
    • TargetServer acepta una nueva conexión al puerto especificado, responde a una solicitud en ese puerto y, luego, cierra el puerto en el plazo especificado. La respuesta del TargetServer contiene Connection: close
    • TargetServer responde a una solicitud de verificación de estado con un código HTTP 200 (OK) o algún otro código de estado HTTP que sea aceptable.
    • TargetServer responde a una solicitud de verificación de estado con un cuerpo de mensaje que coincide con el cuerpo del mensaje esperado.

    Cuando Apigee determina que un servidor está en buen estado, Apigee continúa o reanuda el envío de solicitudes a este.

  • Error: TargetServer puede fallar a una verificación de estado de diferentes maneras, según el tipo de verificación. Se puede registrar una falla cuando el TargetServer:
    • Usa una conexión de Apigee al puerto de verificación de estado.
    • No responde a una solicitud de verificación de estado en un período específico.
    • Muestra un código de estado HTTP inesperado.
    • Responde con un cuerpo de mensaje que no coincide con el cuerpo del mensaje esperado.

    Cuando un TargetServer falla a una verificación de estado, Apigee aumenta el recuento de fallas de ese servidor. Si la cantidad de fallas para ese servidor alcanza o supera un umbral predefinido (<MaxFailures>), Apigee deja de enviar solicitudes a ese servidor.

Habilita un HealthMonitor

Para crear un HealthMonitor, debes agregar el elemento <HealthMonitor> a la configuración HTTPConnection de TargetEndpoint para un proxy. No puedes hacer esto en la IU. En su lugar, debes crear una configuración de proxy y subirla como un archivo ZIP a Apigee. Una configuración de proxy es una descripción estructurada de todos los aspectos de un proxy de API. Las configuraciones de proxy consisten en archivos XML en una estructura de directorio predefinida. Para obtener más información, consulta la Referencia de configuración de proxy de la API.

Un HealthMonitor simple define un IntervalInSec combinado con un TCPMonitor o un HTTPMonitor. El elemento <MaxFailures> especifica la cantidad máxima de solicitudes fallidas del proxy de API al TargetServer, que da como resultado la solicitud a otro TargetServer. De forma predeterminada, <MaxFailures> es 0, lo que significa que Apigee no realiza ninguna acción correctiva. Cuando configures un monitor de estado, asegúrate de establecer <MaxFailures> en la etiqueta <HTTPTargetConnection> de la etiqueta <TargetEndpoint> en un valor distinto de cero.

TCPMonitor

La siguiente configuración define un HealthMonitor que sondea cada TargetServer cuando abre una conexión en el puerto 80 cada cinco segundos. (El puerto es opcional. Si no se especifica, el puerto TCPMonitor es el puerto TargetServer).

  • Si la conexión falla o toma más de 10 segundos en conectarse, el recuento de fallas aumenta en 1 para ese TargetServer.
  • Si la conexión se realiza correctamente, el recuento de fallas de TargetServer se restablece a 0.

Puedes agregar un elemento HealthMonitor como elemento secundario del elemento HTTPTargetConnetion de TargetEndpoint, como se muestra a continuación:

<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 con elementos de configuración de TCPMonitor

En la siguiente tabla, se describen los elementos de configuración de TCPMonitor:

Nombre Descripción Predeterminada ¿Es obligatorio?
IsEnabled Un valor booleano que habilita o inhabilita el HealthMonitor. falso No
IntervalInSec El intervalo de tiempo, en segundos, entre cada solicitud de sondeo de TCP. 0
ConnectTimeoutInSec El tiempo en que la conexión al puerto TCP se debe establecer para que se considere correcta. Si no se puede establecer la conexión en el intervalo especificado, se considera una falla y se incrementa el recuento de fallas del balanceador de cargas para TargetServer. 0
Port Opcional. El puerto en el que se establecerá la conexión TCP. Si no se especifica, el puerto TCPMonitor es el puerto TargetServer. 0 No

HTTPMonitor

Un HealthMonitor de muestra que usa un monitor HTTP enviará una solicitud GET al servicio de backend una vez cada cinco segundos. La muestra a continuación agrega un encabezado de autorización básica HTTP al mensaje de solicitud. La configuración de respuesta define una configuración que se comparará con la respuesta real del servicio de backend. En el siguiente ejemplo, la respuesta esperada es un código de respuesta HTTP 200 y un encabezado HTTP personalizado ImOK cuyo valor es YourOK. Si la respuesta no coincide, la solicitud del balanceador de cargas tratará la solicitud como una falla.

HTTPMonitor admite servicios de backend configurados para usar protocolos HTTP y unidireccional. Sin embargo, no es compatible con HTTPS bidireccional, también llamado TLS/SSL bidireccional.

Ten en cuenta que toda la configuración de solicitud y respuesta en un monitor HTTP será específica para el servicio de backend que se debe invocar.

<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>
    </Request>
    <SuccessResponse>
      <ResponseCode>200</ResponseCode>
      <Header name=”ImOK”>YourOK</Header>
    </SuccessResponse>
  </HTTPMonitor>
</HealthMonitor>

HealthMonitor con elementos de configuración HTTPMonitor configuration

En la siguiente tabla, se describen los elementos de configuración de HTTPMonitor:

Nombre Descripción Predeterminada ¿Es obligatorio?
IsEnabled Un valor booleano que habilita o inhabilita el HealthMonitor. falso No
IntervalInSec El intervalo de tiempo, en segundos, entre cada solicitud de sondeo. 0
Request

Opciones de configuración para el mensaje de solicitud saliente que envió HealthMonitor a los TargetServers en la rotación.

La ruta de acceso no admite variables.

N/A
ConnectTimeoutInSec Tiempo, en segundos, en que el protocolo de enlace de conexión TCP al servicio HTTP debe completarse para que se considere un resultado correcto. Si no se puede conectar en el intervalo especificado, se cuenta un error y se incrementa el recuento de fallas de LoadBalancer para TargetServer. 0 No
SocketReadTimeoutInSec Tiempo, en segundos, en que los datos se deben leer desde el servicio HTTP para que se considere exitoso. Si no se lee el intervalo especificado, se producirá una falla, lo que aumenta el recuento de fallas de LoadBalancer para TargetServer. 0 No
Port El puerto en el que se establecerá la conexión HTTP con el servicio de backend. N/A No
Verb El verbo HTTP que se usa para cada solicitud HTTP de sondeo al servicio de backend. N/A No
Path La ruta de acceso adjunta a la URL definida en el TargetServer. Usa el elemento de ruta para configurar un "extremo de sondeo" en tu servicio HTTP. N/A No
Payload El cuerpo HTTP generado para cada solicitud HTTP de sondeo. Ten en cuenta que este elemento no es obligatorio para las solicitudes GET. N/A No
SuccessResponse Opciones que coinciden con el mensaje de respuesta HTTP entrante que genera el servicio de backend sondeado. Las respuestas que no coinciden incrementan el recuento de fallas en 1. N/A No
ResponseCode Se espera que el código de respuesta HTTP se haya recibido del TargetServer que se sondea. Un código diferente del código especificado genera un error y el recuento se incrementa para el servicio de backend sondeado. Puedes definir varios elementos de ResponseCode. N/A No
Headers Una lista de uno o más encabezados y valores HTTP que se espera que se reciban del servicio de backend sondeado. Cualquier encabezado o valor HTTP de la respuesta que sea diferente de los especificados es el resultado y el recuento de TargetServer sondeado que se aumenta en 1. Puedes definir varios elementos del encabezado. N/A No