View log messages for plugins

This page describes Service Extensions logs and how you can view and correlate the information in log messages.

Log messages

Service Extensions supports generating log messages during the execution of your plugin. Recording logs is disabled by default. To record logs for a plugin, enable it while creating the plugin or updating it.

Plugin log records are annotated with the following contextual information:

  • Standard log annotations, such as timestamp and log level.
  • The identity of the plugin that generated the message.
  • The plugin callback in which the log message was generated.
  • A requestId trace identifier that helps determine the request log that a log message is associated with.

Logs that are pertinent to Service Extensions are of one of the following categories:

  • Plugin log messages generated by a logging call, such as info!(...) for Rust or LOG_INFO for C++. Service Extensions exports these log messages to Cloud Logging. You can view these messages under the service.

  • Media CDN log messages for HTTP requests to EdgeCacheService resources with an associated Wasm action. These are regular Media CDN log entries that are viewable under the service.

View log messages

Logs can be viewed by building queries in the Logs Explorer.

You can view plugin logs in the following formats:

  • As standalone Service Extensions logs.

    In this view, each plugin log message is recorded in its own log record and is not automatically associated with request log information.

    These log messages are in the log with the resource type

    The system might also add informational log messages to this log. For example, if there's a plugin failure when a plugin invocation exceeds CPU or memory limits, a message of ERROR severity is logged. Such messages can also be seen in Error Reporting.

  • Correlated with the corresponding Media CDN request logs.

    While viewing request logs, when you expand a request log entry, the plugin logs related to the request appear nested under the request log. This view helps you understand plugin logs in the context of their associated request.

    For more information, see View correlated log entries in the Logs Explorer.

Log samples

Consider a sample Service Extensions log entry. The value of message is passed to the plugin's LOG_INFO call. The severity value depends on the log level used in the plugin log call. In the labels section, the value of is HTTP_REQUEST_HEADER, which indicates that the logged operation is the on_http_request_headers plugin callback.

  "insertId": "65224aac-0000-24bd-a0e1-582429bd544c@a1",
  "jsonPayload": {
    "@type": "",
    "metroIataCode": "ber",
    "proxyRegionCode": "DE",
    "message": "[net/turing/wasm/static_plugins/]::onRequestHeaders() AddHeaderStreamContext::onRequestHeaders called",
    "requestId": "effc0311-6716-431b-9e2a-7586835fdff1"
  "resource": {
    "type": "",
    "labels": {
      "plugin_version": "prod-1",
      "resource_container": "projects/123456789",
      "location": "global",
      "plugin_name": "add-headers-plugin-prod-resource"
  "timestamp": "2023-05-10T03:05:43.317015458Z",
  "severity": "INFO",
  "labels": {
  "logName": "projects/bdn-prober/logs/",
  "trace": "projects/123456789/traces/effc0311-6716-431b-9e2a-7586835fdff1",
  "receiveTimestamp": "2023-05-10T03:05:44.207265284Z"

The related Media CDN log entry appears as follows. The requestId and trace values in both log messages are the same.

  "insertId": "6c95cc54-0000-26ba-ba73-f403043c328c@a1",
  "jsonPayload": {
    "cacheMode": "USE_ORIGIN_HEADERS",
    "@type": "",
    "wasmAction": "add-headers-action-prod-resource",
    "cacheKeyFingerprint": "f04d02bb12f2e79e",
    "proxyStatus": "Google-Edge-Cache",
    "clientCity": "Erlangen",
    "clientAsn": "8881",
    "origin": "example-origin",
    "cacheId": "ber",
    "tlsVersion": "NONE",
    "latency": "0.002840304s",
    "originIp": "",
    "requestId": "effc0311-6716-431b-9e2a-7586835fdff1",
    "clientRegionCode": "DE",
    "originalRequestId": "7656c418-df7c-4ae5-9db5-4f247ec5a82c",
    "httpTtfb": "0.002814903s",
    "metroIataCode": "BER",
    "proxyRegionCode": "DE",
    "cacheStatus": "hit"
  "httpRequest": {
    "requestMethod": "GET",
    "requestUrl": "",
    "requestSize": "1631",
    "status": "200",
    "responseSize": "402907",
    "userAgent": "Wtrace",
    "remoteIp": "2001:1438:1:19::5",
    "protocol": "HTTP/1.1"
  "resource": {
    "type": "",
    "labels": {
      "location": "global",
      "route_destination": "projects/123456789/locations/global/edgeCacheOrigins/example-origin",
      "matched_path": "/turing/",
      "route_type": "ORIGIN",
      "path_matcher_name": "routes",
      "resource_container": "projects/123456789",
      "service_name": "example-service"
  "timestamp": "2023-05-10T03:05:43.321347304Z",
  "logName": "projects/bdn-prober/logs/",
  "trace": "projects/1069774196212/traces/effc0311-6716-431b-9e2a-7586835fdff1",
  "receiveTimestamp": "2023-05-10T03:05:49.919781008Z"


Plugins are limited to logging up to 16 KiB of payload data per client HTTP request. This amount is divided across multiple logging calls that are associated with a given HTTP request. The limit applies only to log message text, not to additional metadata added to the log record by Service Extensions.

For example, if an on_http_request_headers callback makes two logging calls with 4 KiB messages each, and then an on_http_response_headers callback attempts to make three logging calls with 4 KiB messages each for the same HTTP request, the third logging message is dropped. A log message is added to record the number of plugin-generated log messages that were dropped.

What's next