Balanceo de cargas entre servidores de backend

Esta página se aplica a Apigee y Apigee Hybrid.

Consulta la documentación de Apigee Edge.

Apigee mejora la disponibilidad de tus API, puesto 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 opciones de configuración de TargetEndpoint. En lugar de definir una URL concreta en la configuración, puedes configurar uno o más TargetServers con nombre. Luego, se hace referencia a cada TargetServer por nombre en una HTTPConnection 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 de destino Enruta una API a un servidor de destino diferente según el entorno.

Información acerca de la configuración de TargetServer

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

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

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

Para obtener más información sobre la API de TargetServers, consulta organizations.environments.targetservers.

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.

Apigee en la consola de Cloud

Para crear TargetServers con Apigee en la consola de Cloud, sigue estos pasos:

  1. Accede a la IU de Apigee en la consola de Cloud.
  2. Selecciona Administración > Entornos > TargetServers.
  3. Selecciona el entorno en el que deseas definir un TargetServer nuevo.
  4. Haz clic en Servidores de destino en la parte superior del panel.
  5. Haz clic en + Crear servidor de destino.

  6. Ingresa un nombre, un host, un protocolo y un puerto en los campos proporcionados. Las opciones para Protocolo son: HTTP para los servidores de destino basados en REST, gRPC: Destino para los servidores de destino basados en gRPC o gRPC: Callout externo. Consulta Crea proxies de API de gRPC para obtener más información sobre la compatibilidad con el proxy de gRPC.

    De manera opcional, puedes seleccionar Habilitar SSL. Consulta Descripción general de certificados SSL.

  7. Haz clic en Crear.

Apigee clásico

Para crear TargetServers con la IU clásica de Apigee, haz lo siguiente:

  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:

    Lista de servidores de destino

  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:

    Cuadro de diálogo Agregar servidor de destino

  5. Haz clic en Habilitado para habilitar la nueva definición de TargetServer. inmediatamente después de crearlo.

  6. Ingresa un nombre, un host, un protocolo y un puerto en los campos proporcionados. Las opciones para Protocolo son HTTP o GRPC.

    De manera opcional, puedes seleccionar la casilla de verificación SSL. Para obtener más información sobre estos campos, consulta TargetServers (video 4MV4D).

  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/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",
  }'

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. Para obtener una descripción de las variables de entorno utilizadas, 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",
  "protocol": "http",
  "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/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",
  }'

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

{
  "host" : "2.mybackendservice.com",
  "protocol": "http",
  "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/organizations/$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 usen los proxies de API implementados 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 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. El balanceador de cargas admite tres algoritmos de balanceo de cargas, Round Robin, Weighted 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, uno por uno, entre target1 y target2.

El elemento <Path> forma la ruta base del URI de TargetEndpoint para todos los TargetServers. Solo se usa cuando se utiliza <LoadBalancer>. De lo contrario, se ignora. En el ejemplo anterior, una solicitud que llega a 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 para 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 weighted te permite configurar cargas de tráfico proporcionales para tus TargetServers. El balanceador de cargas con el algoritmo weighted distribuye solicitudes a tus TargetServers en proporción directa con cada ponderación del 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 solicitud enrutada 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 de respuesta significa que Apigee no recibe ninguna respuesta de un TargetServer. Cuando esto sucede, el contador de fallas suma una.

Sin embargo, cuando Apigee recibe una respuesta de un destino, 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 recuento del 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> a la configuración de tu balanceador de cargas. Apigee 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 de 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 MaxFailures es 0. Esto significa que Apigee siempre intenta conectarse al destino de cada solicitud y nunca quita TargetServer de la rotación.

Lo mejor es usar MaxFailures > 0 con un HealthMonitor. Si configuras MaxFailures > 0, TargetServer se quita de la rotación cuando el destino 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 quitará automáticamente el TargetServer de la rotación cuando se detecte la primera falla. Apigee verificará el estado del TargetServer cada cinco minutos y lo mostrará en la rotación cuando responda con normalidad.

Volver a intentarlo

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 resguardo. 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 target1 y target2 hasta que target1 y target2 no estén disponibles. Cuando target1 y target2 no están disponibles, todo el tráfico se enruta a target3.

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>

Configura un TargetServer 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 TargetServer para TLS/SSL unidireccional, en la que Apigee realiza solicitudes HTTPS al servicio de backend:

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

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

Para crear un TargetServer con SSL mediante una llamada a la API, haz lo siguiente: 

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"
    }
  }'

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, los TargetServers a los que no se puede acceder o que muestran una respuesta de error se marcan en mal estado. Un TargetServer con error se vuelve a rotar automáticamente cuando el HealthMonitor determina que el TargetServer está activo. No se requieren reimplementaciones de 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, 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:

  • Exitosa: se considera que TargetServer está 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 las siguientes situaciones:
    • 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 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 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 TargetServer falla en 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 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 redireccionada a otro TargetServer. De forma predeterminada, <MaxFailures> es 0, lo que significa que Apigee 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>
</TargetEndpoint>

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 usa 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 es compatible con HTTPS bidireccional, también llamado TLS/SSL bidireccional o 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.

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

Elementos de configuración <HTTPMonitor>

En la siguiente tabla, se describen los elementos de configuración de <HTTPMonitor> de nivel superior:

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í

Elementos de configuración <HTTPMonitor>/<Request>

Opciones de configuración para el mensaje de solicitud saliente que envió el HealthMonitor a los TargetServers en la rotación. Ten en cuenta que <Request> es un elemento obligatorio.

Nombre Descripción Predeterminada ¿Es obligatorio?
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. Puerto del servidor de destino 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 Path para configurar un "extremo de sondeo" en tu servicio HTTP. Ten en cuenta que el elemento Path no admite variables. 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

Elementos de configuración <HTTPMonitor>/<SuccessResponse>

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

Nombre Descripción Predeterminada ¿Es obligatorio?
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