Todos os produtos
Search
Central de documentação

Server Load Balancer:Use CLB access logs to locate unhealthy backend servers

Última atualização: Jul 24, 2026

Quando um listener de Camada 7 do Classic Load Balancer (CLB) retorna erros, os logs de acesso permitem identificar qual servidor de back-end causa o problema. O CLB integra-se ao Simple Log Service (SLS) para armazenar, consultar e visualizar esses logs.

Nota

Apenas listeners HTTP e HTTPS oferecem suporte a logs de acesso. Listeners de Camada 4 não oferecem esse suporte.

Pré-requisitos

Antes de começar, verifique se você tem:

Etapa 1: Configure logs de acesso

  1. Faça login no console do CLB.

  2. Faça login no console do CLB.

  3. No painel de navegação à esquerda, escolha Logs > Access Log.

  4. Na barra de navegação superior, selecione a região onde sua instância de CLB está implantada.

  5. Se esta for a primeira vez que você usa logs de acesso, conceda as permissões necessárias. Clique em Authorize e, na página RAM Quick Authorization, clique novamente em Agree to Authorization.

    Nota

    A autorização é necessária apenas uma vez. Se você usar um usuário do Resource Access Management (RAM), o proprietário da conta deverá autorizar esse usuário separadamente. Consulte Authorize a RAM user to use the access log feature of CLB.

  6. Na página Access Log (Layer 7), localize sua instância de CLB e clique em Configure na coluna Actions.

  7. No painel Log Settings, defina os parâmetros Project e Logstore e clique em OK.

    Parâmetro

    Descrição

    Project

    Um project do SLS isola e gerencia recursos. Selecione um project existente na lista suspensa ou insira um nome para criar um novo. O nome do project deve ser exclusivo e sua região deve corresponder à da instância de CLB.

    Logstore

    Um Logstore do SLS coleta, armazena e consulta logs. Selecione um Logstore existente na lista suspensa ou insira um nome para criar um novo.

Etapa 2: Visualize dados dos logs de acesso

  1. Faça login no console do CLB.

  2. No painel de navegação à esquerda, escolha Logs > Access Log.

  3. Na barra de navegação superior, selecione a região onde sua instância de CLB está implantada.

  4. Localize sua instância de CLB e clique em View Logs na coluna Actions para abrir o console do SLS.

  5. Entradas de log são geradas sempre que um cliente acessa o CLB. Visualize esses dados no Simple Log Service.

  6. Insira uma instrução SQL para consultar os dados de log. Por exemplo, execute a seguinte instrução SQL para listar os 20 clientes mais ativos. Essa análise ajuda a identificar as origens das requisições e a tomar decisões de negócios fundamentadas.

    * | select http_user_agent, count(*) as pv group by http_user_agent order by pv desc limit 20

Etapa 3: Localizar servidores de back-end não saudáveis

Use o painel do SLS para obter um resumo visual dos tempos de resposta dos servidores de back-end.

  1. Na página do project, passe o mouse sobre o ícone image.png no painel de navegação à esquerda e clique em Dashboards.

  2. Clique no nome do painel de logs de acesso, por exemplo slb_layer7_access_center_en.

  3. Na seção top upstream_response_time, ordene a coluna avg upstream_response_time(s) em ordem decrescente.

  4. Se o tempo médio de resposta de um servidor de back-end ultrapassar 1 segundo, faça login nesse servidor para investigar a causa raiz.

Solucionar falhas de encaminhamento multicaminho

Em cenários de encaminhamento multicaminho, quando alguns servidores de back-end ficam inacessíveis, use consultas de log do SLS para filtrar requisições com falha por código de status e identificar os servidores de back-end específicos que causaram as falhas.

Nota

Os logs de acesso têm suporte apenas para listeners de Camada 7 (HTTP e HTTPS). Listeners de Camada 4 (TCP e UDP) não oferecem suporte a este recurso.

Campos de log principais

Campo

Descrição

upstream_addr

Endereço IP e porta do servidor de back-end para o qual o CLB encaminhou a requisição. Em arquiteturas de encaminhamento multicaminho, use este campo para rastrear o caminho real de roteamento de cada requisição.

status

Código de status HTTP retornado ao cliente. Valores comuns em cenários de falha de encaminhamento: 502 (Bad Gateway) e 504 (Gateway Timeout).

upstream_status

Código de status HTTP real retornado pelo servidor de back-end. Use este campo em conjunto com status para analisar a causa raiz das falhas.

upstream_response_time

Tempo (em segundos) que o servidor de back-end levou para responder. Use este valor para distinguir entre uma falha de timeout e uma falha de conexão recusada.

Procedimento

  1. Faça login no console do CLB. No painel de navegação à esquerda, escolha Logs > Access Log. Na barra de navegação superior, selecione a região onde sua instância de CLB está implantada. Localize sua instância de CLB e clique em View Logs na coluna Actions para abrir a página de consulta de logs do SLS.

  2. Insira a seguinte consulta para filtrar requisições de encaminhamento com falha:

    status:502 or status:504
  3. Nos resultados da consulta, verifique o campo upstream_addr para identificar os endereços IP dos servidores de back-end que receberam as requisições com falha. Estes representam os caminhos inacessíveis na sua configuração de encaminhamento multicaminho.

  4. Para obter uma visão agregada das falhas por servidor de back-end, execute a seguinte consulta:

    status:502 or status:504 | select upstream_addr, upstream_status, upstream_response_time, count(*) as error_count group by upstream_addr, upstream_status, upstream_response_time order by error_count desc

    Analise a coluna upstream_status para ver o código de resposta real de cada servidor de back-end e restringir a causa da falha.

  5. Para diferenciar falhas de timeout de falhas de conexão recusada, verifique o campo upstream_response_time nos resultados da consulta:

    • Se upstream_response_time estiver próximo ao limiar de timeout de upstream do listener, o servidor de back-end atingiu o timeout.

    • Se upstream_response_time estiver próximo de zero, o servidor de back-end recusou a conexão imediatamente.

Usar logs de acesso para investigar picos de tráfego

Quando sua instância de Classic Load Balancer (CLB) recebe um pico repentino de tráfego, use os logs de acesso do CLB para analisar as origens e tendências do tráfego e determinar se o aumento é esperado.

Nota

Antes de executar consultas SQL, ative o recurso de índice no Logstore de destino do Simple Log Service (SLS). Sem um índice, o console do SLS retorna um erro "Index not enabled for Logstore" ao executar uma instrução de consulta.

Procedimento

  1. Faça login no console do CLB.

  2. No painel de navegação à esquerda, escolha Logs > Access Log.

  3. Na barra de navegação superior, selecione a região onde sua instância de CLB está implantada.

  4. Localize a instância de CLB desejada e clique em View Logs na coluna Actions para abrir o painel do SLS.

  5. No painel do SLS, use o seletor de intervalo de tempo para ajustar a janela de observação. Compare o volume de tráfego atual com as linhas de base históricas para avaliar se o pico é anômalo.

  6. Clique na aba Statistical Charts para visualizar os gráficos de page view (PV) e Traffic Trend. Procure padrões como uma mudança abrupta em degrau ou um pico concentrado em uma janela de tempo curta.

  7. Para identificar origens específicas de tráfego, insira uma instrução de consulta na caixa de entrada de consulta. A seguinte instrução SQL retorna os 20 principais endereços IP de source e URIs de requisição classificados por contagem de requisições:

    * | SELECT client_ip, request_uri, count(*) AS cnt
    GROUP BY client_ip, request_uri
    ORDER BY cnt DESC
    LIMIT 20

Causas comuns de picos de tráfego e ações recomendadas

Causa

Características

Ação recomendada

Ataque CC ou DDoS

Taxa de requisições extremamente alta proveniente de poucos endereços IP de source, visando URIs específicos

Verifique os logs de acesso do WAF para confirmar a origem do ataque; configure regras de limitação de taxa

Promoção comercial ou lançamento de product

O pico de tráfego coincide com um evento promocional agendado; a distribuição geográfica corresponde ao público-alvo

Confirme com a equipe de negócios; dimensione horizontalmente os servidores de back-end se necessário

Web crawlers ou scrapers

Alto volume de requisições de múltiplos endereços IP de source com strings User-Agent semelhantes; concentrado em caminhos com muito conteúdo

Consulte o campo http_user_agent nos logs de acesso; configure regras de gerenciamento de bots do WAF se necessário

Redirecionamento upstream ou configuração incorreta

Pico repentino em um caminho específico; muitas requisições compartilham um cabeçalho Referer comum

Inspecione os campos host e request_uri para identificar e corrigir a origem do redirecionamento

Tópicos relacionados