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á.
# Solução dos problemas de um Classic Load Balancer: verificações de integridade
Seu balanceador de carga verifica a integridade das instâncias registradas usando a configuração padrão de verificação de integridade fornecida pelo Elastic Load Balancing ou uma configuração de verificação de integridade personalizada que você especificar. A configuração de verificação de integridade contém informações como protocolo, porta de ping, caminho de ping, tempo limite de resposta e intervalo de verificação de integridade. Uma instância é considerada íntegra se retornar um código de resposta 200 dentro do intervalo de verificação de integridade. Para obter mais informações, consulte [Verificações de integridade para as instâncias do Classic Load Balancer](elb-healthchecks.md).
Se o estado atual de algumas ou todas as suas instâncias for `OutOfService` e o campo de descrição exibir a mensagem `Instance has failed at least the Unhealthy Threshold number of health checks consecutively`, as instâncias terão falhado na verificação de integridade do load balancer. A seguir estão os problemas a serem procurados, as possíveis causas e as etapas que você pode tomar para resolver os problemas.
**Topics**
+ [Erro na página de destino da verificação de integridade](#ts-elb-healthcheck-targetpage)
+ [A conexão com as instâncias expirou](#ts-elb-healthcheck-failed)
+ [A autenticação de chave pública não está funcionando](#ts-elb-healthcheck-publickey)
+ [A instância não está recebendo tráfego do load balancer](#ts-elb-healthcheck-securitygroup)
+ [As portas da instância não estão abertas](#ts-elb-healthcheck-ports)
+ [As instâncias em um grupo do Auto Scaling estão falhando na verificação de integridade do ELB](#ts-elb-healthcheck-autoscaling)
## Erro na página de destino da verificação de integridade
**Problema**: uma solicitação HTTP GET emitida para a instância na porta e no caminho de ping especificados (por exemplo, HTTP:80/index.html) recebe um código de resposta diferente de 200.
**Causa 1**: nenhuma página de destino foi configurada na instância.
**Solução 1**: crie uma página de destino (por exemplo, `index.html`) em cada instância registrada e especifique seu caminho como o caminho de ping.
**Causa 2**: o valor do cabeçalho Content-Length na resposta não está definido.
**Solução 2**: se a resposta inclui um corpo, defina o cabeçalho Content-Length para um valor maior ou igual a zero ou defina o valor de Transfer-Encoding para "chunked" (em partes).
**Causa 3**: o aplicativo não foi configurado para receber solicitações do load balancer nem para retornar um código de resposta 200.
**Solução 3**: verifique o aplicativo na instância para investigar a causa.
## A conexão com as instâncias expirou
**Problema**: as solicitações de verificação de integridade do load balancer para as instâncias do EC2 estão expirando ou apresentando falhas intermitentemente.
Primeiro, verifique o problema conectando-se diretamente com a instância. Recomendamos que você se conecte à sua instância de dentro da rede usando o endereço IP privado da instância.
Use o comando a seguir para uma conexão TCP:
```
telnet {{private-IP-address-of-the-instance}} {{port}}
```
Use o comando a seguir para uma conexão HTTP ou HTTPS:
```
curl –I {{private-IP-address-of-the-instance}}:{{port}}/{{health-check-target-page}}
```
Se você estiver usando uma HTTP/HTTPS conexão e obtendo uma resposta diferente de 200, consulte[Erro na página de destino da verificação de integridade](#ts-elb-healthcheck-targetpage). Se você for capaz de se conectar diretamente com a instância, verifique o seguinte:
**Causa 1**: a instância está falhando ao responder dentro do tempo limite de resposta configurado.
**Solução 1**: ajuste as configurações de tempo limite de resposta na configuração de verificação de integridade do load balancer.
**Causa 2**: a instância está sob uma carga significativa e está demorando mais do que o tempo limite de resposta configurado para responder.
**Solução 2**:
+ Verifique o gráfico de monitoramento quanto à superutilização de CPU. Para obter mais informações, consulte [Obter estatísticas para uma instância do EC2 específica](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/US_SingleMetricPerInstance.html) no *Guia do usuário do Amazon EC2*.
+ Verifique a utilização de recursos de outros aplicativos, como memória ou limites, conectando-se às suas instâncias EC2.
+ Se necessário, adicione mais instâncias ou habilite o Auto Scaling. Para obter mais informações, consulte o [Guia do usuário do Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/).
**Causa 3**: se você está usando uma conexão HTTP ou HTTPS e a verificação de integridade está sendo executada em uma página de destino especificada no campo de caminho de ping (por exemplo, `HTTP:80/index.html`), pode ser que a página de destino precise de mais tempo para responder do que o tempo limite configurado.
**Solução 3**: use uma página de destino de verificação de integridade mais simples ou ajuste as configurações do intervalo de verificação de integridade.
## A autenticação de chave pública não está funcionando
**Problema**: um load balancer configurado para usar o protocolo HTTPS ou SSL com a autenticação de back-end habilitada falha ao autenticar a chave pública.
**Causa**: a chave pública no certificado SSL não corresponde à chave pública configurada no load balancer. Use o comando `s_client` para ver a lista de certificados no servidor na cadeia de certificação. Para obter mais informações, consulte [s\_client](https://www.openssl.org/docs/man1.1.1/man1/openssl-s_client.html) na documentação do OpenSSL.
**Solução**: talvez você precise atualizar seu certificado SSL. Se o seu certificado SSL estiver atualizado, tente reinstalá-lo no seu load balancer. Para obter mais informações, consulte [Substituir o certificado SSL do seu Classic Load Balancer](elb-update-ssl-cert.md).
## A instância não está recebendo tráfego do load balancer
**Problema**: o security group da instância está bloqueando o tráfego do load balancer.
Faça uma captura de pacotes na instância para verificar o problema. Use o seguinte comando:
```
# tcpdump port {{health-check-port}}
```
**Causa 1**: o security group associado à instância não permite tráfego do load balancer.
**Solução 1**: edite o security group da instância para permitir o tráfego do load balancer. Adicione uma regra para permitir todo o tráfego do security group do load balancer.
**Causa 2**: o grupo de segurança do balanceador de carga não permite tráfego para as instâncias do EC2.
**Solução 2**: edite o security group do load balancer para permitir o tráfego para as sub-redes e instâncias do EC2.
Para obter informações sobre como gerenciar grupo de seguranças, consulte [Configurar grupos de segurança para o Classic Load Balancer](elb-vpc-security-groups.md).
## As portas da instância não estão abertas
**Problema**: a verificação de integridade enviada à instância do EC2 pelo load balancer está bloqueada pela porta ou por um firewall.
Verifique o problema usando o seguinte comando:
```
netstat –ant
```
**Causa**: a porta de integridade ou a porta do listener especificada (se configurada de outra maneira) não está aberta. Tanto a porta especificada para a verificação de integridade quanto a porta do listener devem estar abertas e ouvindo.
**Solução**: abra a porta do listener e a porta especificadas na configuração de verificação de integridade (se configurada de outra maneira) nas instâncias para receber tráfego do load balancer.
## As instâncias em um grupo do Auto Scaling estão falhando na verificação de integridade do ELB
**Problema**: as instâncias no grupo do Auto Scaling são aprovadas na verificação de integridade padrão do Auto Scaling, mas não na verificação de integridade do ELB.
**Causa**: o Auto Scaling usa as verificações de status do EC2 para detectar problemas de hardware e software com as instâncias, mas o balanceador executa verificações de integridade enviando uma solicitação à instância e aguardando um código de resposta 200 ou estabelecendo uma conexão TCP (para uma verificação de integridade baseada em TCP) com a instância.
Uma instância pode falhar na verificação de integridade do ELB porque um aplicativo em execução na instância tem problemas que fazem com que o load balancer a considere fora de serviço. Essa instância pode ser aprovada na verificação de integridade do Auto Scaling. Ela não seria substituída pela política do Auto Scaling, porque é considerada íntegra com base na verificação de status do EC2.
**Solução**: use a verificação de integridade do ELB para o grupo do Auto Scaling. Quando você usa a verificação de integridade do ELB, o Auto Scaling determina o status da integridade de suas instâncias ao verificar os resultados tanto da verificação de status da instância quanto da verificação de integridade do ELB. Para obter mais informações, consulte [Adicionar verificações de integridade do Elastic Load Balancing ao grupo do Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/attach-load-balancer-asg.html) no *Manual do usuário do Amazon EC2 Auto Scaling*.