Registo e monitorização do balanceador de carga de aplicações externo global

Este documento mostra-lhe como configurar e usar o Cloud Logging e o Cloud Monitoring com balanceadores de carga de aplicações clássicos, balanceadores de carga de aplicações externos globais e o Cloud CDN.

Registo

Pode ativar, desativar e ver registos de um serviço de back-end do balanceador de carga de aplicações externo. Para equilibradores de carga de aplicações externos com buckets de back-end, o registo é ativado automaticamente e não pode ser desativado.

Ativa ou desativa o registo para cada serviço de back-end. Pode configurar se pretende registar todos os pedidos ou uma fração aleatória de amostras.

Tem de garantir que não tem uma exclusão de registos que se aplique a equilibradores de carga de aplicações externos. Para obter informações sobre como verificar se os registos Cloud HTTP Load Balancer são permitidos, consulte a secção Filtros de exclusão.

Amostragem e recolha de registos

Os pedidos (e as respostas correspondentes) processados pelas instâncias de máquinas virtuais (VMs) do back-end do balanceador de carga são amostrados. Estes pedidos com amostragem são, em seguida, processados para gerar registos. Controla a fração dos pedidos que são emitidos como entradas de registo de acordo com o parâmetro logConfig.sampleRate. Quando logConfig.sampleRate é 1.0 (100%), significa que os registos são gerados para todos os pedidos e escritos no Cloud Logging.

Campos opcionais

Os registos de registo contêm campos obrigatórios e campos opcionais. A secção O que é registado indica que campos são opcionais e quais são obrigatórios. Todos os campos obrigatórios estão sempre incluídos. Pode personalizar os campos opcionais que quer manter.

  • Se selecionar incluir todos os campos opcionais, todos os campos opcionais no formato de registo são incluídos nos registos. Quando são adicionados novos campos opcionais ao formato de registo, os registos incluem automaticamente os novos campos.

  • Se selecionar excluir todos os opcionais, todos os campos opcionais são omitidos.

  • Se selecionar personalizado, pode especificar os campos opcionais que quer incluir, como tls.protocol,tls.cipher,orca_load_report.cpu_utilization,orca_load_report.mem_utilization.

Para obter informações sobre a personalização de campos opcionais, consulte o artigo Ative o registo num novo serviço de back-end.

Ativar o registo num novo serviço de back-end

Consola

  1. Na Google Cloud consola, aceda à página Equilíbrio de carga.

    Aceda a Balanceamento de carga

  2. Clique no nome do balanceador de carga.

  3. Clique em Editar.

  4. Clique em Configuração de back-end.

  5. Selecione Criar um serviço de back-end.

  6. Preencha os campos de serviço de back-end obrigatórios.

  7. Na secção Registo, selecione a caixa de verificação Ativar registo.

  8. Defina uma fração da Taxa de amostragem. Pode definir um número de 0.0 a 1.0, em que 0.0 significa que não são registados pedidos e 1.0 significa que 100% dos pedidos são registados. O valor predefinido é 1.0.

  9. Opcional: para incluir todos os campos opcionais nos registos, na secção Campos opcionais, clique em Incluir todos os campos opcionais.

  10. Para terminar a edição do serviço de back-end, clique em Atualizar.

  11. Para terminar a edição do equilibrador de carga, clique em Atualizar.

gcloud: modo global

Crie um serviço de back-end e ative o registo através do comando gcloud compute backend-services create.

gcloud compute backend-services create BACKEND_SERVICE \
    --global \
    --enable-logging \
    --logging-sample-rate=VALUE \
    --load-balancing-scheme=EXTERNAL_MANAGED \
    --logging-optional=LOGGING_OPTIONAL_MODE \
    --logging-optional-fields=OPTIONAL_FIELDS

O comando gcloud compute backend-services create suporta os seguintes campos:

  • --global indica que o serviço de back-end é global. Use este campo para serviços de back-end usados com balanceadores de carga de aplicações externos globais.
  • O --enable-logging ativa o registo para esse serviço de back-end.
  • --logging-sample-rate permite-lhe especificar um valor de 0.0 a 1.0, em que 0.0 significa que não são registados pedidos e 1.0 significa que 100% dos pedidos são registados. Este campo só é significativo com o parâmetro --enable-logging. A ativação do registo, mas a definição da taxa de amostragem para 0.0, é equivalente à desativação do registo. O valor predefinido é 1.0.

  • --logging-optional permite-lhe especificar os campos opcionais que quer incluir nos registos:

    • INCLUDE_ALL_OPTIONAL para incluir todos os campos opcionais.

    • EXCLUDE_ALL_OPTIONAL (predefinição) para excluir todos os campos opcionais.

    • CUSTOM para incluir uma lista personalizada de campos opcionais que especifica em OPTIONAL_FIELDS.

  • --logging-optional-fields permite-lhe especificar uma lista separada por vírgulas de campos opcionais que quer incluir nos registos.

    Por exemplo, tls.protocol,tls.cipher só pode ser definido se LOGGING_OPTIONAL_MODE estiver definido como CUSTOM. Se usar métricas personalizadas e quiser registar elementos do relatório de carregamento ORCA, defina LOGGING_OPTIONAL_MODE como CUSTOM e especifique que elementos têm de ser registados no campo OPTIONAL_FIELDS. Por exemplo, orca_load_report.cpu_utilization,orca_load_report.mem_utilization.

Ativar o registo num serviço de back-end existente

Consola

  1. Na Google Cloud consola, aceda à página Equilíbrio de carga.

    Aceda a Balanceamento de carga

  2. Clique no nome do balanceador de carga.

  3. Clique em Editar.

  4. Clique em Configuração de back-end.

  5. Clique em Editar junto ao seu serviço de back-end.

  6. Na secção Registo, selecione a caixa de verificação Ativar registo.

  7. No campo Taxa de amostragem, defina a probabilidade de amostragem. Pode definir um número de 0.0 a 1.0, em que 0.0 significa que não são registados pedidos e 1.0 significa que 100% dos pedidos são registados. O valor predefinido é 1.0.

  8. Para terminar a edição do serviço de back-end, clique em Atualizar.

  9. Para terminar a edição do equilibrador de carga, clique em Atualizar.

gcloud: modo global

Ative o registo num serviço de back-end existente com o comando gcloud compute backend-services update.

gcloud compute backend-services update BACKEND_SERVICE \
    --global \
    --enable-logging \
    --logging-sample-rate=VALUE

onde

  • --global indica que o serviço de back-end é global. Use este campo para serviços de back-end usados com balanceadores de carga de aplicações externos globais.
  • O --enable-logging ativa o registo para esse serviço de back-end.
  • --logging-sample-rate permite-lhe especificar um valor de 0.0 a 1.0, em que 0.0 significa que não são registados pedidos e 1.0 significa que 100% dos pedidos são registados. Só é significativo com o parâmetro --enable-logging. A ativação do registo, mas a definição da taxa de amostragem para 0.0, é equivalente à desativação do registo. O valor predefinido é 1.0.

gcloud: modo clássico

Ative o registo num serviço de back-end existente com o comando gcloud compute backend-services update.

gcloud compute backend-services update BACKEND_SERVICE \
    --global \
    --enable-logging \
    --logging-sample-rate=VALUE

onde

  • --global indica que o serviço de back-end é global. Use este campo para serviços de back-end usados com um Application Load Balancer clássico.
  • O --enable-logging ativa o registo para esse serviço de back-end.
  • --logging-sample-rate permite-lhe especificar um valor de 0.0 a 1.0, em que 0.0 significa que não são registados pedidos e 1.0 significa que 100% dos pedidos são registados. Só é significativo com o parâmetro --enable-logging. A ativação do registo, mas a definição da taxa de amostragem para 0.0, é equivalente à desativação do registo. O valor predefinido é 1.0.

Desativar ou modificar o registo num serviço de back-end existente

Consola

  1. Na Google Cloud consola, aceda à página Equilíbrio de carga.

    Aceda a Balanceamento de carga

  2. Clique no nome do balanceador de carga.

  3. Clique em Editar.

  4. Clique em Configuração de back-end.

  5. Clique em Editar junto ao seu serviço de back-end.

  6. Para desativar o registo por completo, na secção Registo, desmarque a caixa de verificação Ativar registo.

  7. Se deixar o registo ativado, pode definir uma fração de taxa de amostragem diferente. Pode definir um número de 0.0 a 1.0, em que 0.0 significa que não são registados pedidos e 1.0 significa que 100% dos pedidos são registados. O valor predefinido é 1.0. Por exemplo, 0.2 significa que 20% dos pedidos de amostra geram registos.

  8. Para terminar a edição do serviço de back-end, clique em Atualizar.

  9. Para terminar a edição do equilibrador de carga, clique em Atualizar.

gcloud: modo global

Desative o registo num serviço de back-end com o comando gcloud compute backend-services update.

Desativar o registo por completo

gcloud compute backend-services update BACKEND_SERVICE \
    --global \
    --no-enable-logging

onde

  • --global indica que o serviço de back-end é global. Use este campo para serviços de back-end usados com balanceadores de carga de aplicações externos globais.
  • O --no-enable-logging desativa o registo para esse serviço de back-end.

Ativar o registo de campos opcionais num serviço de back-end existente

gcloud compute backend-services update BACKEND_SERVICE \
    --global \
    --enable-logging \
    --logging-sample-rate=VALUE \
    --logging-optional=LOGGING_OPTIONAL_MODE \
    --logging-optional-fields=OPTIONAL_FIELDS

onde

  • --logging-sample-rate permite-lhe especificar um valor de 0.0 a 1.0, em que 0.0 significa que não são registados pedidos e 1.0 significa que 100% dos pedidos são registados. Só é significativo com o parâmetro --enable-logging. A ativação do registo, mas a definição da taxa de amostragem para 0.0, é equivalente à desativação do registo. O valor predefinido é 1.0.

  • --logging-optional permite-lhe especificar os campos opcionais que quer incluir nos registos:

    • INCLUDE_ALL_OPTIONAL para incluir todos os campos opcionais.

    • EXCLUDE_ALL_OPTIONAL (predefinição) para excluir todos os campos opcionais.

    • CUSTOM para incluir uma lista personalizada de campos opcionais que especifica em OPTIONAL_FIELDS.

  • --logging-optional-fields permite-lhe especificar uma lista separada por vírgulas de campos opcionais que quer incluir nos registos.

    Por exemplo, tls.protocol,tls.cipher só pode ser definido se LOGGING_OPTIONAL_MODE estiver definido como CUSTOM. Se usar métricas personalizadas e quiser registar elementos do relatório de carregamento ORCA, defina LOGGING_OPTIONAL_MODE como CUSTOM e especifique que elementos têm de ser registados no campo OPTIONAL_FIELDS. Por exemplo, orca_load_report.cpu_utilization,orca_load_report.mem_utilization.

Atualizar o modo opcional de registo de CUSTOM para outros

gcloud compute backend-services update BACKEND_SERVICE \
    --global \
    --enable-logging \
    --logging-sample-rate=VALUE \
    --logging-optional=LOGGING_OPTIONAL_MODE \
    --logging-optional-fields=

onde

  • --logging-optional permite-lhe especificar os campos opcionais que quer incluir nos registos:

    • INCLUDE_ALL_OPTIONAL para incluir todos os campos opcionais.

    • EXCLUDE_ALL_OPTIONAL (predefinição) para excluir todos os campos opcionais.

  • Tem de configurar explicitamente o seguinte: --logging-optional-fields, conforme mostrado, para limpar os campos CUSTOM existentes. A API não permite combinar um modo não CUSTOM com campos CUSTOM.

Modificar a taxa de amostragem de registo

gcloud compute backend-services update BACKEND_SERVICE \
    --global \
    --logging-sample-rate=VALUE

gcloud: modo clássico

Desative o registo num serviço de back-end com o comando gcloud compute backend-services update.

Desativar o registo por completo

gcloud compute backend-services update BACKEND_SERVICE \
    --global \
    --no-enable-logging

onde

  • --global indica que o serviço de back-end é global. Use este campo para serviços de back-end usados com um Application Load Balancer clássico.
  • O --no-enable-logging desativa o registo para esse serviço de back-end.

Modificar a taxa de amostragem de registo

gcloud compute backend-services update BACKEND_SERVICE \
    --global \
    --logging-sample-rate=VALUE

onde

  • --global indica que o serviço de back-end é global. Use este campo para serviços de back-end usados com um Application Load Balancer clássico.
  • --logging-sample-rate permite-lhe especificar um valor de 0.0 a 1.0, em que 0.0 significa que não são registados pedidos e 1.0 significa que 100% dos pedidos são registados. Só é significativo com o parâmetro --enable-logging. A ativação do registo, mas a definição da taxa de amostragem para 0.0, é equivalente à desativação do registo.

Ver registos

Para seguir orientações passo a passo para esta tarefa diretamente na Google Cloud consola, clique em Orientar-me:

Visita guiada

Os registos HTTP(S) são indexados primeiro por uma regra de encaminhamento e, em seguida, por um mapa de URLs.

Para ver os registos, aceda à página Explorador de registos:

Aceda ao Explorador de registos

  • Para ver todos os registos, no menu de filtro Recurso, selecione Balanceador de carga HTTP do Google Cloud > Todas as regras de encaminhamento.

  • Para ver os registos de uma regra de encaminhamento, selecione o nome de uma única regra de encaminhamento.

  • Para ver os registos de um mapa de URLs, selecione uma regra de encaminhamento e, de seguida, selecione um mapa de URLs.

Os campos de registo do tipo booleano normalmente só aparecem se tiverem um valor de true. Se um campo booleano tiver um valor de false, esse campo é omitido do registo.

A codificação UTF-8 é aplicada aos campos de registo. Os carateres que não são carateres UTF-8 são substituídos por pontos de interrogação. Para balanceadores de carga de aplicações clássicos e balanceadores de carga de aplicações externos globais, pode exportar métricas baseadas em registos através de registos de recursos (resource.type="http_load_balancer"). As métricas criadas baseiam-se no recurso regra do balanceador de carga de aplicações (métricas baseadas em registos) (l7_lb_rule), que está disponível nos painéis de controlo do Cloud Monitoring em vez de no recurso https_lb_rule.

O que é registado

As entradas de registo do balanceador de carga de aplicações externo contêm informações úteis para monitorizar e depurar o seu tráfego HTTP(S). Os registos de registo contêm campos obrigatórios, que são os campos predefinidos de todos os registos de registo.

Os registos contêm campos opcionais que adicionam informações adicionais sobre o seu tráfego HTTP(S). Os campos opcionais podem ser omitidos para poupar custos de armazenamento.

Alguns campos de registo estão num formato de vários campos, com mais do que um elemento de dados num determinado campo. Por exemplo, o campo tls está no formato TlsInfo, que contém o campo earlyDataRequest. Estes campos de vários campos estão descritos na tabela de formato de registo seguinte.

Campo Formato do campo Tipo de campo: obrigatório ou opcional Descrição
severity
insertID
logName		 LogEntry Obrigatória Os campos gerais, conforme descrito numa entrada de registo.
timestamp string (formato Timestamp) Opcional A hora em que a primeira camada do GFE recebe o pedido.
httpRequest HttpRequest Obrigatória Um protocolo comum para registar pedidos HTTP.

HttpRequest.protocol não está preenchido para resource.type="http_load_balancer"

.
recurso MonitoredResource Obrigatória

O MonitoredResource é o tipo de recurso associado a uma entrada de registo.

O MonitoredResourceDescriptor descreve o esquema de um objeto MonitoredResource através da utilização de um nome de tipo e um conjunto de etiquetas. Para mais informações, consulte o artigo Etiquetas de recursos.
jsonPayload objeto (formato Struct) Obrigatória O payload da entrada do registo expresso como um objeto JSON. O objeto JSON contém os seguintes campos:
  • statusDetails
  • backendTargetProjectNumber
  • overrideResponseCode
  • errorService
  • errorBackendStatusDetails
  • authzPolicyInfo
  • loadBalancingScheme
  • tls
  • orca_load_report
de string Obrigatória O campo statusDetails contém uma string que explica o motivo pelo qual o balanceador de carga devolveu o Código de estado HTTP que devolveu. Para mais informações acerca destas strings de registo, consulte as mensagens de êxito HTTP statusDetails e as mensagens de falha HTTP statusDetails.
de string Obrigatória O campo backendTargetProjectNumber contém o número do projeto onde o destino de back-end (serviço de back-end ou contentor de back-end) foi criado. Este campo está no formato: "projects/PROJECT_NUMBER". Estas informações só estão disponíveis para equilibradores de carga de aplicações externos globais que usam respostas de erro personalizadas.
número inteiro Obrigatória O elemento overrideResponseCode contém o código de resposta de substituição aplicado à resposta enviada ao cliente. Estas informações só estão disponíveis para balanceadores de carga de aplicações externos globais que usam respostas de erro personalizadas.
de string Obrigatória O campo errorService contém o serviço de back-end que forneceu a resposta de erro personalizada. Estas informações só estão disponíveis para equilibradores de carga de aplicações externos globais que usam respostas de erro personalizadas.
de string Obrigatória O campo errorBackendStatusDetails contém o statusDetails da resposta final apresentada ao cliente. Estas informações só estão disponíveis para equilibradores de carga de aplicações externos globais que usam respostas de erro personalizadas.
AuthzPolicyInfo Obrigatória O campo authzPolicyInfo armazena informações sobre o resultado da política de autorização. Estas informações só estão disponíveis para equilibradores de carga de aplicações externos globais que tenham ativado as políticas de autorização. Para mais informações, consulte o que é registado para as políticas de autorização.
de string Opcional O campo loadBalancingScheme só é preenchido se usar a funcionalidade de migração do balanceador de carga de aplicações clássico. Este campo contém uma string que descreve o esquema de equilíbrio de carga usado para encaminhar o pedido. Os valores possíveis são EXTERNAL ou EXTERNAL_MANAGED.
TlsInfo Obrigatória

O campo tls contém o campo TlsInfo que especifica os metadados TLS para a ligação entre o cliente e o balanceador de carga. Este campo só está disponível se o cliente estiver a usar a encriptação TLS/SSL.

Use o parâmetro --logging-optional-fields para especificar os elementos que têm de ser registados:

  • Opcional: tls.protocol
  • Opcional: tls.cipher
  • Obrigatório: tls.earlyDataRequest

Não pode definir --logging-optional-fields como tls para especificar todos os elementos.
OrcaLoadReport Opcional

O campo orca_load_report contém alguns ou todos os elementos do relatório de carregamento ORCA devolvido pelo back-end. Este campo só está presente se o back-end devolver um relatório de carga da ORCA e tiver configurado o balanceador de carga para registar o relatório de carga da ORCA.

Use o parâmetro --logging-optional-fields para especificar qual dos seguintes elementos do relatório de carregamento do ORCA tem de ser registado:

  • orca_load_report.cpu_utilization
  • orca_load_report.mem_utilization
  • orca_load_report.request_cost
  • orca_load_report.utilization
  • orca_load_report.rps_fractional
  • orca_load_report.eps
  • orca_load_report.named_metrics
  • orca_load_report.application_utilization

Também pode definir --logging-optional-fields como orca_load_report para especificar que todos os elementos têm de ser registados.

Formato do campo TlsInfo

Campo Formato do campo Tipo de campo: obrigatório ou opcional Descrição
protocol de string Opcional Protocolo TLS que os clientes usam para estabelecer uma ligação com o equilibrador de carga. Os valores possíveis são TLSv1, TLSv1.1, TLSv1.2, TLSv1.3, ou QUIC. Este valor é definido como NULL se o cliente não estiver a usar a encriptação TLS/SSL.
cipher de string Opcional Cifra TLS que os clientes usam para estabelecer uma ligação com o balanceador de carga. Este valor é definido como NULL se o cliente não estiver a usar HTTP(S) ou se o cliente não estiver a usar a encriptação TLS/SSL.
earlyDataRequest booleano Obrigatória O pedido inclui dados iniciais no handshake TLS.

Etiquetas de recursos

A tabela seguinte lista as etiquetas de recursos para resource.type="http_load_balancer".

Campo Tipo Descrição
backend_service_name de string O nome do serviço de back-end.
forwarding_rule_name de string O nome do objeto da regra de encaminhamento.
project_id de string O identificador do Google Cloud projeto associado a este recurso.
target_proxy_name de string O nome do objeto proxy de destino referenciado pela regra de encaminhamento.
url_map_name de string O nome do objeto de mapa de URL configurado para selecionar um serviço de back-end.
zone de string A zona na qual o balanceador de carga está em execução. A zona é global.

statusDetails HTTP success messages

statusDetails (com êxito) Significado Códigos de resposta acompanhantes comuns
byte_range_caching O pedido HTTP foi publicado através da memorização em cache de intervalos de bytes do Cloud CDN. É possível qualquer código de resposta memorizável em cache.
response_from_cache O pedido HTTP foi publicado a partir de uma cache da RFC da nuvem. É possível qualquer código de resposta memorizável em cache.
response_from_cache_validated O código de retorno foi definido a partir de uma entrada em cache do CDN da Cloud que foi validada por um back-end. É possível qualquer código de resposta memorizável em cache.
response_sent_by_backend O pedido HTTP foi encaminhado com êxito para o back-end e a resposta foi devolvida pelo back-end. O código de resposta HTTP é definido pelo software em execução no back-end.

statusDetails HTTP failure messages

statusDetails (falha) Significado Códigos de estado comuns associados
aborted_request_due_to_backend_early_response Um pedido com corpo foi anulado porque o back-end enviou uma resposta antecipada com um código de estado. A resposta foi encaminhada para o cliente. O pedido foi terminado. 4XX ou 5XX
backend_connection_closed_after_partial_response_sent A ligação de back-end foi fechada inesperadamente depois de ter sido enviada uma resposta parcial ao cliente.

O código de estado HTTP é definido pelo software em execução no back-end. O código de estado HTTP 0 (zero) significa que o back-end enviou cabeçalhos HTTP incompletos.

O código de estado HTTP é 101 se a ligação HTTP(S) tiver sido atualizada para uma ligação websocket.
backend_connection_closed_before_data_sent_to_client O back-end fechou inesperadamente a respetiva ligação ao equilibrador de carga antes de a resposta ser enviada por proxy para o cliente.

502, 503

O código de estado HTTP é 101 se a ligação HTTP(S) tiver sido atualizada para uma ligação websocket.
backend_early_response_with_non_error_status O back-end enviou um código de estado sem erro (1XX ou 2XX) a um pedido antes de receber o corpo do pedido completo. 502, 503
backend_interim_response_not_supported O back-end enviou um código de estado 1XX provisório para o pedido num contexto em que as respostas provisórias não são suportadas.

502, 503
backend_response_corrupted O corpo da resposta HTTP enviado pelo back-end tem uma codificação de transferência fragmentada inválida ou está danificado. Qualquer código de estado possível, dependendo da natureza da corrupção. Muitas vezes 502, 503.
backend_response_headers_too_long Os cabeçalhos de resposta HTTP enviados pelo back-end excederam o limite permitido. Consulte a secção Tamanho do cabeçalho para equilibradores de carga de aplicações externos para mais informações. 502, 503
backend_timeout

O back-end excedeu o tempo limite durante a geração de uma resposta.

Para uma ligação WebSocket:

  • Para o Application Load Balancer externo global, é gerado um código de estado quando o GFE fecha a ligação websocket no estado inativo após o limite de tempo do serviço de back-end expirar.
  • Para o Application Load Balancer clássico, é gerado um código de estado quando o GFE fecha a ligação websocket no estado inativo ou ativo, após o limite de tempo do serviço de back-end expirar.

502, 503

O código de estado HTTP é 101 se a ligação HTTP(S) tiver sido atualizada para uma ligação websocket.
banned_by_security_policy A solicitação foi proibida por uma regra de proibição baseada na taxa do Cloud Armor. 429
body_not_allowed O cliente enviou um pedido HTTP com um corpo, mas o método HTTP usado não permite um corpo. 400
byte_range_caching_aborted O equilibrador de carga recebeu anteriormente uma resposta a indicar que o recurso era armazenável em cache e suportava intervalos de bytes. O Cloud CDN recebeu uma resposta inconsistente (por exemplo, uma com um código de estado diferente do esperado 206 Partial Content). Isto aconteceu quando tentou preencher a cache através de um pedido de intervalo de bytes. Como resultado, o equilibrador de carga anulou a resposta ao cliente. 2XX
byte_range_caching_forwarded_backend_response O equilibrador de carga recebeu anteriormente uma resposta a indicar que o recurso era armazenável em cache e suportava intervalos de bytes. O Cloud CDN recebeu uma resposta inconsistente (por exemplo, uma com um código de estado diferente do esperado 206 Partial Content). Isto aconteceu quando tentou preencher a cache através de um pedido de intervalo de bytes. Em seguida, o balanceador de carga encaminhou a resposta inconsistente para o cliente.

Devolvido a partir do back-end: é possível qualquer código de estado.
byte_range_caching_retrieval_abandoned O cliente cancelou um pedido de intervalo de bytes ou um pedido de validação iniciado pelo Cloud CDN.

Devolvido a partir do back-end: é possível qualquer código de estado.
byte_range_caching_retrieval_from_backend_failed_after_partial_response Um pedido de intervalo de bytes ou um pedido de validação iniciado pela RFC de multimédia na nuvem encontrou um erro. Consulte a entrada de registo do Cloud Logging correspondente ao pedido iniciado pelo Cloud CDN para ver o estado detalhado do back-end. 2XX
cache_lookup_failed_after_partial_response O balanceador de carga não conseguiu fornecer uma resposta completa a partir da cache do Cloud CDN devido a um erro interno. 2XX
cache_lookup_timeout_after_partial_response O fluxo de pesquisa da cache da RFC de multimédia na nuvem excedeu o limite de tempo porque o cliente não obteve o conteúdo atempadamente. 2XX
client_disconnected_after_partial_response A ligação ao cliente foi interrompida depois de o equilibrador de carga ter enviado uma resposta parcial.

Devolvido a partir do back-end: é possível qualquer código de estado.

O código de estado HTTP é 101 se a ligação HTTP(S) tiver sido atualizada para uma ligação websocket.
client_disconnected_before_any_response A ligação ao cliente foi interrompida antes de o balanceador de carga enviar qualquer resposta.

0

O código de estado HTTP é 101 se a ligação HTTP(S) tiver sido atualizada para uma ligação websocket.
client_timed_out O front-end da Google (GFE) deixou a ligação do cliente inativa devido à falta de progresso enquanto encaminhava o pedido ou a resposta. 0 ou 408
client_cert_invalid_rsa_key_size Um certificado de folha ou intermédio de cliente tinha um tamanho da chave RSA inválido. Para mais informações, consulte o artigo Erros registados para ligações fechadas. 0
client_cert_unsupported_elliptic_curve_key Um certificado intermédio ou de cliente está a usar uma curva elíptica não suportada. Para mais informações, consulte o artigo Erros registados para ligações fechadas. 0
client_cert_unsupported_key_algorithm Um certificado de cliente ou intermédio está a usar um algoritmo que não seja RSA ou ECDSA. Para mais informações, consulte o artigo Erros registados para ligações fechadas. 0
client_cert_pki_too_large A PKI a usar para validação tem mais de dez certificados intermédios que partilham o mesmo assunto e informações da chave pública do assunto. Para mais informações, consulte Erros registados para ligações fechadas. 0
client_cert_chain_max_name_constraints_exceeded Um certificado intermédio fornecido para validação tinha mais de dez restrições de nomes. Para mais informações, consulte o artigo Erros registados para ligações fechadas. 0
client_cert_chain_invalid_eku O certificado de cliente ou o respetivo emissor não tem a utilização de chave alargada (EKU) que inclui clientAuth. Para mais informações, consulte o artigo Erros registados para ligações fechadas. 0
client_cert_validation_timed_out O limite de tempo foi excedido durante a validação da cadeia de certificados. Para mais informações, consulte o artigo Erros registados para ligações fechadas. 0
client_cert_validation_search_limit_exceeded O limite de profundidade ou iteração foi atingido ao tentar validar a cadeia de certificados. Para mais informações, consulte o artigo Erros registados para ligações fechadas. 0
client_cert_validation_not_performed Configurou o mTLS sem configurar um TrustConfig. Para mais informações, consulte o artigo Erros registados para ligações fechadas. 0
client_cert_not_provided O cliente não forneceu o certificado pedido durante a negociação. Para mais informações, consulte o artigo Erros registados para ligações fechadas. 0
client_cert_validation_failed O certificado de cliente falha a validação com o TrustConfig quando são usados algoritmos de hash, como MD4, MD5 e SHA-1. Para mais informações, consulte o artigo Erros registados para ligações fechadas. 0
config_not_found

O balanceador de carga não tem a configuração do projeto. Isto pode ocorrer intermitentemente depois de fazer alterações à configuração que adicionam um novo recurso.

Outra causa do erro é o facto de o GFE de primeira camada não conseguir comunicar com o GFE de segunda camada. Isto pode dever-se a um erro interno, como uma implementação em curso, uma sobrecarga do equilibrador de carga ou problemas de configuração intermitentes.

Estes erros são de natureza transitória e espera-se que se enquadrem bem no SLA. No entanto, se a taxa de erros exceder 0,01%, contacte o Google Cloud apoio técnico para receber assistência adicional.

 404, 502, 503
direct_response O balanceador de carga substituiu este pedido e devolveu uma resposta fixa. Pode ver qualquer código de estado HTTP, consoante a natureza do problema. Por exemplo, o código de estado HTTP 410 significa que o back-end está indisponível devido a incumprimento de pagamento.
denied_by_security_policy O balanceador de carga recusou este pedido devido a uma política de segurança do Google Cloud Armor. Configurado na política de segurança.
error_uncompressing_gzipped_body Ocorreu um erro ao descomprimir uma resposta HTTP com gzip. 502, 503
failed_to_connect_to_backend O equilibrador de carga não conseguiu estabelecer ligação ao back-end. Isto inclui tempos limite durante a fase de ligação. 502, 503
failed_to_pick_backend O equilibrador de carga não conseguiu selecionar um back-end em bom estado para processar o pedido. 502, 503
failed_to_negotiate_alpn O equilibrador de carga e o back-end não conseguiram negociar um protocolo de camada de aplicação (como HTTP/2) para usar na comunicação entre si através de TLS. 502, 503
headers_too_long Os cabeçalhos do pedido eram superiores ao máximo permitido. 413
http_version_not_supported A versão HTTP não é suportada. Apenas são suportados os protocolos HTTP 0.9, 1.0, 1.1 e 2.0. 400
internal_error Erro interno no balanceador de carga. Normalmente, representa um erro transitório na infraestrutura do balanceador de carga. Repita a consulta. 4XX ou 5XX
invalid_chunk_framing Os pedidos e as respostas enviados com o cabeçalho Transfer-Encoding: Chunked não estão em conformidade com a RFC 9112. De acordo com a RFC, os campos chunked_body e last-chunk têm de terminar em CRLF. 400
invalid_external_origin_endpoint A configuração do back-end externo é inválida. Reveja a configuração do NEG da Internet e certifique-se de que especifica um FQDN/endereço IP e uma porta válidos. 4XX
invalid_request_headers

Os cabeçalhos de pedidos HTTP recebidos de um cliente contêm, pelo menos, um caráter que não é permitido ao abrigo de uma especificação HTTP aplicável.

Por exemplo, os nomes dos campos de cabeçalho que incluem aspas duplas (") ou quaisquer carateres fora do intervalo ASCII padrão (ou seja, qualquer byte >= 0x80) são inválidos.

Para mais informações, consulte:

 400
invalid_http2_client_header_format Os cabeçalhos HTTP/2 de um cliente são inválidos. Para mais informações, consulte invalid_request_headers. 400
invalid_http2_client_request_path

O caminho do pedido HTTP/2 de um cliente contém, pelo menos, um caráter que não é permitido na especificação do URI.

Para mais informações, consulte o "3.3. Secção "Caminho" do RFC 3986.

 400
multiple_iap_policies Não é possível combinar várias políticas do Identity-Aware Proxy (IAP). Se tiver uma política de IAP anexada a um serviço de back-end e outra política anexada a um objeto sem servidor, remova uma das políticas e tente novamente. Os objetos sem servidor incluem o App Engine, o Cloud Run e as funções do Cloud Run. 500
malformed_chunked_body O corpo do pedido foi codificado em blocos de forma incorreta. 411
request_loop_detected O balanceador de carga detetou um ciclo de pedidos. Este ciclo pode ser causado por uma configuração incorreta em que o back-end reencaminhou o pedido de volta para o balanceador de carga. 502, 503
required_body_but_no_content_length O pedido HTTP requer um corpo, mas os cabeçalhos do pedido não incluem um cabeçalho de comprimento do conteúdo ou de transferência codificada em partes. 400, 403, 411
secure_url_rejected Foi recebido um pedido com um URL https:// através de uma ligação HTTP/1.1 de texto simples. 400
server_cert_chain_exceeded_limit A cadeia de certificados do servidor é demasiado longa (mais de 10 certificados intermédios incluídos no certificado do servidor). 502, 503

server_cert_chain_invalid_eku

 O certificado do servidor tem um campo de extensão Extended Key Usage (EKU), mas esse campo não inclui serverAuth.

server_cert_chain_max_name_constraints_exceeded

 Um certificado intermédio fornecido para validação tinha mais de 10 restrições de nomes. 502, 503
server_cert_exceeded_size_limit A carga útil do certificado do servidor (incluindo todos os certificados intermédios) é demasiado grande (mais de 16 KB). 503
server_cert_invalid_rsa_key_size

Um servidor ou um certificado intermédio tem um tamanho da chave RSA inválido.

Não é feita nenhuma validação.

As chaves RSA podem variar entre 2048 e 4096 bits.

 503
server_cert_not_provided O servidor não forneceu o certificado pedido durante a negociação. 503
server_cert_pki_too_large

A PKI a usar para validação tem mais de dez certificados intermédios que partilham o mesmo assunto e informações da chave pública do assunto.

Não é feita nenhuma validação.

 503
server_cert_trust_config_not_found Não foi encontrado nenhum TrustConfig correspondente. 503
server_cert_unsupported_elliptic_curve_key

Um servidor ou um certificado intermédio está a usar uma curva elíptica não suportada.

Não é feita nenhuma validação.

As curvas válidas são P-256 e P-384.

 503
server_cert_unsupported_key_algorithm

Um servidor ou um certificado intermédio está a usar um algoritmo não RSA ou não ECDSA.

Não é feita nenhuma validação.

 503
server_cert_validation_internal_error Erro interno ao validar a cadeia de certificados. 503
server_cert_validation_not_performed

Configurou o mTLS sem configurar um recurso TrustConfig.

 503
server_cert_validation_search_limit_exceeded

O limite de profundidade ou iteração foi atingido ao tentar validar a cadeia de certificados.

A profundidade máxima de uma cadeia de certificados é de dez, incluindo os certificados de raiz e de servidor. O número máximo de iterações é 100 (certificados examinados para validar a cadeia de certificados do servidor).

 503
server_cert_validation_timed_out O limite de tempo foi excedido ao tentar validar a cadeia de certificados. 503
server_cert_validation_unavailable O serviço não consegue realizar a validação da cadeia de certificados. 503
ssl_certificate_san_verification_failed O equilibrador de carga não consegue encontrar um nome alternativo de entidade (SAN) no certificado SSL apresentado pelo back-end que corresponda ao nome de anfitrião configurado. 502, 503
ssl_certificate_chain_verification_failed O certificado SSL apresentado pelo back-end falhou na validação do certificado SSL. 502, 503
throttled_by_security_policy O pedido foi bloqueado por uma regra de limitação do Cloud Armor. 429
unsupported_method O cliente forneceu um método de pedido HTTP não suportado. 400
unsupported_100_continue O pedido do cliente incluiu o cabeçalho "Expect: 100-continue" num protocolo que não o suporta. 400
upgrade_header_rejected O pedido HTTP do cliente continha o cabeçalho Upgrade e foi recusado. 400
websocket_closed A ligação WebSocket foi fechada. 101
websocket_handshake_failed O handshake do WebSocket falhou. Qualquer código de estado possível, dependendo da natureza da falha de sincronização.
request_body_too_large O corpo do pedido HTTP excedeu o máximo suportado pelo back-end. Não aplicável a back-ends de VMs. 413
handled_by_identity_aware_proxy Esta resposta foi gerada pelo Identity-Aware Proxy durante a validação de identidade do cliente antes de permitir o acesso.

200, 302, 400, 401, 403, 500, 502, 503

429 (limitado pela CAsI)
serverless_neg_routing_failed Não é possível enviar o pedido de NEG sem servidor. Este erro pode ocorrer quando não é possível aceder à região especificada no NEG ou quando não é possível encontrar o nome do recurso (por exemplo, o nome das funções do Cloud Run). 404, 502, 503
fault_filter_abort Este erro pode ocorrer se o cliente tiver configurado um filtro de falhas e o filtro de falhas tiver sido acionado para o pedido em questão. O valor tem de estar entre 200 e 599.
early_data_rejected

O pedido enviado nos dados iniciais do TLS era inválido.

Isto pode ocorrer nos seguintes casos, entre outros:

  • O TargetHttpsProxy tem os dados antecipados do TLS definidos como STRICT, mas o pedido incluiu parâmetros de consulta.
  • O TargetHttpsProxy tem dados antecipados do TLS definidos como STRICT ou PERMISSIVE, mas o pedido usou um método HTTP não idempotente (como POST ou PUT).
 425

Veja os registos da validação de certificados de cliente mTLS

Para ver os erros registados para ligações fechadas durante a validação do certificado do cliente TLS mútuo, conclua os seguintes passos.

Consulta da consola

  1. Na Google Cloud consola, aceda à página Explorador de registos.

    Aceda ao Explorador de registos

  2. Clique no botão Mostrar consulta.

  3. Cole o seguinte no campo de consulta. Substitua FORWARDING_RULE_NAME pelo nome da sua regra de encaminhamento.

    jsonPayload.statusDetails=~"client_cert"
jsonPayload.@type="type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry"
resource.labels.forwarding_rule_name=FORWARDING_RULE_NAME

  4. Clique em Executar consulta.

Registos de pedidos da política de autorização

O objeto authz_info no payload JSON da entrada do registo do equilibrador de carga contém informações sobre as políticas de autorização. Pode configurar métricas baseadas em registos para o tráfego permitido ou recusado por estas políticas. Consulte mais detalhes do registo das políticas de autorização.

Campo Tipo Descrição
authz_info.policies[] objeto A lista de políticas que correspondem ao pedido.
authz_info.policies[].name de string O nome da política de autorização que corresponde ao pedido.

O nome está vazio pelos seguintes motivos:

  • Nenhuma política ALLOW corresponde ao pedido e o pedido é recusado.
  • Nenhuma política DENY corresponde ao pedido e o pedido é permitido.
authz_info.policies[].result enum O resultado pode ser ALLOWED ou DENIED.
authz_info.policies[].details de string Os detalhes incluem o seguinte:
  • allowed_as_no_deny_policies_matched_request
  • denied_as_no_allow_policies_matched_request
  • denied_by_authz_extension
  • denied_by_cloud_iap
authz_info.overall_result enum O resultado pode ser ALLOWED ou DENIED.

Registo para contentores de back-end

O registo está ativado automaticamente para balanceadores de carga com contentores de back-end. Não pode modificar nem desativar o registo para contentores de back-end.

Registo para o Cloud Armor

A tabela de mensagens de falha de HTTP statusDetail contém algumas mensagens que se aplicam ao Cloud Armor. Para mais informações sobre o que o Cloud Armor regista, consulte o artigo Usar o registo de pedidos.

Registo para implementações de VPC partilhada

Normalmente, os registos e as métricas do Application Load Balancer são exportados para o projeto que tem a regra de encaminhamento. Por conseguinte, os administradores de serviços, ou seja, os proprietários ou os utilizadores de projetos onde o serviço de back-end é criado, não têm acesso aos registos e às métricas do equilibrador de carga por predefinição. Pode usar funções do IAM para conceder estas autorizações aos administradores de serviços. Para saber mais sobre as funções do IAM disponíveis e os passos para conceder acesso, consulte o artigo Conceda acesso ao Monitoring.

Interagir com os registos

Pode interagir com os registos do Application Load Balancer externo através da API Cloud Logging. A API Logging oferece formas de filtrar interativamente registos que têm campos específicos definidos. Exporta os registos correspondentes para o Cloud Logging, o Cloud Storage, o BigQuery ou o Pub/Sub. Para mais informações acerca da API Logging, consulte a vista geral da API Logging.

Monitorização

O balanceador de carga exporta dados de monitorização para o Monitoring.

Pode usar as métricas de monitorização para:

  • Avalie a configuração, a utilização e o desempenho de um balanceador de carga
  • Resolva problemas
  • Melhore a utilização de recursos e a experiência do utilizador

Além dos painéis de controlo predefinidos no Monitoring, pode criar painéis de controlo personalizados, configurar alertas e consultar as métricas através da API Cloud Monitoring.

Visualizar painéis de controlo do Cloud Monitoring predefinidos

O Cloud Monitoring oferece painéis de controlo predefinidos para monitorizar os seus balanceadores de carga. Estes painéis de controlo são preenchidos automaticamente pelo Monitoring.

Os equilibradores de carga não aparecem como um recurso que pode ser monitorizado, a menos que exista um equilibrador de carga no projeto atual.

Siga os passos abaixo para aceder aos painéis de controlo predefinidos:

  1. Na Google Cloud consola, aceda à página Monitorização.

    Aceder a Monitorização

  2. No painel de navegação Monitorização, clique em Painéis de controlo.

  3. Em Categorias, clique em GCP.

    • Para ver uma lista de painéis de controlo de todos os seus Google Cloud balanceadores de carga, selecione o painel de controlo denominado Google Cloud Load Balancers. Para ver o painel de controlo de um equilibrador de carga específico, localize o equilibrador de carga na lista e clique no respetivo nome.

    • Para ver os painéis de controlo predefinidos apenas para os seus balanceadores de carga de aplicações externos, selecione o painel de controlo denominado Balanceadores de carga HTTP(S) externos. Esta página apresenta um painel de controlo que mostra as proporções de respostas 5XX e a latência de back-end para todos os equilibradores de carga de aplicações externos no seu projeto. Também fornece uma lista de painéis de controlo para todos os equilibradores de carga de aplicações externos no seu projeto.

      Pode clicar para aceder ao painel de controlo de cada equilibrador de carga. Cada painel de controlo inclui o seguinte:

      • Gráficos pré-preenchidos que apresentam discriminações das respostas por classes de códigos de estado (5XX, 4XX, 3XX, 2XX)
      • Latência total
      • Latência de back-end
      • RTT do front-end
      • Contagem de pedidos
      • Um link para os registos do balanceador de carga

  4. Para ver painéis de controlo de serviços de terceiros, regresse à página Painéis de controlo. Em Categorias, clique em Outro.

    • Para ver um painel de controlo de um serviço de terceiros específico, localize-o na lista e clique no respetivo nome.

Definir políticas de alerta

Para seguir orientações passo a passo para esta tarefa diretamente na Google Cloud consola, clique em Orientar-me:

Visita guiada

Pode criar políticas de alerta para monitorizar os valores das métricas e receber uma notificação quando essas métricas violarem uma condição.

  1. Na Google Cloud consola, aceda à página  Alertas:

    Aceder a Alertas

    Se usar a barra de pesquisa para encontrar esta página, selecione o resultado cujo subtítulo é Monitorização.

  2. Se não tiver criado os canais de notificação e quiser receber notificações, clique em Editar canais de notificação e adicione os seus canais de notificação. Regresse à página Alertas depois de adicionar os seus canais.
  3. Na página Alertas, selecione Criar política.
  4. Para selecionar a métrica, expanda o menu Selecione uma métrica e, em seguida, faça o seguinte:
    1. Para limitar o menu a entradas relevantes, introduza Global External Application Load Balancer Rule na barra de filtros. Se não houver resultados depois de filtrar o menu, desative o botão Mostrar apenas recursos e métricas ativos.
    2. Para o Tipo de recurso, selecione Regra do balanceador de carga de aplicações externo global.
    3. Selecione uma Categoria de métrica e uma Métrica e, de seguida, selecione Aplicar.
  5. Clicar em Seguinte.
  6. As definições na página Configurar acionador de alerta determinam quando o alerta é acionado. Selecione um tipo de condição e, se necessário, especifique um limite. Para mais informações, consulte Crie políticas de alertas de limite métrico.
  7. Clicar em Seguinte.
  8. Opcional: para adicionar notificações à sua política de alertas, clique em Canais de notificação. Na caixa de diálogo, selecione um ou mais canais de notificação no menu e, de seguida, clique em OK.
  9. Opcional: atualize a Duração do encerramento automático do incidente. Este campo determina quando o Monitoring fecha incidentes na ausência de dados de métricas.
  10. Opcional: clique em Documentação e, de seguida, adicione as informações que quer incluir numa mensagem de notificação.
  11. Clique em Nome do alerta e introduza um nome para a política de alertas.
  12. Clique em Criar política.
Para mais informações, consulte o artigo Vista geral dos alertas.

Definir painéis de controlo personalizados do Cloud Monitoring

Pode criar painéis de controlo personalizados do Cloud Monitoring para as métricas do balanceador de carga:

  1. Na Google Cloud consola, aceda à página Monitorização.

    Aceder a Monitorização

  2. Selecione Painéis de controlo > Criar painel de controlo.

  3. Clique em Adicionar gráfico e, de seguida, atribua um título ao gráfico.

  4. Para identificar a série cronológica a apresentar, escolha um tipo de recurso e um tipo de métrica:

    1. Na secção Recurso e métrica, clique no gráfico e, de seguida, na secção Selecionar uma métrica, selecione uma das opções disponíveis:
      • Para um Application Load Balancer externo global, selecione o tipo de recurso Regra do Application Load Balancer externo global.
    2. Clique em Aplicar.

  5. Para especificar filtros de monitorização, clique em Filtros > Adicionar filtro.

  6. Clique em Guardar.

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

As métricas dos equilibradores de carga de aplicações externos são exportadas para o Cloud Monitoring em lotes de granularidade de 1 minuto. Os dados de monitorização são retidos durante seis (6) semanas.

O painel de controlo apresenta a análise de dados em intervalos predefinidos de 1H (uma hora), 6H (seis horas), 1D (um dia), 1W (uma semana) e 6W (seis semanas). Pode pedir manualmente a análise em qualquer intervalo de 6 semanas a 1 minuto.

Métricas de monitorização

Pode monitorizar as seguintes métricas para equilibradores de carga de aplicações externos.

As seguintes métricas para balanceadores de carga de aplicações externos globais são comunicadas no Cloud Monitoring. Estas métricas têm o prefixo loadbalancing.googleapis.com/.

Métrica Nome Descrição
Contagem de pedidos https/request_count O número de pedidos publicados pelo balanceador de carga de aplicações externo
Contagem de bytes de pedidos https/request_bytes_count O número de bytes enviados como pedidos de clientes para o Application Load Balancer externo
Contagem de bytes de resposta https/response_bytes_count O número de bytes enviados como respostas do Application Load Balancer externo para os clientes
Latências totais https/total_latencies

Uma distribuição da latência total. A latência total é o tempo em milissegundos entre o primeiro byte do pedido recebido pelo proxy e o último byte da resposta enviada pelo proxy. Inclui: o tempo que o proxy demora a processar o pedido, o tempo que o pedido demora a ser enviado do proxy para o back-end, o tempo que o back-end demora a processar o pedido, o tempo que a resposta demora a ser enviada de volta para o proxy e o tempo que o proxy demora a processar a resposta e a enviá-la para o cliente.

Não inclui o tempo de resposta entre o cliente e o proxy. Além disso, as pausas entre pedidos na mesma ligação que usam Connection: keep-alive não afetam a medição. Normalmente, esta medição é reduzida ao percentil 95 nas vistas do Cloud Monitoring.

Para ligações WebSocket, este campo refere-se à duração total da ligação.*

Exemplo: um equilibrador 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 uma latência de 50 ms. Durante um determinado minuto, houve 60 pedidos do Reino Unido e 540 pedidos dos EUA. A monitorização das métricas preserva a distribuição em todas as dimensões. Pode pedir informações como as seguintes:

  • Latência geral mediana (300/600) – 50 ms
  • Latência mediana no Reino Unido (30/60) – 100 ms
  • Percentil 95 da latência geral (570/600) – 100 ms
RTT de front-end† https/frontend_tcp_rtt

Uma distribuição do RTT de front-end. O RTT de frontend é o tempo em milissegundos que os dados demoram a viajar do cliente para o proxy e vice-versa. Inclui o tempo necessário para um pedido viajar do cliente para o proxy e do proxy para o cliente. Este valor não é atualizado durante a duração da ligação. Por exemplo, a configuração de uma ligação (TCP) com um handshake de 3 vias demoraria 1,5 RTTs.

Quando os pedidos são processados, o balanceador de carga faz a amostragem e a média do tempo que os dados demoram a viajar entre o cliente e o proxy, e, em seguida, regista um valor de RTT suavizado. O RTT suavizado é um algoritmo que lida com variações e anomalias que podem ocorrer nas medições de RTT.
Latências de back-end† https/backend_latencies

Uma distribuição da latência do back-end. A latência do back-end é o tempo, em milissegundos, entre o último byte do pedido enviado para o back-end e o último byte da resposta recebida pelo proxy. Inclui o tempo que o back-end demora a processar o pedido e o tempo que a resposta demora a ser enviada de volta para o proxy.
Fração da classe do código de resposta Fração do total de respostas do balanceador de carga de aplicações externo que se encontram em cada classe de código de resposta (2XX, 4XX, ...). No Monitoring, este valor só está disponível em painéis de controlo predefinidos. Não está disponível para painéis de controlo personalizados. Pode usar a API Monitoring para definir alertas para a mesma.
Contagem de pedidos de back-end https/backend_request_count O número de pedidos enviados do balanceador de carga da aplicação externo para os servidores de back-end.
Contagem de bytes de pedidos de back-end https/backend_request_bytes_count O número de bytes enviados como pedidos do equilibrador de carga da aplicação externo para os servidores de back-end.
Número de bytes de resposta do back-end https/backend_response_bytes_count O número de bytes enviados como respostas dos back-ends (incluindo a cache) para o Application Load Balancer externo.

* Para monitorizar ligações de websocket, crie um serviço de back-end especificamente para websockets.

† A soma do RTT da interface e das latências de back-end pode não ser inferior ou igual às latências totais. Isto deve-se ao facto de, embora sondemos o RTT através do socket do GFE para o cliente no momento em que a resposta HTTP é reconhecida, dependermos dos relatórios do kernel para algumas destas medições e não podermos ter a certeza de que o kernel tem uma medição do RTT para a resposta HTTP fornecida. O resultado final é um valor de RTT suavizado que também é afetado por respostas HTTP anteriores, SYN/ACKs e negociações de SSL que não estão a afetar os tempos reais do pedido HTTP atual.

Filtrar dimensões para métricas

Pode aplicar filtros para métricas de equilibradores de carga de aplicações externos.

As métricas são agregadas para cada balanceador de carga de aplicações clássico e balanceador de carga de aplicações externo global. Pode filtrar métricas agregadas pelas seguintes dimensões para resource.type="http_load_balancer" ou resource.type="https_lb_rule". Tenha em atenção que nem todas as dimensões estão disponíveis em todas as métricas.

Propriedade Descrição
backend_scope O Google Cloud âmbito (região ou zona) do grupo de instâncias do serviço de back-end que publicou a ligação.

Se não estiver disponível nenhum grupo de instâncias ou se o pedido tiver sido publicado por outra entidade, vê um dos seguintes valores em vez da região ou da zona do grupo de instâncias do serviço de back-end.

  • FRONTEND_5XX: ocorreu um erro interno antes de o GFE poder selecionar um back-end. O GFE devolveu 5XX ao cliente.
  • INVALID_BACKEND: o GFE não conseguiu encontrar um back-end saudável para atribuir o pedido, pelo que devolveu uma resposta 5XX ao requerente.
  • NO_BACKEND_SELECTED: ocorreu um erro ou uma interrupção antes de ser selecionado um back-end, ocorreu um redirecionamento de URL ou um Application Load Balancer clássico com back-ends sem servidor devolveu uma resposta 200 OK.
  • MULTIPLE_BACKENDS: o pedido foi publicado por potencialmente vários back-ends. Isto pode acontecer quando o Cloud CDN tiver publicado o pedido parcialmente a partir da respetiva cache e também tiver enviado um ou mais pedidos de intervalo de bytes para o back-end. Use a discriminação backend_scope para visualizar cada pedido do equilibrador de carga para o back-end.

Quando esta discriminação é escolhida, os gráficos mostram métricas de back-end (load balancer-to-backends) e não métricas de front-end (client-to-load balancer).
backend_type

O nome do grupo de back-end que publicou o pedido do cliente. Pode ser INSTANCE GROUP, NETWORK_ENDPOINT_GROUP ou UNKNOWN é devolvido se o back-end não tiver sido atribuído. Se não estiver disponível nenhum grupo de back-end ou se o pedido tiver sido publicado por outra entidade, é apresentado um dos seguintes valores em vez de um grupo de back-end.

  • FRONTEND_5XX: ocorreu um erro interno antes de o GFE poder selecionar um back-end. O GFE devolveu 5XX ao cliente.
  • INVALID_BACKEND: o GFE não conseguiu encontrar um back-end saudável para atribuir o pedido, pelo que devolveu uma resposta 5XX ao requerente.
  • NO_BACKEND_SELECTED: ocorreu um erro ou uma interrupção antes de ser selecionado um back-end, ocorreu um redirecionamento de URL ou um Application Load Balancer clássico com back-ends sem servidor devolveu uma resposta 200 OK.
  • MULTIPLE_BACKENDS: o pedido foi publicado por potencialmente vários back-ends. Isto pode acontecer quando o Cloud CDN tiver publicado o pedido parcialmente a partir da respetiva cache e também tiver enviado um ou mais pedidos de intervalo de bytes para o back-end. Use a discriminação backend_scope para visualizar cada pedido do equilibrador de carga para o back-end.
backend_target_type O nome do serviço de back-end que publicou o pedido. Pode ser BACKEND_SERVICE, BACKEND_BUCKET, UNKNOWN se o back-end não tiver sido atribuído ou NO_BACKEND_SELECTED se tiver ocorrido um erro ou uma interrupção antes de ser selecionado um back-end, ter ocorrido um redirecionamento de URL ou um Application Load Balancer clássico com back-ends sem servidor tiver devolvido uma resposta 200 OK.
matched_url_path_rule A regra de caminho do mapa de URLs que correspondeu ao prefixo do pedido HTTP(S) (até 50 carateres).
forwarding_rule_name O nome da regra de encaminhamento usada pelo cliente para enviar o pedido.
url_map_name

A regra de caminho do mapa de URLs ou a regra de trajeto configurada como parte da chave do mapa de URLs. Pode ser UNMATCHED ou UNKNOWN como alternativas.

  • UNMATCHED refere-se a um pedido que não corresponde a nenhuma regra de caminho do URL, pelo que url_map_name usa a regra de caminho predefinida.
  • UNKNOWN indica um erro interno.
target_proxy_name O nome do objeto de proxy HTTP(S) de destino referenciado pela regra de encaminhamento.
backend_target_name O nome do destino de back-end. O destino pode ser um serviço de back-end ou um contentor de back-end. UNKNOWN é devolvido se não tiver sido atribuído um back-end.
backend_name O nome do grupo de instâncias, do contentor ou do NEG de back-end. UNKNOWN é devolvido se o back-end não tiver sido atribuído ou NO_BACKEND_SELECTED se tiver ocorrido um erro ou uma interrupção antes de ser selecionado um back-end, ter ocorrido um redirecionamento de URL ou um Application Load Balancer clássico com back-ends sem servidor tiver devolvido uma resposta 200 OK.
backend_scope_type

O tipo do âmbito do grupo de back-end. Pode ser GLOBAL, REGION, ZONE, MULTIPLE_BACKENDS ou NO_BACKEND_SELECTED se ocorreu um erro ou uma interrupção antes de ser selecionado um back-end, ocorreu um redirecionamento de URL ou um Application Load Balancer clássico com back-ends sem servidor devolveu uma resposta 200 OK ou outras possíveis saídas de backend_type.

MULTIPLE_BACKENDS é usado quando o armazenamento em cache de fragmentos é usado. São enviadas várias consultas para o mesmo back-end para diferentes blocos de dados para suportar um único pedido do cliente.
proxy_continent Continente do GFE HTTP(S) que terminou a ligação HTTP(S), por exemplo, America, Europe, Asia
protocol Protocolo usado pelo cliente, um dos seguintes: HTTP/1.0, HTTP/1.1, HTTP/2.0, QUIC/HTTP/2.0, UNKNOWN.
response_code O código de estado HTTP do pedido.
response_code_class A classe do código de estado HTTP do pedido: 200, 300, 400, 500 ou 0 para nenhum.
cache_result Cache result for serving HTTP request by proxy: HIT, MISS, DISABLED, PARTIAL_HIT (for a request served partially from cache and partially from backend), or UNKNOWN.
client_country País do cliente que emitiu o pedido HTTP, por exemplo, United States ou Germany.
load_balancing_scheme O esquema de balanceamento de carga usado. Se for usado o Application Load Balancer clássico, o valor é EXTERNAL. Se for usado o Application Load Balancer externo global, o valor é EXTERNAL_MANAGED.

O que se segue?