Balanceo de cargas entre servidores de backend

Estás viendo la documentación de Apigee Edge.
Ve a la Documentación de Apigee X. información

Apigee Edge mejora la disponibilidad de tu API a través de compatibilidad integrada con funciones de carga y conmutación por error en varias instancias de servidor de backend.

Los parámetros de configuración de TargetServer separan las URL de extremos concretos de TargetEndpoint. parámetros de configuración. Se hace referencia a cada TargetServer por nombre en un TargetEndpoint. HTTPConnection En lugar de definir una URL concreta en la configuración, puedes establecer una o más TargetServers, como se describe en la sección TargetEndpoint.

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

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 de destino	Enruta una API a un servidor de destino diferente según el entorno.
el enrutamiento de APIs y balanceo de cargas con servidores de destino (Classic Edge)	Enruta una API a un servidor de destino diferente según el entorno y balancea la carga de tu API en los servidores de destino en la IU de Edge clásico.

Configuración de muestra de TargetServer

El siguiente código define un servidor de destino:

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

Elementos de configuración de TargetServer

En la siguiente tabla, se describen los elementos que se usan para crear y configurar un TargetServer:

Nombre	Descripción	Predeterminada	¿Obligatorio?
name	El nombre de la configuración de TargetServer, que debe ser único en la en un entorno de nube. El nombre TargetServer solo puede contener caracteres alfanuméricos.	N/A	Sí
Host	La URL del host del servicio de backend (sin el protocolo)	N/A	Sí
Port	El puerto en el que escucha el servicio de backend	N/A	Sí
IsEnabled	Es un valor booleano que indica si la configuración de TargetServer está habilitada o inhabilitada. Esto te permite quitar TargetServers de la rotación sin modificar el proxy de API configuración. Un uso común sería escribir una aplicación o una secuencia de comandos que habilite o inhabilite TargetServers se basa en los requisitos de capacidad esperados, los programas de mantenimiento etcétera	true	Sí

Administra servidores de destino con la IU

Administra los servidores de destino, como se describe a continuación.

Administra servidores de destino con la API

Puedes usar la API de Edge para crear, borrar, actualizar, obtener y enumerar los servidores de destino. Para para obtener más información, consulta TargetServers.

Usa la siguiente llamada a la API para crear un servidor de destino:

$ 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

Respuesta de muestra:

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

Después de crear el primer TargetServer, usa la siguiente llamada a la API para crear un segundo TargetServer. Cuando defines dos TargetServers, proporcionas dos URL que un TargetEndpoint puede usar para el balanceo de cargas:

$ 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

Respuesta de muestra:

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

Usa la siguiente llamada a la API para recuperar una lista de TargetServers de un entorno:

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

Respuesta de muestra:

[ "target2", "target1" ]

Ahora hay dos TargetServers disponibles para que los usen los proxies de API implementados en la prueba. en un entorno de nube. 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.

Existe un límite de 500 TargetServers por entorno, ya que que se documentan en el tema Límites.

Configura un TargetEndpoint para el balanceo de cargas en 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 posible. El balanceador de cargas admite tres algoritmos de balanceo de cargas, Round Robin, Weighted y Least Connection. Round Robin es el algoritmo predeterminado. Como no se especificó 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 objetivo1 y objetivo 2.

El elemento <Path> forma la ruta base del URI de TargetEndpoint para a todos los servidores de destino. Solo se usa cuando se utiliza <LoadBalancer>. De lo contrario, se ignora. En el ejemplo anterior, una solicitud que llega a "target1" serán http://target1/test y así para otros servidores de destino.

Configura las opciones del balanceador de cargas

Puedes ajustar la disponibilidad con opciones para el balanceo de cargas y la conmutación por error en el balanceador de cargas y TargetServer. En esta sección, se describen estas opciones.

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 weighted te permite configurar cargas de tráfico proporcionales para tus TargetServers. El balanceador ponderado LoadBalancer distribuye la solicitud a tus TargetServers en forma directa y la proporción a la ponderación de cada TargetServer. Por lo tanto, el algoritmo weighted 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.

Least Connection

Los LoadBalancers configurados para usar el algoritmo de conexión mínima enrutan las solicitudes de salida 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 hace que la solicitud sea redirigida a otro TargetServer.

Un error en la respuesta significa que Apigee no recibe ninguna respuesta de un servidor de destino. Cuando esto sucede, el contador de fallas suma una.

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

En el siguiente ejemplo, se quitará target1 de la rotación después de cinco solicitudes fallidas, incluidas algunas respuestas 5XX del servidor de destino.

<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 MaxFailures es 0. Esto significa que Edge siempre intenta se conecta al destino para cada solicitud y nunca quita el servidor de destino de la rotación.

Lo mejor es usar MaxFailures > 0 con un HealthMonitor. Si configuras MaxFailures > 0, el TargetServer se quita de la rotación. cuando el objetivo falla la cantidad de veces que indicas. Cuando se implementa un HealthMonitor, Apigee vuelve a colocar automáticamente el TargetServer en la rotación después de que el destino vuelve a estar en ejecución, según la configuración de ese HealthMonitor. Consulta Supervisión del estado para obtener más información.

Como alternativa, si configuras MaxFailures > 0 y no configuras un HealthMonitor, Apigee no volverá a incluir el TargetServer en la rotación de forma automática después de que Apigee detecte una falla. En este caso, debes volver a implementar el proxy de API antes de que Apigee incluya el TargetServer de nuevo en rotación. Consulta Implementa un proxy de API.

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 de HTTP) o la respuesta recibida coincida con un valor establecido por <ServerUnhealthyResponse>. Consulta la sección Cantidad máxima de errores que se encuentra antes 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

Se puede establecer un TargetServer (y solo uno) como el servidor de reserva. El TargetServer de reserva 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 no está disponible ningún TargetServer, todo el tráfico se enruta al servidor de reserva. 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 destinos 1 y 2 hasta que ambos destinos 1 y 2 no estén disponibles. Cuando los destinos 1 y 2 no están disponibles, todo el tráfico se enruta al destino 3.

Ruta

La ruta define un fragmento de URI que se agregará a todas las solicitudes que envía eñ 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>

Configurar un servidor de destino para TLS/SSL

Si usas un TargetServer a fin de 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 de TargetServer para TLS/SSL donde Edge 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 >

Para obtener información sobre las propiedades de <SSLInfo>, como <Ciphers> y <ClientAuthEnabled>, consulta la información sobre cómo configurar esas propiedades para un host virtual en Cómo configurar el acceso TLS a una API para la nube privada.

Para obtener instrucciones completas sobre cómo configurar TLS/SSL saliente, consulta Configura TLS del perímetro al backend (nube y nube privada).

Esquema de TargetServer

Consulta el esquema de TargetServer y otras entidades en GitHub.

Supervisión del estado

La supervisión del estado te permite mejorar las configuraciones 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 se vuelve a colocar automáticamente en rotación cuando HealthMonitor determina que el 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, lo que provoca que la solicitud se redireccione a otro TargetServer. Luego, el TargetServer con errores se quita de la rotación hasta que vuelvas a implementar el proxy.

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

El 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 a la supervisión de HTTP debe coincidir con la configuración establecida en el bloque <SuccessResponse>.

Éxitos y fallas

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

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

• Éxito: El servidor de destino se considera en buen estado cuando un estado exitoso de que ocurra una verificación. Por lo general, este es el resultado de uno o más de las siguientes situaciones:
  • El servidor de destino acepta una nueva conexión al puerto especificado, responde a una solicitud en ese puerto y, luego, cierra el puerto dentro del período especificado. La respuesta del servidor de destino contiene "Connection: close".
  • El servidor de destino responde a una solicitud de verificación de estado con un código de estado HTTP 200 (OK) o algún otro código de estado HTTP que determines como aceptable.
  • El servidor de destino responde a una solicitud de verificación de estado con un cuerpo de mensaje que coincide con el cuerpo del mensaje esperado.

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

• Error: El servidor de destino puede fallar en una verificación de estado de diferentes maneras, según el tipo de verificación. Se puede registrar una falla cuando el servidor de destino realiza las siguientes acciones:
  • Rechaza una conexión desde Edge al puerto de verificación de estado.
  • No responde a una solicitud de verificación de estado dentro 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 servidor de destino falla en una verificación de estado, Edge aumenta el recuento de fallas de ese servidor. Si la cantidad de fallas para ese servidor alcanza o supera un umbral predefinido (<MaxFailures>), Edge 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 Edge. 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 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 hace que la solicitud sea redirigida a otro TargetServer. El valor predeterminado de <MaxFailures> es 0, lo que significa Edge no realiza ninguna acción correctiva. Cuando configures una supervisión de estado, asegúrate de establecer <MaxFailures> en la etiqueta <HTTPTargetConnection> de la etiqueta <TargetEndpoint> en un valor que no sea cero.

TCPMonitor

La siguiente configuración define un HealthMonitor que sondea cada TargetServer abriendo una conexión en el puerto 80 cada cinco segundos. (El puerto es opcional. Si no se especifica, el puerto TCPMonitor es el puerto de 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 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 TCP de sondeo.	0	Sí
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 el TargetServer.	0	Sí
Port	Opcional. El puerto en el que se establecerá la conexión TCP. Si no se especifica, el puerto TCPMonitor es el puerto de TargetServer.	0	No

HTTPMonitor

Un HealthMonitor de muestra que utiliza un HTTPMonitor enviará una solicitud GET al servicio de backend una vez cada cinco segundos. La muestra que aparece 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 configuración del balanceador de cargas tratará la solicitud como una falla.

HTTPMonitor admite servicios de backend configurados para usar protocolos HTTP y HTTPS unidireccional. Sin embargo, no admite lo siguiente:

• HTTPS bidireccional (también llamado TLS/SSL bidireccional)
• Certificados autofirmados

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

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

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	Sí
Request	Opciones de configuración para el mensaje de solicitud saliente que envió el HealthMonitor a los TargetServers en la rotación. La ruta de acceso no admite variables.	N/A	Sí
IsSSL	Especifica si se debe usar HTTPS (HTTP seguro) para supervisar las conexiones. Potencial valores: true: Se usa HTTPS. false: Se usa HTTP. Sin especificar: Usa la configuración del servidor de destino.	falso	No
ConnectTimeoutInSec	Tiempo, en segundos, en que el protocolo de enlace de conexión TCP al servicio HTTP debe completarse para que se considere correcto. 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 el TargetServer.	0	No
SocketReadTimeoutInSec	Tiempo, en segundos, en que los datos se deben leer desde el servicio HTTP para que se considere un resultado correcto. Si no se lee el intervalo especificado, se producirá una falla, lo que aumenta el recuento de fallas del LoadBalancer para el TargetServer.	0	No
Port	El puerto en el que se establecerá la conexión HTTP al 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
IncludeHealthCheckIdHeader	Te permite hacer un seguimiento de las solicitudes de verificación de estado en sistemas ascendentes. IncludeHealthCheckIdHeader toma un valor booleano y su valor predeterminado es false. Si lo configuras como true, hay una Header llamada X-Apigee-Healthcheck-Id que se inserta en la solicitud de verificación de estado. El valor del encabezado se asigna de forma dinámica y toma la forma siguiente: ORG/ENV/SERVER_UUID/N, dondeORG es el nombre de la organización, ENV es el nombre del entorno, SERVER_UUID es un ID único que identifica al MP y N es el número de milisegundos transcurridos desde el 1 de enero de 1970. Ejemplo de encabezado de solicitud resultante: X-Apigee-Healthcheck-Id: orgname/envname/E8C4D2EE-3A69-428A-8616-030ABDE864E0/1586802968123	falso	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 aumentan la cantidad de fallas en 1.	N/A	No
ResponseCode	El código de respuesta HTTP que se espera recibir del TargetServer sondeado. Un código distinto del código especificado genera un error y el recuento se incrementa para el servicio de backend sondeado. Puedes definir varios elementos 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 genera un error y el recuento para el TargetServer sondeado se incrementa en 1. Puedes definir varios elementos del encabezado.	N/A	No