Describe the feature
Add either
- a timestamp of the last aggregated sample to the
WallClockSample
- or the duration covered as a field to
WallClockSample
Use Case
The OpenTelemetry inferred-spans internally uses async-profiler in wall clock profiling mode to generate spans based on profiling data. I'm expecting the new batched wall-clock profiling mode to yield great efficiency improvements for this extension!
However, the span inference mechanism doesn't care about sample counts, but about the concrete timestamps of the individual samples. So to integrate the batched mode, we would need the timestamp of the last sample in addition to the one of the first sample in WallClockSample.
In theory, the duration can be inferred via (sampleCount - 1) * samplingRate. However, for longer sleeps I fear that there might be too much jitter (e.g. due to CPU starvation or too many threads being sampled), causing the derived duration / end timestamp to be inaccurate.
Based on your experience, do you think that this is actually problematic? And if yes, would you be open to adding either a duration or end-timestamp to the WallClockSample event?
IINM the implementation should be fairly easy to implement, so I should be able to open a PR for it.
Proposed Solution
No response
Acknowledgements
Describe the feature
Add either
WallClockSampleWallClockSampleUse Case
The OpenTelemetry inferred-spans internally uses async-profiler in wall clock profiling mode to generate spans based on profiling data. I'm expecting the new batched wall-clock profiling mode to yield great efficiency improvements for this extension!
However, the span inference mechanism doesn't care about sample counts, but about the concrete timestamps of the individual samples. So to integrate the batched mode, we would need the timestamp of the last sample in addition to the one of the first sample in
WallClockSample.In theory, the duration can be inferred via
(sampleCount - 1) * samplingRate. However, for longer sleeps I fear that there might be too much jitter (e.g. due to CPU starvation or too many threads being sampled), causing the derived duration / end timestamp to be inaccurate.Based on your experience, do you think that this is actually problematic? And if yes, would you be open to adding either a duration or end-timestamp to the
WallClockSampleevent?IINM the implementation should be fairly easy to implement, so I should be able to open a PR for it.
Proposed Solution
No response
Acknowledgements