In Kubernetes environments, container logs are often scattered and difficult to centralize and manage, leading to inefficient troubleshooting and high operational costs. You can centralize log collection and perform structured processing by deploying LoongCollector in DaemonSet mode and creating a collection configuration in the Simple Log Service (SLS) console. This improves the efficiency of log retrieval, problem diagnosis, and observability analysis.
Requirements
-
Runtime environment:
-
Supports Container Service for Kubernetes (ACK) (managed and dedicated editions) and self-managed Kubernetes clusters.
-
Requires Kubernetes 1.10.0 or later with support for
Mount propagation: HostToContainer. -
Container runtime (Docker and Containerd only)
-
Docker:
-
Requires access to docker.sock.
-
Standard output collection supports only the JSON log driver.
-
Only the overlay and overlay2 storage drivers are supported. For other storage drivers, you must manually mount the log directory.
-
-
Containerd: Requires access to containerd.sock.
-
-
-
Resource requirements: LoongCollector (Logtail) runs with
system-cluster-criticalpriority. Do not deploy it if your cluster has insufficient resources; otherwise, existing Pods on a node may be evicted.-
CPU: Reserve at least 0.1 core.
-
Memory: Reserve at least 150 MB for the collection component and at least 100 MB for the controller component.
-
Actual resource usage depends on the collection rate, the number of monitored directories and files, and data transfer congestion. Ensure that resource utilization stays below 80% of the limit.
-
-
Permission requirements: The Alibaba Cloud account or RAM user used for deployment must have the
AliyunLogFullAccesspermission.To create a custom policy, refer to the AliyunCSManagedLogRolePolicy system policy. Copy the permissions from the system policy and grant them to the target RAM user or role for fine-grained permission configuration.
Collection configuration
-
Install LoongCollector: Deploy LoongCollector in DaemonSet mode. This ensures that a collection container runs on each node in the cluster to collect logs from all containers on that node.
For information about the sidecar pattern, see Collect text logs from Kubernetes Pods by using the sidecar pattern.
-
Create a Logstore: A Logstore stores collected logs.
-
Create and configure log collection rules
-
Global and input configuration: Define the name of the collection configuration and specify the log source and scope.
-
Log processing and structuring: Configure processing rules based on the log format.
-
Multiline logs: For single log entries that span multiple lines, such as Java stack traces or Python tracebacks. Use a regular expression to identify the start of each log entry.
-
Structured parsing: Configure parsing plugins, such as regular expression, delimiter, or NGINX mode, to extract raw log strings into structured key-value pairs for easier querying and analysis.
-
-
Log filtering: Configure collection blacklists and content filtering rules to filter for valid logs. This helps reduce redundant data transmission and storage.
-
Log categorization: Configure log topics and tags to distinguish logs from different services, containers, or source paths.
-
-
Query and analysis configuration: Full-text index is enabled by default to support keyword searches. We recommend enabling field index to perform precise queries and analyses on structured fields, which improves search efficiency.
-
Verification and troubleshooting: After you complete the configuration, verify that logs are collected successfully. If you encounter issues such as missing data, heartbeat failures, or parsing errors, see Troubleshooting FAQ.
Step 1: Install LoongCollector
LoongCollector is the next-generation log collection agent for Simple Log Service and an upgrade to Logtail. LoongCollector and Logtail cannot coexist. To install Logtail, see Install, run, upgrade, and uninstall Logtail.
This topic covers only the basic installation of LoongCollector. For more information about the parameters, see Installation and configuration. If you have already installed LoongCollector or Logtail, skip this step and proceed to Step 2: Create a logstore.
A change in the host time while LoongCollector (Logtail) is running can cause duplicate log collection or data loss.
ACK cluster
By default, LoongCollector sends logs to a Simple Log Service Project in the current Alibaba Cloud account.
Log on to the ACK console. In the left navigation pane, click Clusters.
-
Click the name of the target cluster to open its details page.
-
In the left-side navigation pane, click Add-ons.
-
On the Logs and Monitoring tab, find loongcollector and click Install.
NoteWhen you create a cluster, you can select Enable Log Service on the Component Configurations page. You can choose to Create Project or Select Project.
After the installation, Simple Log Service automatically creates the following resources in the current account. You can view them on the Simple Log Service console.
Type
Parameter
Description
Project
k8s-log-${cluster_id}A resource management unit that isolates logs from different services.
To create a Project for more flexible log resource management, see Create a Project.
machine group
k8s-group-${cluster_id}A set of log collection nodes.
ImportantThe LoongCollector component does not create a logstore named config-operation-log. If this logstore already exists, LoongCollector will not write new logs to it.
Self-managed cluster
-
Connect to your Kubernetes cluster and run the command that corresponds to your cluster's region:
Chinese mainland regions
wget https://aliyun-observability-release-cn-shanghai.oss-cn-shanghai.aliyuncs.com/loongcollector/k8s-custom-pkg/3.0.12/loongcollector-custom-k8s-package.tgz; tar xvf loongcollector-custom-k8s-package.tgz; chmod 744 ./loongcollector-custom-k8s-package/k8s-custom-install.shRegions outside China
wget https://aliyun-observability-release-ap-southeast-1.oss-ap-southeast-1.aliyuncs.com/loongcollector/k8s-custom-pkg/3.0.12/loongcollector-custom-k8s-package.tgz; tar xvf loongcollector-custom-k8s-package.tgz; chmod 744 ./loongcollector-custom-k8s-package/k8s-custom-install.sh -
Change to the
loongcollector-custom-k8s-packagedirectory and modify the./loongcollector/values.yamlconfiguration file.# ===================== Required information ===================== # The Project where logs from this cluster are collected. Example: k8s-log-custom-sd89ehdq projectName: "" # The region where the Project is located. Example: cn-shanghai region: "" # The ID of the Alibaba Cloud account that owns the Project. Enclose the ID in quotation marks (""). Example: "123456789" aliUid: "" # The network type. Valid values: Internet and Intranet. Default value: Internet. net: Internet # The AccessKey ID and AccessKey secret of the Alibaba Cloud account or RAM user. The AliyunLogFullAccess policy is required. accessKeyID: "" accessKeySecret: "" # A custom cluster ID. The ID can contain only uppercase letters, lowercase letters, digits, and hyphens (-). clusterID: "" -
In the
loongcollector-custom-k8s-packagedirectory, run the following command to install LoongCollector and its dependencies:bash k8s-custom-install.sh install -
After the installation is complete, check the status of the component.
If a pod fails to start, verify the configuration in the values.yaml file and ensure the required images have been pulled.
# Check the pod status kubectl get po -n kube-system | grep loongcollector-dsSimple Log Service also automatically creates the following resources, which you can view on the Simple Log Service console.
Type
Parameter
Description
Project
The value of
projectNamedefined in the values.yaml fileA resource management unit that isolates logs from different services.
To create a Project for more flexible log resource management, see Create a Project.
machine group
k8s-group-${cluster_id}A set of log collection nodes.
ImportantThe LoongCollector component does not create a logstore named config-operation-log. If this logstore already exists, LoongCollector will not write new logs to it.
Step 2: Create a logstore
A logstore is the storage unit in Simple Log Service for storing collected logs.
-
Log on to the Simple Log Service console and click the name of the target project.
-
In the left-side navigation pane, choose
, and then click + to create a logstore:-
Logstore Name: Enter a unique name within the project. This name cannot be modified after creation.
-
Logstore Type: Select Standard or Query based on the feature comparison.
-
Billing Mode:
-
Pay-by-feature (Cannot Be Changed): You are billed separately for each resource, such as storage, indexes, and read/write operations. This mode is suitable for small-scale use cases or scenarios where feature usage is uncertain.
-
Pay-by-ingested-data: You are billed only for the volume of raw data that you write. This mode provides 30 days of free storage and free features such as data transformation and delivery. It is suitable for business scenarios where the storage period is around 30 days or the data processing pipeline is complex.
-
-
Data Retention Period: Set the number of days to retain logs, from 1 to 3,650. A value of 3,650 indicates permanent retention. The default is 30 days.
-
Leave the other settings at their default values and click OK. For more information, see Manage a logstore.
-
Step 3: Configure log collection rules
Define what logs LoongCollector collects, how to parse them, and how to filter content. Then, apply the configuration to a registered machine group.
-
On the
LogStores page, click the
icon next to the target LogStore name to expand it. -
Click the
icon next to Import Data. In the Quick Data Import dialog box, select a template for your log source, and then click Integrate Now:-
For container standard output, select K8s-Standard Output-New Version.
Templates for collecting container standard output are available in new and old versions. We recommend that you use the new version. For a comparison of the new and old versions, see Appendix: Comparison of New and Old Container Standard Output Versions.
-
For cluster text logs, select Kubernetes-File.
-
-
Complete the Machine Group Configurations, and then click Next:
-
Scenario: Select Docker Containers.
-
Deployment Method: Select ACK DaemonSet or Self-managed Cluster in DaemonSet Mode.
-
From the Source Machine Group list, add the system-created machine group
k8s-group-${cluster_id}to the Applied Machine Group list on the right.
-
-
On the Logtail Configuration page, specify the following parameters and click Next.
1. Global and input configuration
Before you start, ensure you have selected a data collection template and applied it to a machine group. In this step, you define the collection configuration name, log source, and scope.
Container standard output
Global Configurations
-
Configuration Name: Specify a custom name for the collection configuration. The name must be unique within the Project and cannot be changed after creation. The name must meet the following requirements:
-
It can contain only lowercase letters, digits, hyphens (-), and underscores (_).
-
It must start and end with a lowercase letter or a digit.
-
Input Configuration
-
Enable the switches for Stdout and Stderr and/or Standard Error as needed. By default, both are enabled.
ImportantWe recommend not enabling both standard output and standard error, as this may lead to disorganized log entries.
Cluster text logs
Global Configurations:
-
Configuration Name: Specify a custom name for the collection configuration. The name must be unique within the Project and cannot be changed after creation. The name must meet the following requirements:
-
It can contain only lowercase letters, digits, hyphens (-), and underscores (_).
-
It must start and end with a lowercase letter or a digit.
-
Input Configurations:
-
File Path Type:
-
Path in Container: Collect log files from within the container.
-
Host Path: Collect local service logs from the host.
-
-
File Path: The absolute path for log collection.
-
Linux: The path must start with a forward slash (
/). For example,/data/mylogs/**/*.logindicates all files that have the.logextension in the/data/mylogsdirectory and its subdirectories. -
Windows: The path must start with a drive letter. Example:
C:\Program Files\Intel\**\*.Log.
-
-
Maximum Directory Monitoring Depth: The maximum directory depth that the wildcard
**can match in the File Path. The default value is 0, which indicates the current directory only. The valid range is 0 to 1,000.We recommend setting this value to 0 and specifying the path to the directory where the files are located.
2. Log processing and structuring
Configure log processing rules to convert raw, unstructured logs into structured, searchable data to improve log query and analysis efficiency. We recommend adding a log sample before you configure the rules.
In the Processor Configurations section of the Logtail Configuration page, click Add Sample Log and enter a sample of the log content. The system identifies the log format from the sample and helps you generate regular expressions and parsing rules, simplifying the configuration process.
Scenario 1: Process multi-line logs
Logs such as Java exception stack traces and JSON objects often span multiple lines. In the default collection mode, these logs are split into multiple incomplete records, resulting in a loss of context. To address this, enable multi-line mode and configure a first-line regular expression to merge consecutive lines of a log into a single, complete entry.
Example:
|
Unprocessed raw log |
Default collection mode: Each line becomes a separate log, breaking the stack trace and losing context. |
Multi-line mode enabled: A first-line regular expression identifies the full log, preserving its semantic structure. |
|
The raw log contains a complete Java exception stack trace. It starts with a timestamp and an ERROR level, and includes a |
In the default mode, the raw log is split into multiple separate records. Each line of the stack trace is stored in an individual |
With multi-line mode enabled, the complete exception stack trace is merged into a single log record. The |
Procedure: In the Processor Configurations section of the Logtail Configuration page, enable Multi-line Mode:
-
Type: Select Custom or Multi-line JSON.
-
Custom: If the log format is not fixed, you must configure a Regex to Match First Line to identify the starting line of each entry.
-
Regex to Match First Line: You can automatically generate or manually enter a regular expression. The expression must match an entire line. For example, the regular expression that matches the data in the preceding example is
\[\d+-\d+-\w+:\d+:\d+,\d+]\s\[\w+]\s.*.-
Automatic generation: Click Auto-Generate Regular Expression. Then, in the Log Sample text box, select the log content to extract and click Generate Regex.
-
Manual input: Click Manually Enter Regular Expression. After you enter the expression, click Validate.
-
-
-
Multi-line JSON: Select this option if your raw logs are all in standard JSON format. The service automatically handles line breaks within a single JSON log.
-
-
Processing Method If Splitting Fails:
-
Discard: If a text segment does not match the first-line rule, it is discarded.
-
Retain Single Line: Unmatched text is split and retained as single-line logs.
-
Scenario 2: Structuring logs
When raw logs are unstructured or semi-structured text, such as NGINX access logs or application output logs, direct querying and analysis can be inefficient. The service provides a variety of data parsing processors that can automatically convert raw logs of different formats into structured data. This creates a solid data foundation for subsequent analysis, monitoring, and alerting.
Example:
|
Unprocessed raw log |
Structured log output |
|
|
Procedure: In the Processor Configurations section of the Logtail Configuration page:
-
Add parsing processor: Click Add Processor, and then configure a regular expression, delimiter, or JSON parsing processor based on the log format. In this example, an NGINX log is collected. Select .
-
NGINX Log Configuration: Copy the entire
log_formatdefinition from the NGINX server configuration file (nginx.conf) and paste it into the text box.Example:
log_format main '$remote_addr - $remote_user [$time_local] "$request" ''$request_time $request_length ''$status $body_bytes_sent "$http_referer" ''"$http_user_agent"';ImportantThe format definition here must exactly match the format used to generate the logs on the server. Otherwise, log parsing will fail.
-
Common configuration parameters: The following parameters are common to multiple data parsing processors and have consistent functions and usage.
-
Original Field: Specify the name of the source field to parse. The default value is
content, which represents the entire collected log entry. -
Keep Original Field on Parse Failure: We recommend enabling this option. If a log cannot be successfully parsed by the processor (for example, due to a format mismatch), this option ensures that the original log content is retained in the specified original field.
-
Keep Original Field on Parse Success: If selected, the original log content is retained even if the log is successfully parsed.
-
3. Log filtering
During log collection, indiscriminately collecting large volumes of low-value or irrelevant logs, such as those at the DEBUG or INFO level, can waste storage resources, increase costs, impair query efficiency, and introduce data leakage risks. To address these issues, you can implement fine-grained filtering policies for efficient and secure log collection.
Filter by content
Filter logs based on field content, such as collecting only logs where the level is WARNING or ERROR.
Example:
|
Unprocessed raw logs |
Collect only |
|
|
Procedure: In the Processor Configurations section of the Logtail Configuration page:
Click Add Processor and select .
-
Field Name: The log field to filter by.
-
Field Value: The regular expression used for filtering. Only full-text matching is supported. Partial keyword matching is not supported.
Blacklist
Use a blacklist to exclude specified directories or files, preventing irrelevant or sensitive logs from being uploaded.
Procedure: In the section of the Logtail Configuration page, enable Collection Blacklist and click Add.
Supports exact and wildcard matching for directories and filenames. The only supported wildcards are the asterisk (*) and the question mark (?).
-
File Path Blacklist: The file paths to ignore. Examples:
-
/home/admin/private*.log: Ignores all files in the/home/admin/directory that start withprivateand end with.log. -
/home/admin/private*/*_inner.log: Ignores files that end with_inner.loglocated in any subdirectory that starts withprivateunder the/home/admin/directory.
-
-
File Blacklist: The filenames to ignore during collection. Example:
-
app_inner.log: Ignores all files namedapp_inner.logduring collection.
-
-
Directory Blacklist: The directory path must not end with a forward slash (/). Examples:
-
/home/admin/dir1/: This blacklist entry is invalid and will be ignored. -
/home/admin/dir*: Ignores all files in subdirectories under/home/admin/whose names start withdir. -
/home/admin/*/dir: Ignores all files in any second-level subdirectory nameddirunder the/home/admin/directory. For example, files in the/home/admin/a/dirdirectory are ignored, but files in the/home/admin/a/b/dirdirectory are collected.
-
Container filtering
Set collection conditions based on container metadata, such as environment variables, pod labels, namespaces, and container names, to precisely control log collection from specific containers.
Procedure: In the Input Configurations section of the Logtail Configuration page, enable Container Filtering and click Add.
Multiple conditions are combined with a logical AND. All regular expression matching is based on Go's RE2 engine, which has some limitations compared to engines like PCRE. Ensure your regular expressions comply with the guidelines in Appendix: Regular Expression Usage Limits (Container Filtering).
-
Environment Variable Blacklist/Whitelist: Specify conditions based on the environment variables of the target containers.
-
K8s Pod Label Blacklist/Whitelist: Specify conditions based on the labels of the Pods where the target containers are located.
-
K8s Pod Name Regex Match: Specify containers to collect from by matching the Pod name.
-
K8s Namespace Regex Match: Specify containers to collect from by matching the namespace name.
-
K8s Container Name Regex Match: Specify containers to collect from by matching the container name.
-
Container Label Blacklist/Whitelist: Collect logs from containers whose labels match the specified conditions. This feature is intended for Docker scenarios and is not recommended for Kubernetes scenarios.
4. Log categorization
In scenarios where multiple applications or instances share the same log format, it can be difficult to distinguish the log source. This leads to missing context during queries and inefficient analysis. To address this, you can configure log topics and log tagging for automated context association and logical categorization.
Log topic
When logs from multiple applications or instances share the same format but different paths (e.g., /apps/app-A/run.log and /apps/app-B/run.log), it can be hard to distinguish their sources. In such cases, you can generate a topic based on machine group, a custom name, or file path extraction to flexibly differentiate logs from various business services or paths.
Procedure: Go to and select a topic generation method. The following three methods are supported:
-
Machine Group Topic: If a collection configuration is applied to multiple machine groups, LoongCollector automatically uses the server's machine group name as the value of the
__topic__field. This method is suitable for scenarios where logs are categorized by host cluster. -
Custom: Use the format
customized://<custom_topic_name>, for example,customized://app-login. This method is suitable for static topic scenarios with fixed business identifiers. -
File Path Extraction: Extract key information from the full path of the log file to dynamically tag the log source. This method is suitable for situations where multiple users or applications share the same log filename but have different paths.
If multiple users or services write logs to different top-level directories but use the same subdirectory paths and filenames, the source cannot be distinguished by filename alone. Example:
/data/logs ├── userA │ └── serviceA │ └── service.log ├── userB │ └── serviceA │ └── service.log └── userC └── serviceA └── service.logIn this case, you can configure File Path Extraction and use a regular expression to extract key information from the full path. The matched result is then uploaded to the LogStore as the log topic.
Extraction rules
When you configure a regular expression, the system automatically determines the output field format based on the number and naming of the capturing groups, as described in the following rules:
In the regular expression for the file path, you must escape the forward slash (/).
Capturing group type
Use case
Generated field
Regex example
Matched path example
Generated field
Single capturing group (one
(.*?))Only one dimension is needed to distinguish the source, such as a username or environment.
Generates the
__topic__field.\/logs\/(.*?)\/app\.log/logs/userA/app.log__topic__:userAMultiple unnamed capturing groups (multiple instances of
(.*?))Multiple dimensions are needed, but without semantic labels.
Generates a tag field in the format
__tag__:__topic_{i}__, where{i}is the sequence number of the capturing group.\/logs\/(.*?)\/(.*?)\/app\.log/logs/userA/svcA/app.log__tag__:__topic_1__:userA;__tag__:__topic_2__:svcAMultiple named capturing groups (using
(?P<name>.*?))Multiple dimensions are needed, and clear field meanings are desired for easy querying and analysis.
Generates a tag field in the format
__tag__:{name}.\/logs\/(?P<user>.*?)\/(?P<service>.*?)\/app\.log/logs/userA/svcA/app.log__tag__:user:userA;__tag__:service:svcA
Log tagging
Enable log tag enrichment to extract key information from container environment variables or Kubernetes Pod labels and attach this information as tags for fine-grained log grouping.
Procedure: In the Input Configurations section of the Logtail Configuration page, enable Log Tag Enrichment and click Add.
-
Environment Variables: Configure an environment variable name and a tag name. The value of the environment variable is stored as the value of the tag.
-
Environment Variable Name: The name of the environment variable to extract.
-
Tag Name: The name of the tag that stores the environment variable's value.
-
-
Pod Labels: Configure a Pod label name and a tag name. The value of the Pod label is stored as the value of the tag.
-
Pod Label Name: The name of the Kubernetes Pod label to extract.
-
Tag Name: The name of the tag that stores the Pod label's value.
-
5. Output configuration
By default, all logs are collected and sent to the current LogStore with lz4 compression. To dispatch logs from the same source to different LogStores, follow the steps below.
Multi-destination dispatch
-
Multi-destination dispatch is available only in LoongCollector 3.0.0 and later. Logtail does not support this feature.
-
You can configure a maximum of five output destinations.
-
After you configure multiple output destinations, this collection configuration will no longer be listed under the current LogStore. To view, modify, or delete a multi-destination dispatch configuration, see How do I manage multi-destination dispatch configurations?.
Procedure: In the Output Configurations section of the Logtail Configuration page:
-
Click
to expand the output configuration. -
Click Add Output Targets and complete the following configuration:
-
Logstores: Select the destination LogStore.
-
Compression Method: Supported types are lz4 and zstd.
-
Route Settings: Route and dispatch logs based on their tag fields. Logs that match the routing configuration are sent to the destination LogStore. If this configuration is left empty, all collected logs are sent to the destination LogStore.
-
Tag Name: The name of the tag field used for routing. Enter the field name directly, such as
__path__, without the__tag__:prefix. Tag fields fall into the following two categories:For more information about tags, see Manage LoongCollector Collection Tags.
-
Agent-related: Tags that originate from the collection agent and are independent of processors. Examples:
__hostname__,__user_defined_id__. -
Input processor-related: Tags that are sourced from input processors, which add contextual information to logs. Examples:
__path__for file collection;_pod_name_and_container_name_for K8s collection.
-
-
Tag Value: If a log's tag field matches this value, the log is sent to the destination LogStore.
-
Discard this tag?: If enabled, the uploaded logs will not contain this tag field.
-
-
Step 4: Query and analysis
After configuring log processing and plugins, click Next to open the Query and Analysis Configurations page:
-
By default, the full-text index is enabled, allowing you to search for keywords in raw log content.
-
To run precise queries by field, click Automatic Index Generation after the Preview Data loads. Log Service then generates a field index based on the first entry in the preview data.
After completing the configuration, click Next to finish the collection process.
Step 5: Validation and troubleshooting
After creating a collection configuration and applying it to a machine group, the system automatically deploys the configuration and starts collecting incremental logs.
View collected logs
-
Confirm that new logs are being written to the log file: LoongCollector collects only incremental logs. Run the
tail -f /path/to/your/log/filecommand and trigger a service operation to generate new logs. -
Query logs: Go to the query and analysis page of the target Logstore and click Search & Analyze. The default time range is the last 15 minutes. Check for new logs. By default, each collected container text log includes the following fields:
Field name
Description
__tag__:__hostname__
The name of the container host.
__tag__:__path__
The path of the log file within the container.
__tag__:_container_ip_
The IP address of the container.
__tag__:_image_name_
The name of the image used by the container.
__tag__:_pod_name_
The name of the Pod.
__tag__:_namespace_
The Pod's namespace.
__tag__:_pod_uid_
The unique identifier (UID) of the Pod.
Troubleshooting common issues
Machine group heartbeat failure
-
Check the user identifier: If your server is not an ECS instance, or if the ECS instance and the Project belong to different Alibaba Cloud accounts, verify that the specified directory contains the correct user identifier.
-
Linux: Run the
cd /etc/ilogtail/users/ && touch <uid>command to create the user identifier file. -
Windows: Go to the
C:\LogtailData\users\directory and create an empty file named<uid>.
If a file named after the current Project's Alibaba Cloud account ID exists in the specified path, the user identifier is configured correctly.
-
-
Check the machine group identifier: If you use a machine group with a custom ID, verify that a
user_defined_idfile exists in the specified directory. If it exists, check that its content matches the custom ID configured for the machine group.-
Linux:
# Configure the custom ID. If the directory does not exist, create it manually. echo "user-defined-1" > /etc/ilogtail/user_defined_id -
Windows: In the
C:\LogtailDatadirectory (create it if it does not exist), create auser_defined_idfile and write the custom ID to it.
-
-
If both the user identifier and machine group identifier are configured correctly, see LoongCollector (Logtail) Machine Group Troubleshooting Guide for more troubleshooting steps.
Log collection or format errors
Troubleshooting approach: These errors indicate that the network connection and basic configuration are normal. The cause is typically a mismatch between the log content and the parsing rules. View the specific error message to locate the cause:
-
On the Logtail Configuration page, click the name of the failing LoongCollector (Logtail) configuration. On the Log Collection Error tab, click Select Time Range to set the query time range.
-
In the section, check the alert type of the error log and find the corresponding solution in Common Data Collection Errors.
Next steps
-
Data visualization: Use a visualization dashboard to monitor key metric trends.
-
Automatic alerting for data anomalies: Set an alert policy to detect system anomalies in real time.
Troubleshooting container log collection
-
After you configure LoongCollector (Logtail), if the target log file contains no new logs, LoongCollector (Logtail) does not collect data from it.
FAQ
Manage multi-destination distribution configurations
Because multi-destination distribution configurations are associated with multiple Logstores, they must be managed on the Project-level management page:
-
Log on to the Simple Log Service Console and click the name of the target Project.
-
On the Project page, click
in the left-side navigation pane.NoteThis page centrally manages all collection configurations in the Project, including remaining configurations from Logstores that were accidentally deleted.
Transfer ACK cluster logs to another account
You can send container logs to a Simple Log Service Project in another Alibaba Cloud account by manually installing the LoongCollector (Logtail) component in the ACK cluster and configuring it with the target account's Alibaba Cloud account ID or access credential (AccessKey).
Scenario: To collect log data from an ACK cluster into a Simple Log Service Project in a different Alibaba Cloud account for reasons such as organizational structure, permission isolation, or centralized monitoring, manually install LoongCollector (Logtail) to enable cross-account collection.
Procedure: Follow these steps to manually install LoongCollector. For more information, see Install and configure Logtail.
-
Connect to your Kubernetes cluster and run the command that corresponds to your cluster's region:
Chinese mainland regions
wget https://aliyun-observability-release-cn-shanghai.oss-cn-shanghai.aliyuncs.com/loongcollector/k8s-custom-pkg/3.0.12/loongcollector-custom-k8s-package.tgz; tar xvf loongcollector-custom-k8s-package.tgz; chmod 744 ./loongcollector-custom-k8s-package/k8s-custom-install.shRegions outside China
wget https://aliyun-observability-release-ap-southeast-1.oss-ap-southeast-1.aliyuncs.com/loongcollector/k8s-custom-pkg/3.0.12/loongcollector-custom-k8s-package.tgz; tar xvf loongcollector-custom-k8s-package.tgz; chmod 744 ./loongcollector-custom-k8s-package/k8s-custom-install.sh -
Change to the
loongcollector-custom-k8s-packagedirectory and modify the./loongcollector/values.yamlconfiguration file.# ===================== Required information ===================== # The Project where logs from this cluster are collected. Example: k8s-log-custom-sd89ehdq projectName: "" # The region where the Project is located. Example: cn-shanghai region: "" # The ID of the Alibaba Cloud account that owns the Project. Enclose the ID in quotation marks (""). Example: "123456789" aliUid: "" # The network type. Valid values: Internet and Intranet. Default value: Internet. net: Internet # The AccessKey ID and AccessKey secret of the Alibaba Cloud account or RAM user. The AliyunLogFullAccess policy is required. accessKeyID: "" accessKeySecret: "" # A custom cluster ID. The ID can contain only uppercase letters, lowercase letters, digits, and hyphens (-). clusterID: "" -
In the
loongcollector-custom-k8s-packagedirectory, run the following command to install LoongCollector and its dependencies:bash k8s-custom-install.sh install -
After the installation is complete, check the status of the component.
If a pod fails to start, verify the configuration in the values.yaml file and ensure the required images have been pulled.
# Check the pod status kubectl get po -n kube-system | grep loongcollector-dsSimple Log Service also automatically creates the following resources, which you can view on the Simple Log Service console.
Type
Parameter
Description
Project
The value of
projectNamedefined in the values.yaml fileA resource management unit that isolates logs from different services.
To create a Project for more flexible log resource management, see Create a Project.
machine group
k8s-group-${cluster_id}A set of log collection nodes.
ImportantThe LoongCollector component does not create a logstore named config-operation-log. If this logstore already exists, LoongCollector will not write new logs to it.
Multiple configurations for a single source
By default, Simple Log Service uses only one collection configuration per log source to prevent data duplication:
-
Each text log file can be matched with only one Logtail collection configuration.
-
For a container's standard output (stdout):
-
If you use the new standard output template, only one collection configuration can collect from stdout by default.
-
The legacy standard output template supports multiple collections by default without extra configuration.
-
-
Log on to the Simple Log Service Console and go to the target Project.
-
In the left-side navigation pane, click
Logstores and find the target Logstore. -
Click the
icon next to the Logstore name to expand its details. -
Click Logtail Configuration. In the configuration list, find the target Logtail configuration and click Manage Logtail Configuration in the Actions column.
-
On the configuration page, click Edit and scroll down to the Input Configurations section.
-
For text file logs, enable Allow File to Be Collected for Multiple Times.
-
For container standard output, enable Allow Collection by Different Logtail Configurations.
-
Dependency error during uninstallation
Symptom: When you try to uninstall the loongcollector (logtail-ds) log collection component in Container Service for Kubernetes (ACK), the system reports the following error:
Dependencies of addons are not met: terway-eniip depends on logtail-ds(>0.0) whose version is v3.x.x.x-aliyun or will be v3.x.x.x-aliyun
Cause: This error occurs because the terway-eniip network plugin's log collection feature creates a dependency on the loongcollector (logtail-ds) component. Therefore, ACK prevents uninstallation until this dependency is removed.
Solution: Follow these steps to remove the dependency before uninstalling the component:
-
Log on to the ACK Console.
-
In the cluster list, click the name of the target cluster.
-
In the left-side navigation pane, click Add-ons.
-
On the Add-ons page, find the
terway-eniipcomponent and click . -
In the confirmation dialog box that appears, click OK.
-
After the configuration is applied, try to uninstall the loongcollector (logtail-ds) component again.
Delayed or truncated last log entry
Analysis: Log truncation often occurs when the last line in a log file lacks a line feed character, or when a multiline log entry (such as an exception stack) is incomplete. This happens because the collector cannot determine if a log entry is complete, which may cause the final segment to be split prematurely or reported after a delay. The handling mechanism varies by the LoongCollector (Logtail) version:
-
Versions earlier than 1.8:
If the last line of a log lacks a line feed (or carriage return), or if a multiline log is incomplete, the collector waits for the next write operation to trigger the output. This can cause the last log entry to be held for an extended period until a new log is written. -
Version 1.8 and later:
These versions introduce a timeout flush mechanism to prevent logs from being held indefinitely. When the collector detects an incomplete log line, a timer starts. After the timeout period, the current buffer is automatically submitted, ensuring the log is eventually collected.-
Default timeout: 60 seconds (ensures log integrity in most scenarios).
-
You can adjust this value based on your needs, but do not set it to 0. Setting the value to 0 may cause log truncation or partial data loss.
-
Solution:
You can extend the timeout period to ensure logs are fully written before being collected:
-
Log on to the Simple Log Service Console and go to the target Project.
-
In the left-side navigation pane, click
Logstores and find the target Logstore. -
Click the
icon next to the Logstore name to expand its details. -
Click Logtail Configuration. In the configuration list, find the target Logtail configuration and click Manage Logtail Configuration in the Actions column.
-
On the configuration page, click Edit.
-
Navigate to and add the following JSON configuration to customize the timeout period.
{ "FlushTimeoutSecs": 1 }-
Default value: Determined by the
default_reader_flush_timeoutstartup parameter, which is typically a few seconds. -
Unit: Seconds.
-
Recommended value: ≥1. Do not set this to 0, as it may cause log truncation or partial data loss.
-
-
-
After you complete the configuration, click OK.
Network endpoint failover
If LoongCollector (Logtail) detects a communication anomaly on the internal network, such as a network failure or connection timeout, it automatically fails over to the public network endpoint for data transmission. This ensures continuous and reliable log collection, preventing log backlogs or data loss.
-
LoongCollector: Automatically switches back to the internal network once connectivity is restored.
-
Logtail: Does not automatically switch back. You must manually restart the component to resume communication over the internal network.
Appendix: Native processor reference
In the Processor Configurations section of the Logtail Configuration page, add processors to structure raw logs. To add a processing plugin to an existing configuration:
-
In the navigation pane on the left, choose
Logstores and find the target logstore. -
Click the
icon before its name to expand the logstore. -
Click Logtail Configuration. In the configuration list, find the target Logtail configuration and click Manage Logtail Configuration in the Actions column.
-
On the Logtail configuration page, click Edit.
This section introduces only commonly used processing plugins that cover common log processing use cases. For more features, see Extended processors.
Rules for combining plugins (for LoongCollector / Logtail 2.0 and later):
-
Native and extended processors can be used independently or combined as needed.
-
Prioritize native processors because they offer better performance and stability.
-
When native features cannot meet your business needs, add extended processors after the configured native ones for supplementary processing.
Order constraint:
Plugins run sequentially in configured order, forming a processing chain. All native processors must precede any extended processors. After adding an extended processor, you cannot add more native processors.
Data parsing (regex mode)
You can use regular expressions to extract fields from logs and parse the logs into key-value pairs. Each field can then be queried and analyzed independently.
Example:
|
Raw log |
Result |
|
|
Procedure: On the Logtail Configuration page, in the Processor Configurations section, click Add Processor, and then select :
-
Regular Expression: The regular expression used to match logs. You can automatically generate or manually enter an expression.
-
Auto-generate a regular expression:
-
Click Auto-generate regular expression.
-
In the Log Sample field, highlight the log content that you want to extract.
-
Click Generate regular expression.
After you highlight the content, the Generate regular expression button appears above the log text.
-
-
Manually enter a regular expression based on the log format.
After you complete the configuration, click Validate to test whether the regular expression can correctly parse the log content.
-
-
Extracted Field: Set the field names (keys) for the extracted log values.
-
For information about other parameters, see the description of common configuration parameters in Use Case 2: Structured logs.
Data parsing (delimiter mode)
You can use a delimiter to parse log content into key-value pairs. Both single-character and multi-character delimiters are supported.
Example:
|
Raw log |
Using a specified character |
|
|
Procedure: On the Logtail Configuration page, in the Processor Configurations section, click Add Processor, and then select :
-
Delimiter: The character used to split the log content.
Example: For CSV files, select Custom and enter a half-width comma (,).
-
Quote: If a field value contains the delimiter, you must specify a quote to enclose that field to prevent incorrect splitting.
-
Extracted Field: Set field names (keys) for the resulting columns in order. The following rules apply:
-
Field names can contain only letters, digits, and underscores (_).
-
Field names must start with a letter or an underscore (_).
-
The maximum length is 128 bytes.
-
-
For information about other parameters, see the description of common configuration parameters in Use Case 2: Structured logs.
Data parsing (JSON mode)
You can parse JSON objects from your logs into key-value pairs.
Example:
|
Raw log |
Result |
|
|
Procedure: On the Logtail Configuration page, in the Processor Configurations section, click Add Processor, and then select :
-
Original Field: The default value is
content. This field stores the raw log content to be parsed. -
For information about other parameters, see the description of common configuration parameters in Use Case 2: Structured logs.
Expand JSON field
You can parse nested JSON logs into key-value pairs by specifying an expansion depth.
Example:
|
Raw log |
Expansion depth: 0 |
Expansion depth: 1 |
|
|
|
Procedure: On the Logtail Configuration page, in the Processor Configurations section, click Add Processor, and then select :
-
Original Field: The name of the source field to expand, such as
content. -
JSON Expansion Depth: The number of levels to expand within a JSON object. A value of 0 (the default) expands all levels. A value of 1 prevents the expansion of nested objects.
-
Character to Concatenate Expanded Keys: The character used to join nested field names. The default is an underscore _.
-
Name Prefix of Expanded Keys: The prefix for field names after JSON expansion.
-
Expand Array: Enable this option to expand an array into indexed key-value pairs.
Example:
{"k":["a","b"]}is expanded to{"k[0]":"a","k[1]":"b"}.To rename an expanded field, for example from
prefix_s_key_k1tonew_field_name, you can add a Rename Fields processor to perform the mapping. -
For information about other parameters, see the description of common configuration parameters in Use Case 2: Structured logs.
JSON array parsing
Use the json_extract function to extract JSON objects from a JSON array.
Example:
|
Raw log |
Extracted objects |
|
|
Procedure: On the Logtail Configuration page, in the Processor Configurations section, switch the Processing Method to SPL, configure the SPL statement, and use the json_extract function to extract JSON objects from a JSON array.
Example: Extract elements from the JSON array in the log field content and store the results in new fields named json1 and json2.
* | extend json1 = json_extract(content, '$[0]'), json2 = json_extract(content, '$[1]')Data parsing (Apache mode)
You can structure log content into multiple key-value pairs based on the definitions in your Apache log configuration file.
Example:
|
Raw log |
Apache Common Log Format |
|
|
Procedure: On the Logtail Configuration page, in the Processor Configurations section, click Add Processor, and then select :
-
Log Format: combined
-
APACHE LogFormat Configuration: The system automatically populates this field based on the selected Log Format.
ImportantYou must verify the auto-populated content to ensure it is identical to the LogFormat definition in the Apache configuration file on your server, which is typically located at
/etc/apache2/apache2.conf. -
For information about other parameters, see the description of common configuration parameters in Use Case 2: Structured logs.
Data masking
Mask sensitive data in your logs.
Example:
|
Raw log |
Masked result |
|
|
Procedure: On the Logtail Configuration page, in the Processor Configurations section, click Add Processor, and then select :
-
Original Field: The field that contains the content to be masked.
-
Data Masking Method:
-
const: Replaces sensitive content with a specified string.
-
md5: Replaces sensitive content with its MD5 hash value.
-
-
Replacement String: If you set Data Masking Method to const, you must enter the string to replace the sensitive content.
-
Content Expression that Precedes Replaced Content: A regular expression that matches the content immediately before the sensitive data. This expression uses the RE2 syntax.
-
Content Expression to Match Replaced Content: A regular expression that matches the sensitive content. This expression uses the RE2 syntax.
Time parsing
Parses the time field in the log and sets the parsed result as the __time__ field of the log.
Example:
|
Raw log |
Result |
|
The parsed logs are displayed as structured key-value pairs, with the time field correctly parsed as the log time (for example, 09-29 09:56:01) and other fields such as |
Procedure: On the Logtail Configuration page, in the Processor Configurations section, click Add Processor, and then select :
-
Original Field: The field that contains the time value to be parsed.
-
Time Format: The time format that corresponds to the time value in the log.
-
Time Zone: The time zone of the source time field. By default, the system uses the time zone of the environment where the LoongCollector (Logtail) process is running.
Appendix: Regular expression limits
Regular expressions for container filtering use the Go RE2 engine, which has syntax limitations compared to other engines like Perl Compatible Regular Expressions (PCRE). Keep the following in mind when writing regular expressions:
1. Named group syntax differences
Go uses the (?P<name>...) syntax for named groups and does not support the (?<name>...) syntax used in PCRE.
-
Correct:
(?P<year>\d{4}) -
Incorrect:
(?<year>\d{4})
2. Unsupported regular expression features
RE2 does not support the following common but complex regular expression features. Avoid using them:
-
Assertion:
(?=...),(?!...),(?<=...), or(?<!...) -
Conditional expression:
(?(condition)true|false) -
Recursive matching:
(?R)or(?0) -
Subprogram reference:
(?&name)or(?P>name) -
Atomic group:
(?>...)
3. Recommendations
To debug your regular expressions, use a tool like Regex101. To ensure compatibility, select the Golang (RE2) mode for validation. The plugin will fail to parse or find matches with expressions that use unsupported syntax.
Appendix: Container standard output version comparison
To improve storage efficiency and collection consistency, the log metadata format for container standard output has been upgraded. In the new format, all metadata is consolidated under the __tag__ field to optimize storage and standardize the format.
Core advantages of the new version
Significant performance gains
Refactored in C++, the new version delivers a 180% to 300% performance improvement over the previous Go implementation.
It supports native plugins for data processing and multi-threaded parallel processing to fully utilize system resources.
It supports flexible combinations of native and Go plugins to handle complex scenarios.
Enhanced reliability
It supports a log rotation queue for container standard output and unifies the log collection mechanism with the file collection mechanism. This unification ensures high reliability during rapid log rotation.
Lower resource consumption
CPU usage is reduced by 20% to 25%.
Memory usage is reduced by 20% to 25%.
Enhanced O&M consistency
Unified parameter configuration: The configuration parameters for the new container standard output collection plugin are consistent with those for the file collection plugin.
Unified metadata management: The field names and storage location for container metadata are now consistent with the file collection format. As a result, the consumer side only needs one set of processing logic.
Feature comparison of new and old versions
Feature
Previous behavior
New behavior
Storage method
Metadata is embedded in the log content as individual fields.
Metadata is consolidated under the
__tag__field.Storage efficiency
Each log entry contains a full, duplicate set of metadata, which consumes more storage space.
Multiple log entries from the same source can reuse metadata, saving storage costs.
Format consistency
The format is inconsistent with the file collection format.
Field names and storage structure are now consistent with the file collection format, providing a unified experience.
Query access method
You can query metadata fields directly by name, such as
_container_name_.You must access the corresponding key-value pair through the
__tag__object, such as__tag__: _container_name_.Container metadata field mapping
Previous parameter
New parameter
_container_ip_
__tag__:_container_ip_
_container_name_
__tag__:_container_name_
_image_name_
__tag__:_image_name_
_namespace_
__tag__:_namespace_
_pod_name_
__tag__:_pod_name_
_pod_uid_
__tag__:_pod_uid_
In the new version, all metadata fields are stored in the log's tag section in the format
__tag__:<key>instead of being embedded in the log content.Impact on users
Consumer-side adaptation: Because the storage location has changed from "Content" to "Tag", you must adjust your log consumption logic. For example, you must use __tag__ to access the field when you run a query.
SQL query compatibility: SQL queries are automatically backward-compatible, so you do not need to modify existing queries to process logs from both versions.