access log

Overview

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

1. Log on to the CLB console.

2. In the left-side navigation pane, choose Logs > Access Log.

3. In the top navigation bar, select the region where the CLB instance is deployed.

4. If this is your first time using the feature, click Authorize. On the Authorize Access to Cloud Resources page, click Confirm.

   Note

   You 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.

5. On the Access Log (Layer 7) page, find the target CLB instance, and click Configure in the Actions column.

6. 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.

   Note

   • Ensure the Project is in the same region as the CLB instance and its name is globally unique.

   • After configuration, the SLS Project and Logstore may take a few minutes to appear in the SLS console. Log data is not lost during this period. If they are not yet visible, refresh the page later.

   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.

Usage notes

client_ip and http_x_forwarded_for

When you analyze request sources in SLS access logs, these two fields have different meanings:

• client_ip: The source IP address that established the connection to CLB, as observed by CLB at the network layer. If there is no proxy in front of the client, this is the true client IP address. If the client is behind a proxy, this is the egress IP address of the nearest proxy.

• http_x_forwarded_for: The original value of the X-Forwarded-For header in the inbound request received by CLB. It is written by the client or an upstream proxy, can be spoofed, and is for reference only.

To analyze request sources in access logs, use client_ip.

Identifying which forwarding rule handled a request

Access logs do not record server group IDs or the names of traffic forwarding rules. To determine which forwarding rule handled a specific request, correlate the request_uri and http_host values in the log with the forwarding rules configured in the CLB console. Based on this, you can further verify that a forwarding rule is working as expected:

• Identify inactive forwarding rules: Query the number of times a forwarding rule was matched within a specific time range by combining slbid, request_uri, and a time range. If the result is 0, the rule did not match any request during that period. Evaluate whether to clean it up based on your business needs.

  slbid: <instance-ID> and request_uri: <forwarding-rule-path> | select count(*) as hit_count

• Verify that forwarding matches expectations: Compare the upstream_addr value (the backend server IP address and port to which the request was actually forwarded) in the log with the server group members of the corresponding listener in the CLB console, to confirm that requests are forwarded to the intended backend servers.

TLS policy interception

Connections that are blocked by a TLS security policy do not complete the TLS handshake and therefore do not generate access log entries. Access logs record only requests that successfully establish a connection with CLB.

Query access logs

After you configure the access log feature, you can query logs in the SLS console.

1. Log on to the CLB console.

2. In the left-side navigation pane, choose Logs > Access Log.

3. In the top navigation bar, select the region where the CLB instance is deployed.

4. 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.

5. After SLS is configured, you can view log entries for any client that has accessed the CLB instance.

6. 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 20

   For 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

   Filtering logs when multiple CLB instances share a Logstore

   If multiple CLB instances share the same SLS Logstore, queries that filter only by domain or port may return incomplete or misleading results. To narrow down logs to a specific CLB instance and listener, combine the slbid (instance ID) and slb_vport (listener port) fields in your query.

   For example, to query 5xx errors for a specific instance and listener port, run the following SQL statement:

   slbid: <instance-ID> and slb_vport: <port> and status: 5*

   If your query returns no results, verify the following:

   • The slbid value must exactly match the instance ID shown in the CLB console (not the instance name).

   • The slb_vport value must match the listener port number (for example, 80 or 443).

   • Widen the query time range, because log entries may be written with a short delay.

   Note

   Note the following about log refresh behavior and same-timestamp entries:

   • Log refresh behavior: Field index statistics in SLS are updated in real time as log entries are written. There is no fixed refresh interval. If you switch the query time range in the console, click the query button to reload the results.

   • Multiple entries with the same timestamp: If you see multiple log entries that share the same time value, this is expected behavior and indicates that the client sent multiple requests within the same second. This is a normal pattern for high-frequency clients and does not indicate a system error. If you determine that the repeated requests are abnormal, configure an access control policy to restrict the source IP address.

Analyze access logs

You can use dashboards in SLS to analyze access logs. Dashboards provide rich data visualizations and insights.

1. On the SLS page, click the icon in the left-side navigation pane, and then click Dashboard.

2. 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.

slbid: <instance-ID> and slb_vport: <port> | select count(*) as total_requests

* | select http_host, sum(request_length) as total_bytes, round(sum(request_length) * 100.0 / sum(sum(request_length)) over(), 2) as traffic_pct group by http_host order by total_bytes desc

* | select upstream_addr, count(*) as request_count, sum(request_length) as total_bytes group by upstream_addr order by request_count desc limit 20

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.

* | select client_ip, request_method, request_uri, count(*) as cnt group by client_ip, request_method, request_uri order by cnt desc limit 50

Disable access logs

You can disable the access log feature to stop collecting CLB access logs.

1. Log on to the CLB console.

2. In the left-side navigation pane, choose Logs > Access Log.

3. In the top navigation bar, select the region where the CLB instance is deployed.

4. On the Access Log (Layer 7) page, find the target instance, and then click Disable Logging in the Actions column.

5. 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.

FAQ