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.
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:
Uma instância de CLB. Consulte Crie e gerencie instâncias de CLB
Um grupo vServer com servidores de back-end adicionados e aplicativos implantados. Consulte Crie e gerencie um grupo vServer
Um listener HTTP ou HTTPS na instância de CLB. Consulte Add an HTTP listener e Add an HTTPS listener
O Simple Log Service ativado. Consulte Ative o Simple Log Service
Etapa 1: Configure logs de acesso
Faça login no console do CLB.
Faça login no console do CLB.
No painel de navegação à esquerda, escolha .
Na barra de navegação superior, selecione a região onde sua instância de CLB está implantada.
-
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.
NotaA 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.
Na página Access Log (Layer 7), localize sua instância de CLB e clique em Configure na coluna Actions.
-
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
Faça login no console do CLB.
No painel de navegação à esquerda, escolha .
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 o console do SLS.
Entradas de log são geradas sempre que um cliente acessa o CLB. Visualize esses dados no Simple Log Service.
-
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.
Na página do project, passe o mouse sobre o ícone
no painel de navegação à esquerda e clique em Dashboards.Clique no nome do painel de logs de acesso, por exemplo slb_layer7_access_center_en.
Na seção top upstream_response_time, ordene a coluna avg upstream_response_time(s) em ordem decrescente.
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.
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 |
|
|
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. |
|
|
Código de status HTTP retornado ao cliente. Valores comuns em cenários de falha de encaminhamento: |
|
|
Código de status HTTP real retornado pelo servidor de back-end. Use este campo em conjunto com |
|
|
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
Faça login no console do CLB. No painel de navegação à esquerda, escolha . 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.
-
Insira a seguinte consulta para filtrar requisições de encaminhamento com falha:
status:502 or status:504 Nos resultados da consulta, verifique o campo
upstream_addrpara 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.-
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 descAnalise a coluna
upstream_statuspara ver o código de resposta real de cada servidor de back-end e restringir a causa da falha. -
Para diferenciar falhas de timeout de falhas de conexão recusada, verifique o campo
upstream_response_timenos resultados da consulta:Se
upstream_response_timeestiver próximo ao limiar de timeout de upstream do listener, o servidor de back-end atingiu o timeout.Se
upstream_response_timeestiver 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.
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
Faça login no console do CLB.
No painel de navegação à esquerda, escolha .
Na barra de navegação superior, selecione a região onde sua instância de CLB está implantada.
Localize a instância de CLB desejada e clique em View Logs na coluna Actions para abrir o painel do SLS.
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.
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.
-
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 |
|
Redirecionamento upstream ou configuração incorreta |
Pico repentino em um caminho específico; muitas requisições compartilham um cabeçalho |
Inspecione os campos |