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, ya que proporciona compatibilidad integrada para balanceo de cargas y conmutación por error en varias instancias de servidores de backend.

Las configuraciones de TargetServer separan las URLs de extremos concretas de las configuraciones de TargetEndpoint. Se hace referencia a cada TargetServer por nombre en una TargetEndpoint HTTPConnection. En lugar de definir una URL concreta en la configuración, puedes establecer uno o más TargetServers con nombre como se describe en la sección TargetEndpoint.

Una definición de TargetServer consta de un nombre, un host y un puerto, con un elemento adicional para indicar si el 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.
Enrutamiento de API y balanceo de cargas mediante servidores de destino (versión clásica de Edge) Enruta una API a un servidor de destino diferente según el entorno y balancea las cargas de tu API en los servidores de destino de la IU clásica de Edge.

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 usados para crear y configurar un TargetServer:

Nombre Descripción Predeterminado ¿Obligatorio?
name Es el nombre de la configuración de TargetServer, que debe ser único en el entorno. El nombre de TargetServer solo puede contener caracteres alfanuméricos. No disponible
Host

La URL del host del servicio de backend (sin el protocolo).

No disponible
Port El puerto en el que escucha el servicio de backend No disponible
IsEnabled 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 la configuración de proxy de la API. Un uso común sería escribir una app o secuencia de comandos que habilite o inhabilite TargetServers automáticamente según los requisitos de capacidad esperados, los programas de mantenimiento, etcétera. true

Administra los servidores de destino con la IU

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

Conexión de integración

Para administrar los servidores de destino con la IU de Edge, haz lo siguiente:

  1. Accede a apigee.com/edge.
  2. Selecciona Administrador > Entornos > Servidores de destino en la barra de navegación izquierda.
  3. Selecciona el entorno deseado, como test o prod.
  4. Para crear un servidor de destino, haz lo siguiente:
    1. Haz clic en + Servidor de destino.
    2. Ingresa un nombre, un host y un puerto para el servidor de destino.

      Por ejemplo:

      • Nombre: target1
      • Host: 1.mybackendservice.com
      • Puerto: 80
    3. Selecciona SSL si es necesario.
    4. Selecciona Habilitado para habilitar el servidor de destino.
    5. Haz clic en Agregar.
  5. Para editar el servidor de destino, haz lo siguiente:
    1. Coloca el cursor sobre el servidor de destino que deseas editar para que aparezca el menú de acciones.
    2. Haz clic en .
    3. Edita los valores del servidor targer.
    4. Haz clic en Actualizar.
  6. Para borrar el servidor de destino, haz lo siguiente:
    1. Coloca el cursor sobre el servidor de destino que deseas borrar para que aparezca el menú de acciones.
    2. Haz clic en .
    3. Haz clic en Borrar para confirmar la operación.

Versión clásica de Edge (nube privada)

Para acceder al asistente de creación de proxy con la IU clásica de Edge, sigue estos pasos:

  1. Accede a http://ms-ip:9000, donde ms-ip es la dirección IP o el nombre de DNS del nodo del servidor de administración.
  2. En la barra de navegación izquierda, selecciona APIs > Configuración del entorno > Servidores de destino.
  3. Selecciona el entorno deseado, como test o prod.
  4. Para crear un servidor de destino, haz lo siguiente:
    1. Haz clic en Editar.
    2. Haz clic en + Servidor de destino.
    3. Ingresa un nombre, un host y un puerto para el servidor de destino.

      Por ejemplo:

      • Nombre: target1
      • Host: 1.mybackendservice.com
      • Puerto: 80
    4. Selecciona Habilitado para habilitar el servidor de destino.
    5. Haz clic en Guardar.
  5. Para editar el servidor de destino, haz lo siguiente:
    1. Haz clic en Editar.
    2. Edita los valores del servidor targer.
    3. Haz clic en Guardar.
  6. Para borrar el servidor de destino, haz lo siguiente:
    1. Haz clic en Editar.
    2. Haz clic en Borrar.

Administra los servidores de destino con la API

Puedes usar la API de Edge para crear, borrar, actualizar, obtener y enumerar servidores de destino. 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 en 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 el entorno de pruebas. 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, como se indica 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 especifica ningún algoritmo en la configuración anterior, las solicitudes salientes del proxy de la API a los servidores de backend se alternarán, uno por uno, entre target1 y target 2.

El elemento <Path> forma la ruta base del URI de TargetEndpoint para 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á http://target1/test, y así para otros servidores de destino.

Configura las opciones del balanceador de cargas

Puedes ajustar la disponibilidad mediante las opciones para el balanceo de cargas y la conmutación por error a nivel del balanceador de cargas y de 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 LoadBalancer ponderado distribuye la solicitud a tus TargetServers en proporción directa al peso 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.

Una falla 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 destino, incluso si la respuesta es un error de HTTP (como 500), se cuenta como una respuesta del servidor de destino y se restablece el contador de fallas. Para garantizar que las respuestas HTTP incorrectas (como 500) también aumenten el contador de fallas para quitar 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 del balanceador de cargas. Edge también registrará las respuestas que tengan esos códigos como errores.

En el siguiente ejemplo, target1 se quitará de la rotación después de cinco solicitudes fallidas, incluidas algunas respuestas de 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 conectarse al destino de 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 destino falla la cantidad de veces que indicaste. Cuando se implementa un HealthMonitor, Apigee automáticamente vuelve a rotar el TargetServer una vez que el destino vuelve a estar en funcionamiento, según la configuración de ese HealthMonitor. Consulta Supervisión de 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>

Configura 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 TargetServer de TLS/SSL unidireccional, en la que 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 Configura el acceso de TLS a una API para la nube privada.

Si quieres obtener instrucciones completas para configurar TLS/SSL salientes, consulta Configura TLS desde Edge 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 al servidor de destino. Una verificación de estado es una solicitud que se envía al servidor de destino y que determina si el servidor de destino está en buen estado o no.

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

  • Listo: El servidor de destino se considera en buen estado cuando se produce una verificación de estado correcta. 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 el mensaje “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 cualquier otro que consideres aceptable.
    • El servidor de destino responde a una solicitud de verificación de estado con un cuerpo del 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 a él.

  • Error: El servidor de destino puede fallar una verificación de estado de diferentes maneras, según el tipo de verificación. Se puede registrar una falla en las siguientes situaciones en el servidor de destino:
    • Rechaza la conexión de 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 incrementa el recuento de fallas de ese servidor. Si la cantidad de fallas de 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 del 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 que 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 Predeterminado ¿Es obligatorio?
IsEnabled Un valor booleano que habilita o inhabilita el HealthMonitor. false No
IntervalInSec El intervalo de tiempo, en segundos, entre cada solicitud de TCP de sondeo. 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 el 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 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 Predeterminado ¿Es obligatorio?
IsEnabled Un valor booleano que habilita o inhabilita el HealthMonitor. false 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ó el HealthMonitor a los TargetServers en la rotación.

La ruta de acceso no admite variables.

No disponible
IsSSL Especifica si se debe usar HTTPS (HTTP seguro) para supervisar las conexiones.

Valores posibles:
  • true: Se usa HTTPS.
  • false: Se usa HTTP.
  • Sin especificar: Usa la configuración del servidor de destino.
false 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. No disponible No
Verb El verbo HTTP que se usa para cada solicitud HTTP de sondeo al servicio de backend. No disponible 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. No disponible 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
false 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. No disponible 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. No disponible 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. No disponible 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. No disponible No