Analyze CLB Access Logs in Tencent Cloud CLS

Cloud Load Balancer access logs answer a question that ordinary application logs often cannot: what happened between the client, the load balancer, and the real server?

The source article focuses on Layer 7 CLB access logs and shows how to send them into Tencent Cloud CLS for search, SQL analysis, dashboards, and alerts. It is especially useful when a small number of requests fail under high QPS, when backend servers do not see a request, or when application-side response_time looks normal but users still report slow requests.

Common CLB troubleshooting questions

The original article groups CLB log use cases into troubleshooting and statistical analysis.

Area	Source-backed question	Why CLB logs help
Exception localization	Under high QPS, a few client requests fail and the real server does not receive them. Did the load balancer receive the requests?	CLB access logs show the load-balancer-side request record.
Latency diagnosis	End users report slow requests, while the real server's response_time is normal. Where was time spent?	CLB logs expose request_time, upstream_response_time, upstream_connect_time, and upstream_header_time.
Layer 7 incident scope	Internal Layer 7 requests fail during a time window. Which part of the path is abnormal?	Logs can be filtered by CLB VIP, listener port, server name, upstream address, status code, and request.
Protocol analysis	HTTP/2 is enabled, but teams need to know whether it is actually being used.	The protocol_type and server_protocol fields can be analyzed.
Traffic distribution	Core domains are distributed across different CLB instances. What is the request share by instance?	Queries can group by server_addr, server_name, http_host, or other dimensions.

Onboarding path 1: enable logs for one Layer 7 instance

For a single CLB instance, the source article uses this flow:

1. Select the target Layer 7 CLB instance.
2. Click the edit icon.
3. Enable the access-log switch.
4. Select the target CLS logset and log topic.
5. If no suitable logset or topic exists, create one from the access-log page.
6. Submit the configuration.
7. Open the target log topic and edit the index.
8. When logs arrive, use automatic index configuration and enable statistics for analysis fields.

The Chinese UI in this screenshot is showing the CLB instance detail area. The highlighted control is the edit entry for configuring Layer 7 access logs on that specific instance.

This modal translates to: Enable CLS log service for the current CLB instance. The operator turns on the switch and confirms the setting.

This configuration page asks where the access logs should be delivered. In English: choose the logset, choose the log topic, and save. If the target does not exist yet, the source article points operators to the access-log page to create it first.

After access logs start arriving, go to the CLS log topic and open index editing. Index configuration is required before the fields can be searched and analyzed efficiently.

The source recommends enabling statistics for all relevant fields. In the screenshot, the operator uses automatic field detection and enables the statistics switch so fields can be used in SQL aggregation and dashboard panels.

Onboarding path 2: batch access through the dedicated CLB logset

The source article also describes a batch onboarding path for creating a dedicated clblog logset.

Important source note: at the time described by the article, batch onboarding requires CLB product allowlist access before the entry is visible.

Recommended topic design from the source:

• separate topics by technical layer, such as HTTP layer, cache layer, or data layer;
• or separate topics by business dimension, such as finance, main site, or order business;
• remember that CLS can also act as a pipeline, so different topics may later be delivered to COS, CKafka, SCF, or other processing paths for archiving and downstream handling.

The highlighted Chinese label is Access Logs. This is the batch configuration entry that opens the dedicated CLB logset setup page.

The UI text means: the CLB logset name is fixed, so the operator mainly chooses retention and creates a log topic. The source says the topic should be named according to the real business grouping.

This screenshot shows selecting CLB instances for the new topic. In English: choose the target load balancers, add them to the topic, and save the batch relationship.

The final setup step is to save. The source article says the configuration takes about 5-10 minutes to become effective. After that, use the same index and statistics settings as the single-instance path.

CLB access-log field reference

The original article lists the CLB log variables. The most operationally useful fields are:

Field	Type	Meaning
stgw_request_id	text	Request ID.
time_local	text	Access time and timezone, such as 01/Jul/2019:11:11:00 +0800.
protocol_type	text	Protocol type: HTTP, HTTPS, SPDY, HTTP2, WS, or WSS.
server_addr	text	CLB VIP.
server_port	long	CLB VPort, meaning listener port.
server_name	text	Rule server_name, the domain configured in the CLB listener.
remote_addr	text	Client IP address.
remote_port	long	Client port.
status	long	Status code returned from CLB to the client.
upstream_addr	text	Real server address.
upstream_status	text	Status code returned from the real server to CLB.
request	text	Request line, including method, path, and protocol.
request_length	long	Bytes received from the client.
bytes_sent	long	Bytes sent to the client.
http_host	text	Request domain from the HTTP Host header.
http_user_agent	text	User-Agent header.
http_referer	text	HTTP request source.
request_time	double	Total processing time from the first byte received from the client to the last byte sent back.
upstream_response_time	double	Time spent on the backend request, from connecting to the real server until the response is fully received.
upstream_connect_time	double	TCP connection time to the real server.
upstream_header_time	double	Time from connecting to the real server until the response header is fully received.
tcpinfo_rtt	long	TCP RTT.
ssl_handshake_time	double	SSL handshake time.
ssl_cipher	text	SSL cipher suite.
ssl_protocol	text	SSL protocol version.
vip_vpcid	long	VPC ID of the CLB VIP. For public CLB, the value is -1.
uri	text	Resource identifier.
server_protocol	text	CLB protocol.

Search examples from the source

Find a specific URL request where request time is greater than a threshold:

request:"HEAD /aaa/ HTTP/1.1" AND request_time:>0.005

Find 4xx requests for a specific real server:

status:[400 TO 500} AND upstream_addr:"10.0.1.12:80"

Build dashboard panels from CLB logs

The source article gives three dashboard query patterns.

Time dashboard: average request duration by CLB instance

* |
SELECT
  HISTOGRAM(CAST(__TIMESTAMP__ AS TIMESTAMP), INTERVAL 1 MINUTE) AS dt,
  AVG(request_time) AS "average request duration per CLB instance",
  server_addr
GROUP BY dt, server_addr
ORDER BY dt

This panel is used to observe website response time in real time and identify which CLB instance is slowing down.

The screenshot shows a CLS analysis dashboard. In English, the top area is the time-series result, and the bottom area keeps log details available for drill-down after a spike is found.

The highlighted Chinese operation is Add to dashboard. After running an analysis query and selecting a chart type, the operator saves the chart into a reusable dashboard.

This screenshot is the time dashboard. It translates to: compare request_time by server_addr in one-minute buckets, so operators can quickly see whether latency is isolated to one CLB instance.

Capacity dashboard: request count by real server

* |
SELECT
  HISTOGRAM(CAST(__TIMESTAMP__ AS TIMESTAMP), INTERVAL 1 MINUTE) AS dt,
  COUNT(1) AS "requests per minute to each real server",
  upstream_addr
GROUP BY dt, upstream_addr
ORDER BY dt

This panel checks backend capacity distribution. If one upstream_addr receives an unexpected share of requests, the team can review CLB rules or backend health.

The screenshot shows multiple line charts. In English, each line represents a real server address and the count of requests it receives per minute.

Status-code dashboard: request count by CLB status

* |
SELECT
  HISTOGRAM(CAST(__TIMESTAMP__ AS TIMESTAMP), INTERVAL 1 MINUTE) AS dt,
  COUNT(1),
  status
GROUP BY dt, status
ORDER BY dt

This panel tracks service health by status code. It is useful for separating client errors, backend errors, and normal traffic.

The screenshot combines bar and pie-style views. In English, it is grouping request volume by status so operators can see whether error codes are rising.

The dashboard screenshot shows the outcome of the previous steps: CLB access logs become operational panels rather than one-off search results.

Add real-time alerts from search-analysis results

The source article closes with real-time alerting. CLS can create alert rules from flexible search-analysis queries, attach alert policies, and notify teams through channels such as WeChat, Enterprise WeChat, or webhook.

This screenshot translates to: define the alert query, set the trigger condition, configure scheduling and notification, and route the alert to the selected receiver. For CLB logs, useful conditions include abnormal status-code count, high request_time, or unexpected changes in backend traffic distribution.

Practical CLB log playbook

• Enable CLB access logs either per instance or through batch onboarding.
• Configure the CLS index and enable statistics for fields used in aggregation.
• Start with search examples for URL latency and real-server 4xx requests.
• Build dashboards around request_time, upstream_addr, and status.
• Add alerts for latency spikes, backend error growth, and abnormal request distribution.
• Keep the raw log view near charts so every spike can be investigated with the exact request context.