The access log feature of Classic Load Balancer (CLB) is designed for Layer 7 load balancing. It integrates with Simple Log Service (SLS) to improve the efficiency of log analysis and troubleshooting for business development, testing, and user behavior analysis.
Overview
CLB access logs
The access log feature for Classic Load Balancer (CLB) captures detailed information about all requests sent to a CLB instance, including the request time, client IP address, latency, request path, and server response. As a public-facing entry point, CLB handles a high volume of requests. You can use access logs to analyze user behavior, understand traffic distribution, and troubleshoot issues.
After you enable the access log feature, you can store, collect, and analyze access logs in a Logstore of Simple Log Service (SLS). You can disable the access log configuration at any time.
The CLB access log feature is free, but Simple Log Service incurs charges. For more information, see Billing overview of Simple Log Service.
-
Layer 4 listeners (TCP/UDP) do not support the access log feature. Access logs record only Layer 7 (HTTP/HTTPS) request information.
-
Ensure that HTTP header values do not contain
||. Otherwise, log fields may be misaligned during parsing.
Limitations
The access log feature is available only for Layer 7 load balancing (HTTP and HTTPS listeners) of CLB.
Access logs primarily record Layer 7 request information. Therefore, this feature is not supported for Layer 4 listeners (TCP/UDP).
Prerequisites
-
You have created a CLB instance.
-
You have created a vServer group, added backend servers to the vServer group, and deployed applications on the backend servers.
-
You have configured an HTTP listener or an HTTPS listener for the CLB instance.
-
You have activated Simple Log Service.
Configure access logs
Log on to the CLB console.
-
In the left-side navigation pane, choose .
-
In the top navigation bar, select the region where the CLB instance is deployed.
-
If this is your first time using the feature, click Authorize. On the Authorize Access to Cloud Resources page, click Confirm.
NoteYou only need to perform this authorization once.
If you are a RAM user, the primary Alibaba Cloud account must first grant you the required permissions. For more information, see Authorize a RAM user to use the access log feature of CLB.
-
On the Access Log (Layer 7) page, find the target CLB instance, and click Configure in the Actions column.
-
In the Log Settings panel, set the Project and Logstore, and then click OK.
-
Project: A Project is a resource management unit in SLS used for resource isolation and control. We recommend using different Projects for different applications.
-
Logstore: A Logstore is the unit for collecting, storing, and querying log data in SLS. We recommend creating separate Logstores for different types of logs within the same application.
-
Select Logstore: This enables a preset analysis dashboard for the selected Logstore by default. If an index is already configured for the Logstore, the existing index configuration is overwritten.
-
NoteEnsure the Project is in the same region as the CLB instance and its name is globally unique.
After you configure access logging for the load balancer, you can query and retrieve log information by using the following fields in SLS.
Parameter
Description
body_bytes_sent
The size of the HTTP body sent to the client, in bytes.
client_ip
The client IP address.
client_port
The port of the client that sent the request.
host
The host is retrieved from the first available source in the following order: request parameters, the Host header, and the IP address of the backend server that processes the request.
http_host
The content of the Host header in the request.
http_referer
The Referer header of the HTTP request.
http_user_agent
The User-Agent header of the HTTP request.
http_x_forwarded_for
The X-Forwarded-For header of the HTTP request.
http_x_real_ip
The X-Real-IP header of the HTTP request.
read_request_time
The time that the load balancer takes to read the request. Unit: milliseconds.
request_length
The length of the request, including the start line, HTTP header, and HTTP body.
request_method
The request method.
request_time
The time from when the load balancer receives the first byte of a request to when it sends the last byte of the response. Unit: seconds.
request_uri
The URI of the request that is received by the load balancer.
scheme
The request scheme. Valid values: http and https.
server_protocol
The HTTP version of the request that is received by the load balancer, such as HTTP/1.0 or HTTP/1.1.
slb_vport
The listener port of the load balancer.
slbid
The ID of the load balancer instance.
ssl_cipher
The cipher suite used to establish the SSL connection, such as ECDHE-RSA-AES128-GCM-SHA256.
ssl_protocol
The protocol used to establish the SSL connection, such as TLSv1.2.
status
The status code in the response from the load balancer.
tcpinfo_rtt
The round-trip time (RTT) of the client's TCP connection. Unit: microseconds.
time
The time when the log entry was recorded.
upstream_addr
The IP address and port of the backend server.
upstream_response_time
The time from when a connection to a backend server is established to when the connection is closed after a response is received. Unit: seconds.
upstream_status
The response status code that the load balancer receives from the backend server.
vip_addr
The virtual IP address (VIP).
write_response_time
The time that the load balancer takes to write a response. Unit: milliseconds.
-
Query access logs
After you configure the access log feature, you can query logs in the SLS console.
Log on to the CLB console.
-
In the left-side navigation pane, choose .
-
In the top navigation bar, select the region where the CLB instance is deployed.
-
On the Access Log (Layer 7) page, find the target instance, and click View Logs in the Actions column. You are redirected to the SLS console.
-
After SLS is configured, you can view log entries for any client that has accessed the CLB instance.
-
Enter an SQL statement to query specific access logs.
For example, run the following SQL statement to find the top 20 clients. The results can help you analyze traffic sources and inform business decisions.
* | select http_user_agent, count(*) as pv group by http_user_agent order by pv desc limit 20For example, run the following SQL statement to query for access requests from a specific IP address range by filtering logs by source IP address and response status code.
* | select * where client_ip like '172.17.%' and status=200
Identify abnormal requests
CLB access logs record all external requests that pass through the load balancer instance. If you find requests from unknown sources in the logs, you can use the following key fields to determine whether they are abnormal external requests and take appropriate protective measures.
Key fields
Combine the following log fields to determine if a request is from an abnormal client:
-
client_ip: The IP address of the client that sent the request. If the IP address does not belong to your business systems or the Alibaba Cloud internal IP address range, the request originates from an external client. You can use an IP lookup tool to further confirm the source. -
request_uri: The URI path of the request. If paths unrelated to your business appear (such as probe or scan paths, or API paths of other cloud services), the requests are typically abnormal external requests. -
request_method: The HTTP method of the request. If your business uses only GET requests but the logs show a large number of PUT or DELETE requests, check for abnormal behavior. -
http_user_agent: The User-Agent identifier of the request. Automated tools or crawlers often use specific User-Agent headers, such ascurlorpython-requests, which differ from those of normal browser requests.
For example, you can use the following SQL statement in SLS to query abnormal requests from unexpected IP addresses:
* | select client_ip, request_method, request_uri, count(*) as cnt group by client_ip, request_method, request_uri order by cnt desc limit 50
Restrict abnormal source IPs
After you confirm the source IP addresses of abnormal requests, you can use the access control feature of CLB to configure a blacklist and block subsequent requests from these IP addresses. Perform the following steps:
-
In the left-side navigation pane of the CLB console, choose Access Control.
-
Create an access control policy group and add the identified abnormal source IP addresses to it.
-
Bind the policy group to your listener as a blacklist. CLB will then reject all requests from the blacklisted IP addresses instead of forwarding them to backend servers.
Analyze access logs
You can use dashboards in SLS to analyze access logs. Dashboards provide rich data visualizations and insights.
-
On the SLS page, click the
icon in the left-side navigation pane, and then click Dashboard. -
Click the name of the dashboard that corresponds to the access logs of your CLB instance, such as slb_layer7_access_center_cn, to view the analysis report.
Disable access logs
You can disable the access log feature to stop collecting CLB access logs.
Disabling access logging for a CLB instance does not delete the associated Project or Logstore. The instance's historical logs are not immediately deleted, and you can still manage them in SLS.
Log on to the CLB console.
-
In the left-side navigation pane, choose .
-
In the top navigation bar, select the region where the CLB instance is deployed.
-
On the Access Log (Layer 7) page, find the target instance, and then click Disable Logging in the Actions column.
-
In the dialog box that appears, click OK to disable access logging for the instance.
Related documents
-
To learn more about Simple Log Service, see What is Simple Log Service?.
-
If you suspect a backend server is unhealthy when using Layer 7 load balancing, see Use CLB access logs to quickly locate an unhealthy backend server.