Cloud CDN-Logging und -Monitoring

Jede Anfrage von Cloud CDN wird in Cloud Logging in Logs erfasst. Informationen zum Aktivieren und Deaktivieren von Logging finden Sie unter HTTP(S)-Load-Balancing und Cloud CDN-Logging und -Monitoring.

Logs für Cloud CDN sind mit dem externen HTTP(S)-Load-Balancer verknüpft, an den Ihre Cloud CDN-Back-Ends angehängt sind. Cloud CDN-Logs werden zuerst nach der Weiterleitungsregel und dann nach der URL-Zuordnung indexiert.

So rufen Sie Cloud CDN-Logs auf:

Console

1. Rufen Sie in der Google Cloud Console die Seite Logs-Explorer auf.

   Zur Seite „Log-Explorer“

2. Zum Ansehen aller Logs wählen Sie im ersten Drop-down-Menü in der Zeile Cloud-HTTP-Load-Balancer > Alle Weiterleitungsregeln aus.

3. Um die Logs für nur eine Weiterleitungsregel aufzurufen, wählen Sie eine Weiterleitungsregel aus der Liste aus.

4. Wenn Sie nur Logs für eine URL-Zuordnung ansehen möchten, die von einer Weiterleitungsregel verwendet wird, wählen Sie Cloud-HTTP-Load-Balancer und dann die für Sie relevante Weiterleitungsregel und URL-Zuordnung aus.

Vom Back-End bereitgestellte Anfrage

Es gibt drei Hauptfelder, die Sie darauf prüfen können, ob eine Anfrage von einem Cloud CDN-fähigen Back-End bereitgestellt wird:

• httpRequest: Wenn eine Anfrage von einem Back-End bereitgestellt wird, sehen Sie, dass der Cache gefüllt wird. Auch die Anfrage-URL können Sie bestätigen.
  • cacheFillBytes: NUMBER_OF_BYTES
  • cacheLookup: True
  • requestURL: URL
• jsonPayload: Im Feld statusDetails können Sie bestätigen, dass die Antwort vom Back-End bereitgestellt wurde.
  • statusDetails: "response_sent_by_backend"

Aus dem Cache bereitgestellte Anfrage

Der folgende Logeintrag zeigt einen Cache-Treffer.

 {
    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"
}

Was wird protokolliert?

Zusätzlich zu den in den meisten Logs enthaltenen allgemeinen Informationen wie etwa Wichtigkeit, Projekt-ID, Projektnummer und Zeitstempel enthalten HTTP(S)-Load-Balancing- und Cloud CDN-Logs Folgendes:

• Die HttpRequest-Logfelder, in denen der HTTP-Statuscode und die zurückgegebenen Byte erfasst sind und die angeben, ob eine Cache-Suche und/oder Cache-Füllung durchgeführt wurde.

• Das Feld jsonPayload.cacheId, das den Standort und die Cache-Instanz angibt, von der die Cache-Antwort bereitgestellt wurde. Beispiel: Eine Cache-Antwort, die von einem Cache in Amsterdam bereitgestellt wurde, hätte den cacheId-Wert AMS-85e2bd4b, wobei AMS der IATA-Code und 85e2bd4b eine intransparente Kennzeichnung der Cache-Instanz ist, da manche Cloud CDN-Standorte mehrere separate Caches haben.

• Die Felder statusDetails und cacheDetail der jsonPayload.

Sie können nach den folgenden Feldern filtern, um den Cache-Treffer-, Cache-Fehler- oder Neuvalidierungsstatus einer von Cloud CDN bereitgestellten Anfrage zu bestimmen:

• Cache-Treffer

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

  oder

  httpRequest.cacheHit=true
httpRequest.cacheValidatedWithOriginServer!=true

• Mit Ursprungsserver validierter Cache-Treffer

  jsonPayload.statusDetails="response_from_cache_validated"

  oder

  httpRequest.cacheHit=true
httpRequest.cacheValidatedWithOriginServer=true

• Cache-Fehler

  jsonPayload.statusDetails="response_sent_by_backend"

  oder

  httpRequest.cacheHit!=true
httpRequest.cacheLookup=true

Boolesche Logfelder werden normalerweise nur angezeigt, wenn sie den Wert true haben. Wenn ein boolesches Feld den Wert false hat, wird es nicht im Log ausgegeben.

Für diese Felder wird zwangsweise eine UTF-8-Codierung durchgeführt. Zeichen, bei denen es sich nicht um UTF-8-Zeichen handelt, werden durch Fragezeichen ersetzt.

Wenn Cloud CDN eine Clientanfrage durch Initiieren von Validierungs- und/oder Bytebereichsanfragen bereitstellt, wird das Feld serverIp aus dem Logeintrag von Cloud Logging für die Clientanfrage weggelassen. Dies liegt daran, dass Cloud CDN als Antwort auf eine einzelne Clientanfrage Anfragen an mehrere Server-IP-Adressen senden kann.

Durch jede von Cloud CDN initiierte Anfrage wird außerdem ein Logeintrag in Cloud Logging erstellt. Der resultierende Logeintrag enthält ein Feld parentInsertId innerhalb von jsonPayload. Sie können dieses Feld verwenden, um die insertId des Logeintrags für die einzelne Clientanfrage zu identifizieren, durch die Cloud CDN die Validierungs- oder Bytebereichsanfrage initiiert. Darüber hinaus wird Cloud CDN durch den Logeintrag als User-Agent identifiziert.

Monitoring für Cloud CDN

Cloud CDN exportiert Monitoring-Daten mithilfe von HTTP(S)-Load-Balancing in Cloud Monitoring. Monitoring wird verwendet, um den Zustand einer Cloud CDN-Bereitstellung zu überwachen.

Cloud Monitoring bietet eine Reihe von Dashboard-Definitionen, die auf GitHub im monitoring-dashboard-samples-Repository als JSON-Dateien verfügbar sind. In der Netzwerkdatei gibt es ein Cloud CDN-spezifisches Dashboard mit dem Namen cloud-cdn-monitoring.json. Laden Sie dieses benutzerdefinierte Dashboard in Monitoring hoch. Folgen Sie dazu der Anleitung unter Beispiel-Dashboards installieren.

Hinweis: Das Dashboard filtert keine bestimmten Back-Ends. Der gesamte Load-Balancing-Traffic für alle Back-Ends ist enthalten. Wenn Sie nach einem bestimmten Back-End filtern möchten, müssen Sie filter (resource.backend_target_name = 'my-backend') zur MQL jedes Diagramms hinzufügen. Wenn Sie nur nach Back-Ends filtern möchten, für die Cloud CDN aktiviert ist, fügen Sie filter (metric.cache_result!= 'DISABLED') ein.

Cloud CDN-Beispielabfragen überwachen

Mit Monitoring können Sie benutzerdefinierte Dashboards erstellen. Dashboards können alle Monitoringmesswerte für externe HTTP(S)-Load-Balancer verwenden. Im Folgenden finden Sie einige Beispiele für MQL-Snippets, die Sie in benutzerdefinierte Monitoring-Dashboards einfügen können.

Anzahl der Anfragebyte nach Cache-Ergebnis aufgeschlüsselt

Diese Abfrage konzentriert sich auf Back-Ends, für die Cloud CDN aktiviert ist. Dies geschieht durch Einbinden von 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)]

Client-Roundtrip-TCP-Latenz bei 95% für ein bestimmtes Back-End-Ziel

Diese Abfrage enthält filter (resource.backend_target_name = 'example-backend'), wodurch der Traffic auf das Back-End example-backend eingeschränkt wird. Ein Back-End kann ein Cloud Storage-Bucket, eine Compute Engine-VM-Gruppe oder ein externes Back-End sein.

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)]

Anzahl der Anfragen nach Antwortcodeklasse für Cloud CDN-fähige Back-Ends aufgeschlüsselt

Diese Abfrage schlüsselt den Traffic nach der Antwortcodeklasse (2xx, 3xx, 4xx, 5xx) auf, um die Clienterfolge, Clientfehler und Serverfehler zu trennen.

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)]

Anzahl der Anfragen nach Herkunftsland aufgeschlüsselt

In dieser Abfrage wird der Traffic nach dem Herkunftsland aufgeschlüsselt, das mithilfe von Client-IP-Adressen bestimmt wird.

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)]

Nächste Schritte

• Weitere Informationen zum Logging, einschließlich zum Exportieren von Logs nach BigQuery, Pub/Sub oder Cloud Storage sowie zum Konfigurieren logbasierter Messwerte für das Monitoring und Benachrichtigungen, finden Sie in der Dokumentation zu Cloud Logging.

• Informationen zu den im Logeintrag httpRequest enthaltenen Feldern finden Sie unter HttpRequest.