Docs

Torch Log Service

VKE log collection

Collect VKE logs

This topic explains the features and usage restrictions associated with VKE logs.

Features overview

VKE Container Service leverages Torch Log Service (TLS) to provide log capability, including container log data collection, keyword queries, SQL analysis, and more.

With log capability, container service logs and events can be stored in TLS for persistent storage. If a cluster fails, you can review historical log information in TLS to troubleshoot issues. For details, see Container service log overview.

Container service clusters support log collection for various resources including container logs, component logs, and control plane component logs.

Collection target	Description
Container logs	Container standard output: Container standard output means sending logs from the container to the container’s standard output device (Stdout) and standard error device (Stderr). These two standard output devices are actually the container’s console terminal. Container file path: In addition to the container’s standard output devices, most applications write their logs to log files in fixed paths. You can obtain logs from a specific container by specifying the log file path inside the container. For example: The container service outputs GPU Xid related information to the Pod's log file /var/log/xid.log. You can use this path to access logs, observe the time and details of Xid occurrences, and assist in troubleshooting GPU device issues.
Ingress component log	Supports collecting the standard output logs of the ingress component and sending them to TLS for storage and query.
Component log on control plane	Supports collecting logs from the main control plane components to understand the cluster’s control plane status and keep records.

After enabling real-time log feature, logs are stored in the designated log topic in TLS. You can use query and analysis to retrieve and analyze logs in real time, understand access to popular accelerated sites, and create dashboards or configure monitoring alerts using SQL statements.

Configuration related to VKE container log features includes:

Configuration	Description
Log type	Container log.
Log storage location	The location refers to the projects or topics created manually or automatically on TLS console. For log resources management details, see Manage VKE log resources. Dedicated log project: Custom Dedicated log topic: Created automatically or custom
Log retention period	The default is 30 days. Logs will be deleted automatically after expiration. You can also modify the log retention period based on your business needs.
Log shards	Container logs are preset with 2 shards; component logs are preset with 1 shard. Auto split is enabled by default. When write traffic increases, TLS automatically splits shards to meet data writing needs.
Index settings	Indexes have been configured for all fields.
Log fields	For a detailed list of log fields, see VKE log fields.

Collect VKE logs

VKE log overview and usage limits. For details, see Log overview.

Steps to collect container logs to TLS. For details, see Collect container logs.

Steps to collect component logs to TLS. For details, see Collect ingress component logs.

Steps to collect control plane logs to TLS. For details, see Collect control plane component logs.

VKE log fields

Container/Component log fields

Field	Description
bytes_sent	The number of bytes in the response body returned to the client for the current request.
request_time	The total duration from receiving the request to sending the complete response.
status	HTTP status code. For example, 200, 404, or 500, which indicate whether the request was successful and the type of error if it failed.
request_length	Total length of the HTTP request.
time	The timestamp when the log event occurred, which is the time the server processed the request.
remote_addr	Client IP address.
x_forward_for	X-Forwarded-For header, records the original client IP chain when passing through multiple proxy levels.
request_id	The unique ID that identifies the request.
remote_user	The remote user ID after HTTP authentication.
vhost	Virtual host name.
request_proto	Protocol version used for the request.
request_query	Query string part of the URL.
method	HTTP method, such as GET, POST, PUT, DELETE, and more.
http_referrer	HTTP Referer header.
http_user_agent	Client-side User-Agent string that identifies browser, SDK, or caller type and version.
content	Raw log content or request/response text information.
namespace	Kubernetes namespace where the Pod is located.
pod_name	Pod name used to locate a specific Pod instance.
pod_uid	Unique Pod UID in Kubernetes.
container_name	Container name.
host_ip	Node IP hosting the Pod.
container_id	Container ID assigned by the runtime.
pod_ip	Pod business IP.
image_name	Container image name.
cluster_id	Kubernetes cluster ID.

Control plane log fields

Field	Description
annotations	Key-value pair annotations attached to audit events.
apiVersion	The API version used by audit events or operated objects.
auditID	The unique ID of the audit event.
cluster_id	Kubernetes cluster ID.
impersonatedUser	Impersonation user information.
kind	Type of audit record or affected object.
level	Audit level.
namespace	Namespace where the resource is located.
objectRef	Reference information.
requestObject	The object content submitted in the client request body.
requestReceivedTimestamp	The timestamp when the API Server received this request.
requestURI	The complete request URI.
responseObject	The object content returned by the API Server to the client.
responseStatus	Response status information.
sourceIPs	List of source IP addresses for requests.
stage	Processing stage corresponding to the audit event.
stageTimestamp	Timestamp when the current audit stage record was generated.
user	Authenticated user information.
userAgent	User-Agent of the requesting client.
verb	Operation verbs in the Kubernetes context, such as get, list, create, update, patch, delete, and watch. These verbs correspond to resource operation types.

Last updated: 2026.06.10 10:03:34