Deploy LoongCollector as a DaemonSet and configure collection rules in the Simple Log Service console to centralize container log collection—covering both stdout/stderr and file-based logs—with structured parsing, filtering, and indexing.
Step 4: Configure indexing
After configuring log processing, click Next to open the Query and Analysis Configurations page:
-
Full-text index is enabled by default, supporting keyword searches across raw log content.
-
To query by specific field, click Automatic Index Generation after Preview Data loads. Simple Log Service generates a field index based on the first entry in the preview.
Click Next to complete the collection setup.
Step 5: Verify collection
After applying the collection configuration to a machine group, the system deploys the configuration automatically and begins collecting incremental logs.
Check that logs are arriving
-
Confirm new log entries exist: LoongCollector only collects incremental logs. Run the following command and trigger a business operation to generate new log entries:
tail -f /path/to/your/log/file -
Query logs in the console: Go to the Logstore's query and analysis page and click Search & Analyze. The default time range is the last 15 minutes. To quickly verify collection, run this query to check for recent log entries:
Field name Description __tag__:__hostname__Name of the container's host. __tag__:__path__Path of the log file in the container. __tag__:_container_ip_IP address of the container. __tag__:_image_name_Name of the container image. __tag__:_pod_name_Name of the pod. __tag__:_namespace_Namespace of the pod. __tag__:_pod_uid_Unique identifier (UID) of the pod. * | SELECT __time__, __tag__:_pod_name_, __tag__:_namespace_, content LIMIT 20To filter by a specific pod:
* | SELECT * WHERE __tag__:_pod_name_ LIKE 'your-pod-name%' LIMIT 20Each collected container text log includes the following fields by default:
Troubleshooting
Machine group heartbeat failure
-
Check user identity: If the server is not an Elastic Compute Service (ECS) instance, or the ECS instance and project belong to different Alibaba Cloud accounts, create the user identity file: If a file named with the project's Alibaba Cloud account ID exists at the path, the identity is configured correctly.
-
Linux:
cd /etc/ilogtail/users/ && touch <uid> -
Windows: Create an empty file named
<uid>inC:\LogtailData\users\
-
-
Check machine group identity: If you use a custom identifier-based machine group, verify that a
user_defined_idfile exists with the correct content:-
Linux:
echo "user-defined-1" > /etc/ilogtail/user_defined_id -
Windows: Create
user_defined_idinC:\LogtailData\and write the custom ID to the file.
-
-
For further troubleshooting, see Troubleshoot LoongCollector machine group issues.
Log parsing errors
This issue occurs when log content does not match the configured parsing rule.
-
On the Logtail Configuration page, click the name of the affected configuration.
-
On the Log Collection Error tab, click Select Time Range to set a query window.
-
Review the alarm metric and refer to Common errors during data collection for solutions.
No logs collected from a container
-
Check that new log entries exist. LoongCollector does not collect a log file unless new entries are added after the configuration takes effect.
-
Check the Logtail operational log: Find the LoongCollector pod:
kubectl get po -n kube-system | grep logtailThe output is similar to:
logtail-ds-****d 1/1 Running 0 8d logtail-ds-****8 1/1 Running 0 8dOpen a shell in the pod:
kubectl exec -it -n kube-system logtail-ds-****d -- bashView the operational logs (stored in
/usr/local/ilogtail/):cd /usr/local/ilogtail cat ilogtail.LOG cat logtail_plugin.LOGCheck for alarm metrics and refer to Common error types for data collection.
-
Check machine group heartbeat: Go to Resource Group > Machine Groups and click the target machine group name. Under Machine Group Status, check the Heartbeat column. Then compare the heartbeat node count with the actual worker node count:
-
All nodes show failed heartbeat (self-managed cluster): Verify that
regionId,aliuid,access-key-id, andaccess-key-secretare correctly set invalues.yaml. If any are incorrect, runhelm del --purge alibaba-log-controllerto remove the existing installation, then reinstall LoongCollector. -
Fewer nodes than expected show a healthy heartbeat: Check whether you deployed the DaemonSet manually using a YAML file. If so, download the latest DaemonSet template, replace the placeholder values, and apply it: ``
bash kubectl apply -f ./logtail-daemonset.yaml``
kubectl get node | grep -v masterExpected output:
NAME STATUS ROLES AGE VERSION cn-hangzhou.i-bp17enxc2us3624wexh2 Ready <none> 238d v1.10.4 cn-hangzhou.i-bp1ad2b02jtqd1shi2ut Ready <none> 220d v1.10.4 -
-
Check container filtering conditions: In the Simple Log Service console, review the collection configuration. Verify that IncludeLabel, ExcludeLabel, IncludeEnv, and ExcludeEnv match your collection requirements. These labels refer to Docker container labels (from
docker inspect), not Kubernetes labels. To isolate whether a filter is the issue, temporarily remove all filter conditions and check whether logs appear.
What's next
-
Log query and analysis: Search and analyze collected logs.
-
Data visualization: Monitor trends with dashboards.
-
Automatic anomaly alerts: Set alert policies to detect anomalies in real time.
FAQ
Manage multi-destination distribution configurations
Multi-destination configurations are associated with multiple Logstores, so manage them at the project level:
-
Log on to the Simple Log Service console and click the target project.
-
In the left navigation pane, click
Resource Group > Configurations.
This page centralizes all collection configurations in the project, including configurations that remain after their Logstores were accidentally deleted.
Send ACK cluster logs to a project in a different Alibaba Cloud account
Manually install LoongCollector in the ACK cluster and configure it with the destination account's ID and AccessKey credentials. This sends logs to a Simple Log Service project under a different Alibaba Cloud account—useful for organizational separation, permission isolation, or centralized monitoring.
Follow the self-managed cluster installation steps above, setting aliUid, accessKeyID, and accessKeySecret to the values for the destination account.
For information about installing Logtail instead, see Logtail installation and configuration.
Allow multiple configurations to collect the same log source
By default, each log source can only match one collection configuration:
-
A text log file can match only one Logtail configuration.
-
A container's stdout can only be collected by one new-template configuration by default. (Legacy-template configurations support multiple collection copies without extra configuration.)
To allow multiple configurations to collect the same source:
-
Log on to the Simple Log Service console. Go to the target project.
-
In the left navigation pane, select
Logstores, find the target Logstore, and click
to expand it. -
Click Logtail Configuration, find the target configuration, and click Manage Logtail Configuration in the Actions column.
-
On the configuration page, click Edit and scroll to Input Configurations:
-
For text log files: enable Allow File to Be Collected for Multiple Times.
-
For container stdout: enable Allow Collection by Different Logtail Configurations.
-
Dependency error when uninstalling the loongcollector (logtail-ds) component in ACK
Problem: Uninstalling the loongcollector (logtail-ds) component fails with:
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: The terway-eniip network plugin has log collection enabled and depends on loongcollector (logtail-ds). Remove the dependency before uninstalling:
-
Log on to the ACK console.Container Service for Kubernetes consoleSimple Log Service console
-
Click the target cluster name and go to its details page.
-
In the left navigation pane, click Add-ons.
-
Find
terway-eniipand click Disable Logging. -
Click OK in the dialog box.
-
After the change takes effect, uninstall the loongcollector (logtail-ds) component.
Why is the last log segment delayed or truncated?
Log truncation occurs when a log file lacks a trailing newline or a multi-line log is not fully written before collection.
Behavior by version:
-
Versions earlier than 1.8: LoongCollector waits for the next write to trigger output, which may delay the last log entry indefinitely.
-
Versions 1.8 and later: A timeout mechanism automatically submits incomplete content after 60 seconds (default). Adjust this value if needed, but do not set it to 0—doing so causes truncation.
To extend the flush timeout:
-
Log on to the Simple Log Service console. Go to the target project and Logstore.
-
Find the target Logtail configuration and click Manage Logtail Configuration.
-
Click Edit, then go to Input Configurations > Other Input Configurations > Advanced Parameters.
-
Add the following JSON:
{ "FlushTimeoutSecs": 1 }The default value is determined by the
default_reader_flush_timeoutstartup parameter (usually a few seconds). Set the value to at least 1 second. The unit is seconds. -
Click OK.
Why does LoongCollector switch from private network to public network during runtime?
When LoongCollector detects abnormal private network communication (network unavailability or connection timeouts), it automatically switches to the public network endpoint to prevent log loss.
-
LoongCollector: Automatically switches back to the private network when connectivity recovers.
-
Logtail: Does not switch back automatically. Restart Logtail manually to restore private network communication.
Appendix: Native plugin details
Add native processors in the Processor Configurations section of the Logtail Configuration page. To add a processor to an existing configuration:
-
In the left navigation pane, select
Logstores and find the target Logstore. -
Click the
icon to expand the Logstore. -
Click Logtail Configuration, find the target configuration, and click Manage Logtail Configuration.
-
Click Edit.
For additional processing plugins not listed here, see Extended processors.
Plugin combination rules (LoongCollector and Logtail 2.0 and later):
-
Native and extended processors can be combined freely. Prioritize native processors—they offer better performance and stability.
-
Add extended processors only after all native processors. Once an extended processor is added, no more native processors can be appended.
-
All plugins execute sequentially in the order configured.
Regular expression parsing
Extract log fields using regular expressions and parse logs into key-value pairs.
Example:
| Raw log | Parsed output |
|---|---|
127.0.0.1 - - [16/Aug/2024:14:37:52 +0800] "GET /wp-admin/admin-ajax.php HTTP/1.1" 200 41 ... |
remote_addr: 127.0.0.1<br>request_method: GET<br>request_uri: /wp-admin/admin-ajax.php<br>status: 200<br>body_bytes_sent: 41 |
Configuration: Click Add Processor and select Native Processor > Data Parsing (Regex Mode):
-
Regular expression: Match logs using a regular expression.
-
Auto-generate: click Generate Regular Expression automatically, select the content to extract in Log Sample, and click Generate Regular Expression. See screenshot:

-
Manual input: click Manually enter a regular expression, enter your expression, then click Validate.
-
-
Extracted field: Map each captured group to a field name (Key).
-
For shared parameters, see Scenario 2: Structured logs.
Delimiter parsing
Split log fields by a separator character and map each column to a field name.
Example (comma-delimited):
| Raw log | Parsed output |
|---|---|
05/May/2025:13:30:28,10.10.*.*,"POST /PutData HTTP/1.1",200,18204,aliyun-sdk-java |
time: 05/May/2025:13:30:28<br>ip: 10.10.*.*<br>request: POST /PutData HTTP/1.1<br>status: 200<br>size: 18204<br>user_agent: aliyun-sdk-java |
Configuration: Click Add Processor and select Native Processor > Data Parsing (Delimiter Mode):
-
Delimiter: The character used to split log fields. For CSV files, select Custom and enter a comma (
,). -
Quote: Enclose field values containing a delimiter to prevent incorrect splitting.
-
Extracted field: Map each column to a field name in order. Field names can only contain letters, numbers, and underscores, must start with a letter or underscore, and have a maximum length of 128 bytes.
-
For shared parameters, see Scenario 2: Structured logs.
Standard JSON parsing
Parse flat JSON logs into key-value pairs.
Example:
| Raw log | Parsed output |
|---|---|
{"url": "POST /PutData HTTP/1.1", "ip": "10.200.98.220", "user-agent": "aliyun-sdk-java", "time": "05/Jan/2025:13:30:28"} |
url: POST /PutData HTTP/1.1<br>ip: 10.200.98.220<br>user-agent: aliyun-sdk-java<br>time: 05/Jan/2025:13:30:28 |
Configuration: Click Add Processor and select Native Processor > Data Parsing (JSON Mode):
-
Original field: The field containing the raw JSON. Default is
content. -
For shared parameters, see Scenario 2: Structured logs.
Nested JSON parsing
Flatten deeply nested JSON objects into key-value pairs by specifying an expansion depth.
Example:
| Raw log | Depth 0 (full expansion) | Depth 1 |
|---|---|---|
{"s_key":{"k1":{"k2":{"k3":{"k4":{"k51":"51","k52":"52"},"k41":"41"}}}}} |
0_s_key_k1_k2_k3_k41: 41<br>0_s_key_k1_k2_k3_k4_k51: 51<br>0_s_key_k1_k2_k3_k4_k52: 52 |
1_s_key: {"k1":{"k2":...}} |
Configuration: Click Add Processor and select Extended Processor > Expand JSON Field:
-
Original field: The source field to expand (for example,
content). -
JSON expansion depth:
0means full expansion (default);1means the top level only. -
Character to concatenate expanded keys: Separator for expanded field names. Default is underscore (
_). -
Name prefix of expanded keys: Prefix for all expanded field names.
-
Expand array: Enable to expand arrays into indexed key-value pairs. For example,
{"k":["a","b"]}expands to{"k[0]":"a","k[1]":"b"}.
To rename expanded fields, add a Rename Fields plugin after this one.
JSON array parsing
Extract JSON objects from a JSON array using the json_extract function.
Example:
| Raw log | Parsed output |
|---|---|
[{"key1":"value1"},{"key2":"value2"}] |
json1: {"key1":"value1"}<br>json2: {"key2":"value2"} |
Configuration: In the Logtail Configuration area, switch the Processing Method to SPL and enter an SPL statement using the json_extract function.
Example: Extract elements from the content field array and store them in json1 and json2:
* | extend json1 = json_extract(content, '$[0]'), json2 = json_extract(content, '$[1]')
Apache log parsing
Parse Apache access logs using the format definition from your Apache configuration file.
Example:
| Raw log | Parsed output |
|---|---|
192.168.1.10 - - [08/May/2024:15:30:28 +0800] "GET /index.html HTTP/1.1" 200 1234 ... |
remote_addr: 192.168.1.10<br>request_method: GET<br>request_uri: /index.html<br>status: 200<br>response_size_bytes: 1234 |
Configuration: Click Add Processor and select Native Processor > Data Parsing (Apache Mode):
-
Log format: Select combined.
-
APACHE LogFormat configuration: The system auto-populates based on the selected format.
Verify the auto-filled content matches the LogFormat in your Apache configuration file (typically /etc/apache2/apache2.conf).
Data masking
Mask sensitive values in logs before they are stored.
Example:
| Raw log | After masking |
|---|---|
[{'account':'1812213231432969','password':'04a23f38'}] |
[{'account':'1812213231432969','password':'********'}] |
Configuration: Click Add Processor and select Native Processor > Data Masking:
-
Original field: The field containing the content to mask.
-
Data masking method:
-
const: Replace sensitive content with a fixed string.
-
md5: Replace sensitive content with its MD5 hash.
-
-
Replacement string: The replacement string when using the const method.
-
Content expression that precedes replaced content: Identifies the context before the sensitive content. Uses RE2 syntax.
-
Content expression to match replaced content: Matches the sensitive content. Uses RE2 syntax.
Time parsing
Parse a time field and set the result as the __time__ field for the log.
Example:
| Raw log | Parsed result |
|---|---|
{"level":"INFO","timestamp":"2025-09-23T19:11:47+0800","message":"User logged in"} |
![]() |
Configuration: Click Add Processor and select Native Processor > Time Parsing:
-
Original field: The field containing the raw time value.
-
Time format: The format string matching your log's time content. See Time formats.
-
Time zone: The time zone of the log time field. Defaults to the time zone of the machine running LoongCollector.
Appendix: Regular expression limits (container filtering)
Container filtering uses Go's RE2 engine, which has fewer features than PCRE. Note the following differences:
1. Named group syntax
Go uses (?P<name>...) for named groups. The PCRE syntax (?<name>...) is not supported.
-
Correct:
(?P<year>\d{4}) -
Incorrect:
(?<year>\d{4})
2. Unsupported features
The following are not available in RE2:
-
Lookahead and lookbehind assertions:
(?=...),(?!...),(?<=...),(?<!...) -
Conditional expressions:
(?(condition)true|false) -
Recursive matching:
(?R),(?0) -
Subroutine references:
(?&name),(?P>name) -
Atomic groups:
(?>...)
3. Validation
When testing regular expressions with tools such as Regex101, select Golang (RE2) mode to ensure compatibility.
Appendix: Comparison of new and legacy stdout versions
The new stdout collection template stores container metadata in the __tag__ field instead of embedding it directly in log content, improving storage efficiency and aligning the format with file collection.
Core advantages of the new template
| Dimension | New version | Legacy version |
|---|---|---|
| Performance | Refactored in C++; 180%–300% faster than the Go-based legacy version. Supports native plugins and multi-threading. | Go-based; lower throughput. |
| Reliability | Supports stdout log rotation queuing, unified with file collection for high reliability during rapid rotation. | Less reliable under rapid rotation. |
| Resource usage | CPU and memory usage reduced by 20%–25%. | Higher resource usage. |
| Configuration | Parameters are consistent with the file collection plugin. | Separate parameter set. |
Metadata storage format
| Feature | Legacy version | New version |
|---|---|---|
| Storage method | Metadata embedded directly as regular log fields. | Metadata stored centrally in the __tag__ field. |
| Storage efficiency | Each log carries full metadata repeatedly. | Multiple logs in the same context reuse metadata. |
| Format consistency | Inconsistent with file collection format. | Fully aligned with file collection. |
| Query access | Direct field name, for example _container_name_. |
Accessed through __tag__, for example __tag__:_container_name_. |
Field mapping
| Legacy field name | New field name |
|---|---|
_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_ |
Query SQL has been automatically updated for compatibility, so existing query statements work with both old and new format logs simultaneously.



