-
Notifications
You must be signed in to change notification settings - Fork 5k
metricbeat: ensure event.duration field is not discarded on Windows #44442
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
metricbeat: ensure event.duration field is not discarded on Windows #44442
Conversation
Windows, starting with Go 1.23+, provides high-resolution timers, but the effective clock resolution remains around 0.5 ms. When event processing is very fast, the elapsed time between start and end may be below this resolution, resulting in a zero duration. A zero event duration is interpreted as absence of value and discarded when setting event fields. This commit ensures a minimum duration is always set.
🤖 GitHub commentsExpand to view the GitHub comments
Just comment with:
|
|
This pull request does not have a backport label.
To fixup this pull request, you need to add the backport labels for the needed
|
|
Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane) |
6856bef to
32f6b57
Compare
487ad2d to
04a7578
Compare
…44442) * metricbeat: ensure event.duration field is not discarded on Windows Windows, starting with Go 1.23+, provides high-resolution timers, but the effective clock resolution remains around 0.5 ms. When event processing is very fast, the elapsed time between start and end may be below this resolution, resulting in a zero duration. A zero event duration is interpreted as absence of value and discarded when setting event fields. This commit ensures a minimum duration is always set. * linter fixes * use rand.N * add changelog (cherry picked from commit 7839c6b)
…44442) * metricbeat: ensure event.duration field is not discarded on Windows Windows, starting with Go 1.23+, provides high-resolution timers, but the effective clock resolution remains around 0.5 ms. When event processing is very fast, the elapsed time between start and end may be below this resolution, resulting in a zero duration. A zero event duration is interpreted as absence of value and discarded when setting event fields. This commit ensures a minimum duration is always set. * linter fixes * use rand.N * add changelog (cherry picked from commit 7839c6b)
…44442) * metricbeat: ensure event.duration field is not discarded on Windows Windows, starting with Go 1.23+, provides high-resolution timers, but the effective clock resolution remains around 0.5 ms. When event processing is very fast, the elapsed time between start and end may be below this resolution, resulting in a zero duration. A zero event duration is interpreted as absence of value and discarded when setting event fields. This commit ensures a minimum duration is always set. * linter fixes * use rand.N * add changelog (cherry picked from commit 7839c6b)
…44442) * metricbeat: ensure event.duration field is not discarded on Windows Windows, starting with Go 1.23+, provides high-resolution timers, but the effective clock resolution remains around 0.5 ms. When event processing is very fast, the elapsed time between start and end may be below this resolution, resulting in a zero duration. A zero event duration is interpreted as absence of value and discarded when setting event fields. This commit ensures a minimum duration is always set. * linter fixes * use rand.N * add changelog (cherry picked from commit 7839c6b)
…t discarded on Windows (#44453) * metricbeat: ensure event.duration field is not discarded on Windows (#44442) * metricbeat: ensure event.duration field is not discarded on Windows Windows, starting with Go 1.23+, provides high-resolution timers, but the effective clock resolution remains around 0.5 ms. When event processing is very fast, the elapsed time between start and end may be below this resolution, resulting in a zero duration. A zero event duration is interpreted as absence of value and discarded when setting event fields. This commit ensures a minimum duration is always set. * linter fixes * use rand.N * add changelog (cherry picked from commit 7839c6b) * Update CHANGELOG.next.asciidoc --------- Co-authored-by: Mauri de Souza Meneguzzo <[email protected]> Co-authored-by: Pierre HILBERT <[email protected]>
…44442) (#44455) * metricbeat: ensure event.duration field is not discarded on Windows Windows, starting with Go 1.23+, provides high-resolution timers, but the effective clock resolution remains around 0.5 ms. When event processing is very fast, the elapsed time between start and end may be below this resolution, resulting in a zero duration. A zero event duration is interpreted as absence of value and discarded when setting event fields. This commit ensures a minimum duration is always set. * linter fixes * use rand.N * add changelog (cherry picked from commit 7839c6b) Co-authored-by: Mauri de Souza Meneguzzo <[email protected]>
…44442) (#44454) * metricbeat: ensure event.duration field is not discarded on Windows Windows, starting with Go 1.23+, provides high-resolution timers, but the effective clock resolution remains around 0.5 ms. When event processing is very fast, the elapsed time between start and end may be below this resolution, resulting in a zero duration. A zero event duration is interpreted as absence of value and discarded when setting event fields. This commit ensures a minimum duration is always set. * linter fixes * use rand.N * add changelog (cherry picked from commit 7839c6b) Co-authored-by: Mauri de Souza Meneguzzo <[email protected]>
… discarded on Windows (#44456) * metricbeat: ensure event.duration field is not discarded on Windows (#44442) * metricbeat: ensure event.duration field is not discarded on Windows Windows, starting with Go 1.23+, provides high-resolution timers, but the effective clock resolution remains around 0.5 ms. When event processing is very fast, the elapsed time between start and end may be below this resolution, resulting in a zero duration. A zero event duration is interpreted as absence of value and discarded when setting event fields. This commit ensures a minimum duration is always set. * linter fixes * use rand.N * add changelog (cherry picked from commit 7839c6b) * Update CHANGELOG.next.asciidoc * fix signature of module.NewWrapper --------- Co-authored-by: Mauri de Souza Meneguzzo <[email protected]> Co-authored-by: Pierre HILBERT <[email protected]>
|
For anyone landing here from: While they work on golang/go#67066 you can use https://github.com/loov/hrtime |
Proposed commit message
Windows, starting with Go 1.23+, provides high-resolution timers, but the effective clock resolution remains around 0.5 ms. When event processing is very fast, the elapsed time between start and end timestamps may be less than this resolution, resulting in a diff of zero.
A zero event duration is interpreted as absence of value and discarded when setting event fields.
This commit ensures a minimum duration is set to preserve event.duration in the ingested event.
Checklist
CHANGELOG.next.asciidocorCHANGELOG-developer.next.asciidoc.How to test this PR locally
Related issues