Como configurar o balanceamento de carga HTTP(S)

O balanceamento de carga HTTP(S) do Google Cloud Platform (GCP) fornece balanceamento global de carga para solicitações HTTP(S) destinadas a suas instâncias. É possível configurar regras de URL que direcionem alguns URLs para um conjunto de instâncias e direcionem outros URLs para outras instâncias. As solicitações são sempre direcionadas para o grupo de instâncias que está mais próximo do usuário, desde que o grupo tenha capacidade suficiente e seja adequado para a solicitação. Se o grupo mais próximo não tem capacidade suficiente, a solicitação é enviada ao grupo mais próximo que tenha capacidade.

O balanceamento de carga HTTP(S) é compatível com endereços IPv4 e IPv6 para o tráfego do cliente. As solicitações IPv6 do cliente são encerradas na camada global de balanceamento de carga e, em seguida, encaminhadas por proxy sobre IPv4 para seus back-ends.

O balanceamento de carga das solicitações HTTP pode ser feito com base na porta 80 ou na porta 8080. O balanceamento de carga das solicitações HTTPS pode ser feito na porta 443.

O balanceador de carga atua como uma camada de conversão de HTTP/2 em HTTP/1.1, o que significa que os servidores da Web sempre consultam e respondem as solicitações HTTP/1.1, mas que as solicitações do navegador podem ser HTTP/1.0, HTTP/1.1 ou HTTP/2.

Antes de começar

O balanceamento de carga HTTP(S) usa grupos de instâncias para organizar as instâncias. Familiarize-se com os grupos de instâncias antes de usar o balanceamento de carga.

Exemplos de configurações

Se você preferir ir em frente e criar um balanceador de carga funcional para teste, há nos seguintes guias dois cenários diferentes com o serviço de balanceamento de carga HTTP(S). Nesses cenários, há um contexto prático para balanceamento de carga HTTP(S) e demonstrações de como é possível configurar o balanceamento de carga para suas necessidades específicas.

No restante dessa página, há mais detalhes sobre como os balanceadores de carga são construídos e como funcionam.

Criar um balanceador de carga entre regiões

Representação de balanceamento de carga entre regiões

É possível usar um endereço IP global que possa direcionar de modo inteligente os usuários com base na proximidade. Por exemplo, se você configurar instâncias na América do Norte, na Europa e na Ásia, usuários em todo o mundo serão automaticamente enviados aos back-ends mais próximos, supondo que aquelas instâncias tenham capacidade suficiente. Se as instâncias mais próximas não têm capacidade suficiente, o balanceamento de carga entre regiões encaminha automaticamente os usuários para a região mais próxima seguinte.

Primeiros passos com o balanceamento de carga entre regiões


Criar um balanceador de carga baseado em conteúdo

Representação de balanceamento de carga baseado em conteúdo

O balanceamento de carga baseado em conteúdo ou de acordo com o conteúdo usa o balanceamento de carga HTTP(S) para distribuir o tráfego a diferentes instâncias com base no URL HTTP(S) de entrada. Por exemplo, configure algumas instâncias para administrar seu conteúdo de vídeo e outras para o conteúdo restante. É possível configurar seu balanceador de carga para direcionar o tráfego para example.com/video para os servidores de vídeo e para example.com/ para os servidores padrão.

Primeiros passos com o balanceamento de carga baseado em conteúdo

Você também pode usar o balanceamento de carga HTTP(S) com intervalos do Google Cloud Storage. Depois de configurar o balanceador de carga baseado em conteúdo, é possível adicionar um intervalo do Cloud Storage a ele.


O balanceamento de carga baseado em conteúdo e o balanceamento de carga entre regiões podem funcionar juntos usando serviços de vários back-end e várias regiões. É possível criar usando os cenários acima para definir uma configuração de balanceamento de carga própria que satisfaça suas necessidades.

Princípios básicos

Visão geral

Um balanceador de carga HTTP(S) tem diversos componentes. O diagrama a seguir representa a arquitetura de um balanceador de carga HTTP(S) completo:

Diagrama de balanceamento de carga entre regiões (clique para ampliar)

Nas seções a seguir, há informações sobre como cada componente funciona em conjunto para criar cada tipo de balanceador de carga. Para uma descrição detalhada de cada componente, consulte Componentes a seguir.

Balanceamento de carga HTTP

Um balanceador de carga HTTP completo é estruturado da seguinte maneira:

  1. Uma regra de encaminhamento global direciona as solicitações de entrada para um proxy HTTP de destino.
  2. O proxy HTTP de destino verifica cada solicitação em um mapa de URLs para determinar o serviço de back-end apropriado para a solicitação.
  3. O serviço de back-end direciona cada solicitação a um back-end apropriado com base na capacidade de serviço, zona e integridade da instância de seus back-ends anexados. A integridade de cada instância de back-end é verificada com uma verificação de integridade HTTP ou uma verificação de integridade HTTPS. Se o serviço de back-end está configurado para usar a última, a solicitação é criptografada ao ser direcionada à instância de back-end.

Balanceamento de carga HTTPS

Um balanceador de carga HTTPS tem a mesma estrutura básica de um balanceador de carga HTTP (descrito acima), mas difere dos seguintes modos:

  • Usa um proxy HTTPS de destino em vez de um proxy HTTP de destino.
  • Requer pelo menos um certificado SSL assinado para o balanceador de carga.
  • A sessão do cliente SSL termina no balanceador de carga. As sessões entre o balanceador de carga e a instância podem ser HTTPS (recomendado) ou HTTP. Se forem HTTPS, é preciso que cada instância tenha um certificado.

Componentes

Regras e endereços globais de encaminhamento

As regras de encaminhamento globais direcionam o tráfego por endereço IP, porta e protocolo para uma configuração de balanceamento de carga que consiste em um proxy de destino, mapa de URL e um ou mais serviços de back-end.

Cada regra de encaminhamento global fornece um endereço IP global único que pode ser usado nos registros de DNS de seu aplicativo. Não é necessário nenhum balanceamento de carga baseado no DNS. Especifique o endereço IP a ser usado ou deixe que o Google Compute Engine atribua um para você.

Proxies de destino

Os proxies de destino terminam conexões HTTP(S) de clientes, são referenciados por uma ou mais regras de encaminhamento globais e direcionam as solicitações de entrada para um mapa de URL.

Os proxies definem cabeçalhos de solicitação/resposta HTTP da seguinte maneira:

  • Via: 1.1 google (solicitações e respostas)
  • X-Forwarded-Proto: [http | https] (somente solicitações)
  • X-Forwarded-For: <unverified IP(s)>, <immediate client IP>, <global forwarding rule external IP>, <proxies running in GCP> (somente solicitações)
    Uma lista separada por vírgulas de endereços IP anexada pelos intermediários pelos quais a solicitação passou. Se você está executando proxies no GCP que associam dados ao cabeçalho X-forward-For, seu software precisa levar em consideração a existência e o número desses proxies. Somente as entradas <immediate client IP> e <global forwarding rule external IP> são fornecidas pelo balanceador de carga. Todas as outras entradas na lista são transmitidas sem verificação. A entrada <immediate client IP> é o cliente que se conectou diretamente ao balanceador de carga. A entrada <global forwarding rule external IP> é o endereço IP externo da regra de encaminhamento do balanceador de carga. Se houver mais entradas do que isso, a primeira entrada na lista é o endereço do cliente original. Outras entrada antes de <immediate client IP> representam outros proxies que encaminharam a solicitação para o balanceador de carga.
  • X-Cloud-Trace-Context: <trace-id>/<span-id>;<trace-options> (somente solicitações)
    Parâmetros para o Stackdriver Trace.

Mapas de URL

Os mapas de URL definem os padrões de correspondência do direcionamento de solicitações baseado em URL para os serviços de back-end apropriados. Um serviço padrão é definido para lidar com qualquer solicitação que não corresponda a uma regra de host ou regra de correspondência de caminho especificada. Em algumas situações, como o exemplo de balanceamento de carga entre regiões, é possível não definir nenhuma regra de URL e depender apenas do serviço padrão. Para direcionamento de tráfego baseado em conteúdo, o mapa de URL permite dividir o tráfego examinando os componentes do URL para enviar solicitações a diferentes conjuntos de back-ends.

Certificados SSL

Os certificados SSL são usados por proxies HTTPS de destino para direcionar de modo seguro as solicitações HTTPS de entrada para serviços de back-end definidos em um mapa de URL. Um proxy HTTPS de destino pode ter até dez certificados SSL.

Serviços de back-end

Os serviços de back-end direcionam o tráfego de entrada a um ou mais back-ends anexados. Cada back-end é composto por um grupo de instâncias e metadados com capacidade adicional de serviço. A capacidade de serviço do back-end pode ser baseada em CPU ou em solicitações por segundo (RPS).

Cada serviço de back-end também especifica quais verificações de integridade serão feitas nas instâncias disponíveis.

O balanceamento de carga HTTP(S) é compatível com o Compute Engine Autoscaler, que permite aos usuários fazer escalonamentos automáticos nos grupos de instâncias em um serviço de back-end. Para mais informações, consulte Escalonamento com base na capacidade de serviço de balanceamento de carga HTTP.

É possível ativar a diminuição da conexão em serviços de back-end para garantir interrupção mínima para seus usuários quando uma instância que está servindo ao tráfego é terminada, removida manualmente ou removida por um autoescalador. Para saber mais sobre diminuição de conexão, leia a documentação Como ativar diminuição de conexão.

Intervalos de back-end

Os intervalos de back-end direcionam o tráfego recebido para os intervalos do Google Cloud Storage. Para um exemplo de como adicionar intervalos a uma configuração de balanceador de carga existente, consulte Como adicionar um intervalo do Cloud Storage a um balanceamento de carga baseado em conteúdo.

Regras de firewall

Crie uma regra de firewall para permitir que o tráfego proveniente de 130.211.0.0/22 e 35.191.0.0/16 chegue às suas instâncias. Essa regra permite tráfego tanto do balanceador de carga quanto do verificador de integridade. A regra precisa permitir o tráfego na porta em que a regra de encaminhamento global foi configurada, e é necessário que seu verificador de integridade seja configurado para usar a mesma porta. Se o verificador de integridade usar uma porta diferente, é necessário criar outra regra de firewall para essa porta.

Observe que as regras de firewall bloqueiam e permitem o tráfego em nível de instância, não nos limites da rede. Não é possível usá-las para impedir o tráfego de chegar ao próprio balanceador de carga.

Algoritmo de distribuição de carga

O balanceamento de carga HTTP(S) fornece dois métodos para determinar a carga da instância. Dentro do objeto de serviço de back-end, a propriedade balancingMode escolhe o modo de solicitações por segundo (RPS, na sigla em inglês) ou e de utilização de CPU. Ambos permitem especificar um valor máximo. O balanceador de carga HTTP tentará garantir que a carga permaneça abaixo do limite, mas podem ocorrer picos curtos acima do limite durante eventos de failover ou de picos de carga.

As solicitações recebidas são enviadas à região mais próxima do usuário, desde que essa região tenha capacidade disponível. Se mais de uma zona for configurada com back-ends em uma região, o tráfego será distribuído entre os grupos de instâncias em cada zona, de acordo com a capacidade de cada grupo. Dentro da zona, as solicitações são distribuídas de modo uniforme entre as instâncias por meio de um algoritmo round-robin. A distribuição round-robin pode ser substituída pela configuração de afinidade da sessão.

Afinidade da sessão

A afinidade da sessão envia todas as solicitações do mesmo cliente para a mesma instância de máquina virtual desde que a instância permaneça íntegra e tenha capacidade.

O balanceamento de carga HTTP(S) do GCP tem dois tipos de afinidade da sessão:

Suporte ao proxy WebSocket

O balanceador de carga HTTP(S) tem suporte nativo para o protocolo WebSocket. Os back-ends que usam o WebSocket para se comunicarem com clientes podem usar o balanceador de carga HTTP(S) como um front-end, com a finalidade de escalonamento e disponibilidade. O balanceador de carga não precisa de nenhuma configuração adicional para conexões WebSocket do proxy.

O protocolo WebSocket, definido em RFC6455, oferece um canal de comunicação full-duplex entre clientes e servidores. O canal é iniciado a partir de uma solicitação HTTP(S).

Ao reconhecer uma solicitação de upgrade do WebSocket proveniente de um cliente HTTP(S) e a quando a solicitação é acompanhada de uma resposta de upgrade bem-sucedida proveniente da instância de back-end, o balanceador de carga HTTP(S) encaminha por meio de proxy o tráfego durante o período de conexão atual. Se o back-end não retornar uma resposta de upgrade bem-sucedida, o balanceador de carga fechará a conexão.

O tempo limite padrão de uma conexão é de 30 segundos, independentemente de a conexão estar em uso ou não. Se seu serviço requer conexões com maior duração, aumente o valor de timeout (timeoutSec na API) do serviço de back-end.

Se você configurou o IP do cliente ou gerou uma afinidade de sessão por cookie para seu balanceador de carga HTTP(S), todas as conexões WebSocket de um cliente serão enviadas para a mesma instância de back-end, contanto que a instância continue a transmitir verificações de integridade e tenha capacidade.

Interfaces

Seu serviço de balanceamento de carga HTTP(S) pode ser configurado e atualizado por meio das seguintes interfaces:

  • Ferramenta de linha de comando gcloud: uma ferramenta de linha de comando incluída no Cloud SDK. A documentação de balanceamento de carga HTTP(S) chama essa ferramenta frequentemente para realizar tarefas. Para uma visão geral completa da ferramenta, consulte o Guia da ferramenta gcloud. Os comandos relativos ao balanceamento de carga podem ser encontrados no grupo de comandos gcloud compute.

    Também é possível acessar a ajuda detalhada para os comandos do gcloud usando a sinalização --help:

    gcloud compute http-health-checks create --help
    
  • Console do Google Cloud Platform: as tarefas de balanceamento de carga podem ser feitas por meio do console do Google Cloud Platform.

  • REST API: todas as tarefas de balanceamento de carga podem ser realizadas por meio da API do Google Compute Engine. Na documentação de referência da API é apresentada a descrição dos recursos e métodos disponíveis.

Suporte a TLS

Um proxy HTTPS de destino aceita somente TLS 1.0, 1.1 e 1.2 ao encerrar as solicitações SSL do cliente. Ele utiliza somente TLS 1.0, 1.1 e 1.2 ao se comunicar com o serviço de back-end quando o protocolo de back-end é HTTPS.

Tempo limite e tentativas

O balanceamento de carga HTTP(S) tem um tempo limite de resposta padrão de 30 segundos. É um tempo limite fixo e não por inatividade. Se você precisar de conexões com maior duração, como ocorre com WebSocket, aumente esse valor da maneira apropriada.

O balanceamento de carga HTTP(S) tem um tempo limite da sessão de TCP de 10 minutos (600 segundos) como padrão. O tempo limite de keepalive no serviço de destino precisa ser maior que isso para evitar o fechamento prematuro das conexões. Alguns servidores da Web, como o nginx, podem ter tempos limite padrão menores do que esse.

O balanceamento de carga HTTP(S) faz novas tentativas de solicitações GET com falha, mas não faz novas tentativas de solicitações POST com falha.

Tratamento de solicitações inválidas

O balanceador de carga HTTP(S) bloqueia as solicitações do cliente e impede que atinjam o back-end por diversas razões: algumas estritamente por compliance HTTP/1.1 e outras para evitar que dados inesperados passem para os back-ends.

O balanceador de carga bloqueia os casos seguintes por compliance HTTP/1.1:

  • Não pode analisar a primeira linha da solicitação.
  • Falta o delimitador : de um cabeçalho.
  • Cabeçalhos ou a primeira linha contêm caracteres inválidos.
  • O comprimento de conteúdo não é um número válido, ou há cabeçalhos com vários comprimentos de conteúdo.
  • Há várias chaves de codificação de transferência, ou há valores de codificação de transferência não reconhecidos.
  • Há um corpo não fragmentado e sem comprimento de conteúdo especificado.
  • Não é possível analisar os fragmentos do corpo. Este é o único caso em que alguns dados chegarão ao back-end. O balanceador de carga fechará as conexões com o cliente e o back-end quando receber um fragmento não analisável.

O balanceador de carga também bloqueia a solicitação se ocorrer qualquer um destes casos:

  • A combinação de URL e cabeçalhos da solicitação for maior do que 15 KB.
  • O método de solicitação não permite corpo, mas a solicitação tem um.
  • A solicitação contém um cabeçalho de upgrade.
  • A versão do HTTP é desconhecida.

Registros

Cada solicitação HTTP(S) é registrada temporariamente com o Stackdriver Logging. Se você foi aceito para a fase de teste Alfa, o registro é automático e não precisa ser ativado.

Como visualizar os registros

Para visualizar os registros, vá para o Visualizador de registros.

Os registros HTTP(S) são indexados primeiro pela regra de encaminhamento e, depois, pelo mapa de URL.

  • Para ver todos os registros no primeiro menu suspenso, selecione Balanceador de carga de HTTP do Cloud > Todas as forwarding_rule_name.
  • Para ver os registros de apenas uma regra de encaminhamento, selecione um único nome de regra de encaminhamento na lista.
  • Para ver os registros de apenas um mapa de URL usado por uma regra de encaminhamento, selecione Mapa de URL do GCE e escolha o mapa de URL desejado.

Campos de registro do tipo booleano geralmente só aparecem se tiverem um valor true. Se um campo booleano tem um valor de false, esse campo é omitido do registro.

A codificação UTF-8 é obrigatória para campos de registro. Os caracteres que não sejam UTF-8 são substituídos por pontos de interrogação.

O que é registrado

As entradas do registro do balanceamento de carga HTTP(S) contêm informações úteis para monitorar e depurar seu tráfego HTTP(S). As entradas do registro contêm:

  • informações gerais mostradas na maioria dos registros do GCP, como gravidade, project ID, número do projeto, timestamp e assim por diante;
  • campos de registro HttpRequest;
  • um campo statusDetails dentro do structPayload. Este campo tem uma string que explica por que o balanceador de carga retornou o status HTTP específico. As tabelas abaixo contêm mais explicações dessas strings de registro.

Mensagens de sucesso de HTTP statusDetail

statusDetails (bem-sucedida) Significado Códigos comuns de resposta associados
response_from_cache A solicitação HTTP foi atendida pelo cache. Qualquer código de resposta armazenável é possível.
response_from_cache_validated O código de retorno foi definido por um entrada de cache que foi validada por um back-end. Qualquer código de resposta armazenável é possível.
response_sent_by_backend A solicitação HTTP foi encaminhada com sucesso por um proxy para o back-end. Devolvido do back-end da VM - qualquer código de resposta é possível.

Mensagens de falha de HTTP statusDetail

statusDetails (falha) Significado Códigos comuns de resposta associados
aborted_request_due_to_backend_early_response Uma solicitação com corpo foi cancelada devido ao back-end enviar uma resposta inicial com um código de erro. A resposta foi encaminhada ao cliente. A solicitação foi encerrada. 4XX ou 5XX
backend_503_propagated_as_error O back-end enviou um 503 do qual o balanceador de carga não pôde se recuperar com novas tentativas. 503
backend_connection_closed_after_partial_response_sent A conexão do back-end fechou inesperadamente depois de uma resposta parcial ter sido enviada ao cliente. Devolvido do back-end da VM - qualquer código de resposta é possível. O valor 0 indica que o back-end não enviou cabeçalhos de resposta completos.
backend_connection_closed_before_data_sent_to_client O back-end fechou inesperadamente sua conexão com o balanceador de carga antes de a resposta ser encaminhada por proxy para o cliente. Isso pode acontecer se o balanceador de carga estiver enviando tráfego para outra entidade, como um balanceador de carga de terceiros executado em uma instância de VM, que tenha um tempo limite de TCP menor que o tempo limite de 10 minutos (600 segundos) do balanceador de carga HTTP(S). Definir manualmente o tempo limite de TCP (keepalive) no serviço de destino para mais de 600 segundos pode resolver esse problema. 502
backend_early_response_with_non_error_status O backend enviou uma resposta sem erro (1XX ou 2XX) a uma solicitação antes de receber todo o corpo da solicitação. 502
backend_response_corrupted O corpo da resposta HTTP enviada pelo back-end tem uma codificação de transferência fragmentada inválida ou corrompida de outro modo. Qualquer código de resposta é possível, dependendo da natureza da corrupção. Geralmente, 502.
backend_timeout O tempo limite do back-end foi atingido enquanto uma resposta era gerada. 502
body_not_allowed O cliente enviou uma solicitação HTTP com corpo, mas o método HTTP usado não permite um corpo. 400
cache_lookup_failed_after_partial_response O balanceador de carga falhou em fornecer uma resposta completa do cache devido a um erro interno. 2XX
client_disconnected_after_partial_response A conexão com o cliente foi interrompida depois de o balanceador de carga enviar uma resposta parcial. Devolvido do back-end da VM - qualquer código de resposta é possível.
client_disconnected_before_any_response A conexão com o cliente foi interrompida antes de o balanceador de carga enviar uma resposta. 0
client_timed_out O balanceador de carga deixou inativa a conexão com o cliente devido à falta de progresso enquanto a solicitação ou a resposta era encaminhada por proxy. 0
error_uncompressing_gzipped_body Houve um erro ao descompactar uma resposta HTTP compactada como gzip. 503
failed_to_connect_to_backend O balanceador de carga falhou ao se conectar com o back-end. 502
failed_to_pick_backend O balanceador de carga falhou ao escolher um back-end íntegro para administrar a solicitação. 502
headers_too_long Os cabeçalhos da solicitação eram maiores do que o máximo permitido. 413
http_version_not_supported Versão HTTP não compatível. Atualmente, apenas HTTP 0.9, 1.0, 1.1 e 2.0 são compatíveis. 400
http2_server_push_canceled_invalid_response_code O balanceador de carga cancelou o push do servidor HTTP/2 porque o back-end retornou um código de resposta inválido. Pode ocorrer apenas ao usar http2 para o back-end. O cliente receberá um RST_STREAM contendo INTERNAL_ERROR.
internal_error Erro interno no balanceador de carga. 400
invalid_http2_client_header_format Os cabeçalhos HTTP/2 do cliente são inválidos. 400
malformed_chunked_body O corpo da solicitação foi codificado inadequadamente em fragmentos. 411
required_body_but_no_content_length A solicitação HTTP requer um corpo, mas os cabeçalhos da solicitação não incluem um comprimento de conteúdo ou cabeçalho fragmentado de codificação de transferência. 400 ou 403
secure_url_rejected Uma solicitação com um URL https:// foi recebida em uma conexão HTTP/1.1 de texto simples. 400
unsupported_method O cliente forneceu um método de solicitação HTTP não compatível. 400
upgrade_header_rejected A solicitação HTTP do cliente continha o cabeçalho Upgrade e foi recusada. 400
uri_too_long O URI de solicitação HTTP era mais longo do que o comprimento máximo permitido. 414
websocket_closed A conexão WebSocket foi fechada.
websocket_handshake_failed O handshake do WebSocket falhou. 501

Monitoramento

O balanceamento de carga HTTP(S) exporta dados de monitoramento para Stackdriver. As métricas de monitoramento podem ser usadas para avaliar a configuração, o uso e o desempenho do balanceador de carga HTTP(S), solucionar problemas e melhorar a utilização dos recursos e a experiência do usuário.

Além dos painéis predefinidos no Stackdriver, você pode criar painéis personalizados, configurar alertas e consultar as métricas por meio da Stackdriver Monitoring API.

Como visualizar os painéis de monitoramento do Stackdriver

  1. Acesse o Stackdriver no console do Google Cloud Platform.
    Ir para o Stackdriver
  2. Selecione Recursos > Balanceadores de carga do Google Cloud.
  3. Clique no nome do seu balanceador de carga.

No painel esquerdo, você pode ver vários detalhes desse balanceador de carga HTTP(S). No painel direito, você pode ver gráficos de séries temporais. Clique no link Detalhamentos para ver os detalhamentos específicos.

Como definir alertas do Stackdriver

Você pode definir alertas do Stackdriver em várias métricas de balanceamento de carga HTTP(S):

  1. Acesse o Stackdriver no console do Google Cloud Platform.
    Ir para o Stackdriver
  2. Selecione Alertas > Criar uma política.
  3. Clique em Adicionar condição e selecione o tipo de condição.
  4. Selecione as métricas e os filtros. Para métricas, o tipo de recurso é Balanceador de carga HTTP(S) (Beta)(*).
  5. Clique em Salvar condição.
  6. Digite o nome da política e clique em Salvar política.

(*) Se você não é um usuário Alfa, use apenas a versão Beta. Os usuários Alfa são obrigados a migrar o monitoramento existente para Beta porque o uso da versão Alfa será suspenso. Um e-mail será enviado a todos os usuários Alfa, informando-os sobre os detalhes da suspensão de uso.

Como definir os painéis personalizados do Stackdriver

Você pode criar painéis personalizados do Stackdriver com as métricas de balanceamento de carga HTTP(S):

  1. Acesse o Stackdriver no console do Google Cloud Platform.
    Ir para o Stackdriver
  2. Selecione Painéis > Criar Painel.
  3. Clique em Adicionar gráfico.
  4. Dê um título ao gráfico.
  5. Selecione as métricas e os filtros. Para métricas, o tipo de recurso é Balanceador de carga HTTP(S) (Beta)(*).
  6. Clique em Salvar.

(*) Se você não é um usuário Alfa, use apenas a versão Beta. Os usuários Alfa são obrigados a migrar o monitoramento existente para Beta porque o uso da versão Alfa será suspenso. Um e-mail será enviado a todos os usuários Alfa, informando-os sobre os detalhes da suspensão de uso.

Frequência e retenção de relatórios de métricas

As métricas dos balanceadores de carga HTTP(S) são exportadas para o Stackdriver em lotes com granularidade de um minuto. Os dados de monitoramento são retidos por seis semanas. O painel fornece análise de dados em intervalos padrão de uma hora, seis horas, um dia, uma semana e seis semanas. Você pode solicitar análises manualmente em qualquer intervalo de seis semanas a um minuto.

Como monitorar métricas de balanceadores de carga HTTP(S)

As seguintes métricas de balanceadores de carga HTTP(S) são informadas no Stackdriver:

Métrica Descrição
Contagem de solicitações O número de solicitações atendidas pelo balanceador de carga HTTP(S)
Contagem de bytes da solicitação O número de bytes enviados como solicitações dos usuários para o balanceador de carga HTTP(S)
Contagem de bytes de resposta O número de bytes enviados como respostas do balanceador de carga HTTP(S) para usuários
Latências totais Uma distribuição da latência medida a partir do momento em que o primeiro byte da solicitação foi recebido pelo proxy do balanceador de carga até o proxy receber um ACK do cliente solicitante no último byte de resposta. Normalmente reduzida para o 95º percentil nas visualizações do Stackdriver.
Exemplo: um balanceador de carga tem 1 pedido por segundo do Reino Unido, todos com uma latência de 100 ms, e 9 pedidos por segundo dos EUA, todos com latência de 50 ms. Durante um determinado minuto, houve 60 pedidos do Reino Unido e 540 pedidos dos EUA. As métricas de monitoramento preservam a distribuição em todas as dimensões. Você pode solicitar o seguinte:
  • latência global mediana (300/600) - 50 ms
  • latência do Reino Unido (30/60) - 100 ms
  • latência geral do 95º percentil (570/600) - 100 ms
  • e assim por diante...
RTT do front-end(*) Uma distribuição do RTT suavizado medido para cada conexão entre cliente e proxy (medida pela pilha TCP do proxy). Normalmente reduzida para o 95º percentil nas visualizações do Stackdriver.
Latências de back-end(*) Uma distribuição da latência medida a partir de quando o primeiro byte de solicitação foi enviado pelo proxy para o back-end, até que o proxy tenha recebido do back-end o último byte da resposta. Normalmente reduzida para o 95º percentil nas visualizações do Stackdriver.
Fração de classe de código de resposta Porcentagem do total de respostas do balanceador de carga HTTP(S) que estão em cada classe de código de resposta (2XX, 4XX...). No Stackdriver, esse valor só está disponível nos painéis padrão. Não está disponível para painéis personalizados. Você pode definir alertas para ele por meio da API.

(*) A soma das latências do RTT de front-end e do back-end não tem garantida de ser menor ou igual às latências totais. Isso ocorre porque, mesmo que pesquisemos o RTT sobre o soquete a partir do proxy de cliente no momento em que a resposta HTTP é ACKed, confiamos no relatório do kernel para algumas dessas medidas e não podemos garantir que o kernel tenha uma medida RTT para a resposta HTTP específica. O resultado final é um valor RTT suavizado que também é afetado por respostas HTTP anteriores, SYN/ACKs e handshakes SSL que não estão afetando os tempos reais da solicitação HTTP.

Como filtrar dimensões das métricas do balanceador de carga HTTP(S)

As métricas são agregadas para cada balanceador de carga HTTP(S). Você pode filtrar métricas agregadas pelas seguintes dimensões(*):

Propriedade Descrição
ZONA DE BACK-END A zona do Google Cloud Platform do grupo de instâncias que atendeu à solicitação do usuário.Exemplos: us-central1-a, europe-west1-b, asia-east1-c.
CONTINENTE DO PROXY Continente do proxy HTTP(S) que encerrou a conexão HTTP(S) do usuário. Exemplos: America, Europe, Asia.
GRUPO DE INSTÂNCIAS O nome do grupo de instâncias que atendeu a solicitação do usuário.

Se nenhum grupo de instâncias estava disponível ou se a solicitação foi atendida por outra entidade, você verá um dos valores a seguir em vez de um grupo de instâncias.
  • FRONTEND_5XX: devido a um erro interno ou falta de back-ends íntegros, o proxy não pôde atribuir um grupo de instâncias para a solicitação. Em vez disso, o proxy retornou uma resposta 5xx ao solicitante.
  • SERVED_FROM_BACKEND_BUCKET: a solicitação foi processada por um intervalo de back-end, não por um grupo de instâncias.
  • SERVED_FROM_CACHE: o pedido foi processado pelo cache do proxy, portanto, não havia nenhum back-end atribuído.
SERVIÇO DE BACK-END O nome do serviço de backend que atendeu a solicitação do usuário.
REGRA DE URL CORRESPONDENTE A regra do caminho do mapa de URL que corresponde ao prefixo da solicitação HTTP(S) do usuário (até 50 caracteres).

(*) Atualmente, a métrica "Fração de classe do código de resposta" está disponível apenas no balanceador de carga completo, sem mais detalhamentos disponíveis.

Observações e restrições

  • O balanceamento de carga HTTP(S) é compatível com a resposta HTTP/1.1 100 Continue.
  • Se as instâncias de carga balanceada estão executando uma imagem de sistema operacional público, fornecida pelo Compute Engine, as regras do firewall no sistema operacional são configuradas automaticamente para permitir tráfego de carga balanceada. Se usar uma imagem personalizada, é preciso configurar manualmente o firewall do sistema operacional. Isso é feito separadamente da regra de firewall do GCP, que é preciso criar como parte da configuração de um balanceador de carga HTTP(S).
  • O balanceamento de carga não mantém instâncias em sincronização. É preciso configurar seus próprios mecanismos, como usar o Administrador de implantação, para garantir que suas instâncias tenham configurações e dados consistentes.
  • O balanceador de carga HTTP(S) não é compatível com o envio de um HTTP DELETE com um corpo para o balanceador de carga. Essas solicitações receberão uma mensagem de erro: Error 400 (Bad Request)!! Your client has issued a malformed or illegal request. Apenas solicitações DELETE sem corpo são compatíveis.

Como solucionar problemas

Tráfego com carga balanceada não tem endereço de origem do cliente original

O tráfego do balanceador de carga para suas instâncias tem um endereço IP nos intervalos de 130.211.0.0/22 e 35.191.0.0/16. Ao visualizar registros em suas instâncias de cargas balanceadas, não é possível consultar o endereço de origem do cliente original. Em vez disso, você verá os endereços de origem desse intervalo.

Erro de permissão ao tentar visualizar um objeto em meu intervalo do Cloud Storage

Para veicular objetos pelo balanceamento de carga, os objetos do Cloud Storage precisam ser publicamente acessíveis. Não se esqueça de atualizar as permissões dos objetos veiculados para que a leitura pública seja possível.

O URL não veicula o objeto do Cloud Storage esperado

O objeto do Cloud Storage a ser veiculado é determinado com base no mapa de URLs e no URL solicitado. Quando o caminho da solicitação aponta para um intervalo de back-end no mapa de URLs, esse objeto é definido pelo acréscimo do caminho completo da solicitação ao intervalo do Cloud Storage especificado no mapa.

Por exemplo, se você associa /static/* a gs://[EXAMPLE_BUCKET], a solicitação para https://<GCLB IP or Host>/static/path/to/content.jpg tenta veicular gs://[EXAMPLE_BUCKET]/static/path/to/content.jpg. Se esse objeto não existir, você receberá a seguinte mensagem de erro em vez do objeto:


NoSuchKey
The specified key does not exist.

Monitore seus recursos de onde você estiver

Instale o app do Google Cloud Console para ajudar você a gerenciar seus projetos.

Enviar comentários sobre…

Compute Engine Documentation