Make sure the filter gets updated with the last timestamp on each #2796
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
run. Otherwise, all checks are done relative to when the agent was started, resulting in an ever-growing list of events to be parsed
|
Looks good to me. Let's make sure we test this well on the release candidate. 👍 |
|
CI failure is unrelated, on flaky test. |
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?
PR fixes a customer problem whereby the CPU consumed by the Win32 event log check would increase linearly with time.
Motivation
Customer request
Testing Guidelines
An overview on testing
is available in our contribution guidelines.
Additional Notes
Reset WMI query filters before each run. Otherwise, all checks are done relative to when the agent was started, resulting in an ever-growing list of events to be parsed.
The WMI filter was attached to the (cached) sampler object. So, even though the filter was recomputed each time with a new "TimeGenerated >= " string, that was never actually used by the WMI query. So, each successive query returned any new entries, PLUS any entries that had already been retrieved. Processing the list then had a linearly increasing time (and space). Compounding it is the check to make sure the duplicate entries aren't reported, which then caused the (ever growing) list to be parsed again.