Logging
You can enable, disable, and view logs for an external Application Load Balancer backend service . For external Application Load Balancers with backend buckets , logging is automatically enabled and cannot be disabled.
You enable or disable logging for each backend service. You can configure whether to log all requests or a randomly sampled fraction.
You must ensure that you don't have a logs exclusion that applies to
external Application Load Balancers. For instructions about how to verify that Cloud HTTP Load
Balancer
logs are allowed, see Viewing resource-type
exclusions
.
Enabling logging on a new backend service
Console
-
In the Google Cloud console, go to the Load Balancingpage.
-
Click the name of your load balancer.
-
Click Edit.
-
Click Backend Configuration.
-
Select Create a backend service.
-
Complete the required backend service fields.
-
In the Loggingsection, select the Enable loggingcheckbox.
-
In the Sample ratefield, set the sampling probability. You can set a number from
0.0
through1.0
, where0.0
means that no requests are logged and1.0
means that 100% of the requests are logged. The default value is1.0
. -
To finish editing the backend service, click Update.
-
To finish editing the load balancer, click Update.
gcloud: Global mode
Create a backend service and enable logging by using the gcloud compute backend-services create
command
.
gcloud compute backend-services create BACKEND_SERVICE \ --global \ --enable-logging \ --logging-sample-rate= VALUE \ --load-balancing-scheme=EXTERNAL_MANAGED
where
-
--global
indicates that the backend service is global. Use this field for backend services used with global external Application Load Balancers. -
--enable-logging
enables logging for that backend service. -
--logging-sample-rate
lets you specify a value from0.0
through1.0
, where0.0
means that no requests are logged and1.0
means that 100% of the requests are logged. Only meaningful with the--enable-logging
parameter. Enabling logging but setting the sampling rate to0.0
is equivalent to disabling logging. The default value is1.0
.
gcloud: Classic mode
Create a backend service and enable logging by using the gcloud compute backend-services create
command
.
gcloud compute backend-services create BACKEND_SERVICE \ --global \ --enable-logging \ --logging-sample-rate= VALUE \ --load-balancing-scheme=EXTERNAL
where
-
--global
indicates that the backend service is global. Use this field for backend services used with a classic Application Load Balancer. -
--enable-logging
enables logging for that backend service. -
--logging-sample-rate
lets you specify a value from0.0
through1.0
, where0.0
means that no requests are logged and1.0
means that 100% of the requests are logged. Only meaningful with the--enable-logging
parameter. Enabling logging but setting the sampling rate to0.0
is equivalent to disabling logging. The default value is1.0
.
Enabling logging on an existing backend service
Console
-
In the Google Cloud console, go to the Load Balancingpage.
-
Click the name of your load balancer.
-
Click Edit.
-
Click Backend Configuration.
-
Click Editnext to your backend service.
-
In the Loggingsection, select the Enable loggingcheckbox.
-
In the Sample ratefield, set the sampling probability. You can set a number from
0.0
through1.0
, where0.0
means that no requests are logged and1.0
means that 100% of the requests are logged. The default value is1.0
. -
To finish editing the backend service, click Update.
-
To finish editing the load balancer, click Update.
gcloud: Global mode
Enable logging on an existing backend service with the gcloud compute backend-services update
command
.
gcloud compute backend-services update BACKEND_SERVICE \ --global \ --enable-logging \ --logging-sample-rate= VALUE
where
-
--global
indicates that the backend service is global. Use this field for backend services used with global external Application Load Balancers. -
--enable-logging
enables logging for that backend service. -
--logging-sample-rate
lets you specify a value from0.0
through1.0
, where0.0
means that no requests are logged and1.0
means that 100% of the requests are logged. Only meaningful with the--enable-logging
parameter. Enabling logging but setting the sampling rate to0.0
is equivalent to disabling logging. The default value is1.0
.
gcloud: Classic mode
Enable logging on an existing backend service with the gcloud compute backend-services update
command
.
gcloud compute backend-services update BACKEND_SERVICE \ --global \ --enable-logging \ --logging-sample-rate= VALUE
where
-
--global
indicates that the backend service is global. Use this field for backend services used with a classic Application Load Balancer. -
--enable-logging
enables logging for that backend service. -
--logging-sample-rate
lets you specify a value from0.0
through1.0
, where0.0
means that no requests are logged and1.0
means that 100% of the requests are logged. Only meaningful with the--enable-logging
parameter. Enabling logging but setting the sampling rate to0.0
is equivalent to disabling logging. The default value is1.0
.
Disabling or modifying logging on an existing backend service
Console
-
In the Google Cloud console, go to the Load Balancingpage.
-
Click the name of your load balancer.
-
Click Edit.
-
Click Backend Configuration.
-
Click Editnext to your backend service.
-
To disable logging entirely, in the Loggingsection, clear the Enable loggingcheckbox.
-
If you leave logging enabled, you can set a different sampling probability in the Sample ratefield. You can set a number from
0.0
through1.0
, where0.0
means that no requests are logged and1.0
means that 100% of the requests are logged. The default value is1.0
. To reduce the number of stored logs to 20%, set the value to0.2
. -
To finish editing the backend service, click Update.
-
To finish editing the load balancer, click Update.
gcloud: Global mode
Disable logging on a backend service with the gcloud compute backend-services update
command
.
Disabling logging entirely
gcloud compute backend-services update BACKEND_SERVICE \ --global \ --no-enable-logging
where
-
--global
indicates that the backend service is global. Use this field for backend services used with global external Application Load Balancers. -
--region
indicates that the backend service is regional. Use this field for backend services used with regional external Application Load Balancers. -
--no-enable-logging
disables logging for that backend service.
Modifying the logging sample rate
gcloud compute backend-services update BACKEND_SERVICE \ --global \ --logging-sample-rate= VALUE
gcloud: Classic mode
Disable logging on a backend service with the gcloud compute backend-services update
command
.
Disabling logging entirely
gcloud compute backend-services update BACKEND_SERVICE \ --global \ --no-enable-logging
where
-
--global
indicates that the backend service is global. Use this field for backend services used with a classic Application Load Balancer. -
--no-enable-logging
disables logging for that backend service.
Modifying the logging sample rate
gcloud compute backend-services update BACKEND_SERVICE \ --global \ --logging-sample-rate= VALUE
where
-
--global
indicates that the backend service is global. Use this field for backend services used with a classic Application Load Balancer. -
--logging-sample-rate
lets you specify a value from0.0
through1.0
, where0.0
means that no requests are logged and1.0
means that 100% of the requests are logged. Only meaningful with the--enable-logging
parameter. Enabling logging but setting the sampling rate to0.0
is equivalent to disabling logging.
View logs
To follow step-by-step guidance for this task directly in the Google Cloud console, click Guide me :
HTTP(S) logs are indexed first by a forwarding rule , then by a URL map .
To view logs, go to the Logs Explorerpage:
-
To view all logs, in the Resourcefilter menu, select Cloud HTTP Load Balancer > All forwarding rules.
-
To view logs for one forwarding rule, select a single forwarding rule name.
-
To view logs for one URL map, select a forwarding rule, and then select a URL map.
Log fields of type boolean
typically only appear if they have a value of true
.
If a boolean field has a value of false
, that field is omitted from the log.
UTF-8
encoding
is enforced for log fields. Characters that are not UTF-8
characters are replaced with question marks. For classic Application Load Balancers and global external Application Load Balancers,you can export logs-based metrics
using
resource logs ( resource.type="http_load_balancer"
). The metrics
created are based on the "Application Load Balancer Rule
(Logs-based Metrics)" resource ( l7_lb_rule
), which is available under
Cloud Monitoring dashboards instead of under the https_lb_rule
resource.
What is logged
External Application Load Balancer log entries contain information useful for monitoring and debugging your HTTP(S) traffic. Log records contain required fields, which are the default fields of every log record.
string ( Timestamp
format)
HttpRequest.protocol
is not populated for resource.type="http_load_balancer"
The MonitoredResource is the resource type associated with a log entry.
The MonitoredResourceDescriptor
describes the schema of a MonitoredResource
object by
using a type name and a set of labels. For more information,
see Resource labels
.
-
statusDetails
-
backendTargetProjectNumber
-
overrideResponseCode
-
errorService
-
errorBackendStatusDetails
statusDetails
field
holds a string that explains why the load balancer returned
the HTTP status that it did. For more information about these log strings,
see statusDetails HTTP success messages
and statusDetails HTTP failure messages
.backendTargetProjectNumber
field holds the project
number where the backend target—backend service or backend
bucket—has been created. This field is in the format: "projects/ PROJECT_NUMBER
"
. This information is
only available for global external Application Load Balancers using custom error
responses
.overrideResponseCode
holds the override response code
applied to the response sent to the client. This information is
only available for global external Application Load Balancers using custom error
responses
.errorService
field holds the backend service that
provided the custom error response. This information is
only available for global external Application Load Balancers using custom error
responses
.errorBackendStatusDetails
field holds the statusDetails
of the final response served to the client.
This information is only available for global external Application Load Balancers using custom error
responses
.Resource labels
The following table lists the resource labels for resource.type="http_load_balancer"
.
Field | Type | Description |
---|---|---|
backend_service_name
|
string | The name of the backend service. |
forwarding_rule_name
|
string | The name of the forwarding rule object. |
project_id
|
string | The identifier of the Google Cloud project associated with this resource. |
target_proxy_name
|
string | The name of the target proxy object referenced by the forwarding rule. |
url_map_name
|
string | The name of the URL map object configured to select a backend service. |
zone
|
string | The zone in which the load
balancer is running. The zone is global
. |
statusDetails HTTP success messages
statusDetails (successful) | Meaning | Common accompanying response codes |
---|---|---|
byte_range_caching
|
The HTTP request was served using Cloud CDN byte range caching . | Any cacheable response code is possible. |
response_from_cache
|
The HTTP request was served from a Cloud CDN cache. | Any cacheable response code is possible. |
response_from_cache_validated
|
The return code was set from a Cloud CDN cached entry that was validated by a backend. | Any cacheable response code is possible. |
response_sent_by_backend
|
The HTTP request was proxied successfully to the backend, and the response was returned by the backend. | The HTTP response code is set by the software running on the backend. |
statusDetails HTTP failure messages
aborted_request_due_to_backend_early_response
backend_connection_closed_after_partial_response_sent
The HTTP response code is set by the software running on the backend. HTTP response code 0 (zero) means that the backend sent incomplete HTTP headers.
The HTTP response code is 101 if the HTTP(S) connection was upgraded to a websocket connection.
backend_connection_closed_before_data_sent_to_client
502, 503
The HTTP response code is 101 if the HTTP(S) connection was upgraded to a websocket connection.
backend_early_response_with_non_error_status
backend_interim_response_not_supported
502, 503
backend_response_corrupted
backend_response_headers_too_long
backend_timeout
The backend timed out while generating a response.
For a websocket connection:
- For global external Application Load Balancer, an error is generated when the GFE closes the websocket connection in idle state after the backend service timeout expires.
- For classic Application Load Balancer, an error is generated when the GFE closes the websocket connection in either idle or active state, after the backend service timeout expires.
502, 503
The HTTP response code is 101 if the HTTP(S) connection was upgraded to a websocket connection.
banned_by_security_policy
body_not_allowed
byte_range_caching_aborted
byte_range_caching_forwarded_backend_response
Returned from the backend—any response code is possible.
byte_range_caching_retrieval_abandoned
Returned from the backend—any response code is possible.
byte_range_caching_retrieval_from_backend_failed_after_partial_response
cache_lookup_failed_after_partial_response
cache_lookup_timeout_after_partial_response
client_disconnected_after_partial_response
Returned from the backend—any response code is possible.
The HTTP response code is 101 if the HTTP(S) connection was upgraded to a websocket connection.
client_disconnected_before_any_response
0
The HTTP response code is 101 if the HTTP(S) connection was upgraded to a websocket connection.
client_timed_out
client_cert_invalid_rsa_key_size
client_cert_unsupported_elliptic_curve_key
client_cert_unsupported_key_algorithm
client_cert_pki_too_large
client_cert_chain_max_name_constraints_exceeded
client_cert_chain_invalid_eku
Extended Key Usage
(EKU) that includes clientAuth
. For more information, see Logged errors for closed connections
.client_cert_validation_timed_out
client_cert_validation_search_limit_exceeded
client_cert_validation_not_performed
TrustConfig
.
For more information, see Logged errors for closed connections
.client_cert_not_provided
client_cert_validation_failed
TrustConfig
when hashing algorithms such as MD4, MD5, and SHA-1 are used.
For more information, see Logged errors for closed connections
.config_not_found
The load balancer is missing project configuration. This might occur intermittently, especially after you've made configuration changes that add a new resource.
As there are two layers of proxies, sometimes, the first-layer GFE might fail to reach the second-layer GFE. This could be due to an internal error, such as an in-progress rollout, a load balancer overload, or intermittent configuration issues.
direct_response
denied_by_security_policy
error_uncompressing_gzipped_body
failed_to_connect_to_backend
failed_to_pick_backend
failed_to_negotiate_alpn
headers_too_long
http_version_not_supported
internal_error
invalid_external_origin_endpoint
invalid_request_headers
The HTTP request headers received from a client contain at least one character that isn't allowed under an applicable HTTP specification.
For example, header field names that include a double quotation mark
( "
) or any characters outside of the standard
ASCII range (that is, any byte >= 0x80
) are invalid.
For more information, see:
invalid_http2_client_header_format
invalid_request_headers
.multiple_iap_policies
malformed_chunked_body
request_loop_detected
required_body_but_no_content_length
secure_url_rejected
ssl_certificate_san_verification_failed
ssl_certificate_chain_verification_failed
throttled_by_security_policy
unsupported_method
unsupported_100_continue
upgrade_header_rejected
websocket_closed
websocket_handshake_failed
request_body_too_large
handled_by_identity_aware_proxy
serverless_neg_routing_failed
fault_filter_abort
View logs for mTLS client certificate validation
To view the logged errors for closed connections during mutual TLS client certificate validation, complete the following steps.
Console query
-
In the Google Cloud console, go to the Logs Explorer page.
-
Click the Show querytoggle.
-
Paste the following into the query field. Replace
FORWARDING_RULE_NAME
with the name of your forwarding rule.jsonPayload.statusDetails=~"client_cert" jsonPayload.@type="type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry" resource.labels.forwarding_rule_name= FORWARDING_RULE_NAME
-
Click Run query.
Authorization policy request logs
The authz_info
object in the Load Balancer Log Entry JSON payload contains
information about authorization policies. You can configure log-based metrics
for traffic allowed or denied by these policies.
authz_info.policies[]
authz_info.policies[].name
The name is empty for the following reasons:
- No
ALLOW
policy matches the request and the request is denied. - No
DENY
policy matches the request and the request is allowed.
authz_info.policies[].result
ALLOWED
or DENIED
.authz_info.policies[].details
-
allowed_as_no_deny_policies_matched_request
-
denied_as_no_allow_policies_matched_request
-
denied_by_authz_extension
-
denied_by_cloud_iap
authz_info.overall_result
ALLOWED
or DENIED
.Logging for backend buckets
Logging is automatically enabled for load balancers with backend buckets. You cannot modify or disable logging for backend buckets .
Logging for Google Cloud Armor
The table for statusDetail
HTTP failure messages contains some messages that
apply to Google Cloud Armor. For more information about what
Google Cloud Armor logs, see Using request logging
.
Logging for Shared VPC deployments
Application Load Balancer logs and metrics are typically exported to the project that has the forwarding rule. Therefore, service admins—owners or users of projects where the backend service is created—won't have access to the load balancer's logs and metrics by default. You can use IAM roles to grant these permissions to service admins. To learn more about the IAM roles that are available, and the steps to provide access, see Grant access to Monitoring .
Interacting with the logs
You can interact with the external Application Load Balancer logs by using the Cloud Logging API. The Logging API provides ways to interactively filter logs that have specific fields set. It exports matching logs to Cloud Logging, Cloud Storage, BigQuery, or Pub/Sub. For more information about the Logging API, see Cloud Logging API overview .
Monitoring
The load balancer exports monitoring data to Cloud Monitoring .
You can use monitoring metrics to do the following:
- Evaluate a load balancer's configuration, usage, and performance
- Troubleshoot problems
- Improve resource utilization and user experience
In addition to the predefined dashboards in Cloud Monitoring, you can create custom dashboards, set up alerts, and query the metrics through the Cloud Monitoring API .
Viewing predefined Cloud Monitoring dashboards
Cloud Monitoring provides predefined dashboards to monitor your load balancers. These dashboards are automatically populated by Cloud Monitoring.
Perform the following steps to access the predefined dashboards:
-
Go to Monitoringin the Google Cloud console.
-
In the Monitoring navigation panel, click Dashboards.
-
Under Categories, click GCP.
-
To view a list of dashboards for all your Google Cloud load balancers, select the dashboard named Google Cloud Load Balancers. To view a specific load balancer's dashboard, locate the load balancer in the list and click its name.
-
To view the predefined dashboards for only your external Application Load Balancers, select the dashboard named External HTTP(S) Load Balancers. This page displays a dashboard that shows the 5XX response ratios and backend latency for all external Application Load Balancers in your project. It also provides a list of dashboards for all the external Application Load Balancers in your project.
You can click through to each load balancer's dashboard. Each dashboard includes the following:- Pre-populated graphs that display breakdowns for responses by response code classes (5XX, 4XX, 3XX, 2XX)
- Total latency
- Backend latency
- Frontend RTT
- Request count
- A link to the logs for the load balancer
-
-
To view dashboards for third-party services, go back to the Dashboardspage. Under Categories, click Other.
- To view a specific third-party service dashboard, locate it in the list and click its name.
Defining alerting policies
To follow step-by-step guidance for this task directly in the Google Cloud console, click Guide me :
You can create alerting policies to monitor the values of metrics and to notify you when those metrics violate a condition.
-
In the Google Cloud console, go to the notifications Alerting page:
If you use the search bar to find this page, then select the result whose subheading is Monitoring .
- If you haven't created your notification channels and if you want to be notified, then click Edit Notification Channels and add your notification channels. Return to the Alerting page after you add your channels.
- From the Alerting page, select Create policy .
- To select the metric, expand the Select a metric
menu and then do the following:
- To limit the menu to relevant entries, enter
Global External Application Load Balancer Rule
into the filter bar. If there are no results after you filter the menu, then disable the Show only active resources & metrics toggle. - For the Resource type , select Global External Application Load Balancer Rule .
- Select a Metric category and a Metric , and then select Apply .
- To limit the menu to relevant entries, enter
- Click Next .
- The settings in the Configure alert trigger page determine when the alert is triggered. Select a condition type and, if necessary, specify a threshold. For more information, see Create metric-threshold alerting policies .
- Click Next .
- Optional: To add notifications to your alerting policy, click Notification channels . In the dialog, select one or more notification channels from the menu, and then click OK .
- Optional: Update the Incident autoclose duration . This field determines when Monitoring closes incidents in the absence of metric data.
- Optional: Click Documentation , and then add any information that you want included in a notification message.
- Click Alert name and enter a name for the alerting policy.
- Click Create Policy .
Defining Cloud Monitoring custom dashboards
You can create custom Cloud Monitoring dashboards for the load balancer's metrics:
-
In the Google Cloud console, go to the Monitoringpage.
-
Select Dashboards > Create Dashboard.
-
Click Add Chart, and then give the chart a title.
-
To identify the time series to be displayed, choose a resource type and metric type:
- In the Resource & Metricsection, click the chart, and then
in the Select a metricsection, select from the available options:
- For a global external Application Load Balancer, select the resource type Global External Application Load Balancer Rule.
- Click Apply.
- In the Resource & Metricsection, click the chart, and then
in the Select a metricsection, select from the available options:
-
To specify monitoring filters, click Filters > Add filter.
-
Click Save.
Metric reporting frequency and retention
Metrics for the external Application Load Balancers are exported to Cloud Monitoring in 1-minute granularity batches. Monitoring data is retained for six (6) weeks.
The dashboard provides data analysis in default intervals of 1H (one hour), 6H (six hours), 1D (one day), 1W (one week), and 6W (six weeks). You can manually request analysis in any interval from 6W to 1 minute.
Monitoring metrics
You can monitor the following metrics for external Application Load Balancers.
The following metrics for global external Application Load Balancers are reported into Cloud Monitoring
.
These metrics are prepended with loadbalancing.googleapis.com/
.
https/request_count
https/request_bytes_count
https/response_bytes_count
https/total_latencies
A distribution of the latency. Latency is the time between the first byte of the request received to the last byte of the response sent by the GFE.
Total latencies are measured by request/response. Pauses between requests
on the same connection that use Connection: keep-alive
do not
affect the measurement. This measurement is typically reduced to the 95th
percentile in Cloud Monitoring views.
For websocket connections, this field refers to the entire time duration of the connection. †
Example: A load balancer has 1 request per second from the UK, all with 100 ms latency, and 9 requests per second from the US, all with 50 ms latency. Over a certain minute there were 60 requests from the UK and 540 requests from the US. Monitoring metrics preserves the distribution over all dimensions. You can request information such as the following:
- median overall latency (300/600) - 50 ms
- median UK latency (30/60) - 100 ms
- 95th percentile overall latency (570/600) - 100 ms
https/frontend_tcp_rtt
https/backend_latencies
A distribution of the latency measured from when the first request byte was sent by the GFE to the backend, until the GFE received from the backend the last byte of the response.
For websocket connections, backend latencies apply to the entire duration of the websocket session. †
https/backend_request_count
https/backend_request_bytes_count
https/backend_response_bytes_count
* The sum of Frontend RTT and Backend latencies is not guaranteed to be less than or equal to Total latencies. This is because although we poll RTT over the socket from the GFE to the client at the time the HTTP response is ACKed, we rely on kernel reporting for some of these measurements, and we cannot guarantee that the kernel will have an RTT measurement for the given HTTP response. The end result is a smoothed RTT value that is also affected by previous HTTP responses, SYN/ACKs, and SSL handshakes that aren't affecting current HTTP request actual timings.
† For monitoring websocket connections, create a backend service specifically for websockets.
Filtering dimensions for metrics
You can apply filters for metrics for external Application Load Balancers.
Metrics are aggregated for each classic Application Load Balancer and global external Application Load Balancer. You can filter
aggregated metrics by the following dimensions for resource.type="http_load_balancer"
or resource.type="https_lb_rule"
. Note
that not all dimensions are available on all metrics.
backend_scope
If no instance group was available or if the request was served by another entity, you will see one of the following values instead of the region or zone of the backend service instance group.
- FRONTEND_5XX - An internal error occurred before the GFE could select a backend. The GFE returned `5XX` to the client.
- INVALID_BACKEND - The GFE couldn't find a healthy backend to assign the request to, so it returned a `5XX` response to the requestor.
- NO_BACKEND_SELECTED - An error or other interruption occurred before a backend could be selected or a URL redirect happened.
- MULTIPLE_BACKENDS - The request was served by potentially multiple
backends. This can happen when Cloud CDN has served the request
partially from its cache and has also sent one or more byte range
requests
to the backend. Use the
backend_scope
breakdown to visualize each load balancer-to-backend request.
When this breakdown is chosen, the charts show backend metrics (load balancer-to-backends), not frontend metrics (client-to-load balancer).
backend_type
The name of the backend group that served the client's request.
Can be INSTANCE GROUP
, NETWORK_ENDPOINT_GROUP
,
or UNKNOWN
is returned if the backend wasn't assigned.
If no backend group was available or if the request was served by
another entity, one of the following values is displayed instead of a
backend group.
- FRONTEND_5XX - An internal error occurred before the GFE could select a backend. The GFE returned `5XX` to the client.
- INVALID_BACKEND - The GFE couldn't find a healthy backend to assign the request to, so it returned a `5XX` response to the requestor.
- NO_BACKEND_SELECTED - An error or other interruption occurred before backend could be selected or a URL redirect happened.
- MULTIPLE_BACKENDS - The request was served by potentially multiple
backends. This can happen when Cloud CDN has served the request
partially from its cache and has also sent one or more byte range
requests
to the backend. Use the
backend_scope
breakdown to visualize each load balancer-to-backend request.
backend_target_type
BACKEND_SERVICE
, BACKEND_BUCKET
, UNKNOWN
if the backend wasn't assigned, or NO_BACKEND_SELECTED
if an error or other interruption occurred before a
backend could be selected or a URL redirect happened.matched_url_path_rule
forwarding_rule_name
url_map_name
The URL map path rule or route rule configured as part of the URL map
key. Can be UNMATCHED
or UNKNOWN
as fallbacks.
-
UNMATCHED
refers to a request that doesn't match any URL path rules, sourl_map_name
uses the default path rule. -
UNKNOWN
indicates an internal error.
target_proxy_name
backend_target_name
UNKNOWN
is returned if a backend
wasn't assigned.backend_name
UNKNOWN
is returned if the backend wasn't assigned, or NO_BACKEND_SELECTED
if an error or other interruption occurred
before a backend could be selected or a URL redirect happened.backend_scope_type
The type of the scope of the backend group. Can be GLOBAL
, REGION
, ZONE
, MULTIPLE_BACKENDS
, or NO_BACKEND_SELECTED
if an error or other interruption occurred
before a backend could be selected or a URL redirect happened, or other
possible backend_type outputs.
MULTIPLE_BACKENDS
is used when chunk caching is used.
Multiple queries are sent to the same backend for different chunks of data
to support a single client request.
proxy_continent
America
, Europe
, Asia
)protocol
HTTP/1.0
, HTTP/1.1
, HTTP/2.0
, QUIC/HTTP/2.0
, UNKNOWN
.response_code
response_code_class
cache_result
HIT
, MISS
, DISABLED
, PARTIAL_HIT
(for a
request served partially from cache and partially from backend) or UNKNOWN
.client_country
United States
or Germany
)load_balancing_scheme
EXTERNAL
. If global external Application Load Balancer is used, the value
is EXTERNAL_MANAGED
.What's next
- Read the overview of Cloud CDN logging
- Read about caching .
- Read about signed URLs and signed cookies .