

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Verificações de integridade de grupos de destino do Gateway Load Balancer
<a name="health-checks"></a>

Você pode registrar os destinos com um ou mais grupos de destino. O Gateway Load Balancer inicia o roteamento de solicitações para um destino recém-registrado assim que o processo de registro é concluído. Pode levar alguns minutos para que o processo de registro seja concluído e as verificações de integridade sejam iniciadas.

O Gateway Load Balancer envia periodicamente uma solicitação para cada destino registrado para verificar seu status. Após cada verificação de integridade ser concluída, o Gateway Load Balancer fechará a conexão estabelecida para a verificação de integridade.

## Configurações de verificação de integridade
<a name="health-check-settings"></a>

Você pode configurar as verificações de integridade ativas para os destinos em um grupo de destino usando as configurações a seguir. Se as verificações de integridade excederem o número especificado de falhas **UnhealthyThresholdCount**consecutivas, o Gateway Load Balancer desativará o alvo. Quando as verificações de integridade excedem o número especificado de sucessos **HealthyThresholdCount**consecutivos, o Gateway Load Balancer coloca o alvo novamente em serviço.


| Configuração | Descrição | 
| --- | --- | 
| **HealthCheckProtocol** | O protocole que o load balancer usa ao executar verificações de integridade nos destinos. Os protocolos possíveis são HTTP, HTTPS e TCP. O padrão é TCP. | 
| **HealthCheckPort** | A porta que o Gateway Load Balancer usa ao executar verificações de integridade nos destinos. O intervalo é de 1 a 65535. O padrão é 80. | 
| **HealthCheckPath** | [Verificações de integridade de HTTP/HTTPS] O caminho da verificação de integridade que é o destino para verificações de integridade. O padrão é /. | 
| **HealthCheckTimeoutSeconds** | O tempo, em segundos, durante o qual ausência de resposta de um destino significa uma falha na verificação de integridade. O intervalo é de 2 a 120. O padrão é 5. | 
| **HealthCheckIntervalSeconds** | A quantia aproximada de tempo, em segundos, entre as verificações de integridade de um destino individual. O intervalo é de 5 a 300. O padrão é 10 segundos. Esse valor deve ser maior ou igual **HealthCheckTimeoutSeconds**a. As verificações de integridade para Gateway Load Balancers são distribuídas e usam um mecanismo de consenso para determinar a integridade do destino. Portanto, você deve esperar que os dispositivos de destino recebam várias verificações de integridade dentro do intervalo de tempo configurado.  | 
| **HealthyThresholdCount** | O número de verificações de integridade bem-sucedidas consecutivas necessárias antes de considerar íntegro um destino não íntegro. O intervalo é de 2 a 10. O padrão é 5. | 
| **UnhealthyThresholdCount** | O número de verificações de integridade consecutivas exigido antes considerar um destino não íntegro. O intervalo é de 2 a 10. O padrão é 2. | 
| **Matcher** | [Verificações de integridade de HTTP/HTTPS] Os códigos HTTP a serem usados ao verificar uma resposta bem-sucedida de um destino. Esse valor deve ser entre 200–399. | 

## Status de integridade do destino
<a name="target-health-states"></a>

Antes que o Gateway Load Balancer envie uma solicitação de verificação de integridade para um destino, você deverá registrá-lo com um grupo de destino, especificar o grupo de destino em uma regra do receptor e garantir que a zona de disponibilidade do destino esteja habilitada para o Gateway Load Balancer.

A tabela a seguir descreve os valores possíveis para o status de integridade de um destino registrado.


| Valor | Descrição | 
| --- | --- | 
| `initial` | O Gateway Load Balancer está no processo de registro do destino ou executando as verificações de integridade iniciais no destino.<br />Códigos de motivo relacionados: `Elb.RegistrationInProgress` \| `Elb.InitialHealthChecking` | 
| `healthy` | O destino é íntegro.<br />Códigos de motivo relacionados: nenhum | 
| `unhealthy` | O destino não respondeu a uma verificação de integridade ou falhou em uma verificação de integridade.<br />Código de motivo relacionado: `Target.FailedHealthChecks` | 
| `unused` | O destino não está registrado em um grupo de destino, o grupo de destino não é usado em uma regra do listener, o destino está em uma zona de disponibilidade desativada ou o destino está no estado parado ou encerrado.<br />Códigos de motivo relacionados: `Target.NotRegistered` \| `Target.NotInUse` \| `Target.InvalidState` \| `Target.IpUnusable` | 
| `draining` | O destino está cancelando o registro e está acontecendo drenagem da conexão.<br />Código de motivo relacionado: `Target.DeregistrationInProgress` | 
| `unavailable` | A integridade do destino não está disponível.<br />Código de motivo relacionado: `Elb.InternalError` | 

## Códigos de motivo de verificação de integridade
<a name="target-health-reason-codes"></a>

Se o status de um destino for qualquer valor diferente de `Healthy`, a API retornará um código de motivo e uma descrição do problema; o console exibirá a mesma descrição. Os códigos de motivo que começarem com `Elb` são originados no Gateway Load Balancer, e os códigos de motivo que começarem com `Target` são originados no destino.


| Código do motivo | Descrição | 
| --- | --- | 
| `Elb.InitialHealthChecking` | Verificações de integridade iniciais em andamento | 
| `Elb.InternalError` | As verificações de integridade falharam devido a um erro interno | 
| `Elb.RegistrationInProgress` | O registro do destino está em andamento | 
| `Target.DeregistrationInProgress` | O cancelamento do registro do destino está em andamento | 
| `Target.FailedHealthChecks` | Verificações de integridade com falha | 
| `Target.InvalidState` | O destino está no estado interrompido<br />O destino está no estado encerrado<br />O destino está no estado encerrado ou interrompido<br />O destino está em um estado inválido | 
| `Target.IpUnusable` | O endereço IP não pode ser usado como um destino, uma vez que está sendo usado por um load balancer. | 
| `Target.NotInUse` | O grupo de destino não está configurado para receber tráfego do Gateway Load Balancer<br />O destino está em uma zona de disponibilidade que não está habilitada para o Gateway Load Balancer | 
| `Target.NotRegistered` | O destino não está registrado no grupo de destino | 

## Cenários de falha do destino do Gateway Load Balancer
<a name="failure-scenarios"></a>

**Fluxos existentes**: por padrão, os fluxos existentes vão para o mesmo destino, a menos que atinjam o tempo limite ou sejam redefinidos, independentemente do status de integridade e registro do destino. Essa abordagem facilita a drenagem da conexão e acomoda firewalls de terceiros que às vezes não conseguem responder às verificações de integridade devido ao alto uso da CPU. Para obter mais informações, consulte [Failover de destino](edit-target-group-attributes.md#target-failover).

**Novos fluxos**: novos fluxos são enviados para um destino íntegro. Quando uma decisão de balanceamento de carga para um fluxo for tomada, o Gateway Load Balancer enviará o fluxo para o mesmo destino, mesmo que esse destino não seja mais íntegro ou que outros destinos fiquem íntegros.

Quando todos os destinos não estão íntegros, o Gateway Load Balancer escolhe um destino aleatoriamente e encaminha o tráfego para ele durante toda a vida útil do fluxo, até que ele seja reiniciado ou tenha atingido o tempo limite. Como o tráfego está sendo encaminhado para um destino não íntegro, o tráfego é descartado até que o destino volte a ser íntegro.

**TLS 1.3**: se um grupo de destino estiver configurado com verificações de integridade de HTTPS, seus destinos registrados falharão nas verificações de integridade se oferecerem suporte somente a TLS 1.3. Esses destinos devem oferecer suporte a uma versão anterior do TLS, como o TLS 1.2.

**Balanceamento de carga entre zonas**: por padrão, o balanceamento de carga entre zonas de disponibilidade está desativado. Se o balanceamento de carga entre zonas estiver ativado, cada Gateway Load Balancer poderá ver todos os destinos em todas as zonas de disponibilidade, e todos serão tratados da mesma forma, independentemente da zona. 

As decisões de balanceamento de carga e verificação de integridade são sempre independentes entre as zonas. Mesmo quando o balanceamento de carga entre zonas está ativado, o comportamento dos fluxos existentes e dos novos fluxos é o mesmo descrito acima. Para mais informações, consulte [Balanceamento de carga entre zonas](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#cross-zone-load-balancing) no *Manual do usuário do Elastic Load Balancing*.

## Verificar a integridade de seus destinos
<a name="check-target-health"></a>

Você pode verificar a integridade dos destinos registrados com seus grupos de destino.

**Para verificar a integridade dos seus destinos usando o console**

1. Abra o EC2 console da Amazon em [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. No painel de navegação, em **Balanceamento de carga**, selecione **Grupos de destino**.

1. Escolha o nome do grupo de destino para abrir sua página de detalhes.

1. Na guia **Destinos**, a coluna **Status** indica o status de cada destino.

1. Se o status de destino for qualquer valor diferente de `Healthy`, a coluna **Detalhes do status** conterá mais informações.

**Para verificar a saúde de seus alvos usando o AWS CLI**  
Use o comando [describe-target-health](https://docs.aws.amazon.com/cli/latest/reference/elbv2/describe-target-health.html). O resultado desse comando contém o estado de integridade do destino. Ele incluirá um código de motivo se o status for qualquer valor diferente de `Healthy`.

**Como receber notificações por e-mail sobre destinos não íntegros**  
Use CloudWatch alarmes para acionar uma função Lambda para enviar detalhes sobre alvos não íntegros. Para step-by-step obter instruções, consulte a seguinte postagem no blog: [Identificação de alvos não íntegros do seu balanceador de carga](https://aws.amazon.com/blogs/networking-and-content-delivery/identifying-unhealthy-targets-of-elastic-load-balancer/).

## Modificar configurações de verificação de integridade
<a name="modify-health-check-settings"></a>

Você pode modificar algumas das configurações de verificação de integridade de seu grupo de destino.

**Para modificar as configurações de verificação de integridade de um grupo de destino usando o console**

1. Abra o EC2 console da Amazon em [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. No painel de navegação, em **Balanceamento de carga**, selecione **Grupos de destino**.

1. Escolha o nome do grupo de destino para abrir sua página de detalhes.

1. Na guia **Detalhes do grupo**, na seção **Configurações da verificação de integridade**, escolha **Editar**.

1. Na página **Editar configurações da verificação de integridade**, modifique as configurações conforme necessário e escolha **Salvar alterações**.

**Para modificar as configurações de verificação de saúde de um grupo-alvo usando o AWS CLI**  
Use o comando [modify-target-group](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-target-group.html).