vmware-archive / wavefront-opentracing-sdk-go Goto Github PK

Span.FinishWithOptions is only considering the FinishTime option. Should look at the spanlog options too.

Planning to file a PR addressing this shortly.

It would be great to have a variation of the RateSampler that's capped at a specific number of samples per minute. For example, I'd like to specify that I'd like at the most 100 samples per minute. The sampler would then adaptively calculate a rate that gives approximately that number of samples per minute and block any additional samples from being sent during that time period.

I have code for this that I could put in a PR if you're interested.

See this commit id for Java SDK for reference.
wavefrontHQ/wavefront-opentracing-sdk-java@98c3869

There's a bug in RawSpan.LogKV preventing it from working. The array sent to InterleavedKVToFields needs to be flattened.

Filing a PR for this shortly!

Based on user feedback. The span reporter relies on the default metrics registry for the derived metrics.

If a user is using the span reporter and a custom metrics reporter (go-metrics) alongside each other, they'll both use the default registry and stomp on each other.

We should update the span reporter to use a custom registry for derived metrics as well.

As per https://www.w3.org/TR/trace-context/ - the tracing header should be formatted as follows:

traceparent: 00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01
tracestate: key=value,key=value

It appears that the current tracer (and the jaeger version) don't support this format.

By default, http.status_code gets promoted to the error counter for error spans. But it gets dropped before request and duration RED metrics are sent (https://github.com/wavefrontHQ/wavefront-opentracing-sdk-go/blob/master/reporter/reporter.go#L277). If it is specified in redMetricsCustomTagKeys, http.status_code should not get dropped from request and duration metrics.

This can be fixed by promoting http.status_code by default to all RED metrics for any span, which would be consistent with the update that is being made for java SDKs.