Log input: remove states more eagerly #25756
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The log input removes states on clean_removed by setting the TTL to 0, and wait for another scan to finally remove the state for the from the state registry. The total time window for a state removal thusly was `2*scan_frequency`. The disk scan always is subject to race conditions with the actual on disk state. In case of inode reuse an increased time window might might lead to filebeat detecting a new file as a rename of an old file. Next Filebeat truncate detection would try to handle the case, but if logs are written and rotated very fast the new file might already be bigger then the old file. The change introduced here more eagerly removes the state if clean_removed is set, reduing the time window of detection and state removal to `scan_frequency` in the log input.
|
Pinging @elastic/agent (Team:Agent) |
botelastic
bot
added
needs_team
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
Trends 🧪💚 Flaky test reportTests succeeded. Expand to view the summary
Test stats 🧪
|
kvch
approved these changes
May 19, 2021
urso
added
backport-v7.13.0
|
This pull request is now in conflicts. Could you fix it? 🙏 |
mergify bot
pushed a commit
that referenced
this pull request
May 27, 2021
## What does this PR do? The change introduced here more eagerly removes the state if clean_removed is set, reduing the time window of detection and state removal to `scan_frequency` in the log input. ## Why is it important? The log input removes states on clean_removed by setting the TTL to 0, and wait for another scan to finally remove the state for the from the state registry. The total time window for a state removal thusly was `2*scan_frequency`. The disk scan always is subject to race conditions with the actual on disk state. In case of inode reuse an increased time window might might lead to filebeat detecting a new file as a rename of an old file. Next Filebeat truncate detection would try to handle the case, but if logs are written and rotated very fast the new file might already be bigger then the old file. By removing the state more eagerly we reduce the risk of running into a race condition reopening a new file as old. (cherry picked from commit 2ee21d9)
mergify bot
pushed a commit
that referenced
this pull request
May 27, 2021
## What does this PR do? The change introduced here more eagerly removes the state if clean_removed is set, reduing the time window of detection and state removal to `scan_frequency` in the log input. ## Why is it important? The log input removes states on clean_removed by setting the TTL to 0, and wait for another scan to finally remove the state for the from the state registry. The total time window for a state removal thusly was `2*scan_frequency`. The disk scan always is subject to race conditions with the actual on disk state. In case of inode reuse an increased time window might might lead to filebeat detecting a new file as a rename of an old file. Next Filebeat truncate detection would try to handle the case, but if logs are written and rotated very fast the new file might already be bigger then the old file. By removing the state more eagerly we reduce the risk of running into a race condition reopening a new file as old. (cherry picked from commit 2ee21d9) # Conflicts: # filebeat/input/log/input.go
urso
pushed a commit
that referenced
this pull request
May 28, 2021
cachedout
pushed a commit
that referenced
this pull request
May 28, 2021
## What does this PR do? The change introduced here more eagerly removes the state if clean_removed is set, reduing the time window of detection and state removal to `scan_frequency` in the log input. ## Why is it important? The log input removes states on clean_removed by setting the TTL to 0, and wait for another scan to finally remove the state for the from the state registry. The total time window for a state removal thusly was `2*scan_frequency`. The disk scan always is subject to race conditions with the actual on disk state. In case of inode reuse an increased time window might might lead to filebeat detecting a new file as a rename of an old file. Next Filebeat truncate detection would try to handle the case, but if logs are written and rotated very fast the new file might already be bigger then the old file. By removing the state more eagerly we reduce the risk of running into a race condition reopening a new file as old. (cherry picked from commit 2ee21d9)
urso
pushed a commit
that referenced
this pull request
Jun 1, 2021
Co-authored-by: Steffen Siering <steffen.siering@elastic.co>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this PR do?
The change introduced here more eagerly removes the state if
clean_removed is set, reduing the time window of detection and state
removal to
scan_frequencyin the log input.Why is it important?
The log input removes states on clean_removed by setting the TTL to 0, and wait for another scan to finally remove the state for the from the state registry. The total time window for a state removal thusly was
2*scan_frequency. The disk scan always is subject to race conditions with the actual on disk state. In case of inode reuse an increased time window might might lead to filebeat detecting a new file as a rename of an old file. Next Filebeat truncate detection would try to handle the case, but if logs are written and rotated very fast the new file might already be bigger then the old file.By removing the state more eagerly we reduce the risk of running into a race condition reopening a new file as old.
Checklist
- [ ] I have commented my code, particularly in hard-to-understand areas- [ ] I have made corresponding changes to the documentation- [ ] I have made corresponding change to the default configuration files- [ ] I have added tests that prove my fix is effective or that my feature worksCHANGELOG.next.asciidocorCHANGELOG-developer.next.asciidoc.