Analyze CLB Access Logs with Tencent Cloud CLS

When a load balancer sits in front of an application, many incidents start with the same uncomfortable question: did the request fail before it reached the backend, inside the backend, or while the response was returning through the load balancer?

Tencent Cloud CLB access logs give teams a way to answer that question with searchable, aggregatable evidence. After layer-7 CLB logs are shipped into Tencent Cloud Log Service (CLS), you can search individual requests, compare frontend and backend timings, build per-instance dashboards, and create alerts for latency or HTTP status anomalies.

This guide uses the CLB access log workflow from the source material and turns it into an implementation checklist for operations teams.

Problems CLB Access Logs Help Answer

CLB access logs are useful when backend logs alone cannot explain a request path.

Operational question	Why backend logs are not enough	CLS analysis direction
Some client requests fail during high QPS, but the real server does not receive them.	The request may fail before reaching the real server.	Search by request, client IP, CLB status, and upstream address.
A user reports slow requests, while backend response_time looks normal.	The delay may come from CLB forwarding, connection setup, SSL, or client transfer time.	Compare request_time, upstream_response_time, upstream_connect_time, and upstream_header_time.
Layer-7 internal traffic is abnormal for a period of time.	Application logs may miss listener, domain, protocol, or CLB VIP context.	Group by server_addr, server_name, protocol_type, status, or upstream_addr.
HTTP/2 was enabled, but the team needs proof of adoption.	Backend logs may not record the protocol negotiated at CLB.	Aggregate protocol_type and server_protocol.
Core domains are distributed across multiple CLB instances.	Domain-level traffic share is hard to see across isolated instances.	Group by http_host, server_name, and server_addr.

Enable Layer-7 CLB Logs for a Single Instance

For a single layer-7 CLB instance, enable access logs from the CLB console and bind the logs to a CLS logset and topic.

1. Open the target layer-7 CLB instance.
2. Edit the instance log configuration.
3. Turn on access log collection.
4. Select the CLS logset and log topic. If the right logset or topic does not exist, create it from the access log page first.
5. Submit the configuration.
6. Go to CLS log topic management and edit the index.
7. When logs start arriving, use automatic index configuration and enable statistics for the fields you want to aggregate.

Enabling statistics matters because the workflow later depends on GROUP BY, percentile, histogram, and dashboard panels rather than only raw-text search.

Enable Logs in Batch with a CLB-Specific Logset

Batch onboarding is useful when teams manage multiple CLB instances or want separate topics by business domain. In the source workflow, batch onboarding requires access to the CLB access log entry after allowlist enablement.

Use topic boundaries that match downstream operations:

Topic strategy	When it fits	Downstream use
HTTP layer, cache layer, data layer	Platform teams separate traffic by technical layer.	Different alert rules and retention policies.
Finance, main site, order service	Business teams own different production domains.	Separate dashboards and ownership.
One topic per major CLB group	The priority is instance-level isolation.	Easier per-instance capacity analysis.

After access is enabled, open the CLB access log configuration page, use the fixed CLB logset name, choose retention, add a log topic, bind the relevant CLB instances, and save the configuration. The source material notes that the configuration takes about 5 to 10 minutes to take effect. Once logs arrive, configure indexes and statistics the same way as the single-instance flow.

Key CLB Access Log Fields

The most useful fields fall into five groups.

Group	Fields	How to use them
Request identity	stgw_request_id, request, uri, connection, connection_requests	Trace a request, inspect request shape, and understand connection reuse.
Client and domain	remote_addr, remote_port, http_host, http_user_agent, http_referer, server_name	Diagnose client-side distribution, domain traffic, user agent patterns, and request sources.
CLB listener	protocol_type, server_addr, server_port, server_protocol, vip_vpcid	Compare CLB VIPs, listener ports, protocols, and VPC ownership.
Backend path	upstream_addr, upstream_status	Separate CLB-side status from backend-side status and identify hot or unhealthy real servers.
Timing and size	request_time, upstream_response_time, upstream_connect_time, upstream_header_time, tcpinfo_rtt, ssl_handshake_time, request_length, bytes_sent	Build latency breakdowns, capacity charts, and transfer-size analysis.

The timing fields are especially important:

Field	Meaning
request_time	Total time from the first byte received from the client until the last byte sent back to the client. It includes the client request to CLB, CLB forwarding to the real server, backend response to CLB, and CLB response to the client.
upstream_response_time	Backend request time from starting the connection to the real server until the response is fully received from the real server.
upstream_connect_time	Time spent establishing the TCP connection to the real server.
upstream_header_time	Time from starting the connection to the real server until the backend response header is fully received.
tcpinfo_rtt	TCP round-trip time.
ssl_handshake_time	Time spent on SSL handshake.

Search Recipes for Incident Triage

Use fielded search when you need to narrow a request quickly.

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

Use range filters when you want a family of status codes from a specific real server.

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

For latency investigations, start with request_time. If the total request time is high while upstream_response_time is normal, the delay is likely outside backend processing. If upstream_connect_time or upstream_header_time is high, the backend connection path needs attention.

Build Dashboards for Time, Capacity, and Status

CLS dashboards turn the same queries into operational views.

Request Time by CLB Instance

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

This panel helps compare instances and identify whether latency is isolated or shared across a wider CLB fleet.

Requests per Real Server

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

This panel is useful for capacity distribution. If one real server receives a disproportionate share of traffic, the team can check balancing rules, backend health, or instance capacity.

Status Code Health

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

Use this panel to see status-code mix over time. A sudden increase in 4xx or 5xx responses becomes visible without downloading logs.

After a query returns the expected chart, add it to a dashboard from the analysis result page. Keep the dashboard organized around operating questions: latency, capacity, status, protocol distribution, and domain share.

Turn CLB Log Analysis into Alerts

CLS alerting can be built from the same search and analysis layer. A practical CLB alert strategy starts with a small set of rules:

Alert	Query basis	Notification purpose
High total request time	request_time percentile or average by instance/domain	Detect user-visible latency.
Backend response slowdown	upstream_response_time by upstream_addr	Separate backend slowdowns from CLB or client-side delay.
Connection setup pressure	upstream_connect_time by real server	Catch backend connection or network issues.
Status code spike	count by status and time bucket	Detect 4xx/5xx growth.
Protocol adoption drift	group by protocol_type	Validate HTTP/2 or HTTPS rollout.

Notifications can be routed to WeChat, WeCom, webhook, or other channels supported by the alert policy. The important part is to keep the alert message actionable: include the affected domain, CLB VIP, real server, status code, and top client IPs when those dimensions are available.

Quick Implementation Checklist

• Enable layer-7 CLB access logs.
• Bind the logs to a CLS logset and topic.
• Configure indexes and enable statistics for timing, status, domain, protocol, and upstream fields.
• Verify raw logs by searching one known request or URL.
• Build dashboard panels for latency, request volume, and status code health.
• Add alert rules for high latency, backend slowdown, and error spikes.
• Split topics by business or technical layer when different owners need different retention, delivery, or alert policies.

FAQ

Should CLB logs replace backend logs?

No. CLB logs answer traffic path, forwarding, protocol, and timing questions that backend logs may not contain. Backend logs are still needed for application behavior.

Which field should I start with for slow requests?

Start with request_time, then compare it with upstream_response_time, upstream_connect_time, and upstream_header_time. This separates total user-visible latency from backend processing and connection timing.

Why enable statistics for fields during index setup?

Without statistics, the topic may still support search, but dashboard and aggregation workflows become limited. CLB operations usually need grouped metrics, not only raw events.