You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In Windows, When application logs are rotated, they are not fully scraped. The Alloy agent scrapes logs only from the initial file (e.g., api.log) but misses the newly created file after log rotation is triggered.
Response from Alloy team:
Alloy engineering team confirmed this is an issue with Alloy running on Windows. This was their findings:
On Windows, when the file is deleted the tailer is stopped right away. When the new file is created, it will be picked up by the next sync_period of the local.file_match component. But because the name of the file is the same as the previous one (the one that is cached), it won't propagate the update, resulting in the file not being tailed.
This problem does not happen on Unix systems because it will only stop the tailer when the local.file_match reports that the file is gone and in the meantime it will try to re-open it.
While we continue investigating the problem, a workaround would be to have a different file name for every log rotation.
Steps to reproduce
Set up log rotation with Log4j, where the current log file is closed, compressed, renamed, and a new file is created.
Verify if Loki/Alloy scrapes logs from the new file after log rotation.
We’d appreciate your guidance on resolving this issue to ensure uninterrupted log scraping.
System information
Windows
Software version
Grafana alloy 1.5.1 (Note: 1.3.1 also had similar behaviour)
What's wrong?
In Windows, When application logs are rotated, they are not fully scraped. The Alloy agent scrapes logs only from the initial file (e.g., api.log) but misses the newly created file after log rotation is triggered.
Response from Alloy team:
Alloy engineering team confirmed this is an issue with Alloy running on Windows. This was their findings:
On Windows, when the file is deleted the tailer is stopped right away. When the new file is created, it will be picked up by the next sync_period of the local.file_match component. But because the name of the file is the same as the previous one (the one that is cached), it won't propagate the update, resulting in the file not being tailed.
This problem does not happen on Unix systems because it will only stop the tailer when the local.file_match reports that the file is gone and in the meantime it will try to re-open it.
While we continue investigating the problem, a workaround would be to have a different file name for every log rotation.
Steps to reproduce
Set up log rotation with Log4j, where the current log file is closed, compressed, renamed, and a new file is created.
Verify if Loki/Alloy scrapes logs from the new file after log rotation.
We’d appreciate your guidance on resolving this issue to ensure uninterrupted log scraping.
System information
Windows
Software version
Grafana alloy 1.5.1 (Note: 1.3.1 also had similar behaviour)
Configuration
Logs
The text was updated successfully, but these errors were encountered: