Collection by Logtail - Simple Log Service - Alibaba Cloud Documentation Center

Logtail operations vary based on different collection scenarios. This topic describes how to use Logtail to collect logs in host scenarios, Kubernetes cluster scenarios, and container scenarios.

Installation and collection guide for Logtail in host scenarios

When collecting text logs from hosts, Simple Log Service supports both automatic one-click installation and manual installation of Logtail based on the host ownership. For more information, see Host text log collection.

Installation and collection guide for Logtail in Kubernetes cluster scenarios

Collecting container logs from Kubernetes clusters can be used for troubleshooting, performance optimization, security auditing, and resource utilization analysis. Simple Log Service supports collecting container logs from Kubernetes clusters in DaemonSet mode or Sidecar mode.

DaemonSet mode

In DaemonSet mode, only one Logtail container runs on a node in a Kubernetes cluster. You can use Logtail to collect logs from all containers on a node.
When a node is added to a Kubernetes cluster, the cluster automatically creates a Logtail container on the new node. When a node is removed from a Kubernetes cluster, the cluster automatically destroys the Logtail container on the current node. You do not need to manually manage Logtail instances because of the automatic scaling mechanism of DaemonSet and the identity-based machine groups.

Sidecar mode

In Sidecar mode, each pod runs a Logtail container. You can use Logtail to collect logs from all containers in the pod. In this case, log collection from each pod is isolated.
To ensure that Logtail can collect logs from other containers in a pod, make sure that the Logtail container and application containers share the same volume. For more information about collecting container logs in Sidecar mode, see Introduction to Sidecar log collection and Examples of Sidecar mode. For more information about volumes, see Storage basics.

Collection methods	Scenarios	Advantages	Disadvantages
DaemonSet	DaemonSet is recommended in most cases	Provides simple O&M, low resource usage, and flexible configurations. You can collect container stdout and stderr logs. You can also collect container text logs.	Logtail collects logs from all containers on a DaemonSet-specific node. However, in this mode, performance bottleneck issues may occur on Logtail, and containers are loosely isolated.
Sidecar	Scenarios where each pod requires a separate Logtail instance for collection (serverless Kubernetes (ASK) clusters use the Sidecar mode to deploy Logtail by default).	Creates a Sidecar container for each container that requires log collection, providing good multi-tenant data isolation.	Higher resource consumption, more complex configuration and maintenance.

Container discovery

Before a Logtail container can collect logs from other containers, the Logtail container must identify and determine which containers are running. This process is called container discovery. During container discovery, the Logtail container does not communicate with the kube-apiserver of the Kubernetes cluster. Instead, it communicates directly with the Container Runtime Daemon on the node to obtain information about all containers on the current node. This prevents container discovery from putting pressure on the cluster kube-apiserver.
Logtail supports specifying or excluding containers for log collection based on conditions such as namespace name, pod name, pod label, and container environment variables.

Container file path mapping

In a Kubernetes cluster, because of resource isolation between pods, a Logtail container cannot directly access files in containers of other pods. The file system of a container is created by mounting the file system of the container host to the container. A Logtail container can access any file on the container host only after the file system that includes the root directory of the container host is mounted to the Logtail container. This way, the Logtail container can collect logs from the files in the file system. The relationship between file paths in a container and file paths on the container host is called file path mapping.

If the path of a log file in the current container is /log/app.log, and the mapped path on the host is /var/lib/docker/containers/<container-id>/log/app.log. By default, Logtail mounts the file system that contains the root directory of the host to its own /logtail_host directory. Therefore, the actual file path that Logtail collects is /logtail_host/var/lib/docker/containers/<container-id>/log/app.log.

Considerations

Container runtime support

Supported engines:
- Docker
- Containerd
Storage driver limitations (Docker only):
- Only Overlay and Overlay2 are supported.
- Other drivers: If you use a non-Overlay driver, you need to mount the log directory as a temporary directory using a volume.

Volume mounting methods

If NAS is mounted to the data directory as a PVC.

Do not use: DaemonSet to deploy Logtail.
Recommended:
- Collect cluster text logs (Sidecar): Deploy an independent Logtail container for each pod
  Scenarios: High isolation requirements, multitenancy environments.

Log file path specifications

Do not use symbolic links:
- Incorrect configuration: /var/log/app -> /mnt/nas/logs.
- Correct configuration: Use the physical path directly /mnt/nas/logs.
Mount path matching rules:
If the data directory of an application container is mounted using a volume, the collection path must be greater than or equal to the mount point path.
Example:
```
1Mount point: /var/log/service
2✅ Valid collection paths: /var/log/service or /var/log/service/subdir
3❌ Invalid collection path: /var/log (path too short)
```

Log handling when containers stop

Runtime	Log integrity	Container destruction delay risk	Optimization suggestions
Docker	If collection latency exists due to issues such as network latency or resource overconsumption before the container is stopped, some logs that are collected before the container is stopped may be lost.	When a container is stopped, Logtail immediately releases the container file handles, allowing the container to exit normally.	Increase the log sending frequency (reduce `flush_interval`).
Containerd	When a container is stopped, Logtail continues to hold the file handles of the container (keeping the log files open) until all log file content is sent.	When collection latency occurs due to issues such as network latency or resource overconsumption, application containers may not be destroyed in a timely manner.	Configure `max_hold_buffer_size` to limit memory usage.

Installation and collection guide for Logtail in Docker container scenarios

After deploying Docker on a server, you can collect logs. Docker logs are divided into two types: standard output and file logs. File logs refer to logs generated inside containers that are written to specified file directories on the server, while standard output refers to the real-time output stream of the container itself.