The feature of storing access logs in COS will stop accepting new enablement requests after 00:00:00, May 15, 2020 (00:00:00, April 26, 2020 for the Guangzhou region) and will be officially disused after 00:00:00, June 30, 2020. For more information, please see Announcement on the Deactivation of the Feature of Storing CLB Access Logs in COS. Please use the upgraded feature of storing access logs in CLS.
CLB supports configuring layer-7 (HTTP/HTTPS) access logs that can help you better understand client requests, troubleshoot issues, and analyze access data. Currently, access logs can be stored in COS for download and analysis, and supported regions include Guangzhou, Shanghai, Beijing, Hong Kong (China), Shanghai Finance, and Shanghai Finance.
Access logs of CLB are mainly used to quickly locate and troubleshoot issues. The access logging feature includes log reporting, storage, and search:
- Currently, log aggregation granularity is 1 hour, and log data transfer may have a delay.
- Currently, CLB supports storing and downloading access logs of public network layer-7 (HTTP/HTTPS) CLB instances but not layer-4 (TCP/UDP) or private network layer-7 CLB instances.
- The log service for CLB is free of charge. A free COS storage capacity of 50 GB is provided for individual users as specified in Free Tier. If you have a high number of logs, please clean them up in a timely manner.
- In the regions that support storing access logs in COS, if the access logging feature is not enabled, Tencent Cloud will retain the logs for three days by default; otherwise, the retention period will be subject to the COS configuration. Access log cannot be configured in other regions.
lb-idwill be automatically created in the bucket for request logs.
[$stgw_request_id] [$time_local] [$protocol_type] [$server_addr:$server_port] [$server_name] [$remote_addr:$remote_port] [$status] [$upstream_status] [$proxy_host] [$request] [$request_length] [$bytes_sent] [$http_host] [$http_user_agent] [$http_referer] [$request_time] [$upstream_response_time] [$upstream_connect_time] [$upstream_header_time] [$tcpinfo_rtt] [$connection] [$connection_requests] [$ssl_handshake_time] [$ssl_cipher] [$ssl_protocol] [$ssl_session_reused]
|time_local||Access time and time zone, such as "01/Jul/2019:11:11:00 +0800" where "+0800" represents UTC+8, i.e., Beijing time.|
|protocol_type||Protocol type (HTTP/HTTPS/SPDY/HTTP2/WS/WSS).|
|server_addr:server_port||Destination IP and port of request.|
|remote_addr:remote_port||Client IP and port.|
|status||Status code returned by CLB to client.|
|upstream_status||Status code returned by RS to CLB instance.|
|request_length||Number of bytes of request received from client.|
|bytes_sent||Number of bytes sent to client.|
|http_host||Request domain name.|
|http_referer||HTTP request source.|
|request_time||Request processing time. The timing begins when the first byte is received from the client and stops when the last byte is sent to the client, i.e., the total time the whole process takes, where the client request reaches a CLB instance, the CLB instance forwards the request to an RS, the RS responds and sends data to the CLB instance, and finally the CLB instance forwards the data to the client.|
|upstream_response_time||The time that an entire backend request process takes. The timing begins when a CLB instance connects with an RS and stops when the RS receives the request and responds.|
|upstream_connect_time||The time it takes to establish a TCP connection with an RS. The timing begins when a CLB instance connects with an RS and stops when it sends the HTTP request.|
|upstream_header_time||The time it takes to receive an HTTP header from the RS. The timing begins when a CLB instance connects with an RS and stops when the HTTP response header is received from the RS.|
|tcpinfo_rtt||TCP connection RTT.|
|connection_requests||Number of connection requests.|
|ssl_handshake_time||The time that an SSL handshake takes.|
|ssl_cipher||SSL cipher suite.|
|ssl_protocol||SSL protocol version.|
|ssl_session_reused||SSL SESSION reuse.|