Find answers to frequently asked questions about Logtail, organized by category.
|
Category |
Related documentation |
|
|
Basic concepts |
||
|
Heartbeat issues |
Troubleshoot machine group issues for Logtail (host scenarios) |
|
|
Collection issues |
General scenarios |
|
|
Container scenarios |
||
|
Deployment and management issues |
General scenarios |
|
|
Windows scenarios |
An exception message appears in the service log when you install Logtail on a Windows instance |
|
|
Container scenarios |
||
|
Log format parsing issues |
||
|
Error codes |
Common error types for data collection in Simple Log Service |
|
How do I troubleshoot logs that exist in a LogStore even though Logtail is not configured?
If you see logs in a LogStore but have not configured Logtail collection for it, the logs were most likely written through one of the following paths:
-
Data written directly by an SDK: An SDK, such as the Aliyun Log Java Producer, can call the
PutLogsAPI to write logs directly to a LogStore. This does not require Logtail. To confirm this, go to the log query page and check theMethodfield. A value ofPostLogStoreLogsindicates that the log was written by an SDK instead of Logtail. You can further check theUserAgentfield to identify which SDK was used, for example,aliyun-log-python-sdk. Before you query these fields, make sure that indexing is enabled for the LogStore. -
Multiple Logtail configurations matching the same file: If more than one Logtail configuration collects the same log file, the
MULTI_CONFIG_MATCH_ALARMalert is triggered, which can also explain why logs appear without an obvious matching collection configuration. For the troubleshooting steps and the solution, see Use CloudLens to troubleshoot duplicate file configuration issues in iLogtail (MULTI_CONFIG_MATCH_ALARM).