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

Cada pedido do Cloud CDN é 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 na nuvem 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 Cloud 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 fornece um conjunto de definições de painéis de controlo disponíveis no GitHub no repositório monitoring-dashboard-samples como ficheiros JSON. No diretório dashboards/networking, existe um painel de controlo específico da RFC na nuvem 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.

Nota: o painel de controlo não filtra nenhum back-end específico. Todo o tráfego de equilíbrio de carga para todos os back-ends está incluído. Para filtrar por um back-end específico, tem de adicionar backend_target_name="example-backend" à consulta PromQL de cada gráfico. Além disso, para filtrar apenas os back-ends com o Cloud CDN ativado, inclua cache_result!="DISABLED".

Monitorização de consultas de exemplo do Cloud CDN

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.