Journaux et métriques pour la mise en cache

Chaque requête Cloud CDN est consignée dans Cloud Logging. Pour en savoir plus sur l'activation et la désactivation de la journalisation, consultez la page Présentation de la journalisation et de la surveillance de l'équilibreur de charge d'application externe et de Cloud CDN.

Les journaux de Cloud CDN sont associés à l'équilibreur de charge d'application externe auquel vos backends Cloud CDN sont rattachés. Les journaux Cloud CDN sont d'abord indexés par règle de transfert, puis par mappage d'URL.

Pour afficher les journaux Cloud CDN, procédez comme suit.

Console

1. Dans Google Cloud Console, accédez à la page Explorateur de journaux.

   Accéder à l'explorateur de journaux

2. Dans le menu Ressource, sélectionnez Équilibreur de charge HTTP Cloud.
3. Affichez les journaux comme suit :
   • Afficher tous les journaux:sélectionnez le menu Ressource, puis Toutes les règles de transfert.
   • Afficher les journaux d'une règle de transfert:sélectionnez le nom de la règle de transfert dans la liste des règles de transfert.
   • Afficher les journaux d'un mappage d'URL utilisé par une règle de transfert:sélectionnez une règle de transfert, puis un mappage d'URL.

Requête diffusée à partir du backend

Pour confirmer qu'une requête est diffusée à partir d'un backend compatible avec Cloud CDN, vous devez rechercher trois champs principaux, comme suit :

• httpRequest : Lorsqu'une requête est diffusée à partir d'un backend, vous pouvez constater que le cache est rempli et vous pouvez confirmer l'URL de la requête.
  • cacheFillBytes: NUMBER_OF_BYTES
  • cacheLookup: True
  • requestURL : URL
• jsonPayload : dans le champ statusDetails, vous pouvez confirmer que la réponse a été diffusée à partir du backend.
  • statusDetails: "response_sent_by_backend"

Requête diffusée à partir du cache

L'entrée de journal suivante montre un succès de 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"
}

Contenu consigné

Outre les informations générales contenues dans la plupart des journaux telles que la gravité, l'ID de projet, le numéro de projet et l'horodatage, les journaux d'équilibreur de charge d'application externe et de Cloud CDN contiennent les éléments suivants:

• Le champ de journal HttpRequest, qui enregistre le code d'état HTTP, le nombre d'octets renvoyés et si une recherche dans le cache ou un remplissage de cache ont été effectués.

• Le champ jsonPayload.cacheId, qui indique l'emplacement et l'instance de cache à partir desquels la réponse de cache a été diffusée. Par exemple, une réponse de cache diffusée à partir d'un cache situé à Amsterdam aura une valeur "cacheId" de AMS-85e2bd4b, où AMS correspond au code IATA et 85e2bd4b est un identifiant opaque de l'instance de cache (car certains emplacements Cloud CDN possèdent plusieurs caches distincts).

• Les champs statusDetails et cacheDetail de jsonPayload.

Vous pouvez filtrer ces champs pour déterminer l'état de succès (hit), de défaut (miss) ou de revalidation de cache d'une requête diffusée par Cloud CDN :

• Succès de cache (hit)

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

  ou

  httpRequest.cacheHit=true
httpRequest.cacheValidatedWithOriginServer!=true

• Succès de cache (hit) validé avec le serveur d'origine

  jsonPayload.statusDetails="response_from_cache_validated"

  ou

  httpRequest.cacheHit=true
httpRequest.cacheValidatedWithOriginServer=true

• Défaut de cache (miss)

  jsonPayload.statusDetails="response_sent_by_backend"

  ou

  httpRequest.cacheHit!=true
httpRequest.cacheLookup=true

Vous pouvez également observer l'état du cache côté client en configurant un en-tête de réponse personnalisé avec cdn_cache_status.

Les champs de journal de type booléen n'apparaissent généralement que s'ils comportent la valeur true. Si un champ booléen a la valeur false, il est omis du journal.

Le codage UTF-8 est appliqué pour ces champs. Les caractères qui ne sont pas au format UTF-8 sont remplacés par des points d'interrogation.

Lorsque Cloud CDN diffuse une requête client en initiant des requêtes de validation ou des requêtes de plage d'octets, il omet le champ serverIp de l'entrée de journal Cloud Logging correspondant à la requête client. En effet, Cloud CDN peut envoyer des requêtes à plusieurs adresses IP de serveur en réponse à une requête client unique.

Chaque requête initiée par Cloud CDN crée une entrée de journal Cloud Logging. L'entrée de journal obtenue contient un champ parentInsertId dans jsonPayload. Ce champ permet d'identifier le champ insertId de l'entrée de journal pour la requête client unique qui a invité Cloud CDN à lancer la requête de validation ou la requête de plage d'octets. En outre, l'entrée de journal identifie Cloud CDN en tant qu'entité user-agent.

Monitoring pour Cloud CDN

Cloud CDN exporte les données de surveillance vers Cloud Monitoring. Monitoring est utilisée pour surveiller l'état d'un déploiement Cloud CDN.

Cloud Monitoring fournit un ensemble de définitions de tableau de bord disponible sur GitHub dans le dépôt monitoring-dashboard-samples sous forme de fichiers JSON. Le fichier de mise en réseau contient un tableau de bord propre à Cloud CDN appelé cloud-cdn-monitoring.json. Importez ce tableau de bord personnalisé dans Monitoring en suivant les instructions de la page Installer des exemples de tableaux de bord.

Remarque : Le tableau de bord ne filtre aucun backend spécifique. Tout le trafic d'équilibrage de charge de l'ensemble des backends est inclus. Pour filtrer un backend spécifique, vous devez ajouter filter (resource.backend_target_name = 'my-backend') à la requête MQL (Monitoring Query Language) de chaque graphique. En outre, pour filtrer uniquement les backends sur lesquels Cloud CDN est activé, incluez filter (metric.cache_result!= 'DISABLED').

Exemples de requêtes Monitoring pour Cloud CDN

Monitoring vous permet de créer des tableaux de bord personnalisés. Les tableaux de bord peuvent utiliser n'importe quelle métrique de surveillance pour les équilibreurs de charge d'application externes. Voici quelques exemples d'extraits MQL que vous pouvez coller dans des tableaux de bord Monitoring personnalisés.

Nombre d'octets de requête répartis par résultat de cache

Cette requête porte sur les backends sur lesquels Cloud CDN est activé. Elle est exécutée en incluant le filtre filter (metric.cache_result != 'DISABLED').

fetch https_lb_rule
| metric 'loadbalancing.googleapis.com/https/response_bytes_count'
| filter (metric.cache_result != 'DISABLED')
| align rate(1m)
| every 1m
| group_by [metric.cache_result],
    [value_response_bytes_count_aggregate:
       aggregate(value.response_bytes_count)]

Latence TCP aller-retour client à 95 % pour une cible de backend spécifique

Cette requête inclut filter (resource.backend_target_name = 'example-backend'), qui limite le trafic vers le backend example-backend. Un backend peut être un bucket Cloud Storage, un groupe de VM Compute Engine ou un backend externe.

fetch https_lb_rule
| metric 'loadbalancing.googleapis.com/https/frontend_tcp_rtt'
| filter (resource.backend_target_name = 'example-backend')
| group_by 1m,
    [value_frontend_tcp_rtt_aggregate: aggregate(value.frontend_tcp_rtt)]
| every 1m
| group_by [metric.proxy_continent],
    [value_frontend_tcp_rtt_aggregate_percentile:
       percentile(value_frontend_tcp_rtt_aggregate, 95)]

Nombre de requêtes réparties par classe de code de réponse pour les backends compatibles avec Cloud CDN

Cette requête répartit le trafic par classe de code de réponse (2xx, 3xx, 4xx, 5xx) pour aider à distinguer les réussites des clients, les erreurs client et les erreurs de serveurs.

fetch https_lb_rule
| metric 'loadbalancing.googleapis.com/https/request_count'
| filter (metric.cache_result != 'DISABLED')
| group_by 1h, [row_count: row_count()]
| every 1h
| group_by [metric.response_code_class],
    [row_count_aggregate: aggregate(row_count)]

Nombre de requêtes réparties par pays d'origine

Cette requête affiche le trafic réparti par pays d'origine, déterminé à l'aide des adresses IP clientes.

fetch https_lb_rule
| metric 'loadbalancing.googleapis.com/https/request_count'
| align rate(1m)
| every 1m
| group_by [metric.client_country], [value_request_count_aggregate: aggregate(value.request_count)]

Étapes suivantes

• Consultez la documentation Cloud Logging pour en savoir plus sur la journalisation, y compris sur l'exportation de journaux vers BigQuery, Pub/Sub ou Cloud Storage, et sur la configuration de métriques basées sur les journaux pour la surveillance et les alertes.

• Consultez la section HttpRequest pour en savoir plus sur les champs inclus dans l'entrée de journal httpRequest.