That's a whole lot of dependencies again. Do you know how this comes together? Seems like bad package architecture somewhere in general as I see logging libraries and an Kafka library by Shopify in there.
A go-metrics meta lib thingy does itch me a bit as well.

You missed the conversations on IRC, just consider the first two commits. Tom's working on the rest.

@fabxc:

I don't expect the last two changes will ever go upstream, as they are too much code IMO.

I'm working on a minimal, in-process tracer implementation (using many fewer dependencies) here: weaveworks-experiments/loki#7

Thanks for clarifying. Sounds good.

I have removed the zipkin vendoring & updated common (here prometheus/common#79)

Whilst as it stands this change isn't particularly useful, it could be merged as is. Or we could wait for the in-process tracer, which I'm going to continue work on now but is probably a week or so away from being ready for review.

I'd propose we review as-is.

I'd propose we review as-is.

Whoops missed that. Let me backout the embedded tracer stuff I just pushed.

@brian-brazil I think this should be good to go, updated now prometheus/common#79 is in.

👍

@fabxc do you also want to review?

Have rebased.

👍 Thanks!

This might be my lack of experience with OpenTracing, but wouldn't we have to implement some kind of a receiver/backend that the data is sent to?

@brancz , AFAIK Zipkin is an existing opensource backend to receive traces

Yes, but as far as I'm aware that would require us to explicitly configure the ZipKin instance the data should be sent to, but I'm not able to find where this configuration is done in this PR, I'm only seeing the instrumenting code. Does the config maybe default to something and further configuration will be a follow-up?

This is using the default NOOP backend. There's future work planned.

I see thanks for clarifying @brian-brazil !

This might be my lack of experience with OpenTracing, but wouldn't we have to implement some kind of a receiver/backend that the data is sent to?

As @brian-brazil said, this is setup to use the noop datasource by default, but adding your own is about 3 lines of code + a recompile away. We didn't include it here as it brings it 100k+ loc in dependancies.

I'm working on a much more minimal, in-process tracer that should be applicable. You can follow along at weaveworks-experiments/loki#7. Hopefully this will do what we need, leave the door open for integration with "proper" distributed tracing, and not vendor the world.