Server Load Balancer:Use CLB access logs to locate unhealthy backend servers

Prerequisites

Before you begin, ensure that you have:

• A CLB instance. See Create and manage CLB instances

• A vServer group with backend servers added and applications deployed. See Create and manage a vServer group

• An HTTP or HTTPS listener on the CLB instance. See Add an HTTP listener and Add an HTTPS listener

• Simple Log Service activated. See Activate Simple Log Service

Step 1: Configure access logs

1. Log on to the CLB console.

2. Log on to the CLB console.

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

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

5. If this is your first time using access logs, grant the required permissions. Click Authorize, then on the RAM Quick Authorization page click Agree to Authorization again.

   Note

   Authorization is one-time only. If you use a Resource Access Management (RAM) user, the account owner must authorize the RAM user separately. See Authorize a RAM user to use the access log feature of CLB.

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

7. In the Log Settings panel, set the Project and Logstore parameters, then click OK.

   Parameter	Description
   Project	An SLS project isolates and manages resources. Select an existing project from the drop-down list, or enter a name to create one. The project name must be unique, and its region must match the region of the CLB instance.
   Logstore	An SLS Logstore collects, stores, and queries logs. Select an existing Logstore from the drop-down list, or enter a name to create one.

Step 2: View access log data

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 your CLB instance is deployed.

4. Find your CLB instance and click View Logs in the Actions column to open the SLS console.

5. Log entries are generated each time a client accesses CLB. You can view the log data in Simple Log Service.

6. Enter an SQL statement to query log data. For example, you can run the following SQL statement to query the top 20 most active clients. You can analyze the request sources and make informed business decisions.

   * | select http_user_agent, count(*) as pv group by http_user_agent order by pv desc limit 20

Step 3: Locate unhealthy backend servers

Use the SLS dashboard to get a visual summary of backend server response times.

1. On the project page, hover over the icon in the left-side navigation pane and click Dashboards.

2. Click the access log dashboard name, for example slb_layer7_access_center_en.

3. In the top upstream_response_time section, sort the avg upstream_response_time(s) column in descending order.

4. If a backend server's average response time exceeds 1 second, log on to that server to investigate the root cause.

Troubleshoot multi-path forwarding failures

In multi-path forwarding scenarios, when some backend servers are unreachable, you can use SLS log queries to filter failed requests by status code and identify the specific backend servers that caused the failures.

Key log fields

Procedure

1. Log on to the CLB console. In the left-side navigation pane, choose Logs > Access Log. In the top navigation bar, select the region where your CLB instance is deployed. Find your CLB instance and click View Logs in the Actions column to open the SLS log query page.

2. Enter the following query to filter failed forwarding requests:

   status:502 or status:504

3. In the query results, check the upstream_addr field to identify the backend server IP addresses that received the failed requests. These are the unreachable paths in your multi-path forwarding configuration.

4. To get an aggregated view of failures per backend server, run the following query:

   status:502 or status:504 | select upstream_addr, upstream_status, upstream_response_time, count(*) as error_count group by upstream_addr, upstream_status, upstream_response_time order by error_count desc

   Review the upstream_status column to see the actual response code from each backend server, which helps narrow down the failure cause.

5. To differentiate timeout failures from connection-refused failures, check the upstream_response_time field in the query results:

   • If upstream_response_time is close to the listener's upstream timeout threshold, the backend server timed out.

   • If upstream_response_time is near zero, the backend server refused the connection immediately.

Use access logs to investigate traffic spikes

When your Classic Load Balancer (CLB) instance receives a sudden traffic spike, use Classic Load Balancer (CLB) access logs to analyze traffic sources and trends and determine whether the traffic increase is expected.

Procedure

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 your CLB instance is deployed.

4. Find the target CLB instance, and click View Logs in the Actions column to open the SLS dashboard.

5. In the SLS dashboard, use the time range selector to adjust the observation window. Compare current traffic volume against historical baselines to assess whether the spike is anomalous.

6. Click the Statistical Charts tab to view page view (PV) and Traffic Trend charts. Look for patterns such as a sudden step-change or a spike concentrated within a short time window.

7. To identify specific traffic sources, enter a query statement in the query input box. The following SQL statement returns the top 20 source IP addresses and request URIs ranked by request count:

   * | SELECT client_ip, request_uri, count(*) AS cnt
   GROUP BY client_ip, request_uri
   ORDER BY cnt DESC
   LIMIT 20

Common traffic spike causes and recommended actions

Related topics

• What is Simple Log Service?

• Overview of CLB access logs

• Configure a CLB access log

• FAQ