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 information about how to verify that Cloud HTTP Load
Balancer
logs are allowed, see Exclusion filters
.
Logs sampling and collection
The requests (and corresponding responses) handled by load balancer backend
virtual machine (VM) instances are sampled. These sampled requests are then
processed to generate logs. You control the fraction of the requests that are
emitted as log entries according to the logConfig.sampleRate
parameter
.
When logConfig.sampleRate
is 1.0
(100%), this means that logs are
generated for all of the requests
and written to Cloud Logging.
Optional fields
Log records contain required fields and optional fields. The What is logged section lists which fields are optional and which are required. All required fields are always included. You can customize which optional fields you keep.
-
If you select include all optional, all optional fields in the log record format are included in the logs. When new optional fields are added to the record format, the logs automatically include the new fields.
-
If you select exclude all optional, all optional fields are omitted.
-
If you select custom, you can specify the optional fields that you want to include, such as
tls.protocol,tls.cipher,orca_load_report.cpu_utilization,orca_load_report.mem_utilization
.
For information about customizing optional fields, see Enable logging on a new backend service .
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.
-
Set a Sample ratefraction. 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
. -
Optional: To include all the optional fields in the logs, in the Optional fieldssection, click Include all optional fields.
Pro tip: To specify the CUSTOMoption, use the gcloud CLI and the REST API.
-
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 \ --logging-optional= LOGGING_OPTIONAL_MODE \ --logging-optional-fields= OPTIONAL_FIELDS
The gcloud compute backend-services create
command supports the
following fields:
-
--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. This field is 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
. -
--logging-optional
lets you specify the optional fields that you want to include in the logs:-
INCLUDE_ALL_OPTIONAL
to include all optional fields. -
EXCLUDE_ALL_OPTIONAL
(default) to exclude all optional fields. -
CUSTOM
to include a custom list of optional fields that you specify inOPTIONAL_FIELDS
.
-
-
--logging-optional-fields
lets you specify a comma-separated list of optional fields that you want to include in the logs.For example,
tls.protocol,tls.cipher
can only be set ifLOGGING_OPTIONAL_MODE
is set toCUSTOM
. If you use custom metrics and want to log elements of the ORCA load report, you setLOGGING_OPTIONAL_MODE
toCUSTOM
and specify which elements must be logged in theOPTIONAL_FIELDS
field. For example,orca_load_report.cpu_utilization,orca_load_report.mem_utilization
.
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 Sample ratefraction. 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
. For example,0.2
means 20% of the sampled requests generate logs. -
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. -
--no-enable-logging
disables logging for that backend service.
Enabling logging optional fields on an existing backend service
gcloud compute backend-services update BACKEND_SERVICE \ --global \ --enable-logging \ --logging-sample-rate= VALUE \ --logging-optional= LOGGING_OPTIONAL_MODE \ --logging-optional-fields= OPTIONAL_FIELDS
where
-
--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
. -
--logging-optional
lets you specify the optional fields that you want to include in the logs:-
INCLUDE_ALL_OPTIONAL
to include all optional fields. -
EXCLUDE_ALL_OPTIONAL
(default) to exclude all optional fields. -
CUSTOM
to include a custom list of optional fields that you specify inOPTIONAL_FIELDS
.
-
-
--logging-optional-fields
lets you specify a comma-separated list of optional fields that you want to include in the logs.For example,
tls.protocol,tls.cipher
can only be set ifLOGGING_OPTIONAL_MODE
is set toCUSTOM
. If you use custom metrics and want to log elements of the ORCA load report, you setLOGGING_OPTIONAL_MODE
toCUSTOM
and specify which elements must be logged in theOPTIONAL_FIELDS
field. For example,orca_load_report.cpu_utilization,orca_load_report.mem_utilization
.
Updating logging optional mode from CUSTOM to others
gcloud compute backend-services update BACKEND_SERVICE \ --global \ --enable-logging \ --logging-sample-rate= VALUE \ --logging-optional= LOGGING_OPTIONAL_MODE \ --logging-optional-fields=
where
-
--logging-optional
lets you specify the optional fields that you want to include in the logs:-
INCLUDE_ALL_OPTIONAL
to include all optional fields. -
EXCLUDE_ALL_OPTIONAL
(default) to exclude all optional fields.
-
-
--logging-optional-fields
must be explicitly configured as shown to clear any existingCUSTOM
fields. The API doesn't let you combine a non-CUSTOM
mode withCUSTOM
fields.
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.
Log records contain optional fields that add additional information about your HTTP(S) traffic. Optional fields can be omitted to save storage costs.
Some log fields are in a multi-field format, with more than one piece of data in a given field. For example, thetls
field is of the TlsInfo
format, which contains the earlyDataRequest
field.
These multi-field fields are described in the following record format table. HttpRequest.protocol
isn't 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
-
authzPolicyInfo
-
loadBalancingScheme
-
tls
-
orca_load_report
statusDetails
field
holds a string that explains why the load balancer returned
the HTTP status code 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
.authzPolicyInfo
field stores information about the
authorization policy result. This information is only available for
global external Application Load Balancers that have enabled authorization policies
. For more information, see what is logged for authorization policies
.loadBalancingScheme
field is only populated if
you use the classic Application Load Balancer migration
feature. This field holds a string that describes which load balancing
scheme was used to route the request. The possible values are either EXTERNAL
or EXTERNAL_MANAGED
.The tls
field holds the TlsInfo
field that specifies the TLS
metadata for the connection between the client and the load balancer.
This field is only available if the client is
using TLS/SSL encryption.
Use the --logging-optional-fields
parameter to specify which elements must be logged:
- Optional:
tls.protocol
- Optional:
tls.cipher
- Required:
tls.earlyDataRequest
You can't
set --logging-optional-fields
to tls
to specify all elements.
The orca_load_report
field contains some or all
elements of the ORCA load report returned by the backend. This field is
only present if the backend returns an ORCA load report and you
configured the load balancer to log the ORCA load report.
Use the --logging-optional-fields
parameter to specify which of the following elements of the ORCA load
report must be logged:
-
orca_load_report.cpu_utilization
-
orca_load_report.mem_utilization
-
orca_load_report.request_cost
-
orca_load_report.utilization
-
orca_load_report.rps_fractional
-
orca_load_report.eps
-
orca_load_report.named_metrics
-
orca_load_report.application_utilization
You can also set --logging-optional-fields
to orca_load_report
to specify that all elements must be
logged.
TlsInfo field format
Field | Field format | Field type: Required or Optional | Description |
---|---|---|---|
protocol
|
string | Optional | TLS protocol that clients use to establish a connection with the
load balancer. Possible values are TLSv1
, TLSv1.1
, TLSv1.2
, TLSv1.3
,
or QUIC
.
This value is set to NULL
if the client is not using TLS/SSL
encryption. |
cipher
|
string | Optional | TLS cipher that clients use to establish a connection with the load
balancer. This value is set to NULL
if the client isn't
using HTTP(S) or the client isn't using TLS/SSL encryption. |
earlyDataRequest
|
boolean | Required | The request includes early data in the TLS handshake. |
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
4XX
or 5XX
backend_connection_closed_after_partial_response_sent
The HTTP status code is set by the software running on the backend.
HTTP status code 0
(zero) means that the backend sent
incomplete HTTP headers.
The HTTP status 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 status code is 101
if the HTTP(S) connection was
upgraded to a websocket connection.
backend_early_response_with_non_error_status
1 XX
or 2 XX
) to a request before
receiving the whole request body.502
, 503
backend_interim_response_not_supported
1 XX
status code to the
request in a context where interim responses aren't supported. 502
, 503
backend_response_corrupted
502
, 503
.backend_response_headers_too_long
502
, 503
backend_timeout
The backend timed out while generating a response.
For a websocket connection:
- For global external Application Load Balancer, a status code is generated when the GFE closes the websocket connection in idle state after the backend service timeout expires.
- For classic Application Load Balancer, a status code 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 status code is 101
if the HTTP(S) connection was
upgraded to a websocket connection.
banned_by_security_policy
429
body_not_allowed
400
byte_range_caching_aborted
206 Partial Content
). This happened
when attempting to perform cache fill using a byte range request
.
As a result, the load balancer aborted the response to the client.2 XX
byte_range_caching_forwarded_backend_response
206 Partial Content
). This happened
when attempting to perform cache fill using a byte range request
.
The load balancer then forwarded the inconsistent response to the client.Returned from the backend—any status code is possible.
byte_range_caching_retrieval_abandoned
Returned from the backend—any status code is possible.
byte_range_caching_retrieval_from_backend_failed_after_partial_response
2 XX
cache_lookup_failed_after_partial_response
2 XX
cache_lookup_timeout_after_partial_response
2 XX
client_disconnected_after_partial_response
Returned from the backend—any status code is possible.
The HTTP status code is 101
if the HTTP(S) connection
was upgraded to a websocket connection.
client_disconnected_before_any_response
0
The HTTP status code is 101
if the HTTP(S) connection was
upgraded to a websocket connection.
client_timed_out
0
or 408
client_cert_invalid_rsa_key_size
0
client_cert_unsupported_elliptic_curve_key
0
client_cert_unsupported_key_algorithm
0
client_cert_pki_too_large
0
client_cert_chain_max_name_constraints_exceeded
0
client_cert_chain_invalid_eku
clientAuth
. For more information, see Logged errors for closed connections
.0
client_cert_validation_timed_out
0
client_cert_validation_search_limit_exceeded
0
client_cert_validation_not_performed
TrustConfig
.
For more information, see Logged errors for closed connections
.0
client_cert_not_provided
0
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
.0
config_not_found
The load balancer is missing project configuration. This can occur intermittently after you've made configuration changes that add a new resource.
Another cause of the error is that the first-layer GFE fails to communicate with the second-layer GFE. This can be due to an internal error, such as an in-progress rollout, load balancer overload, or intermittent configuration issues.
These errors are transient in nature and are expected to fall well within the SLA . However, if the error rate exceeds 0.01%, please contact Google Cloud support for further assistance.
404
, 502
, 503
direct_response
410
status code means that
the backend is unavailable due to payment delinquency.denied_by_security_policy
error_uncompressing_gzipped_body
502
, 503
failed_to_connect_to_backend
502
, 503
failed_to_pick_backend
502
, 503
failed_to_negotiate_alpn
502
, 503
headers_too_long
413
http_version_not_supported
400
internal_error
4 XX
or 5 XX
invalid_external_origin_endpoint
4 XX
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:
400
invalid_http2_client_header_format
invalid_request_headers
.400
invalid_http2_client_request_path
The HTTP/2 request path from a client contains at least one character that isn't allowed under the URI specification.
For more information, see the "3.3. Path" section of RFC 3986 .
400
multiple_iap_policies
500
malformed_chunked_body
411
request_loop_detected
502
, 503
required_body_but_no_content_length
400
, 403
, 411
secure_url_rejected
https://
URL
was received over a plaintext HTTP/1.1 connection.400
server_cert_chain_exceeded_limit
502
, 503
server_cert_chain_invalid_eku
Extended Key Usage (EKU)
extension field but that field doesn't include serverAuth
. server_cert_chain_max_name_constraints_exceeded
502
, 503
server_cert_exceeded_size_limit
503
server_cert_invalid_rsa_key_size
A server or an intermediate certificate has an invalid RSA key size.
No validation is performed.
RSA keys can range from 2048 to 4096 bits.
503
server_cert_not_provided
503
server_cert_pki_too_large
The PKI to be used for validation has more than ten intermediate certificates that share the same Subject and Subject Public Key Info.
No validation is performed.
503
server_cert_trust_config_not_found
TrustConfig
not found.503
server_cert_unsupported_elliptic_curve_key
A server or an intermediate certificate is using an unsupported elliptic curve.
No validation is performed.
Valid curves are P-256 and P-384.
503
server_cert_unsupported_key_algorithm
A server or an intermediate certificate is using a non-RSA or non-ECDSA algorithm.
No validation is performed.
503
server_cert_validation_internal_error
503
server_cert_validation_not_performed
You configured mTLS without setting up a TrustConfig
resource.
503
server_cert_validation_search_limit_exceeded
The depth or iteration limit is reached while attempting to validate the certificate chain.
The maximum depth for a certificate chain is ten, including the root and server certificates. The maximum number of iterations is 100 (certificates examined to validate the server certificate chain).
503
server_cert_validation_timed_out
503
server_cert_validation_unavailable
503
ssl_certificate_san_verification_failed
502
, 503
ssl_certificate_chain_verification_failed
502
, 503
throttled_by_security_policy
429
unsupported_method
400
unsupported_100_continue
400
upgrade_header_rejected
400
websocket_closed
101
websocket_handshake_failed
request_body_too_large
413
handled_by_identity_aware_proxy
200
, 302
, 400
, 401
, 403
, 500
, 502
, 503
serverless_neg_routing_failed
404
, 502
, 503
fault_filter_abort
200
to 599
.early_data_rejected
The request sent in TLS early data was invalid.
This might occur in the following cases but isn't limited to them:
- The
TargetHttpsProxy
has TLS early data set toSTRICT
, but the request included query parameters. - The
TargetHttpsProxy
has TLS early data set toSTRICT
orPERMISSIVE
, but the request used a nonidempotent HTTP method (such as POST or PUT).
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. Check more authorization policies log details
.
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 Cloud Armor
The table for statusDetail
HTTP failure messages contains some messages that
apply to Cloud Armor. For more information about what
Cloud Armor logs, see Use 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 Logging API overview .
Monitoring
The load balancer exports monitoring data to 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
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 total latency. Total latency is the time in milliseconds between the first byte of the request received by the proxy and the last byte of the response sent by the proxy. It includes: the time taken by the proxy to process the request, the time taken for the request to be sent from the proxy to the backend, the time taken by the backend to process the request, the time taken for the response to be sent back to the proxy, and the time taken for the proxy to process the response and send the response to the client.
It doesn't include the RTT between the client and the proxy. Additionally,
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
A distribution of the frontend RTT. Frontend RTT is the time in milliseconds it takes for data to travel from the client to the proxy and back again. It includes the time taken for a request to travel from the client to the proxy and back from the proxy to the client. This is not updated during the lifetime of the connection. For example, setting up a (TCP) connection with a 3-way handshake would take 1.5 RTTs.
When requests are processed, the load balancer samples and averages the time it takes for data to travel back and forth between the client and the proxy, and then logs a smoothed RTT value. Smoothed RTT is an algorithm that deals with variations and anomalies that might occur in RTT measurements.
https/backend_latencies
A distribution of the backend latency. Backend latency is the time in milliseconds between the first byte of the request received by the backend and the last byte of the response received by the proxy. It includes: the time taken for the request to be sent from the proxy to the backend, the time taken by the backend to process the request, and the time taken for the response to be sent back to the proxy.
2 XX
, 4 XX
, ...).
In Monitoring, this value is
only available on default dashboards. It isn't available for custom
dashboards. You can use the Monitoring API to set alerts for it.https/backend_request_count
https/backend_request_bytes_count
https/backend_response_bytes_count
* For monitoring websocket connections, create a backend service specifically for websockets.
† The sum of Frontend RTT and Backend latencies might not 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 acknowledged, we rely on kernel reporting for some of these measurements, and we cannot be sure 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.
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 see one of the following values instead of the region or zone of the backend service instance group.
-
FRONTEND_5 XX
: an internal error occurred before the GFE could select a backend. The GFE returned5 XX
to the client. - INVALID_BACKEND: the GFE couldn't find a healthy backend to assign
the request to, so it returned a
5 XX
response to the requestor. - NO_BACKEND_SELECTED: either an error or interruption occurred before
a backend was selected, a URL redirect occurred, or a
classic Application Load Balancer with serverless backends returned a
200 OK
response. - 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
5 XX
to the client. - INVALID_BACKEND: the GFE couldn't find a healthy backend to assign
the request to, so it returned a
5 XX
response to the requestor. - NO_BACKEND_SELECTED: either an error or interruption occurred before
a backend was selected, a URL redirect occurred, or a
classic Application Load Balancer with serverless backends returned a
200 OK
response. - 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 interruption occurred
before a backend was selected, a URL redirect occurred, or a
classic Application Load Balancer with serverless backends returned a 200 OK
response.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 interruption occurred
before a backend was selected, a URL redirect occurred, or a
classic Application Load Balancer with serverless backends returned a 200 OK
response.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 interruption occurred
before a backend was selected, a URL redirect occurred, or a
classic Application Load Balancer with serverless backends returned a 200 OK
response, 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
200
, 300
, 400
, 500
or 0
for
none.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 .