Registos e métricas para colocação em cache

Cada pedido da RFC na nuvem é registado nos Registos na nuvem. Para ver informações sobre como ativar e desativar o registo, consulte a vista geral do registo e da monitorização do balanceador de carga de aplicações externo e do Cloud CDN.

Os registos do Cloud CDN estão associados ao Application Load Balancer externo ao qual os back-ends do Cloud CDN estão anexados. Os registos da RFC são indexados primeiro pela regra de encaminhamento e, em seguida, pelo mapa de URLs.

Para ver os registos da CDN da Google Cloud, siga estes passos.

Consola

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

    Aceda ao Explorador de registos

  2. No menu Recurso, selecione Cloud HTTP Load Balancer.
  3. Veja os registos da seguinte forma:
    • Ver todos os registos: selecione o menu Recurso e, de seguida, selecione Todas as regras de encaminhamento.
    • Ver os registos de uma regra de encaminhamento: selecione o nome da regra de encaminhamento na lista de regras de encaminhamento.
    • Ver os registos de um mapa de URLs usado por uma regra de encaminhamento: selecione uma regra de encaminhamento e, em seguida, selecione um mapa de URLs.

Pedido publicado a partir do back-end

Para confirmar que um pedido é publicado a partir de um back-end com a RFC de multimédia na nuvem ativada, existem três campos principais a procurar, da seguinte forma:

  • httpRequest: quando um pedido é publicado a partir de um back-end, pode ver que a cache está preenchida e pode confirmar o URL do pedido.
    • cacheFillBytes: NUMBER_OF_BYTES
    • cacheLookup: True
    • requestURL: URL
  • jsonPayload: no campo statusDetails, pode confirmar que a resposta foi publicada pelo back-end.
    • statusDetails: "response_sent_by_backend"

Pedido publicado a partir da cache

A entrada de registo seguinte mostra um resultado da cache.

 {
    insertId: "1oek5rg3l3fxj7"
    jsonPayload: {
        @type: "type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry"
        cacheId: "SFO-fbae48ad"
        statusDetails: "response_from_cache"
    }
    httpRequest: {
        requestMethod: "GET"
        requestUrl: "http://LOAD_BALANCER_IP_ADDRESS/static/us/three-cats.jpg"
        requestSize: "577"
        status: 304
        responseSize: "157"
        userAgent: "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.61 Safari/537.36"
        remoteIp: "CLIENT_IP_ADDRESS"
        cacheHit: true
        cacheLookup: true
    }
    resource: {
        type: "http_load_balancer"
        labels: {
            zone: "global"
            url_map_name: "URL_MAP_NAME"
            forwarding_rule_name: "FORWARDING_RULE_NAME"
            target_proxy_name: "TARGET_PROXY_NAME"
            backend_service_name: ""
            project_id: "PROJECT_ID"
        }
    }
    timestamp: "2020-06-08T23:41:30.078651Z"
    severity: "INFO"
    logName: "projects/PROJECT_ID/logs/requests"
    trace: "projects/PROJECT_ID/traces/241d69833e64b3bf83fabac8c873d992"
    receiveTimestamp: "2020-06-08T23:41:30.588272510Z"
    spanId: "7b6537d3672e08e1"
}

O que é registado

Além das informações gerais contidas na maioria dos registos, como a gravidade, o ID do projeto, o número do projeto e a data/hora, os registos do Application Load Balancer externo e do Cloud CDN contêm o seguinte:

  • O campo HttpRequest, que capta o código de estado HTTP, os bytes devolvidos e se foi realizada uma pesquisa na cache ou um preenchimento da cache.

  • O campo jsonPayload.cacheId, que indica a localização e a instância da cache a partir das quais a resposta da cache foi fornecida. Por exemplo, uma resposta da cache servida a partir de uma cache em Amesterdão teria um valor cacheId de AMS-85e2bd4b, em que AMS é o código IATA e 85e2bd4b é um identificador opaco da instância da cache (porque algumas localizações da CDN da nuvem têm várias caches discretas).

  • Os campos statusDetails e cacheDetail do jsonPayload.

Pode filtrar os seguintes campos para determinar o estado de acerto, falha ou revalidação da cache de um pedido publicado pelo Cloud CDN:

  • Resultado da cache

    jsonPayload.statusDetails=("response_from_cache" OR "byte_range_caching")

    ou

    httpRequest.cacheHit=true
    httpRequest.cacheValidatedWithOriginServer!=true

  • Cache Hit Validated With Origin Server

    jsonPayload.statusDetails="response_from_cache_validated"

    ou

    httpRequest.cacheHit=true
    httpRequest.cacheValidatedWithOriginServer=true

  • Cache Miss

    jsonPayload.statusDetails="response_sent_by_backend"

    ou

    httpRequest.cacheHit!=true
    httpRequest.cacheLookup=true

Em alternativa, pode observar o estado da cache do lado do cliente configurando um cabeçalho de resposta personalizado com cdn_cache_status.

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 a estes campos. Os carateres que não são carateres UTF-8 são substituídos por pontos de interrogação.

Quando o Cloud CDN processa um pedido do cliente iniciando pedidos de validação ou pedidos de intervalo de bytes, omite o campo serverIp da entrada de registo do Cloud Logging para o pedido do cliente. Isto acontece porque a CDN da Google Cloud pode enviar pedidos para vários endereços IP de servidores em reação a um único pedido do cliente.

Cada pedido iniciado pela RFC do Google Cloud cria uma entrada de registo do Cloud Logging. A entrada de registo resultante contém um campo parentInsertId no interior de jsonPayload. Pode usar este campo para identificar o insertId da entrada de registo para o pedido de cliente único que levou o Cloud CDN a iniciar o pedido de validação ou o pedido de intervalo de bytes. Além disso, a entrada do registo identifica o Cloud CDN como o agente do utilizador.

Monitorização do Cloud CDN

A RFC exporta dados de monitorização para o Cloud Monitoring. A monitorização é usada para monitorizar o estado de funcionamento de uma implementação do Cloud CDN.

O Cloud Monitoring oferece painéis de controlo predefinidos que são ativados por predefinição para uma análise rápida do estado de funcionamento e do desempenho do sistema. A monitorização também oferece um conjunto de painéis de controlo personalizados. As definições destes painéis de controlo personalizados estão disponíveis no GitHub no repositório monitoring-dashboard-samples como ficheiros JSON. No diretório dashboards/networking, existe um painel de controlo personalizado específico do Cloud CDN denominado cloud-cdn-monitoring.json. Carregue este painel de controlo personalizado para a Monitorização seguindo as instruções em Instalar painéis de controlo de exemplo.

Painéis de controlo predefinidos

O Cloud Monitoring oferece painéis de controlo predefinidos para o Cloud CDN. Estes painéis de controlo apresentam métricas importantes que lhe permitem monitorizar a distribuição do tráfego e a eficácia da cache sem configuração manual.

Veja painéis de controlo predefinidos

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

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

    Aceda ao Cloud CDN

  2. Clique no nome da origem para a qual quer ver os painéis de controlo.

  3. Na página Detalhes de origem, clique em Monitorização.

    Os painéis de controlo predefinidos são apresentados por predefinição.

Métricas nos painéis de controlo

Os painéis de controlo predefinidos fornecem as seguintes métricas principais sobre as origens da RFC:

  • Distribuição do tráfego de clientes

    Um mapa geográfico dinâmico que apresenta a origem dos pedidos de clientes. Este mapa oferece uma vista geral visual e global da origem do tráfego. Pode ajustar o filtro de intervalo de tempo para analisar padrões de distribuição de tráfego em períodos específicos.

  • Métricas principais

    A tabela seguinte descreve as métricas principais apresentadas no painel de controlo.

    Métrica Descrição
    Total de pedidos A contagem agregada de todos os pedidos HTTP/HTTPS processados pela CDN da Google Cloud, publicados a partir da cache ou do serviço de back-end de origem. O gráfico mostra a quantidade de pedidos ao longo do tempo.
    Saída de cache O volume total de dados, em bytes, publicado a partir das caches periféricas da CDN na nuvem. O gráfico de barras mostra o volume de saída ao longo do tempo.
    Rácio de erro total A percentagem de todos os pedidos que resultaram num código de estado de erro 4xx ou 5xx. Esta métrica é um indicador principal do estado geral do serviço.
    Rácio de erros 4xx A percentagem de pedidos que resultaram num código de estado do lado do cliente. Estes são códigos 4xx, como 404 Not Found ou 403 Forbidden. Estes erros indicam problemas com o conteúdo pedido ou as permissões do cliente.
    Rácio de erros 5xx A percentagem de pedidos que resultaram num código de estado do lado do servidor. Estes são códigos 5xx, como 502 Bad Gateway ou 503 Service Unavailable. Estes erros indicam problemas com o serviço de origem de back-end ou a configuração do equilibrador de carga.
    Relação de resultados da cache A relação, em percentagem, dos pedidos apresentados diretamente a partir da cache do Cloud CDN em comparação com o número total de pedidos.
    Preenchimento total da cache O volume total de dados, em bytes, obtidos do back-end de origem e armazenados na cache do Cloud CDN.

Painéis de controlo personalizados

A monitorização permite-lhe criar painéis de controlo personalizados. Os painéis de controlo podem usar qualquer uma das métricas de monitorização para balanceadores de carga de aplicações externos. Seguem-se alguns exemplos de fragmentos de PromQL que pode colar em painéis de controlo de monitorização personalizados.

Pedir a discriminação da contagem de bytes por resultado da cache

Esta consulta centra-se nos back-ends que têm o Cloud CDN ativado, o que é feito incluindo cache_result!="DISABLED".

sum by (cache_result) (
 rate({"loadbalancing.googleapis.com/https/response_bytes_count", monitored_resource="https_lb_rule", cache_result!="DISABLED"}[1m])
)

Latência TCP de ida e volta do cliente a 95% para um alvo de back-end específico

Esta consulta inclui backend_target_name="example-backend", que restringe o tráfego ao back-end example-backend. Um back-end pode ser um contentor do Cloud Storage, um grupo de VMs do Compute Engine ou um back-end externo.

histogram_quantile(
 0.95,
 sum by (proxy_continent, le) (
   rate({"loadbalancing.googleapis.com/https/frontend_tcp_rtt_bucket",
     monitored_resource="https_lb_rule",
     backend_target_name="example-backend"
   }[1m])
 )
)

Contagem de pedidos discriminada por classe de código de resposta para back-ends ativados para a RFC na nuvem

Esta consulta divide o tráfego por classe de código de resposta (2xx, 3xx, 4xx, 5xx) para ajudar a separar os êxitos do cliente, os erros do cliente e os erros do servidor.

sum by (response_code_class) (
 count_over_time(
  {"loadbalancing.googleapis.com/https/request_count",
     monitored_resource="https_lb_rule",
     cache_result!="DISABLED"
   }[1h]
 )
)

Contagem de pedidos discriminada por país de origem

Esta consulta mostra o tráfego discriminado por país de origem, que é determinado através de endereços IP do cliente.

sum by (client_country) (
 rate({"loadbalancing.googleapis.com/https/request_count", monitored_resource="https_lb_rule"}[1m])
)

O que se segue?

  • Para saber mais sobre o registo, incluindo como exportar registos para o BigQuery, o Pub/Sub ou o Cloud Storage, e como configurar métricas baseadas em registos para monitorização e alertas, consulte a documentação do Cloud Logging.

  • Para saber mais acerca dos campos incluídos na entrada do registo httpRequest, consulte HttpRequest.