Balanceamento de carga entre servidores de back-end

Esta página se aplica à Apigee e à Apigee híbrida.

Confira a documentação da Apigee Edge.

A Apigee aumenta a disponibilidade de suas APIs ao fornecer suporte integrado para balanceamento de carga e failover em várias instâncias de servidor de back-end.

Os TargetServers separam os URLs de endpoint concretos das configurações do TargetEndpoint. Em vez de definir um URL concreto na configuração, é possível configurar um ou mais TargetServers nomeados. Depois, cada TargetServer será referenciado pelo nome em uma HTTPConnection de TargetEndpoint.

Vídeos

Assista os vídeos a seguir para saber mais sobre roteamento de API e balanceamento de carga usando servidores de destino

Vídeo Descrição
Balanceamento de carga com servidores de destino APIs de balanceamento de carga em servidores de destino
Roteamento de API com base no ambiente usando servidores de destino Encaminhe uma API para outro servidor de destino com base no ambiente.

Sobre a configuração do TargetServer

Uma configuração TargetServer consiste em um nome, um host, um protocolo e uma porta, com um elemento extra para indicar se o TargetServer está ativado ou desativado.

O código a seguir mostra um exemplo de configuração do TargetServer:

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

Para mais informações sobre a API TargetServers, consulte organizations.environments.targetservers.

Consulte o esquema do TargetServer e de outras entidades no GitHub.

Como criar TargetServers

Crie TargetServers usando a IU ou a API do Apigee conforme descrito nas seções a seguir.

Apigee no console do Cloud

Para criar TargetServers usando a Apigee no console do Cloud:

  1. Faça login na interface da Apigee no console do Cloud.
  2. Selecione Gerenciamento > Ambientes > TargetServers.
  3. Selecione o ambiente em que você quer definir um novo TargetServer.
  4. Clique em Servidores de destino na parte superior do painel.
  5. Clique em + Criar servidor de destino.

  6. Insira um nome, um host, um protocolo e uma porta nos campos fornecidos. As opções de Protocolo são: HTTP para servidores de destino baseados em REST e gRPC - Target para servidores de destino com base em gRPC ou gRPC - External callout. Consulte Como criar proxies de API gRPC para informações sobre a compatibilidade com o proxy gRPC.

    Como opção, é possível selecionar Ativar SSL. Consulte Visão geral dos certificados SSL.

  7. Clique em Criar.

Apigee clássica

Para criar TargetServers usando a interface clássica da Apigee:

  1. Faça login na IU da Apigee.
  2. Selecione Administrador > Ambientes > TargetServers.
  3. Na lista suspensa Ambiente, selecione o ambiente em que você quer definir um novo TargetServer.

    A IU da Apigee exibe uma lista dos TargetServers atuais no ambiente selecionado:

    Lista de servidores de destino

  4. Clique em +Servidor de destino para adicionar um novo TargetServer ao ambiente selecionado.

    A caixa de diálogo Adicionar servidor de destino é exibida:

    Caixa de diálogo "Adicionar servidor de destino"

  5. Clique em Ativado para ativar a nova definição de TargetServer imediatamente após a criação.

  6. Insira um nome, um host, um protocolo e uma porta nos campos fornecidos. As opções para Protocolo são HTTP ou GRPC.

    Também é possível marcar a caixa de seleção SSL. Para mais informações sobre esses campos, consulte TargetServers (vídeo 4MV4D, em inglês).

  7. Clique em Add.

    A Apigee cria a nova definição do TargetServer.

  8. Depois de criar um novo TargetServer, edite o proxy de API e altere o elemento <HTTPTargetConnection> para referenciar a nova definição.

API Apigee

As seções a seguir mostram exemplos de como usar a API Apigee para criar e listar TargetServers.

Para mais informações, consulte a API TargetServers.

Como criar um TargetServer em um ambiente usando a API

Para criar um TargetServer nomeado target1 que se conecta a 1.mybackendservice.com na porta 80, use a seguinte chamada de 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",
  }'

Em que $TOKEN está definido como seu token de acesso OAuth 2.0, conforme descrito em Como receber um token de acesso OAuth 2.0. Para informações sobre as opções de curl usadas neste exemplo, consulte Como usar curl. Para uma descrição das variáveis de ambiente usadas, consulte Como definir variáveis de ambiente para solicitações de API da Apigee.

Veja a seguir um exemplo de resposta:

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

Crie um segundo TargetServer usando a chamada de API a seguir. Ao definir dois TargetServers, você fornece dois URLs que um TargetEndpoint pode usar para o balanceamento de carga:

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

Veja a seguir um exemplo de resposta:

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

Como listar os TargetServers em um ambiente usando a API

Para listar os TargetServers em um ambiente, use a seguinte chamada de API:

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

Veja a seguir um exemplo de resposta:

[ "target2", "target1" ]

Agora, há dois TargetServers disponíveis para uso por proxies de API implantados no ambiente test. Para balancear a carga do tráfego nesses TargetServers, configure a conexão HTTP no endpoint de destino de um proxy de API para usar os TargetServers.

Como configurar um TargetEndpoint para balancear a carga em TargetServers nomeados

Agora que há dois TargetServers disponíveis, é possível modificar a configuração de conexão HTTP TargetEndpoint para fazer referência a esses dois TargetServers por nome:

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

A configuração de balanceamento de carga acima é a mais básica. O balanceador de carga aceita três algoritmos de balanceamento de carga: round-robin, ponderado e dinâmico. Round-robin é o algoritmo padrão. Como nenhum algoritmo é especificado na configuração acima, as solicitações de saída do proxy de API para os servidores de back-end serão alternativas, um para um, entre target1 e target2.

O elemento <Path> forma o caminho base do URI do TargetEndpoint para todos os TargetServers. Ele só é usada quando <LoadBalancer> é usado. Caso contrário, será ignorado. No exemplo acima, uma solicitação que alcança target1 será http://target1/test e, portanto, para outros TargetServers.

Para mais informações, consulte TargetEndpoint.

Como configurar opções do balanceador de carga

Ajuste a disponibilidade configurando as opções de balanceamento de carga e failover no balanceador de carga e no nível do TargetServer, conforme descrito nas seções a seguir.

Algoritmo

Define o algoritmo usado por <LoadBalancer>. Os algoritmos disponíveis são RoundRobin, Weighted e LeastConnections, cada um deles documentado abaixo.

Round robin

O algoritmo padrão, round-robin, encaminha uma solicitação para cada TargetServer na ordem em que os servidores estão listados na conexão HTTP do endpoint de destino. Exemplo:

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

Ponderado

O algoritmo de balanceamento de carga ponderado permite configurar cargas de tráfego proporcionais para os TargetServers. O LoadBalancer ponderado distribui as solicitações aos TargetServers em proporção direta ao peso de cada TargetServer. Portanto, o algoritmo ponderado requer que você defina um atributo weight para cada TargetServer. Exemplo:

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

Neste exemplo, duas solicitações serão encaminhadas para target2 para cada solicitação encaminhada para target1.

Escalonamento dinâmico

LoadBalancers configurados para usar o algoritmo de escalonamento dinâmico roteiam solicitações de saída para o TargetServer com menos conexões HTTP abertas. Exemplo:

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

Máximo de falhas

O número máximo de solicitações com falha do proxy de API para o TargetServer que fazem com que a solicitação seja redirecionada para outro TargetServer.

Uma falha na resposta significa que a Apigee não recebe resposta de um TargetServer. Quando isso acontece, o contador de falhas é incrementado em um.

No entanto, quando a Apigee recebe uma resposta de um destino, mesmo que ela seja um erro de HTTP (como 500), isso é contabilizado como uma resposta do TargetServer e o contador de falha é redefinido. Para ajudar a garantir que respostas de HTTP inválidas (como 500) também incrementem o contador de falhas para tirar um servidor não íntegro da rotação do balanceamento de carga o quanto antes, é possível adicionar o elemento <ServerUnhealthyResponse> com elementos filhos <ResponseCode> na configuração do balanceador de carga. A Apigee também contará respostas com esses códigos como falhas.

No exemplo a seguir, target1 será removido da rotação após cinco solicitações com falha, incluindo algumas respostas 5XX do 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>

O padrão MaxFailures é 0. Isso significa que a Apigee sempre tenta se conectar ao destino de cada solicitação e nunca remove o TargetServer da rotação.

É melhor usar MaxFailures > 0 com um HealthMonitor. Se você configurar o MaxFailures > 0, o TargetServer será removido da rotação quando o destino falhar o número de vezes que você indicar. Quando um HealthMonitor está em vigor, a Apigee coloca automaticamente o TargetServer em rotação após o destino estar em execução novamente, de acordo com a configuração desse HealthMonitor. Consulte Monitoramento de integridade para mais informações.

Como alternativa, se você configurar MaxFailures > 0 e não configurar um HealthMonitor, a Apigee tirará o TargetServer de rotação automaticamente quando a primeira falha for detectada. A Apigee verificará a integridade do TargetServer a cada cinco minutos e o retornará à rotação quando responder normalmente.

Tentar de novo

Se a nova tentativa for ativada, uma solicitação será repetida sempre que ocorrer uma falha de resposta (erro de E/S ou de tempo limite HTTP) ou a resposta recebida corresponder a um valor definido por <ServerUnhealthyResponse>. Consulte Máximo de falhas acima para mais informações sobre a configuração de <ServerUnhealthyResponse>.

Por padrão, <RetryEnabled> é definido como true. Defina como false para desativar a nova tentativa. Exemplo:

<RetryEnabled>false</RetryEnabled>

IsFallback

Um (e apenas um) TargetServer pode ser definido como o servidor substituto. O TargetServer substituto não será incluído nas rotinas de balanceamento de carga até que todos os outros TargetServers sejam identificados como indisponíveis pelo balanceador de carga. Quando o balanceador de carga determina que todos os TargetServers estão indisponíveis, todo o tráfego é roteado para o servidor substituto. Exemplo:

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

A configuração acima resulta em um balanceamento de carga round-robin entre target1 e target2 até que target1 e target2 estejam indisponíveis. Quando target1 e target2 estiverem indisponíveis, todo o tráfego será roteado para target3.

Caminho

O caminho define um fragmento de URI que será anexado a todas as solicitações emitidas pelo TargetServer para o servidor de back-end.

Esse elemento aceita um caminho de string literal ou um modelo de mensagem. Um modelo de mensagem permite fazer substituição de strings variáveis no tempo de execução. Por exemplo, na definição do endpoint de destino a seguir, o valor de {mypath} é usado para o caminho:

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

Como configurar um TargetServer para TLS/SSL

Se você estiver usando um TargetServer para definir o serviço de back-end e esse serviço exigir a conexão para usar o protocolo HTTPS, será necessário ativar o TLS/SSL na definição do TargetServer. Isso é necessário porque a tag host não permite que você especifique o protocolo de conexão. Veja abaixo a definição do TargetServer para TLS/SSL unidirecional, em que a Apigee faz solicitações HTTPS ao serviço de back-end:

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

Se o serviço de back-end exigir o recurso TLS/SSL de duas vias ou mutuo, configure o TargetServer usando as mesmas definições de configuração do TLS/SSL que o 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 criar um TargetServer com SSL usando uma chamada de API: 

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

Monitoramento de integridade

O monitoramento de integridade permite aprimorar as configurações de balanceamento de carga pesquisando ativamente os URLs de serviço de back-end definidos nas configurações do TargetServer. Com o monitoramento de integridade ativado, os ServerServers inacessíveis ou que retornam uma resposta de erro são marcados como não íntegros. Um TargetServer com falha é automaticamente colocado de volta em rotação quando o HealthMonitor determina que o TargetServer está ativo. Não é necessário reimplantações de proxy.

O HealthMonitor atua como um cliente simples que invoca um serviço de back-end por TCP ou HTTP:

  • Um cliente TCP simplesmente garante que um soquete possa ser aberto.
  • Você configura o cliente HTTP para enviar uma solicitação HTTP válida ao serviço de back-end. É possível definir operações HTTP GET, PUT, POST ou DELETE. A resposta da chamada do monitor HTTP precisa corresponder às configurações definidas no bloco <SuccessResponse>.

Sucessos e falhas

Ao ativar o monitoramento de integridade, a Apigee começa a enviar verificações de integridade ao servidor de destino. A verificação de integridade é uma solicitação enviada ao TargetServer que determina se o TargetServer está íntegro ou não.

Uma verificação de integridade pode ter um destes dois resultados:

  • Sucesso: o TargetServer é considerado íntegro quando ocorre uma verificação de integridade bem-sucedida. Isso normalmente é resultado de um ou mais dos seguintes procedimentos:
    • O TargetServer aceita uma nova conexão com a porta especificada, responde a uma solicitação nessa porta e, em seguida, fecha a porta dentro do período especificado. A resposta do TargetServer contém Connection: close
    • O TargetServer responde a uma solicitação de verificação de integridade com um código 200 (OK) ou outro código de status HTTP que você determinar como aceitável.
    • O TargetServer responde a uma solicitação de verificação de integridade com um corpo de mensagem que corresponde ao corpo esperado da mensagem.

    Quando a Apigee determina que um servidor está íntegro, ela continua ou retoma o envio de solicitações para o servidor.

  • Falha: o TargetServer pode falhar em uma verificação de integridade de maneiras diferentes, dependendo do tipo de verificação. Uma falha pode ser registrada quando o TargetServer:
    • recusa uma conexão da Apigee com a porta de verificação de integridade;
    • não responde a solicitações de verificação de integridade dentro de um período especificado;
    • retorna um código de status HTTP inesperado;
    • responde com um corpo de mensagem que não corresponde ao corpo esperado da mensagem.

    Quando um TargetServer falha em uma verificação de integridade, a Apigee aumenta a contagem de falhas do servidor. Se o número de falhas desse servidor atingir ou exceder um limite predefinido (<MaxFailures>), a Apigee interromperá o envio de solicitações para esse servidor.

Como ativar um HealthMonitor

Para criar um HealthMonitor, adicione o elemento <HealthMonitor> à configuração HTTPConnection do TargetEndpoint para um proxy. Não é possível fazer isso na IU. Em vez disso, você cria uma configuração de proxy e faz upload dela como um arquivo ZIP para a Apigee. Uma configuração de proxy é uma descrição estruturada de todos os aspectos de um proxy de API. As configurações de proxy consistem em arquivos XML em uma estrutura de diretórios predefinida. Para mais informações, consulte a Referência de configuração do proxy da API.

Um HealthMonitor simples define um IntervalInSec combinado com um TCPMonitor ou um HTTPMonitor. O elemento <MaxFailures> especifica o número máximo de solicitações com falha do proxy de API para o TargetServer que faz com que a solicitação seja redirecionada para outro TargetServer. Por padrão, <MaxFailures> é 0, o que significa que a Apigee não executa nenhuma ação corretiva. Ao configurar um monitor de integridade, configure <MaxFailures> na tag <HTTPTargetConnection> da tag <TargetEndpoint> como um valor diferente de zero.

TCPMonitor

A configuração abaixo define um HealthMonitor que pesquisa cada TargetServer abrindo uma conexão na porta 80 a cada cinco segundos. A porta é opcional. Se não for especificada, a porta TCPMonitor será a TargetServer.

  • Se a conexão falhar ou levar mais de 10 segundos para se conectar, a contagem de falhas aumentará em 1 para esse TargetServer.
  • Se a conexão for bem-sucedida, a contagem de falhas para TargetServer será redefinida como 0.

É possível adicionar um HealthMonitor como um elemento filho do elemento HTTPTargetConnetion do TargetEndpoint, como mostrado abaixo:

<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 com elementos de configuração TCPMonitor

A tabela a seguir descreve os elementos de configuração do TCPMonitor:

Nome Descrição Padrão Obrigatória?
IsEnabled É um booleano que ativa ou desativa o HealthMonitor. false Não
IntervalInSec O intervalo de tempo, em segundos, entre cada solicitação TCP de pesquisa. 0 Sim
ConnectTimeoutInSec Tempo em que a conexão com a porta TCP precisa ser estabelecida para ser considerada bem-sucedida. A falha de conexão no intervalo especificado conta como uma falha, aumentando a contagem de falhas do balanceador de carga do TargetServer. 0 Sim
Port Opcional. A porta em que a conexão TCP será estabelecida. Se não for especificada, a porta TCPMonitor será a TargetServer. 0 Não

HTTPMonitor

Uma amostra do HealthMonitor que usa um HTTPMonitor enviará uma solicitaçãoGET para o serviço de back-end uma vez a cada cinco segundos. O exemplo abaixo adiciona um cabeçalho de autorização básica HTTP à mensagem de solicitação. A configuração de resposta define configurações que serão comparadas com a resposta real do serviço de back-end. No exemplo abaixo, a resposta esperada é um código de resposta HTTP 200 e um cabeçalho HTTP personalizado ImOK, com valor YourOK. Se a resposta não for correspondente, a solicitação será tratada como uma falha pela configuração do balanceador de carga.

O HTTPMonitor é compatível com serviços de back-end configurados para usar protocolos HTTP e HTTPS unidirecionais. No entanto, ele não é compatível com HTTPS bidirecional, também chamado de TLS/SSL bidirecional, ou certificados autoassinados.

Observe que todas as configurações de Solicitação e Resposta em um monitor HTTP serão específicas para o serviço de back-end que precisa ser invocado.

    <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 configuração de <HTTPMonitor>

A tabela a seguir descreve os elementos de configuração <HTTPMonitor> de nível superior:

Nome Descrição Padrão Obrigatória?
IsEnabled É um booleano que ativa ou desativa o HealthMonitor. false Não
IntervalInSec O intervalo de tempo, em segundos, entre cada solicitação de pesquisa. 0 Sim

Elementos de configuração de <HTTPMonitor>/<Request>

Opções de configuração para a mensagem de solicitação de saída enviada pelo HealthMonitor para os TargetServers na rotação. Lembre-se de que <Request> é um elemento obrigatório.

Nome Descrição Padrão Obrigatório?
ConnectTimeoutInSec Tempo, em segundos, em que o handshake da conexão TCP com o serviço HTTP precisa ser concluído para ser considerado bem-sucedido Falha de conexão nos intervalos especificados conta como uma falha, incrementando a contagem de falhas do LoadBalancer para o TargetServer. 0 Não
SocketReadTimeoutInSec Tempo, em segundos, em que os dados precisam ser lidos do serviço HTTP para serem considerados bem-sucedidos. Falha ao ler o intervalo especificado conta como uma falha, incrementando a contagem de falhas do LoadBalancer para o TargetServer. 0 Não
Port A porta em que a conexão HTTP com o serviço de back-end será estabelecida. Porta do servidor de destino No
Verb O verbo HTTP usado para cada solicitação HTTP de sondagem para o serviço de back-end. N/A Não
Path O caminho anexado ao URL definido no TargetServer. Use o elemento Path para configurar um "endpoint de sondagem" no seu serviço HTTP. Lembre-se de que o elemento Path não aceita variáveis. N/A Não

IncludeHealthCheckIdHeader

 Permite rastrear as solicitações de verificação de integridade em sistemas upstream. O IncludeHealthCheckIdHeader usa um valor booleano e o padrão é false. Se você defini-lo como true, haverá um Header chamado X-Apigee-Healthcheck-Id que é injetado na solicitação de verificação de integridade. O valor do cabeçalho é atribuído dinamicamente e assume a forma ORG/ENV/SERVER_UUID/N, em que ORG é o nome da organização, ENV é o nome do ambiente, SERVER_UUID é um ID exclusivo que identifica o MP, e N é o número de milissegundos decorridos desde 1º de janeiro de 1970.

Exemplo de cabeçalho de solicitação resultante:

X-Apigee-Healthcheck-Id: orgname/envname/E8C4D2EE-3A69-428A-8616-030ABDE864E0/1586802968123 		false Não
Payload O corpo HTTP gerado para cada solicitação HTTP de pesquisa. Observe que esse elemento não é necessário para solicitações GET. N/A No

Elementos de configuração de <HTTPMonitor>/<SuccessResponse>

(Opcional) Opções de correspondência para a mensagem de resposta HTTP de entrada gerada pelo serviço de back-end sondado. Respostas sem correspondência aumentam a contagem de falhas em 1.

Nome Descrição Padrão Obrigatório?
ResponseCode É o código de resposta HTTP esperado do servidor TargetServer pesquisado. Um código diferente do especificado especifica uma falha, e a contagem é incrementada para o serviço de back-end pesquisado. É possível definir vários elementos ResponseCode. N/A Não
Headers Uma lista de um ou mais cabeçalhos e valores HTTP que devem ser recebidos do serviço de back-end pesquisado. Todos os cabeçalhos ou valores HTTP na resposta que são diferentes daqueles especificados resultam em uma falha, e a contagem do TargetServer pesquisado é incrementada em 1. É possível definir vários elementos de cabeçalho. N/A Não