- Documentation
Load Balancer
Classic Load Balancer (CLB)
Best Practices
Locating the abnormal backend servers through access logs
Best Practices
Locating the abnormal backend servers through access logs
Locating the abnormal backend servers through access logs
This topic introduces how to locate abnormal backend servers using the access log feature of a Layer 7 listener.
Application scenarios
By configuring the access log feature for a Layer 7 listener, you can view detailed logs of requests to that listener. Analyzing response status codes in the log files allows quick identification of abnormal backend servers.
Prerequisites
- The Layer 7 Classic Load Balancer (CLB) instance clb-test has been configured. For detailed operations, see Configuring a Layer 7 CLB instance.
- The Tinder Object Storage (TOS) service has been enabled, and the bucket name is bucket-test. For detailed operations, see Getting started with TOS.
- The authorization for the load balancing service to associate with the ServiceRoleForClbLogDelivery role is completed.
Procedures
Step 1: Configure access log
- In the top menu bar, select the target project and region.
- Click the name of the target CLB instance, clb-test.
- On the Overview tab in the Instance attribute configuration section, click Configure access log.
- When enabling the access log feature for the load balancer instance under the current account for the first time, follow these steps:
- On the automatically redirected Cross-service access request page, click Authorization.
- On the Overview tab of the CLB instance clb-test details page, click Configure access log again.
- On the Configure access log page, enable access log and select the created bucket bucket-test.
- Click OK to complete the access log configuration.
Step 2: View access log
- On the details page of the CLB instance clb-test, select the Overview tab, and click the bucket name Instance property configuration in the Instance property configuration pane. The bucket details page is displayed.
- In the left navigation pane, click File List. The root directory of the bucket is displayed.
- Choose CLBAccessLogs > YYYY > MM > DD. The log storage path is displayed.
tip
Here, YYYY, MM, and DD represent directories named by year, month, and day, for example: CLBAccessLogs > 2021 > 8 > 17.
- Click Actions > Download on the right side of the target file. After downloading, decompress and view.
Step 3: Analyze access log
- Filter abnormal log entries in the access log files.
- There are many log entries in a log file. Each entry starts with [http] or [https]. The last field shows the status code returned by the backend server to the load balancer. If this status code is like [5XX], it indicates an abnormal backend server log entry. The example is as follows:
[https] [2021-11-10T10:28:17+08:00] [192.168.2.96] [35566] [GET / HTTP/1.1] [curl/7.64.1] [192.168.2.95:81] [-] [41] [TLSv1.2] [ECDHE-RSA-AES256-GCM-SHA384] [f6689ea7a4dbe98b7ba346c02fef0c13] [187578235] [7] [192.168.2.95] [10.249.64.186] [lsn-1g1hsc8ftjb408ibuxwr8lql8] [81] [37.072] [500] [192] [0.039] [-] [rsp-2fel2y2rplp8g5oxruwa2836z] [192.168.2.50:81] [0.000] [0.000] [0.020] [500]
- The above log entry shows that at 10:28:17 on November 10, 2021, Beijing time, CLB received a GET / HTTP/1.1 request from client IP address 192.168.2.96 on port 35566. CLB forwarded the request to the backend server (private IP address 192.168.2.50, port 81) for processing. The backend server returned status code 500 to CLB, which then returned it to the client.
- Based on the returned status code, consult the HTTP status code information to identify the exception's cause and perform fixes.
Last updated: 2026.06.17 14:23:11