CloudWatch métricas para seu Classic Load Balancer - Elastic Load Balancing

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

CloudWatch métricas para seu Classic Load Balancer

O Elastic Load Balancing publica pontos de dados na Amazon CloudWatch para seus balanceadores de carga e suas instâncias de back-end. CloudWatch permite que você recupere estatísticas sobre esses pontos de dados como um conjunto ordenado de dados de séries temporais, conhecido como métricas. Considere uma métrica como uma variável a ser monitorada, e os pontos de dados como os valores dessa variável ao longo do tempo. Por exemplo, você pode monitorar o número total de EC2 instâncias íntegras de um balanceador de carga em um período de tempo especificado. Cada ponto de dados tem um time stamp associado e uma unidade de medida opcional.

Você pode usar métricas para verificar se o sistema está executando conforme o esperado. Por exemplo, você pode criar um CloudWatch alarme para monitorar uma métrica específica e iniciar uma ação (como enviar uma notificação para um endereço de e-mail) se a métrica estiver fora do que você considera um intervalo aceitável.

O Elastic Load Balancing reporta métricas CloudWatch somente quando as solicitações estão fluindo pelo balanceador de carga. Se houver solicitações passando pelo balanceador de carga, o Elastic Load Balancing vai medir e enviar suas métricas em intervalos de 60 segundos. Se não há solicitações passando pelo load balancer ou não há dados para uma métrica, a métrica não é reportada.

Para obter mais informações sobre a Amazon CloudWatch, consulte o Guia CloudWatch do usuário da Amazon.

Métricas do Classic Load Balancer

O namespace AWS/ELB inclui as métricas a seguir.

Métrica Descrição
BackendConnectionErrors

O número de conexões que não foram estabelecidas com êxito entre o load balancer e as instâncias registradas. Como o load balancer tenta executar a conexão novamente quando há erros, essa contagem pode exceder a taxa de solicitações. Observe que essa contagem também inclui erros de conexão relacionados a verificações de saúde.

Critérios de relatório: há um valor diferente de zero

Estatísticas: a estatística mais útil é Sum. Observe que Average, Minimum e Maximum são reportadas por nó do load balancer e geralmente não são úteis. No entanto, a diferença entre o mínimo e o máximo (ou o pico e a média ou a média e o mais baixo) pode ser útil para determinar se um nó de load balancer é uma exceção.

Example: suponhamos que o load balancer tenha 2 instâncias em us-west-2a e 2 instâncias em us-west-2b e que tentativas de se conectar a 1 instância em us-west-2a resultem em erros de conexão do back-end. A soma para us-west-2a inclui esses erros de conexão, enquanto a soma para us-west-2b não os inclui. Portanto, a soma para o load balancer é igual à soma para us-west-2a.

DesyncMitigationMode_NonCompliant_Request_Count

[HTTPouvinte] O número de solicitações que não estão em conformidade com RFC 7230.

Critérios de relatório: há um valor diferente de zero

Estatísticas: a estatística mais útil é Sum.

HealthyHostCount

O número de instâncias íntegras registradas com o load balancer. A instância recém-registrada é considerada saudável após passar pela primeira verificação de saúde. Se o balanceamento de carga entre zonas estiver ativado, o número de instâncias saudáveis para a dimensão LoadBalancerName é calculado em todas as zonas de disponibilidade. Do contrário, ele é calculado por zona de disponibilidade.

Reporting criteria: há instâncias registradas

Estatísticas: as estatísticas mais úteis são Average e Maximum. Essas estatísticas são determinadas pelos nós do load balancer. Observe que alguns nós do load balancer podem determinar que uma instância não é saudável por um breve período, enquanto outros nós determinam que ela é saudável.

Example: suponhamos que o load balancer tenha 2 Instâncias em us-west-2a e 2 instâncias em us-west-2b e us-west-2a tem 1 instância não íntegra e us-west-2b não tem nenhuma instância não íntegra. Com a dimensão AvailabilityZone, há uma média de 1 instância saudável e 1 não saudável em us-west-2a e uma média de 2 instâncias saudáveis e 0 instâncias não saudáveis em us-west-2b.

HTTPCode_Backend_2XX, HTTPCode_Backend_3XX, HTTPCode_Backend_4XX, HTTPCode_Backend_5XX

[HTTPouvinte] O número de códigos de HTTP resposta gerados pelas instâncias registradas. Essa contagem não inclui códigos de resposta gerados pelo load balancer.

Critérios de relatório: há um valor diferente de zero

Estatísticas: a estatística mais útil é Sum. Observe que Minimum, Maximum e Average são todos 1.

Exemplo: suponha que seu balanceador de carga tenha 2 instâncias em us-west-2a e 2 instâncias em us-west-2b, e que as solicitações enviadas para 1 instância em us-west-2a resultem em 500 respostas. HTTP A soma para us-west-2a inclui essas respostas de erro, enquanto a soma para us-west-2b não as inclui. Portanto, a soma para o load balancer é igual à soma para us-west-2a.

HTTPCode_ELB_4XX

[HTTPouvinte] O número de códigos de erro do cliente HTTP 4XX gerados pelo balanceador de carga. Erros de cliente são gerados quando uma solicitação é defeituosa ou incompleta.

Critérios de relatório: há um valor diferente de zero

Estatísticas: a estatística mais útil é Sum. Observe que Minimum, Maximum e Average são todos 1.

Exemplo: suponha que seu balanceador de carga tenha us-west-2a e us-west-2b ativados e que as solicitações do cliente incluam uma solicitação malformada. URL Como resultado, os erros do cliente provavelmente vão aumentar em todas as zonas de disponibilidade. A soma para o load balancer é a soma dos valores para as zonas de disponibilidade.

HTTPCode_ELB_5XX

[HTTPouvinte] O número de códigos de erro do servidor HTTP 5XX gerados pelo balanceador de carga. Essa contagem não inclui códigos de resposta gerados por instâncias registradas. A métrica é reportada se não houver instâncias saudáveis registradas no load balancer, ou se a taxa de solicitações excede a capacidade das instâncias (spillover) ou do load balancer.

Critérios de relatório: há um valor diferente de zero

Estatísticas: a estatística mais útil é Sum. Observe que Minimum, Maximum e Average são todos 1.

Example: suponhamos que o load balancer tenha us-west-2a e us-west-2b habilitados e que as instâncias em us-west-2a estejam enfrentando latência alta e demorando para responder a solicitações. Como resultado, a fila de pico para os nós do load balancer em us-west-2a é preenchida, e os clientes recebem um erro 503. Se us-west-2b continuar a responder normalmente, a soma para o load balancer será igual à soma para us-west-2a.

Latency

[HTTPlistener] O tempo total decorrido, em segundos, desde o momento em que o balanceador de carga enviou a solicitação para uma instância registrada até que a instância começou a enviar os cabeçalhos de resposta.

[TCPlistener] O tempo total decorrido, em segundos, para o balanceador de carga estabelecer com êxito uma conexão com uma instância registrada.

Critérios de relatório: há um valor diferente de zero

Estatísticas: a estatística mais útil é Average. Use Maximum para determinar se algumas solicitações estão levando muito mais tempo do que a média. Observe que Minimum normalmente não é útil.

Example: suponhamos que o load balancer tenha 2 instâncias em us-west-2a e 2 instâncias em us-west-2b e que tentativas enviadas para 1 instância em us-west-2a tenham uma latência maior A média para us-west-2a tem um valor mais alto do que a média para us-west-2b.

RequestCount

O número de solicitações concluídas ou conexões feitas durante o intervalo especificado (1 ou 5 minutos).

[HTTPlistener] O número de solicitações recebidas e roteadas, incluindo respostas de HTTP erro das instâncias registradas.

[TCPouvinte] O número de conexões feitas com as instâncias registradas.

Critérios de relatório: há um valor diferente de zero

Estatísticas: a estatística mais útil é Sum. Observe que Minimum, Maximum e Average retornam 1.

Example: suponhamos que o load balancer tenha 2 instâncias em us-west-2a e 2 instâncias em us-west-2b e que 100 solicitações sejam enviadas para o load balancer. Sessenta solicitações são enviadas para us-west-2a, e cada instância recebe 30 solicitações, e 40 solicitações são enviadas para us-west-2b, e cada instância recebe 20 solicitações. Com a dimensão AvailabilityZone, há uma soma de 60 solicitações em us-west-2a e 40 solicitações em us-west-2b. Com a dimensão LoadBalancerName, há uma soma de 100 solicitações.

SpilloverCount

O número total de solicitações que foram rejeitadas porque a fila de pico está cheia.

[HTTPouvinte] O balanceador de carga retorna um código de erro HTTP 503.

[TCPouvinte] O balanceador de carga fecha a conexão.

Critérios de relatório: há um valor diferente de zero

Estatísticas: a estatística mais útil é Sum. Observe que Average, Minimum e Maximum são reportadas por nó do load balancer e geralmente não são úteis.

Example: suponhamos que o load balancer tenha us-west-2a e us-west-2b habilitados e que as instâncias em us-west-2a estejam enfrentando latência alta e demorando para responder a solicitações. Como resultado, a fila de pico para o nó do load balancer em us-west-2a é preenchida, resultando em spillover. Se us-west-2b continuar a responder normalmente, a soma para o load balancer será a mesma que a soma para us-west-2a.

SurgeQueueLength

O número total de solicitações (HTTPouvinte) ou conexões (TCPouvinte) que estão pendentes de roteamento para uma instância íntegra. O tamanho máximo da fila é 1.024. As solicitações ou conexões adicionais são rejeitadas quando a fila está cheia. Para obter mais informações, consulte SpilloverCount.

Reporting criteria (Critérios de relatório): há um valor diferente de zero.

Statistics: a estatística mais útil é Maximum, porque representa o pico de solicitações em fila. A estatística Average pode ser útil em combinação com Minimum e Maximum para determinar o intervalo de solicitações enfileiradas. Observe que Sum não é útil.

Example: suponhamos que o load balancer tenha us-west-2a e us-west-2b habilitados e que as instâncias em us-west-2a estejam enfrentando latência alta e demorando para responder a solicitações. Como resultado, a fila de pico para os nós do load balancer em us-west-2a é preenchida, gerando maior probabilidade de aumento nos tempos de resposta para os clientes. Se isso continuar, o load balancer provavelmente terá spillovers (consulte a métrica SpilloverCount). Se us-west-2b continuar a responder normalmente, max para o load balancer será o mesmo que max para us-west-2a.

UnHealthyHostCount

O número de instâncias não íntegras registradas com o load balancer. Uma instância é considerada não saudável depois de exceder o limite de saúde configurado para verificações de saúde. Uma instância não saudável é considerada saudável novamente depois de atender ao limite de saúde configurado para verificações de saúde.

Reporting criteria: há instâncias registradas

Estatísticas: as estatísticas mais úteis são Average e Minimum. Essas estatísticas são determinadas pelos nós do load balancer. Observe que alguns nós do load balancer podem determinar que uma instância não é saudável por um breve período, enquanto outros nós determinam que ela é saudável.

Exemplo: consulte HealthyHostCount.

As métricas a seguir permitem estimar os custos caso você migre um Classic Load Balancer para um Application Load Balancer. Essas métricas são destinadas apenas para uso informativo, não para uso com CloudWatch alarmes. Observe que, se o Classic Load Balancer tiver vários listeners, essas métricas serão agregadas entre eles.

Essas estimativas se baseiam em um load balancer com uma regra padrão e um certificado com 2K. Se você usa um certificado de 4K ou mais, recomendamos estimar os custos da seguinte maneira: crie um Application Load Balancer com base no Classic Load Balancer usando a ferramenta de migração e monitore a métrica ConsumedLCUs para o Application Load Balancer. Para obter mais informações, consulte Migrar um Classic Load Balancer para um Application Load Balancer no Manual do usuário do Elastic Load Balancing.

Métrica Descrição
EstimatedALBActiveConnectionCount

O número estimado de TCP conexões simultâneas ativas dos clientes ao balanceador de carga e do balanceador de carga aos destinos.

EstimatedALBConsumedLCUs

O número estimado de unidades de capacidade do balanceador de carga (LCU) usadas por um Application Load Balancer. Você paga pelo número LCUs que usa por hora. Para obter mais informações, consulte Definição de preço do Elastic Load Balancing.

EstimatedALBNewConnectionCount

O número estimado de novas TCP conexões estabelecidas dos clientes com o balanceador de carga e do balanceador de carga com os destinos.

EstimatedProcessedBytes

O número estimado de bytes processados por um Application Load Balancer.

Dimensões métricas dos Classic Load Balancers

Para filtrar as métricas do Classic Load Balancer, use as dimensões a seguir.

Dimensão Descrição
AvailabilityZone

Filtra os dados da métrica pela zona de disponibilidade especificada.

LoadBalancerName

Filtra os dados da métrica pelo load balancer especificado.

Estatísticas para métricas do Classic Load Balancer

CloudWatch fornece estatísticas com base nos pontos de dados métricos publicados pelo Elastic Load Balancing. As estatísticas são agregações de dados de métrica ao longo de um período especificado. Quando você solicita estatísticas, o fluxo de dados apresentado é identificado pelo nome da métrica e pela dimensão. Dimensão é um par de nome/valor que identifica exclusivamente uma métrica. Por exemplo, você pode solicitar estatísticas de todas as EC2 instâncias íntegras por trás de um balanceador de carga lançado em uma zona de disponibilidade específica.

As estatísticas Minimum e Maximum refletem o mínimo e o máximo relatados por cada um dos nós do load balancer. Por exemplo, vamos supor que existam 2 nós no load balancer. Um nó tem HealthyHostCount com Minimum de 2, Maximum de 10 e Average de 6, enquanto o outro nó tem HealthyHostCount com Minimum de 1, Maximum de 5 e Average de 3. Assim, o load balancer tem Minimum de 1, Maximum de 10 e Average de cerca de 4.

A estatística Sum é o valor agregado entre todos os nós do load balancer. Como as métricas incluem vários relatórios por período, Sum só será aplicável às métricas agregadas em todos os nós do load balancer, como RequestCount, HTTPCode_ELB_XXX, HTTPCode_Backend_XXX, BackendConnectionErrors e SpilloverCount.

A estatística SampleCount é o número de amostras medidas. Como as métricas são obtidas com base em intervalos de amostragem e eventos, essa estatística normalmente não é útil. Por exemplo, com HealthyHostCount, SampleCount se baseia no número de amostras que cada nó do load balancer relata, não no número de hosts íntegros.

Um percentil indica a posição relativa de um valor no dataset. É possível especificar qualquer percentil usando até duas casas decimais (por exemplo, p95.45). Por exemplo, 95º percentil significa que 95% dos dados está abaixo desse valor e 5% está acima. Percentis geralmente são usados para isolar anomalias. Por exemplo, vamos supor que um aplicativo atende à maioria das solicitações de um cache em 1-2 ms, mas em 100-200 ms se o cache estiver vazio. O máximo reflete o caso mais lento, cerca de 200 ms. A média não indica a distribuição dos dados. Percentis fornecem uma visão mais significativa da performance do aplicativo. Ao usar o 99º percentil como acionador ou CloudWatch alarme do Auto Scaling, você pode ter como meta que não mais de 1% das solicitações demorem mais do que 2 ms para serem processadas.

Veja CloudWatch as métricas do seu balanceador de carga

Você pode visualizar as CloudWatch métricas dos seus balanceadores de carga usando o EC2 console da Amazon. Essas métricas são exibidas como gráficos de monitoramento. O monitoramento de gráficos mostrará pontos de dados se o load balancer estiver ativo e recebendo solicitações.

Como alternativa, você pode visualizar as métricas do seu balanceador de carga usando o CloudWatch console.

Para visualizar as métricas usando o console
  1. Abra o EC2 console da Amazon em https://console.aws.amazon.com/ec2/.

  2. No painel de navegação, em Load Balancing (Balanceamento de carga), escolha Load balancers (Balanceadores de carga).

  3. Escolha o nome do balanceador de carga para abrir sua página de detalhes.

  4. Escolha a guia Monitoring (Monitoramento).

  5. Para obter uma visão mais ampla de uma única métrica, passe o mouse sobre o gráfico e escolha o ícone Maximize. As seguintes métricas estão disponíveis:

    • Hosts íntegros – HealthyHostCount

    • Hosts não íntegros – UnHealthyHostCount

    • Latência média – Latency

    • Solicitações: RequestCount

    • Erros de conexão do back-end – BackendConnectionErrors

    • Comprimento da fila de sobretensão – SurgeQueueLength

    • Contagem de transmissão – SpilloverCount

    • HTTP2 XXs — HTTPCode_Backend_2XX

    • HTTP3 XXs — HTTPCode_Backend_3XX

    • HTTP4 XXs — HTTPCode_Backend_4XX

    • HTTP5 XXs — HTTPCode_Backend_5XX

    • ELBHTTP4 XXs — HTTPCode_ELB_4XX

    • ELBHTTP5 XXs — HTTPCode_ELB_5XX

    • Estimativa de bytes processados: EstimatedProcessedBytes

    • Consumo ALB estimado LCUs — EstimatedALBConsumedLCUs

    • Contagem estimada de conexões ALB ativas — EstimatedALBActiveConnectionCount

    • Contagem estimada de ALB novas conexões — EstimatedALBNewConnectionCount

Para visualizar métricas usando o CloudWatch console
  1. Abra o CloudWatch console em https://console.aws.amazon.com/cloudwatch/.

  2. No painel de navegação, selecione Métricas.

  3. Selecione o namespace ELB.

  4. Execute um destes procedimentos:

    • Selecione uma dimensão métrica para visualizar as métricas por load balancer, por Zona de disponibilidade ou em todos os load balancers.

    • Para visualizar uma métrica em todas as dimensões, digite o nome no campo de pesquisa.

    • Para visualizar uma métrica de um único load balancer, digite o nome no campo de pesquisa.

    • Para visualizar uma métrica de uma única Zona de disponibilidade, digite o nome no campo de pesquisa.