This topic describes the limits of Logtail.
Runtime environment
Limits | Limitations |
Architecture |
|
Compute resources |
Actual usage depends on the collection rate, the number of monitored directories and files, and the degree of sending blockage. Ensure that the actual usage is less than 80% of the limit. |
System environment | For supported operating systems, see System types. |
Kubernetes |
Important All Logtail components have system-cluster-critical priority. Do not deploy them when cluster resources are insufficient because they may evict existing pods on the nodes. |
Docker | The following limits apply to the collection of container standard output:
|
Storage medium | Do not use shared network storage media, such as NAS or OSS. This may cause data truncation, content inconsistency, or collection suspension. Use Elastic Block Storage (EBS). |
File collection
Limits | Limitations |
Size of a single log | The default limit is 512 KB. You can adjust this limit using the max_read_buffer_size startup parameter. The maximum size cannot exceed 8 MB. For more information, see Set Logtail startup parameters. After a multi-line log is split based on a regular expression that matches the first line, the size of each resulting log is still limited to 512 KB. If a log is larger than 512 KB, it is forcibly split into multiple logs for collection. For example, if a log is 1,025 KB, the first 512 KB is processed, then the next 512 KB, and finally the last 1 KB. This results in multiple incomplete logs. |
File encoding | Logtail supports log files that are encoded in UTF-8 or GBK. For optimal processing performance, we recommend that you use UTF-8 encoding. Warning If log files use other encoding formats, issues such as garbled characters or data loss may occur. |
Log file size | Unlimited. |
Log file rotation | The default size of the log rotation queue is 20. You can adjust this using the logreader_max_rotate_queue_size startup parameter. For more information, see Set Logtail startup parameters. You can specify the log path in the Important Do not mix these two formats in the same Logtail instance. Otherwise, a single file might match multiple Logtail collection configurations, which causes duplicate data collection. If more than 20 files are not processed, newly generated logs are lost. In this case, first check whether the write quota of the Logstore shard is exceeded, and then adjust the concurrency level of Logtail. For more information, see Recommended parameter values. For more information, see related technical articles. |
Collection behavior when log parsing is blocked | When log parsing is blocked, Logtail keeps the file descriptor for the log file open. This prevents the file from being deleted during the blockage, which would cause data loss. If the log file is rotated multiple times while parsing is blocked, Logtail places the file in the rotation queue. |
Regular expression | Perl-compatible regular expressions are supported. |
JSON | Standard JSON, as defined in RFC 7159 and ECMA-404, is fully supported. Non-standard JSON, such as |
Multiple Logtail configurations for one file | By default, a file can match only one Logtail collection configuration. If logs from a file need to be collected multiple times, see How to collect multiple copies of logs from a single file. Important When you collect multiple copies, the file read I/O, compute resources, and network I/O increase linearly. |
File opening behavior | Logtail keeps the collected files and the files that are pending collection in the rotation queue open to ensure data integrity. A file is closed in the following situations:
If you want the file handle to be released within a controllable time after a file is deleted, regardless of whether collection is complete or logs are still being written, you can set a timeout period using the force_release_deleted_file_fd_timeout startup parameter. For more information, see Set Logtail startup parameters. |
Initial log collection behavior | Logtail collects only incremental log files. When a file modification is first detected, if the file size exceeds 1 MB (512 KB for container standard output), collection starts from the last 1 MB of the file. Otherwise, collection starts from the beginning of the file. You can change the value of the tail_size_kb parameter in a Logtail configuration to change the limit. For more information, see Logtail configurations (Legacy). If the log file is not modified after the Logtail collection configuration is applied, Logtail does not collect logs from the file. To collect historical files, see Import historical log files. |
File overwriting behavior | Logtail identifies a file by its inode and the hash of its first 1,024 bytes. If a file is overwritten and its inode or the hash of its first 1,024 bytes changes, it is treated as a new file and collected from the beginning. Otherwise, it is not collected. |
File moving behavior | If a file is moved and it matches a Logtail collection configuration that has never matched this file before, the moved file is treated as a new file and collected from the beginning. Otherwise, it is not collected. |
File collection history | Logtail keeps the file collection history in memory to ensure that only incremental parts are collected after a file changes. If logs are written beyond the retention scope, duplicate data collection occurs.
|
Non-standard text logs | For log lines that contain |
Container collection
When you use Logtail to collect container logs, the following limits apply in addition to the limits on file collection.
Limits | Limitations |
Initial log collection behavior | If you collect container standard output, when a file modification is first detected, if the file size exceeds 512 KB, collection starts from the last 512 KB. Otherwise, collection starts from the beginning. You can adjust this using the StartLogMaxOffset parameter in the Logtail collection configuration. For more information, see Collect container standard output in DaemonSet mode using the console. |
Symbolic link | When you collect logs from container files, symbolic links for directories and files are not supported. |
Container lifecycle | By default, the container lifecycle must be at least 10 seconds for Logtail to collect logs. In container file collection scenarios, for performance reasons, Logtail limits container updates to 10 times within 3 minutes. You can adjust these settings using the docker_config_update_interval and max_docker_config_update_times startup parameters. For more information, see Set Logtail startup parameters. |
Standard output log rotation | The container's standard output files are rotated by Docker or kubelet. The default rotation size for kubelet log files is 10 MB (Docker log rotation is set to 100 MB on ACK). If the container's standard output rate is greater than 10 MB/s, files rotate quickly. To avoid data loss, collect logs from container files or modify the kubelet containerLogMaxSize parameter. |
Standard output log driver | If you use Docker as a container runtime, you must add |
Checkpoint management
Limitations | Limitations |
Checkpoint timeout | By default, if a file is not modified for more than 30 days, its checkpoint is automatically deleted. If you set |
Checkpoint storage policy | Checkpoints are saved periodically (every 15 minutes) and automatically when the program exits. You can adjust this using the check_point_dump_interval startup parameter. For more information, see Set Logtail startup parameters. |
Checkpoint storage location | The default storage path is |
Handling during downtime | Because checkpoints are saved periodically, recovery after downtime starts from the last fully saved checkpoint. This may cause duplicate data collection. Adjust the checkpoint storage policy to reduce duplicate data collection. |
Logtail collection configurations
Limits | Limits |
Configuration update latency | It takes about 30 seconds for a configuration update made in the console or using an API to take effect on the Logtail client. |
Dynamic loading of configurations | Supported. An update to one configuration does not affect others. |
Total number of loadable configurations for a single Logtail instance | Theoretically unlimited. We recommend that you use no more than 100 Logtail collection configurations on a single server. |
Third-party flusher output | Configurations created through the Simple Log Service console or an API are associated with a Logstore. Therefore, when you use a third-party flusher in the plugin configuration, Logtail sends a copy of the data to the current Logstore by default. |
Multi-account and cross-account | Supported. For more information, see Configure a user identifier and Use Logtail to collect container logs across Alibaba Cloud accounts. |
Multi-region | This is not supported by default. If you have this requirement, submit a ticket. |
Global Accelerator | Supported. After you enable this feature on the server-side, set up Global Accelerator on the client. For more information, see Enable Global Accelerator. |
Machine groups
Limitations | Limitations |
Number of machines | Theoretically unlimited. Configure no more than 100,000 machines. Otherwise, heartbeats cannot be obtained correctly. |
Number of applied configurations | Theoretically unlimited. We recommend that you apply no more than 1,000 configurations. |
Performance
Limits | Limitations |
Log processing throughput | The default limit for raw log traffic is 20 MB/s. Data is uploaded after being encoded and compressed, with a typical compression ratio of 5 to 10. If this traffic limit is exceeded, data loss may occur. You can adjust this limit using the max_bytes_per_sec startup parameter. For more information, see Set Logtail startup parameters. |
Maximum performance | The single-core capabilities are as follows:
Using the process_thread_count startup parameter to set multiple processing threads can increase performance by 1.5 to 3 times. |
Maximum number of monitored directories and files | This is related to the mem_usage_limit parameter (default is 384 MB for host scenarios and 2,048 MB for container scenarios) and is divided into the following four levels:
When the number of monitored directories and files at any of these levels reaches the limit, Logtail stops monitoring the remaining directories and files at that level. You can increase the monitoring limit by improving the precision of the monitored directories in the Logtail collection configuration or by adjusting the mem_usage_limit startup parameter. For more information about the mem_usage_limit parameter, see Set Logtail startup parameters. For Linux systems, Logtail also supports monitoring directories through the inotify mechanism to reduce log collection latency. The maximum number of directories (including subdirectories) that can be monitored by inotify is 3,000. |
Resource limit handling policy | If Logtail's resource usage exceeds the maximum limit for 5 minutes, Logtail forcibly restarts. This may cause data loss or duplication. |
Multi-tenant data isolation | Logtail provides isolation at the configuration level. An exception in one Logtail collection configuration does not affect others.For more information, see related technical articles. |
Log collection latency | Under normal conditions, the latency from when a log is written to disk to when it is collected by Logtail is less than 1 second. |
Log upload policy | Logtail automatically aggregates and uploads logs from the same file. Aggregation is triggered when the number of logs exceeds 4,000, the total log size exceeds 512 KB, or the collection time exceeds 3 seconds. The upload is triggered when any of these conditions is met. |
Error handling
Limitations | Limitations |
Network error handling | In the case of a network exception, Logtail actively retries and automatically adjusts the retry interval. In extreme cases, there is a risk of duplicate log collection or data loss:
|
Resource quota exceeded | If the data sending rate exceeds the maximum quota of the Logstore, Logtail blocks collection and automatically retries. To resolve this issue, increase the number of shards for the Logstore.For more information, see related technical articles. |
Client time exception | If the time difference between the client and the server exceeds 15 minutes, retries may fail up to 5 times, and the data is discarded. To resolve this issue, correct the time on the client machine. |
Project or Logstore does not exist | After 5 unsuccessful retries, the data is discarded. This can happen if you deleted the Logstore using an API. To resolve this issue, delete the corresponding Logtail collection configuration and its application using an API. |
Authentication failed | After 5 unsuccessful retries, the data is discarded. This issue usually occurs for two reasons:
|
Other unknown errors | After 5 unsuccessful retries, the data is discarded. |
Maximum retry time before timeout | If data sending fails continuously for more than 6 hours, the data is discarded. |
Status self-check | Logtail supports automatic restart in exceptional situations, such as an abnormal program exit or resource usage that exceeds the configured limits. |
Exceeding the maximum number of monitored directories and files | Logtail cannot find the collection path promptly and accurately. This may cause data loss. |
Significant collection delay | The log collection progress lags behind log generation. If more than 20 unprocessed log files are rotated, data loss occurs. |