Closed SergeyKanzhelev closed 5 years ago
Couple more considerations:
Another scenario, besides the extreme care about the latency, where this approach may be useful - constructing spans from some third party library output or reading spans from file.
After discussion we think that it is wise to avoid any timers inconsistencies in Start/Stop API. If span data needs to be exported for the span from the past - direct creation of SpanData
should be used
As described in #92 - there are cases when you might need to report a span from the past. In that PR Redis library calls are recorded asynchronously. My guess why this API was chosen to expose Redis calls is extreme care of those calls latency.
Current API is quite limiting in this sense.
ISpan
doesn't allow to set start and end timestamps explicitly. Same for time events like annotations. ExpandingISpan
interface may create some confusions.SpanData
directly. This approach can be problematic as a lot of logic like calling start/stop handler and sampling needs to be replicated manually.ISpan
or makeISpan
constructible fromSpanData
. I like this last approach. Not sure what may be the problems here.