Add new tail sampling processor policy: latency #3750
Conversation
|
|
Agree, this is a great suggestion. I'll add this tomorrow 🙂 |
|
Alright, let me know when you need a new review. I'm out next week, though, so you might need to ask someone else to review this if you can't wait for me to return. |
|
Alright, I have switched the implementation to check the entire duration of a trace 👍 I think this use case will be way more common. I wasn't sure how to calculate the total duration of a trace, I've implemented it by searching the min/max timestamps of all spans. Does this seem alright? |
There was a problem hiding this comment.
Looks good! There's a whole world of possible algorithms to determine the real duration of the trace, but this simple "wall clock" approach is correct most of the time for most of the users.
I would just make sure to document this decision in the readme, so that users understand what "trace duration" means for our purposes.
Co-authored-by: Juraci Paixão Kröhling <juraci.github@kroehling.de>
Thanks! Your suggestions have been added 🙂 |
* tailsamplingprocessor: add latency policy * Refactor latency tail sampling processor * Latency tail sampling processor uses total duration of a trace * Apply suggestions from code review Co-authored-by: Juraci Paixão Kröhling <juraci.github@kroehling.de> Co-authored-by: Juraci Paixão Kröhling <juraci.github@kroehling.de>
Description:
This adds a new policy to the tail sampling processor sampling traces based upon the duration of a span. Adding this policy allows you to sample all traces of which the duration exceeds a given threshold.
It's my first time contributing to Open-Telemetry, let me know if this fits with the other code 😊
Link to tracking Issue:Testing:
Added unit tests similar to the other policies.
Documentation:
I have updated the README.