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 servidores de destino separam os URLs de endpoint concretos das configurações do endpoint de destino. Em vez de definir um URL concreto na configuração, é possível configurar um ou mais servidores de destino nomeados. Depois, cada servidores de destino será referenciado pelo nome em uma HTTPConnection de endpoint de destino.

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 servidor de destino

Uma configuração de servidor de destino consiste em um nome, um host, um protocolo e uma porta, com um elemento extra para indicar se o servidor de destino está ativado ou desativado. Um servidor de destino também pode ter um objeto <sSLInfo> opcional.

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

{
  "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 servidores de destino

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

Apigee no console do Cloud

Para criar servidores de destino usando a Apigee no console do Cloud:

Faça login na interface da Apigee no console do Cloud.
Selecione Gerenciamento > Ambientes.
Selecione o ambiente em que você quer definir um novo servidor de destino.
Clique em Servidores de destino na parte superior do painel.
Clique em + Criar servidor de destino.
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.
Clique em Criar.

Apigee clássica

Para criar servidores de destino usando a interface clássica da Apigee:

Faça login na IU da Apigee.
Selecione Administrador > Ambientes > TargetServers.
Na lista suspensa Ambiente, selecione o ambiente em que você quer definir um novo servidor de destino.
A IU da Apigee exibe uma lista dos servidores de destino atuais no ambiente selecionado:
Clique em +Servidor de destino para adicionar um novo servidor de destino ao ambiente selecionado.
A caixa de diálogo Adicionar servidor de destino é exibida:
Clique em Ativado para ativar a nova definição de servidor de destino imediatamente após a criação.
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).
Clique em Adicionar.
A Apigee cria a nova definição do servidor de destino.
Depois de criar um novo servidor de destino, 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 servidores de destino.

Como criar um servidor de destino em um ambiente usando a API
Como listar os servidores de destino em um ambiente usando a API

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

Como criar um servidor de destino em um ambiente usando a API

Para criar um servidor de destino 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 servidor de destino usando a chamada de API a seguir. Ao definir dois servidores de destino , você fornece dois URLs que um endpoint de destino 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 servidores de destino em um ambiente usando a API

Para listar os servidores de destino 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 servidores de destino disponíveis para uso por proxies de API implantados no ambiente test. Para balancear a carga do tráfego nesses servidores de destino, configure a conexão HTTP no endpoint de destino de um proxy de API para usar os servidores de destino.

Como configurar um endpoint de destino para balancear a carga em servidores de destino nomeados

Agora que você tem dois servidores de destino disponíveis, é possível modificar o elemento <HTTPTargetConnection> do endpoint de destino para fazer referência a esses dois servidores 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 endpoint de destino para todos os servidores de destino. 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 servidores de destino.

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 servidor de destino, 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.

Ordem aleatória

O algoritmo padrão, round-robin, encaminha uma solicitação para cada servidor de destino na ordem em que os servidores estão listados na conexão HTTP do endpoint de destino. Por 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 servidores de destino. O LoadBalancer ponderado distribui as solicitações aos servidores de destino em proporção direta ao peso de cada servidor de destino. Portanto, o algoritmo ponderado requer que você defina um atributo weight para cada servidor de destino. Por 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 servidor de destino com menos conexões HTTP abertas. Por 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 servidor de destino que fazem com que a solicitação seja redirecionada para outro servidor de destino.

Uma falha na resposta significa que a Apigee não recebe resposta de um servidor de destino. 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 404 ou 500), isso é contabilizado como uma resposta do servidor de destino e o contador de falha é redefinido. Para 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 404 e algumas respostas 5XX do servidor de destino.

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
        <ServerUnhealthyResponse>
            <ResponseCode>404</ResponseCode>
            <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 servidor de destino da rotação.

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

As chamadas de API regulares e as iniciadas por um monitor de integridade são contabilizadas na contagem de MaxFailures.

Além disso, a contagem de falhas em execução de cada servidor de destino é mantida por balanceador de carga. Por exemplo, imagine que um proxy tem dois endpoints de destino, ambos com um balanceador de carga configurado para usar o mesmo conjunto de servidores de destino. Nesse caso, as falhas de um endpoint de destino são contabilizadas apenas no balanceador de carga correspondente. Elas não afetam a rotação do outro endpoint de destino.

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

Tentar novamente

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. Por exemplo:

<RetryEnabled>false</RetryEnabled>

IsFallback

Um (e apenas um) servidor de destino pode ser definido como o servidor substituto. O balanceador de carga não vai usar o servidor substituto até que todos os outros servidores de destino sejam removidos da rotação pelo balanceador de carga. Quando isso acontece, todo o tráfego é roteado para o servidor substituto até que um dos outros servidores de destino seja novamente considerado íntegro e volte à rotação. Por 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.

Se o servidor substituto não estiver íntegro, a Apigee não vai rotear o tráfego para ele. Em vez disso, as chamadas de API vão retornar o erro 503 "O serviço está temporariamente indisponível".

Caminho

O caminho define um fragmento de URI que será anexado a todas as solicitações emitidas pelo servidor de destino 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 servidor de destino para TLS/SSL

Se você estiver usando um servidor de destino 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 servidor de destino. Isso é necessário porque a tag host não permite que você especifique o protocolo de conexão.

Observação: se você definir o bloco sSLInfo nas definições de endpoint de destino e servidor de destino, o bloco do servidor de destino terá precedência.

Configurar TLS/SSL unidirecional

Use a configuração a seguir para definir um servidor de destino com TLS/SSL unidirecional. Neste exemplo, a Apigee faz solicitações HTTPS para o serviço de back-end:

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

Configurar a aplicação obrigatória de SSL

Para especificar a aplicação rigorosa do SSL na definição do servidor de destino, defina enforce como true no bloco sSLInfo, conforme mostrado no exemplo a seguir:

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

Configurar TLS/SSL bidirecional

Se o serviço de back-end exigir TLS/SSL bidirecional ou mútuo, configure o servidor de destino com as mesmas configurações de TLS/SSL que os endpoints de destino:

{
  "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": []
  }
}

Configurar SSL rigoroso usando a API

Para criar um servidor de destino com aplicação rigorosa de 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,
      "enforce":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 servidor de destino. Com o monitoramento de integridade ativado, os servidores de destino inacessíveis ou que retornam uma resposta de erro são marcados como não íntegros. Um servidor de destino com falha é automaticamente colocado de volta em rotação quando o monitor de integridade determina que o servidor de destino está ativo. Não é necessário reimplantações de proxy.

Você precisa definir <MaxFailures> como maior que 0 ao usar um monitor de integridade. Se o valor de <MaxFailures> for definido como 0, a Apigee sempre tentará se conectar ao destino para cada solicitação e não removerá o servidor de destino da rotação.

Um monitor de integridade 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. Uma verificação de integridade é uma solicitação enviada ao servidor de destino que determina se ele está íntegro ou não.

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

Sucesso: o servidor de destino é considerado íntegro quando ocorre uma verificação de integridade bem-sucedida. Isso normalmente é resultado de um ou mais dos seguintes procedimentos:
- O servidor de destino aceita uma nova conexão com a porta especificada, responde a uma solicitação nessa porta e a fecha dentro do período especificado. A resposta do servidor de destino contém Connection: close
- O servidor de destino responde a uma solicitação de verificação de integridade com um 200 (OK) ou outro código de status HTTP que você determine como aceitável.
- O servidor de destino responde a uma solicitação de verificação de integridade com um corpo de mensagem que corresponda ao esperado.
Quando a Apigee determina que um servidor está íntegro, ela continua ou retoma o envio de solicitações para o servidor.
Falha: o servidor de destino pode falhar em uma verificação de integridade de maneiras diferentes, dependendo do tipo de verificação. Uma falha pode ser registrada quando o servidor de destino:
- 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 servidor de destino 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 monitor de integridade

Para criar um monitor de integridade para um proxy de API, adicione o elemento <HealthMonitor> à configuração de elemento <HTTPTargetConnection do endpoint de destino para o proxy.

Não é possível criar monitores de integridade na interface. 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.

Elementos de configuração `<HealthMonitor>`

A tabela a seguir descreve os elementos de configuração <HealthMonitor>:

Nome	Descrição	Padrão	Obrigatório?
`IsEnabled`	É um booleano que ativa ou desativa o monitor de integridade.	false	Não
`IntervalInSec`	O intervalo de tempo, em segundos, entre cada solicitação TCP ou HTTP de sondagem.	0	Sim
`HTTPMonitor` ou `TCPMonitor`	Uma definição do cliente TCP ou HTTP a ser usado para pesquisar o servidor de destino.	N/A	Sim

Além desses elementos, para ativar um monitoramento de integridade, é necessário definir o elemento <MaxFailures> no bloco <HTTPTargetConnection> do elemento <TargetEndpoint> como um valor maior que 0. <MaxFailures> é usado para especificar o número máximo de solicitações com falha do proxy de API para o servidor de destino que podem ocorrer antes que a solicitação seja redirecionada para outro servidor de destino.

Por padrão, <MaxFailures> é 0, o que significa que a Apigee não executa nenhuma ação corretiva. Ao configurar um monitor de integridade, defina <MaxFailures> como um valor diferente de zero.

Monitoramento de integridade usando monitoramento TCP

O exemplo de monitor de integridade descrito na configuração a seguir usa um monitor TCP para pesquisar cada servidor de destino abrindo uma conexão na porta 80 a cada cinco segundos. A porta é opcional. Se não for especificada, a porta do monitor TCP será a servidor de destino.

Neste exemplo de configuração do monitor de integridade:

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

É possível adicionar um monitor de integridade como elemento filho do elemento <HTTPTargetConnection> do endpoint de destino, conforme 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>

Elementos de configuração `<TCPMonitor>`

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

Nome	Descrição	Padrão	Obrigatório?
`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 servidor de destino.	0	Sim
`Port`	Opcional. A porta em que a conexão TCP será estabelecida. Se não for especificada, a porta TCPMonitor será a servidor de destino.	0	Não

Monitoramento de integridade usando monitoramento HTTP

O monitor de integridade descrito na configuração a seguir usa um monitor HTTP que envia uma solicitação GET para o serviço de back-end uma vez a cada cinco segundos e adiciona um cabeçalho de autorização básica HTTP à mensagem de solicitação.

Neste exemplo de configuração do monitor de integridade:

A resposta esperada do serviço de back-end é um código de resposta HTTP 200.
O valor esperado para o cabeçalho personalizado de autorização básica HTTP ImOK é YourOK.
O elemento <UseTargetServerSSLInfo> é definido como true para usar os parâmetros SSL do bloco <SSLInfo> do servidor de destino.

Com essa configuração, os códigos de resposta e os valores de cabeçalho esperados são comparados com as respostas reais do serviço de back-end. Se a resposta não for correspondente, a solicitação será tratada como uma falha pela configuração do balanceador de carga.

Por padrão, os monitores de integridade não podem acessar keystores, truststores ou outros parâmetros de SSL a partir de seus servidores de destino. Para ativar o acesso a esses parâmetros no monitor de integridade para oferecer suporte ao TLS mútuo, por exemplo, adicione <UseTargetServerSSLInfo>true</UseTargetServerSSLInfo> no bloco <Request>.

    <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>
              <UseTargetServerSSLInfo>true</UseTargetServerSSLInfo>
              <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 `<HTTPMonitor>`

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

Nome	Descrição	Padrão	Obrigatório?
`Request`	A mensagem de solicitação de saída enviada pelo monitor de integridade aos servidores de destino na rotação.	N/A	Sim
`SuccessResponse`	(Opcional) Opções de correspondência para a mensagem de resposta HTTP de entrada gerada pelo serviço de back-end sondado.	N/A	Não

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

Opções de configuração para a mensagem de solicitação de saída enviada pelo monitor de integridade para os servidores de destino 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 A falha de conexão no intervalo especificado conta como uma falha, aumentando a contagem de falhas do balanceador de carga do servidor de destino. Observação: se o valor especificado for 0, a Apigee vai usar um tempo limite padrão de 30 segundos.	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 servidor de destino. Observação: se o valor especificado for 0, a Apigee vai usar um tempo limite padrão de 30 segundos.	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	Não
`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 servidor de destino. 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
`UseTargetServerSSLInfo`	Quando `UseTargetServerSSLInfo` for verdadeiro, as solicitações do monitoramento de integridade para um servidor de destino usarão os parâmetros SSL do bloco SSLInfo ("sSLInfo") do servidor de destino. Caso contrário, os parâmetros de SSL, como protocolo, keystore, truststore e assim por diante, não estarão disponíveis para o monitor de integridade.	false	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	Não
`Header`	Um ou mais cabeçalhos e valores HTTP 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 servidor de destino pesquisado é incrementada em 1. É possível definir vários elementos de cabeçalho.	N/A	Não
`IsSSL`	Quando verdadeiro, especifica que a solicitação do monitor de integridade seja enviada usando HTTPS.	Falso	Não
`TrustAllSSL`	Especifica se a verificação do monitor HTTP confiará automaticamente em todos os certificados SSL.	Falso	Não

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 de destino 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
`Header`	Um ou mais cabeçalhos e valores HTTP 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 servidor de destino pesquisado é incrementada em 1. É possível definir vários elementos de cabeçalho.	N/A	Não

Balanceamento de carga entre servidores de back-end

Vídeos

Sobre a configuração do servidor de destino

Como criar servidores de destino

Apigee no console do Cloud

Apigee clássica

API Apigee

Como criar um servidor de destino em um ambiente usando a API

Como listar os servidores de destino em um ambiente usando a API

Como configurar um endpoint de destino para balancear a carga em servidores de destino nomeados

Como configurar opções do balanceador de carga

Algoritmo

Ordem aleatória

Ponderado

Escalonamento dinâmico

Máximo de falhas

Tentar novamente

IsFallback

Caminho

Como configurar um servidor de destino para TLS/SSL

Configurar TLS/SSL unidirecional

Configurar a aplicação obrigatória de SSL

Configurar TLS/SSL bidirecional

Configurar SSL rigoroso usando a API

Monitoramento de integridade

Sucessos e falhas

Como ativar um monitor de integridade

Elementos de configuração <HealthMonitor>

Monitoramento de integridade usando monitoramento TCP

Elementos de configuração <TCPMonitor>

Monitoramento de integridade usando monitoramento HTTP

Elementos de configuração <HTTPMonitor>

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

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

Elementos de configuração `<HealthMonitor>`

Elementos de configuração `<TCPMonitor>`

Elementos de configuração `<HTTPMonitor>`