Better integration with opentracing

bkielbasa commented 5 years ago

Jaeger is kind of multilanguage standard for opentracing -> https://www.jaegertracing.io/ The required header name

const MessageUUIDHeaderKey = "_watermill_message_uuid"

Is Watermill specific, but messages produced/consumed by this library can be used by anything else. So I can suggest a few things:

change the header name to the same that Jaeger uses
add support for tracer and opentracing https://github.com/opentracing/opentracing-go
span when a new message comes
add generating the correlationID when it's missing

Why would it be cool to have it? If, for example, two companies use Watermill and Jaeger, they have to do the same work twice. The integration is faster and more comfortable then.

roblaszczak commented 5 years ago

Hello, Message UUID is something different than tracing ID :) Tracing ID can be the same for multiple messages (where the payload is different), but UUID should be unique for every message.

I already did some PoC of middleware which will support it. It will probably one of most important part of v1.0 release. Stay tuned! :)

roblaszczak commented 5 years ago

I already started to work on it, but I had not enough time to finish: https://github.com/ThreeDotsLabs/watermill/pull/102/ If you need reference implementation, you should check: https://github.com/census-instrumentation/opencensus-go/ (as I remember, somewhere near to plugin/ochttp/trace.go ;) )

I added help wanted label, so if anyone is interested to help feel free ;) In case of any questions please hit us on Slack.

ThreeDotsLabs / watermill

Better integration with opentracing #74