perf(windows-etw): cut quiet-host alert latency - #314
Merged
Conversation
This file contains hidden or 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
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.
Summary
windows.etw_flush_interval_msControlTraceWproperties blockswhoami /all, matching its generated Sigma rulemainSet
windows.etw_flush_interval_ms = 0to restore ETW's native one-second timer. Values from 1 to 19 ms are clamped to 20 ms.Windows lab results
Windows 11 VM, 6 vCPU, 8 GB. Latency is measured from immediately before
whoami /allto Rustinel's timestampedDetection triggeredrecord, avoiding the harness's 100 ms alert-file polling granularity.15 quiet-host runs per setting with 11 Sigma rules:
With 2,599 Sigma rules after 500 sequential process launches, 100 ms flushing produced a 61 ms median versus 259 ms disabled. The sensor queue high-water mark was 64, so this case was not queue-bound.
A 2,000-file burst raised the queue high-water mark to 4,801/8,192 with zero drops and showed no clear flush benefit, as expected. A deliberately excessive 5,000-file burst saturated the queue and confirmed that forced flushing does not solve downstream backpressure. The 50% guard stops explicit flush requests in that state.
Idle process CPU over 60 seconds remained below 0.4% of one core at every tested interval, with no monotonic increase attributable to flushing.
Validation
cargo test --locked --lib(309 passed)cargo clippy --locked --all-targets -- -D warningscargo test --locked --no-runcargo test --locked sensor::windows::flush::tests(3 passed)cargo build --locked --release