Registros e métricas para serviços de back-end

Neste documento, mostramos como configurar e usar o Cloud Logging e o Cloud Monitoring com balanceadores de carga de aplicativo clássicos, balanceadores de carga de aplicativo externos globais e o Cloud CDN.

Geração de registros

É possível ativar, desativar e visualizar registros para o serviço de back-end de um balanceador de carga de aplicativo externo. Para balanceadores de carga de aplicativos externos com buckets de back-end, a geração de registros é ativada automaticamente e não pode ser desativada.

É possível ativar ou desativar a geração de registros para cada serviço de back-end. Você pode configurar se quer registrar todas as solicitações ou uma fração amostrada aleatoriamente.

É preciso garantir que não haja uma exclusão de registros que se aplique a balanceadores de carga de aplicativo externos. Para saber como verificar se os registros Cloud HTTP Load Balancer são permitidos, consulte Filtros de exclusão.

Coleta e amostragem de registros

As solicitações (e as respostas correspondentes) processadas por instâncias de máquina virtual (VM) do back-end do balanceador de carga são amostradas. Essas solicitações amostradas são processadas para gerar registros. É possível controlar a fração das solicitações emitidas como entradas de registro de acordo com o parâmetro logConfig.sampleRate. Quando logConfig.sampleRate é 1.0 (100%), registros são gerados para todas as conexões e gravados no Cloud Logging.

Campos opcionais

Os registros contêm campos obrigatórios e opcionais. A seção O que é registrado lista quais campos são opcionais e quais são obrigatórios. Todos os campos obrigatórios sempre estão incluídos. É possível personalizar quais campos opcionais serão mantidos.

  • Se for selecionado Incluir todos os opcionais, todos os campos opcionais no formato de registro serão incluídos nos registros. Quando novos campos opcionais são adicionados ao formato de registro, os registros incluem automaticamente os novos campos.

  • Se for selecionado excluir todos os opcionais, todos os campos opcionais serão omitidos.

  • Se for selecionado personalizado, poderão ser especificados os campos opcionais que serão incluídos, como tls.protocol,tls.cipher,orca_load_report.cpu_utilization,orca_load_report.mem_utilization.

Para saber como personalizar campos opcionais, consulte Ativar a geração de registros em um novo serviço de back-end.

Ativação da geração de registros em um novo serviço de back-end

Console

  1. No console do Google Cloud , acesse a página Balanceamento de carga.

    Acesse 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 obrigatórios do serviço de back-end.

  7. Na seção Geração de registros, marque a caixa de seleção Ativar geração de registros.

  8. Defina uma fração da Taxa de amostragem. É possível definir um número de 0.0 a 1.0, em que 0.0 significa que nenhuma solicitação é registrada e 1.0 significa que 100% das solicitações são registradas. O valor padrão é 1.0.

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

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

  11. Para concluir a edição do balanceador de carga, clique em Atualizar.

gcloud: modo global

Crie um serviço de back-end e ative a geração de registros usando o 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 é compatível com os seguintes campos:

  • --global indica que o serviço de back-end é global. Use esse campo para serviços de back-end usados com balanceadores de carga de aplicativo externos globais.
  • --enable-logging ativa a geração de registros para esse serviço de back-end.
  • --logging-sample-rate permite especificar um valor de 0.0 a 1.0, em que 0.0 significa que nenhuma solicitação é registrada e 1.0 significa que 100% das solicitações são registradas. Esse campo só é significativo com o parâmetro --enable-logging. Ativar a geração de registros, mas definir a taxa de amostragem como 0.0 equivale a desativar a geração de registros. O valor padrão é 1.0.

  • --logging-optional permite especificar os campos opcionais que serão incluídos nos registros:

    • INCLUDE_ALL_OPTIONAL para incluir todos os campos opcionais.

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

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

  • --logging-optional-fields permite especificar uma lista separada por vírgulas de campos opcionais que serão incluídos nos registros.

    Por exemplo, tls.protocol,tls.cipher só poderá ser definido se LOGGING_OPTIONAL_MODE for definido como CUSTOM. Se forem usadas métricas personalizadas e forem registrados elementos do relatório de carga do ORCA, LOGGING_OPTIONAL_MODE deverá ser definido como CUSTOM e deverão ser especificados que elementos precisam ser registrados no campo OPTIONAL_FIELDS. Por exemplo, orca_load_report.cpu_utilization,orca_load_report.mem_utilization.

Ativação da geração de registros em um serviço de back-end

Console

  1. No console do Google Cloud , acesse a página Balanceamento de carga.

    Acesse 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 ao lado do serviço de back-end.

  6. Na seção Geração de registros, marque a caixa de seleção Ativar geração de registros.

  7. No campo Taxa de amostragem, defina a probabilidade de amostragem. É possível definir um número de 0.0 a 1.0, em que 0.0 significa que nenhuma solicitação é registrada e 1.0 significa que 100% das solicitações são registradas. O valor padrão é 1.0.

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

  9. Para concluir a edição do balanceador de carga, clique em Atualizar.

gcloud: modo global

Ative a geração de registros em um serviço de back-end com o comando gcloud compute backend-services update.

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

em que

  • --global indica que o serviço de back-end é global. Use esse campo para serviços de back-end usados com balanceadores de carga de aplicativo externos globais.
  • --enable-logging ativa a geração de registros para esse serviço de back-end.
  • --logging-sample-rate permite especificar um valor de 0.0 a 1.0, em que 0.0 significa que nenhuma solicitação é registrada e 1.0 significa que 100% das solicitações são registradas. Só é significativo com o parâmetro --enable-logging. Ativar a geração de registros, mas definir a taxa de amostragem como 0.0 equivale a desativar a geração de registros. O valor padrão é 1.0.

gcloud: modo clássico

Ative a geração de registros em um serviço de back-end com o comando gcloud compute backend-services update.

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

em que

  • --global indica que o serviço de back-end é global. Use este campo para serviços de back-end usados com um balanceador de carga de aplicativo clássico.
  • --enable-logging ativa a geração de registros para esse serviço de back-end.
  • --logging-sample-rate permite especificar um valor de 0.0 a 1.0, em que 0.0 significa que nenhuma solicitação é registrada e 1.0 significa que 100% das solicitações são registradas. Só é significativo com o parâmetro --enable-logging. Ativar a geração de registros, mas definir a taxa de amostragem como 0.0 equivale a desativar a geração de registros. O valor padrão é 1.0.

Desativação ou modificação da geração de registros em um serviço de back-end

Console

  1. No console do Google Cloud , acesse a página Balanceamento de carga.

    Acesse 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 ao lado do serviço de back-end.

  6. Para desativar totalmente a geração de registros, desmarque a caixa de seleção Ativar geração de registros na seção Geração de registros.

  7. Se a geração de registros permanecer ativada, será possível definir uma fração diferente da taxa de amostragem. É possível definir um número de 0.0 a 1.0, em que 0.0 significa que nenhuma solicitação é registrada e 1.0 significa que 100% das solicitações são registradas. O valor padrão é 1.0. Por exemplo, 0.2 significa que 20% das solicitações amostradas geram registros.

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

  9. Para concluir a edição do balanceador de carga, clique em Atualizar.

gcloud: modo global

Desative a geração de registros em um serviço de back-end com o comando gcloud compute backend-services update.

Desativação total da geração de registros

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

em que

  • --global indica que o serviço de back-end é global. Use esse campo para serviços de back-end usados com balanceadores de carga de aplicativo externos globais.
  • --no-enable-logging desativa a geração de registro para esse serviço de back-end.

Ativação de campos opcionais de geração de registros em um serviço de back-end

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

em que

  • --logging-sample-rate permite especificar um valor de 0.0 a 1.0, em que 0.0 significa que nenhuma solicitação é registrada e 1.0 significa que 100% das solicitações são registradas. Só é significativo com o parâmetro --enable-logging. Ativar a geração de registros, mas definir a taxa de amostragem como 0.0 equivale a desativar a geração de registros. O valor padrão é 1.0.

  • --logging-optional permite especificar os campos opcionais que serão incluídos nos registros:

    • INCLUDE_ALL_OPTIONAL para incluir todos os campos opcionais.

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

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

  • --logging-optional-fields permite especificar uma lista separada por vírgulas de campos opcionais que serão incluídos nos registros.

    Por exemplo, tls.protocol,tls.cipher só poderá ser definido se LOGGING_OPTIONAL_MODE for definido como CUSTOM. Se forem usadas métricas personalizadas e forem registrados elementos do relatório de carga do ORCA, LOGGING_OPTIONAL_MODE deverá ser definido como CUSTOM e deverão ser especificados que elementos precisam ser registrados no campo OPTIONAL_FIELDS. Por exemplo, orca_load_report.cpu_utilization,orca_load_report.mem_utilization.

Atualização do modo opcional de geração de registros de PERSONALIZADO para outros

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

em que

  • --logging-optional permite especificar os campos opcionais que serão incluídos nos registros:

    • INCLUDE_ALL_OPTIONAL para incluir todos os campos opcionais.

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

  • --logging-optional-fields precisa ser configurado explicitamente, conforme mostrado, para limpar todos os campos CUSTOM. A API não permite a combinação de um modo que não seja CUSTOM com campos CUSTOM.

Modificação da taxa de amostragem da geração de registros

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

gcloud: modo clássico

Desative a geração de registros em um serviço de back-end com o comando gcloud compute backend-services update.

Desativação total da geração de registros

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

em que

  • --global indica que o serviço de back-end é global. Use este campo para serviços de back-end usados com um balanceador de carga de aplicativo clássico.
  • --no-enable-logging desativa a geração de registro para esse serviço de back-end.

Modificação da taxa de amostragem da geração de registros

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

em que

  • --global indica que o serviço de back-end é global. Use este campo para serviços de back-end usados com um balanceador de carga de aplicativo clássico.
  • --logging-sample-rate permite especificar um valor de 0.0 a 1.0, em que 0.0 significa que nenhuma solicitação é registrada e 1.0 significa que 100% das solicitações são registradas. Só é significativo com o parâmetro --enable-logging. Ativar a geração de registros, mas definir a taxa de amostragem como 0.0 equivale a desativar a geração de registros.

Visualizar registros

Para seguir as instruções detalhadas da tarefa diretamente no console do Google Cloud , clique em Orientações:

Orientações

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

Para visualizar os registros, acesse a página Análise de registros.

Acessar Análise de registros

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

  • Para visualizar os registros de uma regra de encaminhamento, selecione um único nome de regra de encaminhamento.

  • Para visualizar os registros de um mapa de URL, selecione uma regra de encaminhamento e, em seguida, selecione um mapa de URL.

Os campos de registro do tipo booleano normalmente só serão exibidos se tiverem um valor true. Se um campo booleano tiver um valor false, este campo será omitido do registro.

A codificação UTF-8 é aplicada aos campos de registro. Os caracteres que não forem UTF-8 serão substituídos por pontos de interrogação. Para balanceadores de carga de aplicativo clássicos e externos globais, é possível exportar métricas com base em registros usando registros de recurso (resource.type="http_load_balancer"). As métricas criadas são baseadas no recurso Regra de balanceador de carga de aplicativo (métricas com base em registros) (l7_lb_rule), disponível nos painéis do Cloud Monitoring e não no recurso https_lb_rule.

O que é registrado

As entradas de registro do balanceador de carga de aplicativo externo contêm informações úteis para monitorar e depurar o tráfego HTTP(S). Os registros contêm campos obrigatórios, que são os campos padrão de cada registro.

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

Alguns campos de registro aparecem em um formato múltiplo, com mais de um dado em cada campo. Por exemplo, o campo tls está no formato TlsInfo, que contém o campo earlyDataRequest. Esses campos são descritos na tabela de formatos de registro a seguir.

Campo Formato do campo Tipo de campo: obrigatório ou opcional Descrição
gravidade
insertID
logName		 LogEntry Obrigatório Os campos gerais, conforme descrito em uma entrada de registro.
timestamp string (formato Carimbo de data/hora) Opcional A hora em que o GFE da primeira camada recebe a solicitação.
httpRequest HttpRequest Obrigatório Um protocolo comum para o registro de solicitações HTTP.

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

.
resource Recurso monitorado Obrigatório

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

O MonitoredResourceDescriptor descreve o esquema de um objeto MonitoredResource usando um nome de tipo e um conjunto de rótulos. Para mais informações, consulte Rótulos de recursos.
jsonPayload: objeto (formato Struct) Obrigatório O payload da entrada de registro, expresso como um objeto JSON. O objeto JSON contém os seguintes campos:
  • statusDetails
  • backendTargetProjectNumber
  • overrideResponseCode
  • errorService
  • errorBackendStatusDetails
  • authzPolicyInfo
  • loadBalancingScheme
  • tls
  • orca_load_report
string Obrigatório O campo statusDetails tem uma string que explica por que o balanceador de carga retornou esse código de status HTTP específico. Para mais informações sobre essas strings de registro, consulte Mensagens de sucesso HTTP statusDetails e mensagens de falha HTTP statusDetails.
string Obrigatório O campo backendTargetProjectNumber contém o número do projeto em que o destino de back-end (serviço ou bucket de back-end) foi criado. Esse campo está no formato: "projects/PROJECT_NUMBER". Essas informações só estão disponíveis para balanceadores de carga de aplicativo externos globais que usam respostas de erro personalizadas.
inteiro Obrigatório O overrideResponseCode contém o código de resposta de substituição aplicado à resposta enviada ao cliente. Essas informações só estão disponíveis para balanceadores de carga de aplicativo externos globais que usam respostas de erro personalizadas.
string Obrigatório O campo errorService contém o serviço de back-end que forneceu a resposta de erro personalizada. Essas informações só estão disponíveis para balanceadores de carga de aplicativo externos globais que usam respostas de erro personalizadas.
string Obrigatório O campo errorBackendStatusDetails contém o statusDetails da resposta final disponibilizada para o cliente. Essas informações só estão disponíveis para balanceadores de carga de aplicativo externos globais que usam respostas de erro personalizadas.
AuthzPolicyInfo Obrigatório O campo authzPolicyInfo armazena informações sobre o resultado da política de autorização. Essas informações só estão disponíveis para balanceadores de carga de aplicativo externos globais que ativaram políticas de autorização. Para mais informações, consulte o que é registrado para políticas de autorização.
string Opcional O campo loadBalancingScheme só é preenchido se for usado o recurso de migração do balanceador de carga de aplicativo clássico. Esse campo contém uma string que descreve qual esquema de balanceamento de carga foi usado para encaminhar a solicitação. Os valores possíveis são EXTERNAL ou EXTERNAL_MANAGED.
TlsInfo Obrigatório

O campo tls contém o campo TlsInfo que especifica os metadados TLS para a conexão entre o cliente e o balanceador de carga. Esse campo só estará disponível se o cliente estiver usando criptografia TLS/SSL.

Use o parâmetro --logging-optional-fields para especificar quais elementos precisam ser registrados:

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

Não é possível 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 carga do ORCA retornado pelo back-end. Esse campo só estará presente se o back-end retornar um relatório de carga do ORCA e se o balanceador de carga tiver sido configurado para registrar o relatório de carga do ORCA.

Use o parâmetro --logging-optional-fields para especificar qual dos seguintes elementos do relatório de carga do ORCA precisa ser registrado:

  • 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 é possível definir --logging-optional-fields como orca_load_report para especificar que todos os elementos precisam ser registrados.

Formato do campo TlsInfo

Campo Formato do campo Tipo de campo: obrigatório ou opcional Descrição
protocol string Opcional Protocolo TLS que os clientes podem usar para estabelecer uma conexão com o balanceador de carga. Os valores possíveis são TLSv1, TLSv1.1, TLSv1.2, TLSv1.3 ou QUIC. Esse valor será definido como NULL se o cliente não estiver usando criptografia TLS/SSL.
cipher string Opcional Criptografia TLS que os usam para estabelecer uma conexão com o balanceador de carga. Esse valor será definido como NULL se o cliente não estiver usando HTTP(S) ou criptografia TLS/SSL.
earlyDataRequest booleano Obrigatório A solicitação inclui dados iniciais no handshake de TLS.

Rótulos de recursos

A tabela a seguir lista os rótulos dos recursos de resource.type="http_load_balancer".

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

mensagens de sucesso HTTP statusDetails

statusDetails (bem-sucedida) Significado Códigos de resposta associados frequentes
byte_range_caching A solicitação HTTP foi exibida usando o cache de intervalo de bytes do Cloud CDN. Qualquer código de resposta armazenável em cache é possível.
response_from_cache A solicitação HTTP foi exibida por um cache do Cloud CDN. Qualquer código de resposta armazenável em cache é possível.
response_from_cache_validated O código de retorno foi definido por uma entrada em cache do Cloud CDN que foi validada por um back-end. Qualquer código de resposta armazenável em cache é possível.
response_sent_by_backend A solicitação HTTP foi encaminhada por proxy para o back-end e a resposta foi retornada pelo back-end. O código de resposta HTTP é definido pelo software em execução no back-end.

mensagens de falha HTTP statusDetails

statusDetails (falha) Significado Códigos de status associados comuns
aborted_request_due_to_backend_early_response Uma solicitação com corpo foi cancelada porque o back-end enviou uma resposta antecipada com um código de status. A resposta foi encaminhada ao cliente. A solicitação foi encerrada. 4XX ou 5XX
backend_connection_closed_after_partial_response_sent A conexão do back-end fechou inesperadamente depois que uma resposta parcial foi enviada ao cliente.

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

O código de status HTTP será 101 se a conexão HTTP(S) tiver sido submetida a upgrade para uma conexão websocket.
backend_connection_closed_before_data_sent_to_client O back-end fechou inesperadamente a conexão com o balanceador de carga antes que a resposta fosse encaminhada por proxy para o cliente.

502, 503

O código de status HTTP será 101 se a conexão HTTP(S) tiver sido submetida a upgrade para uma conexão websocket.
backend_early_response_with_non_error_status O back-end enviou um código de status sem erro (1XX ou 2XX) a uma solicitação antes de receber todo o corpo da solicitação. 502, 503
backend_interim_response_not_supported O back-end enviou um código de status temporário 1XX para a solicitação em um contexto em que respostas temporárias não são compatíveis.

502, 503
backend_response_corrupted O corpo da resposta HTTP enviada pelo back-end tem uma codificação de transferência em blocos inválida ou corrompida. Qualquer código de status é possível, dependendo da natureza da corrupção. Geralmente, 502 e 503.
backend_response_headers_too_long Os cabeçalhos de resposta HTTP enviados pelo back-end excederam o limite permitido. Consulte a seção Tamanho do cabeçalho para balanceadores de carga de aplicativos externos para mais informações. 502, 503
backend_timeout

O tempo limite do back-end foi atingido enquanto uma resposta era gerada.

Para uma conexão websocket:

  • Para o balanceador de carga de aplicativo externo global, é gerado um código de status quando o GFE fecha a conexão websocket em estado inativo depois que o serviço de back-end atinge o tempo limite.
  • Para o balanceador de carga de aplicativo clássico, é gerado um código de status quando o GFE fecha a conexão websocket no estado inativo ou ativo depois que o serviço de back-end atinge o tempo limite.

502, 503

O código de status HTTP será 101 se a conexão HTTP(S) tiver sido submetida a upgrade para uma conexão websocket.
banned_by_security_policy A solicitação foi proibida por uma regra baseada na taxa do Google Cloud Armor. 429
body_not_allowed O cliente enviou uma solicitação HTTP com corpo, mas o método HTTP usado não permite um corpo. 400
byte_range_caching_aborted Anteriormente, o balanceador de carga recebeu uma resposta indicando que o recurso podia ser armazenado em cache e era compatível com intervalos de bytes. O Cloud CDN recebeu uma resposta inconsistente (por exemplo, com um código de status diferente do 206 Partial Content esperado). Isso aconteceu na tentativa de execução do preenchimento do cache usando uma solicitação de intervalo de bytes. Como resultado, o balanceador de carga cancelou a resposta para o cliente. 2XX
byte_range_caching_forwarded_backend_response Anteriormente, o balanceador de carga recebeu uma resposta indicando que o recurso podia ser armazenado em cache e era compatível com intervalos de bytes. O Cloud CDN recebeu uma resposta inconsistente (por exemplo, com um código de status diferente do 206 Partial Content esperado). Isso aconteceu na tentativa de execução do preenchimento do cache usando uma solicitação de intervalo de bytes. O balanceador de carga encaminhou a resposta inconsistente para o cliente.

Retornado do back-end: qualquer código de status é possível.
byte_range_caching_retrieval_abandoned O cliente cancelou uma solicitação de intervalo de bytes ou de validação iniciada pelo Cloud CDN.

Retornado do back-end: qualquer código de status é possível.
byte_range_caching_retrieval_from_backend_failed_after_partial_response Uma solicitação de intervalo de bytes ou de validação iniciada pelo Cloud CDN encontrou um erro. Consulte a entrada de registro correspondente do Cloud Logging referente à solicitação iniciada pelo Cloud CDN para o status detalhado do back-end. 2XX
cache_lookup_failed_after_partial_response O balanceador de carga não conseguiu exibir uma resposta completa do cache do Cloud CDN devido a um erro interno. 2XX
cache_lookup_timeout_after_partial_response O stream de pesquisa de cache do Cloud CDN atingiu o tempo limite porque o cliente não recuperou o conteúdo em tempo hábil. 2XX
client_disconnected_after_partial_response A conexão com o cliente foi interrompida depois que o balanceador de carga enviou uma resposta parcial.

Retornado do back-end: qualquer código de status é possível.

O código de status HTTP será 101 se a conexão HTTP(S) tiver sido submetida a upgrade para uma conexão websocket.
client_disconnected_before_any_response A conexão com o cliente foi interrompida antes que o balanceador de carga enviasse uma resposta.

0

O código de status HTTP será 101 se a conexão HTTP(S) tiver sido submetida a upgrade para uma conexão websocket.
client_timed_out O Google Front End (GFE) deixou inativa a conexão com o cliente devido à falta de progresso enquanto ela estava enviando por proxy a solicitação ou a resposta. 0 ou 408
client_cert_invalid_rsa_key_size Uma folha do cliente ou um certificado intermediário tinha um tamanho inválido da chave RSA. Para mais informações, consulte Erros registrados para conexões fechadas. 0
client_cert_unsupported_elliptic_curve_key Um cliente ou certificado intermediário está usando uma curva elíptica não compatível. Para mais informações, consulte Erros registrados para conexões fechadas. 0
client_cert_unsupported_key_algorithm Um cliente ou um certificado intermediário está usando um algoritmo não RSA ou não ECDSA. Para mais informações, consulte Erros registrados para conexões fechadas. 0
client_cert_pki_too_large A ICP a ser usada para validação tem mais de dez certificados intermediários que compartilham o mesmo sujeito e as mesmas informações sobre a chave pública do sujeito. Para mais informações, consulte Erros registrados para conexões fechadas. 0
client_cert_chain_max_name_constraints_exceeded Um certificado intermediário fornecido para validação tinha mais de dez restrições de nome. Para mais informações, consulte Erros registrados para conexões fechadas. 0
client_cert_chain_invalid_eku O certificado do cliente ou o emissor não tem o uso de chave estendido (EKU, na sigla em inglês) que inclua clientAuth. Para mais informações, consulte Erros registrados para conexões fechadas. 0
client_cert_validation_timed_out O limite de tempo foi excedido ao validar a cadeia de certificados. Para mais informações, consulte Erros registrados para conexões fechadas. 0
client_cert_validation_search_limit_exceeded O limite de profundidade ou iteração é alcançado ao tentar validar a cadeia de certificados. Para mais informações, consulte Erros registrados para conexões fechadas. 0
client_cert_validation_not_performed O mTLS foi configurado sem a configuração de um TrustConfig. Para mais informações, consulte Erros registrados para conexões fechadas. 0
client_cert_not_provided O cliente não forneceu o certificado solicitado durante o handshake. Para mais informações, consulte Erros registrados para conexões fechadas. 0
client_cert_validation_failed A validação do certificado do cliente apresenta falha com o TrustConfig quando algoritmos de hash, como MD4, MD5 e SHA-1, são usados. Para mais informações, consulte Erros registrados para conexões fechadas. 0
config_not_found

Falta a configuração do projeto no balanceador de carga. Isso pode ocorrer de maneira intermitente, depois que tiverem sido feitas alterações na configuração que adicionem um novo recurso.

Outra causa do erro é que o GFE de primeira camada não consegue se comunicar com o GFE de segunda camada. Isso pode ser decorrente de um erro interno, como um lançamento em andamento, sobrecarga do balanceador de carga ou problemas de configuração intermitentes.

Esses erros são temporários e devem estar dentro do SLA. No entanto, se a taxa de erros exceder 0,01%, entre em contato com o Google Cloud suporte para receber mais ajuda.

 404, 502, 503
direct_response O balanceador de carga substituiu essa solicitação e retornou uma resposta fixa. É possível ver qualquer código de status HTTP, dependendo da natureza do problema. Por exemplo, o código de status HTTP 410 significa que o back-end está indisponível devido a falta de pagamento.
denied_by_security_policy O balanceador de carga negou essa solicitação devido a uma política de segurança do Google Cloud Armor. Configurado na Política de segurança.
error_uncompressing_gzipped_body Houve um erro ao descompactar uma resposta HTTP compactada com gzip. 502, 503
failed_to_connect_to_backend O balanceador de carga não conseguiu se conectar ao back-end. Isso inclui tempos limite durante a fase de conexão. 502, 503
failed_to_pick_backend O balanceador de carga não conseguiu escolher um back-end íntegro para executar a solicitação. 502, 503
failed_to_negotiate_alpn O balanceador de carga e o back-end não conseguiram negociar um protocolo da camada do aplicativo (como HTTP/2) para se comunicar entre si, usando TLS. 502, 503
headers_too_long Os cabeçalhos da solicitação eram maiores do que o tamanho máximo permitido. 413
http_version_not_supported Versão HTTP não compatível. Somente HTTP 0.9, 1.0, 1.1 e 2.0 são compatíveis. 400
internal_error Erro interno no balanceador de carga. Normalmente, representa um erro temporário na infraestrutura do balanceador de carga. Tente refazer a consulta. 4XX ou 5XX
invalid_chunk_framing As solicitações e as respostas enviadas 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 precisam terminar em CRLF. 400
invalid_external_origin_endpoint A configuração do back-end externo é inválida. Revise a configuração do NEG de Internet e verifique se ela especifica um endereço FQDN/IP e uma porta válidos. 4XX
invalid_request_headers

Os cabeçalhos da solicitação HTTP recebidos de um cliente contêm pelo menos um caractere que não é permitido, segundo uma especificação HTTP aplicável.

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

Para mais informações, consulte:

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

O caminho de solicitação HTTP/2 de um cliente contém pelo menos um caractere que não é permitido, segundo a especificação do URI.

Para mais informações, consulte a seção "3.3. Caminho" da RFC 3986.

 400
multiple_iap_policies Não é possível combinar várias políticas do Identity-Aware Proxy (IAP). Se houver uma política de IAP anexada a um serviço de back-end e outra política 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 o Cloud Run functions. 500
malformed_chunked_body O corpo da solicitação foi codificado inadequadamente em blocos. 411
request_loop_detected O balanceador de carga detectou uma repetição de solicitação. Essa repetição pode ser causada por uma configuração incorreta em que o back-end encaminhou a solicitação de volta ao balanceador de carga. 502, 503
required_body_but_no_content_length A solicitação HTTP exige um corpo, mas os cabeçalhos da solicitação não incluem um comprimento de conteúdo ou cabeçalho em blocos de codificação de transferência. 400, 403, 411
secure_url_rejected Uma solicitação com um URL https:// foi recebida em uma conexão HTTP/1.1 de texto simples. 400
server_cert_chain_exceeded_limit A cadeia de certificados do servidor é muito longa (mais de 10 certificados intermediários 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) que não inclui serverAuth.

server_cert_chain_max_name_constraints_exceeded

 Um certificado intermediário fornecido para validação tinha mais de 10 restrições de nome. 502, 503
server_cert_exceeded_size_limit O payload do certificado do servidor (incluindo certificados intermediários) é muito grande (mais de 16 KB). 503
server_cert_invalid_rsa_key_size

Um servidor ou um certificado intermediário tem um tamanho da chave RSA inválido.

Nenhuma validação é executada.

As chaves RSA podem ter entre 2.048 e 4.096 bits.

 503
server_cert_not_provided O servidor não forneceu o certificado solicitado durante o handshake. 503
server_cert_pki_too_large

A ICP a ser usada para validação tem mais de dez certificados intermediários que compartilham as mesmas informações sobre o sujeito e sobre a chave pública do sujeito.

Nenhuma validação é executada.

 503
server_cert_trust_config_not_found TrustConfig correspondente não encontrado. 503
server_cert_unsupported_elliptic_curve_key

Um servidor ou um certificado intermediário está usando uma curva elíptica não compatível.

Nenhuma validação é executada.

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

 503
server_cert_unsupported_key_algorithm

Um servidor ou certificado intermediário está usando um algoritmo não RSA ou não ECDSA.

Nenhuma validação é executada.

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

O mTLS foi configurado sem a configuração de um recurso TrustConfig.

 503
server_cert_validation_search_limit_exceeded

O limite de profundidade ou de iteração é alcançado na tentativa de validação da cadeia de certificados.

A profundidade máxima de uma cadeia de certificados é dez, incluindo os certificados raiz e do 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 é excedido na tentativa de validação da cadeia de certificados. 503
server_cert_validation_unavailable O serviço não consegue executar a validação da cadeia de certificados. 503
ssl_certificate_san_verification_failed O balanceador de carga não consegue encontrar um nome alternativo do sujeito (SAN, na sigla em inglês) no certificado SSL apresentado pelo back-end que corresponde ao nome do host configurado. 502, 503
ssl_certificate_chain_verification_failed O certificado SSL apresentado pelo back-end apresentou falha na verificação do certificado SSL. 502, 503
throttled_by_security_policy A solicitação foi bloqueada por uma regra de limitação do Google Cloud Armor. 429
unsupported_method O cliente forneceu um método de solicitação HTTP não compatível. 400
unsupported_100_continue A solicitação do cliente incluía o cabeçalho "Expect: 100-continue" em um protocolo que não é compatível. 400
upgrade_header_rejected A solicitação HTTP do cliente continha o cabeçalho Upgrade e foi recusada. 400
websocket_closed A conexão websocket foi fechada. 101
websocket_handshake_failed O handshake do websocket apresentou falha. Qualquer código de resposta possível, dependendo da natureza da falha de handshake.
request_body_too_large O corpo da solicitação HTTP excedeu o máximo suportado pelo back-end. Não relevante para back-ends de VMs. 413
handled_by_identity_aware_proxy Esta resposta foi gerada pelo Identity-Aware Proxy durante a confirmação de identidade do cliente antes de permitir o acesso.

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

429 (limitado pelo IAP)
serverless_neg_routing_failed Não é possível enviar a solicitação NEG sem servidor. Esse erro poderá acontecer quando a região especificada no NEG não puder ser acessada ou quando o nome do recurso (por exemplo, o nome do Cloud Run functions) não puder ser encontrado. 404, 502, 503
fault_filter_abort Esse erro poderá acontecer se o cliente tiver configurado um filtro de falha e este tiver sido acionado para a solicitação em questão. O valor precisa estar entre 200 e 599.
early_data_rejected

A solicitação enviada nos dados iniciais do TLS era inválida.

Isso pode ocorrer nos seguintes casos, entre outros:

  • O TargetHttpsProxy tem dados iniciais de TLS definidos como STRICT, mas a solicitação incluiu parâmetros de consulta.
  • O TargetHttpsProxy tem dados iniciais de TLS definidos como STRICT ou PERMISSIVE, mas a solicitação usou um método HTTP não idempotente (como POST ou PUT).
 425
service_extension_error

Ocorreu um erro ao chamar uma extensão de serviço usada pelo balanceador de carga.

Isso pode acontecer se o plug-in Wasm demorar para responder e exceder o limite de um milissegundo para enviar a resposta.

 425

Visualize registros para validação do certificado do cliente mTLS

Para visualizar os erros registrados em conexões fechadas durante a validação do certificado do cliente de TLS mútuo, conclua as etapas a seguir.

Consulta do console

  1. No console do Google Cloud , acesse a página Análise de registros.

    Acessar Análise de registros

  2. Clique no botão Mostrar consulta.

  3. Cole o seguinte no campo de consulta. Substitua FORWARDING_RULE_NAME pelo nome da 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.

Registros de solicitações de política de autorização

O objeto authz_info no payload JSON da entrada de registro do balanceador de carga contém informações sobre políticas de autorização. É possível configurar métricas com base em registros para o tráfego permitido ou negado por essas políticas. Verifique mais detalhes do registro de políticas de autorização.

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

O nome está vazio pelos seguintes motivos:

  • Nenhuma política ALLOW corresponde à solicitação, que é negada.
  • Nenhuma política DENY corresponde à solicitação, que é permitida.
authz_info.policies[].result enum O resultado pode ser ALLOWED ou DENIED.
authz_info.policies[].details string Estes são os detalhes:
  • 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.

Geração de registros para o Cloud Armor

A tabela de mensagens de falha HTTP statusDetail contém algumas mensagens que se aplicam ao Cloud Armor. Para mais informações sobre o que o Cloud Armor registra, consulte Usar a geração de registros de solicitação.

Geração de registros para implantações de VPC compartilhada

Os registros e as métricas do balanceador de carga de aplicativo normalmente são exportados para o projeto que tem a regra de encaminhamento. Portanto, admins de serviço (proprietários ou usuários de projetos em que o serviço de back-end é criado) não terão acesso aos registros e às métricas do balanceador de carga, por padrão. Use papéis do IAM para conceder essas permissões aos admins de serviço. Para saber mais sobre os papéis do IAM disponíveis e as etapas para conceder acesso, consulte Conceder acesso ao Monitoring.

Interação com os registros

É possível interagir com os registros do balanceador de carga de aplicativo externo usando a API Cloud Logging. A API Logging fornece maneiras de filtrar de forma interativa registros que têm campos específicos definidos. Ela exporta registros correspondentes para o Cloud Logging, o Cloud Storage, o BigQuery ou o Pub/Sub. Para mais informações sobre a API Logging, consulte Visão geral da API Logging.

Monitoramento

O balanceador de carga exporta dados de monitoramento para o Monitoring.

Use as métricas de monitoramento para fazer o seguinte:

  • avaliar a configuração, o uso e o desempenho de um balanceador de carga;
  • Resolver problemas
  • melhorar a utilização de recursos e a experiência do usuário

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

As métricas dos balanceadores de carga de aplicativo externos são exportadas para o Cloud Monitoring em lotes de granularidade de 1 minuto. Os dados de monitoramento são retidos por seis (6) semanas.

O painel fornece análise de dados em intervalos padrão de 1H (uma hora), 6H (seis horas), 1D (um dia), 1W (uma semana) e 6W (seis semanas). É possível solicitar manualmente a análise em qualquer intervalo, de 6W a 1 minuto.

Monitoramento de métricas

É possível monitorar as métricas a seguir para balanceadores de carga de aplicativo externos.

As métricas a seguir para balanceadores de carga de aplicativo externos globais são informadas no Cloud Monitoring. Essas métricas são precedidas por loadbalancing.googleapis.com/.

Métrica Nome Descrição
Contagem de solicitações https/request_count O número de solicitações disponibilizadas pelo balanceador de carga de aplicativo externo
Contagem de bytes da solicitação https/request_bytes_count O número de bytes enviados como solicitações dos clientes para o balanceador de carga de aplicativo externo
Contagem de bytes da resposta https/response_bytes_count O número de bytes enviados como respostas do balanceador de carga de aplicativo 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 da solicitação recebida pelo proxy e o último byte da resposta enviada pelo proxy. Ela inclui: o tempo gasto pelo proxy para processar a solicitação, o tempo gasto para que a solicitação seja enviada do proxy para o back-end, o tempo gasto pelo back-end para processar a solicitação, o tempo gasto para que a resposta seja enviada de volta ao proxy e o tempo gasto para que o proxy processe a resposta e a envie ao cliente.

Ela não inclui o RTT entre o cliente e o proxy. Além disso, as pausas entre solicitações na mesma conexão que usam Connection: keep-alive não afetam a medição. Essa medida normalmente é reduzida para o 95.º percentil nas visualizações do Cloud Monitoring.

Para conexões websocket, esse campo se refere a toda a duração da conexão.*

Exemplo: um balanceador de carga tem 1 solicitação por segundo do Reino Unido com uma latência de 100 ms e 9 solicitações por segundo dos EUA com latência de 50 ms. Durante um determinado minuto, houve 60 solicitações do Reino Unido e 540 solicitações dos EUA. As métricas de monitoramento preservam a distribuição em todas as dimensões. Você pode solicitar informações, como:

  • latência global mediana (300/600): 50 ms
  • latência mediana do Reino Unido (30/60): 100 ms
  • latência geral do 95.º percentil (570/600): 100 ms
RTT do front-end† https/frontend_tcp_rtt

Uma distribuição do RTT do front-end. RTT do front-end é o tempo em milissegundos para que os dados viajem do cliente para o proxy e voltem. Ele inclui o tempo para uma solicitação viajar do cliente para o proxy e do proxy para o cliente. Esse valor não é atualizado durante o ciclo de vida da conexão. Por exemplo, configurar uma conexão (TCP) com um handshake de três vias levaria 1,5 RTTs.

Quando as solicitações são processadas, o balanceador de carga faz amostragem e calcula a média do tempo necessário para que os dados viajem entre o cliente e o proxy e registrem um valor de RTT suavizado. O RTT suavizado é um algoritmo que lida com variações e anomalias que podem ocorrer em medições de RTT.
Latências de back-end† https/backend_latencies

Uma distribuição da latência de back-end. Latência de back-end é o tempo, em milissegundos, entre o primeiro byte da solicitação recebida pelo back-end e o último byte da resposta recebida pelo proxy. Ela inclui: o tempo necessário para que a solicitação seja enviada do proxy para o back-end, o tempo necessário para que o back-end processe a solicitação e o tempo necessário para que a resposta seja enviada de volta ao proxy.
Fração de classe de código de resposta Fração do total de respostas do balanceador de carga de aplicativo externo que estão em cada classe de código de resposta (2xx, 4xx, ...). No Monitoring, esse valor só está disponível em painéis padrão. Ele não está disponível em painéis personalizados. É possível usar a API Monitoring para definir alertas para isso.
Contagem de solicitações de back-end https/backend_request_count O número de solicitações enviadas do balanceador de carga de aplicativo externo para os back-ends.
Contagem de bytes da solicitação de back-end https/backend_request_bytes_count O número de bytes enviados como solicitações do balanceador de carga de aplicativo externo para os back-ends.
Contagem de bytes de resposta de back-end https/backend_response_bytes_count O número de bytes enviados como respostas dos back-ends, incluindo o cache, para o balanceador de carga de aplicativo externo.

* Para monitorar conexões websocket, crie um serviço de back-end específico para websockets.

† A soma das latências do RTT de front-end e do back-end talvez não seja menor ou igual às latências totais. Isso ocorre porque, mesmo que pesquisemos o RTT no soquete do GFE para o cliente no momento em que a resposta HTTP é confirmada, dependemos do relatório do kernel para algumas dessas medidas e não podemos garantir que o kernel terá uma medição de RTT para a resposta HTTP em questão. O resultado final é um valor RTT suavizado que também é afetado por respostas HTTP anteriores, por SYN/ACKs e por handshakes SSL que não afetam as verdadeiras marcações de tempo da solicitação HTTP atual.

Filtragem de dimensões para métricas

É possível aplicar filtros a métricas para balanceadores de carga de aplicativo externos.

As métricas são agregadas para cada balanceador de carga de aplicativo clássico e cada balanceador de carga de aplicativo externo global. É possível filtrar métricas agregadas pelas dimensões a seguir para resource.type="http_load_balancer" ou resource.type="https_lb_rule". Nem todas as dimensões estão disponíveis em todas as métricas.

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

Se nenhum grupo de instâncias estava disponível ou se a solicitação foi disponibilizada por outra entidade, é exibido um dos valores a seguir em vez da região ou zona do grupo de instâncias do serviço de back-end.

  • FRONTEND_5xx: ocorreu um erro interno antes que o GFE pudesse selecionar um back-end. O GFE retornou 5xx ao cliente.
  • INVALID_BACKEND: o GFE não conseguiu encontrar um back-end íntegro ao qual atribuir a solicitação, portanto retornou um código de status 5xx ao solicitante.
  • NO_BACKEND_SELECTED: ocorreu um erro ou uma interrupção antes da seleção de um back-end, da ocorrência de um redirecionamento de URL ou do retorno de uma resposta 200 OK de um balanceador de carga de aplicativo clássico com back-ends sem servidor.
  • MULTIPLE_BACKENDS: a solicitação foi disponibilizada possivelmente por vários back-ends. Isso pode acontecer quando o Cloud CDN disponibilizou a solicitação parcialmente no cache e também enviou uma ou mais solicitações de intervalo de bytes para o back-end. Use o detalhamento backend_scope para visualizar cada solicitação de balanceador de carga para back-end.

Quando esse detalhamento é escolhido, os gráficos mostram métricas de back-end (balanceador de carga-para-back-ends), não métricas de front-end (cliente para balanceador de carga).
backend_type

O nome do grupo de back-ends que disponibilizou a solicitação do cliente. Talvez INSTANCE GROUP, NETWORK_ENDPOINT_GROUP, ou UNKNOWN seja retornado se o back-end não tiver sido atribuído. Se nenhum grupo de back-ends estava disponível ou se a solicitação foi disponibilizada por outra entidade, um dos valores a seguir é exibido em vez de um grupo de back-ends.

  • FRONTEND_5XX: ocorreu um erro interno antes que o GFE pudesse selecionar um back-end. O GFE retornou 5xx ao cliente.
  • INVALID_BACKEND: o GFE não conseguiu encontrar um back-end íntegro ao qual atribuir a solicitação, portanto retornou um código de status 5xx ao solicitante.
  • NO_BACKEND_SELECTED: ocorreu um erro ou uma interrupção antes da seleção de um back-end, da ocorrência de um redirecionamento de URL ou do retorno de uma resposta 200 OK de um balanceador de carga de aplicativo clássico com back-ends sem servidor.
  • MULTIPLE_BACKENDS: a solicitação foi disponibilizada possivelmente por vários back-ends. Isso pode acontecer quando o Cloud CDN disponibilizou a solicitação parcialmente no cache e também enviou uma ou mais solicitações de intervalo de bytes para o back-end. Use o detalhamento backend_scope para visualizar cada solicitação de balanceador de carga para back-end.
backend_target_type O nome do serviço de back-end que disponibilizou a solicitação. Pode ser BACKEND_SERVICE, BACKEND_BUCKET, UNKNOWN se o back-end não foi atribuído ou NO_BACKEND_SELECTED se ocorreu um erro ou uma interrupção antes da seleção de um back-end, da ocorrência de um redirecionamento de URL ou do retorno de uma resposta 200 OK de um balanceador de carga de aplicativo clássico com back-ends sem servidor.
matched_url_path_rule A regra do caminho do mapa de URL que correspondeu ao prefixo da solicitação HTTP(S) (até 50 caracteres).
forwarding_rule_name O nome da regra de encaminhamento usada pelo cliente para enviar a solicitação.
url_map_name

A regra do caminho do mapa de URL ou a regra da rota configurada como parte da chave do mapa de URL. Pode ser UNMATCHED ou UNKNOWN como substituto.

  • UNMATCHED refere-se a uma solicitação que não corresponde a qualquer regra do caminho de URL. Portanto, url_map_name usa a regra do caminho padrão.
  • UNKNOWN indica um erro interno.
target_proxy_name O nome objeto do proxy HTTP(S) de destino referenciado pela regra de encaminhamento.
backend_target_name O nome do destino do back-end. O destino pode ser um serviço de back-end ou um bucket de back-end. UNKNOWN será retornado se um back-end não tiver sido atribuído.
backend_name O nome do grupo de instâncias de back-end, do bucket ou do NEG. UNKNOWN será retornado se o back-end não tiver sido atribuído ou NO_BACKEND_SELECTED se ocorrer um erro ou uma interrupção antes da seleção de um back-end, da ocorrência de um redirecionamento de URL ou do retorno de uma resposta 200 OK de um balanceador de carga de aplicativo clássico com back-ends sem servidor.
backend_scope_type

O tipo do escopo do grupo de back-ends. Pode ser GLOBAL, REGION, ZONE, MULTIPLE_BACKENDS ou NO_BACKEND_SELECTED se ocorreu um erro ou interrupção antes da seleção de um back-end, um redirecionamento de URL ou um balanceador de carga de aplicativo clássico com back-ends sem servidor retornou uma resposta 200 OK ou outras saídas possíveis de backend_type.

MULTIPLE_BACKENDS é usado quando é usado armazenamento em cache de blocos. Várias consultas são enviadas ao mesmo back-end para diferentes blocos de dados para dar suporte a uma única solicitação do cliente.
proxy_continent O continente do GFE HTTP(S) que encerrou a conexão HTTP(S): por exemplo, America, Europe, Asia.
protocol Protocolo usado pelo cliente, um entre HTTP/1.0, HTTP/1.1, HTTP/2.0, QUIC/HTTP/2.0, UNKNOWN.
response_code O código de status HTTP da solicitação.
response_code_class A classe de código de status HTTP da solicitação: 200, 300, 400, 500 ou 0 para nenhuma.
cache_result Resultado de cache para disponibilizar a solicitação HTTP por proxy: HIT, MISS, DISABLED, PARTIAL_HIT (para uma disponibilizada parcialmente do cache e parcialmente do back-end), ou UNKNOWN.
client_country País do cliente que emitiu a solicitação HTTP, por exemplo, United States ou Germany.
load_balancing_scheme O esquema de balanceamento de carga usado. Se o balanceador de carga de aplicativo clássico for usado, o valor será EXTERNAL. Se o balanceador de carga de aplicativo externo global for usado, o valor será EXTERNAL_MANAGED.

A seguir