Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenTelemetry support enhancement #1784

Closed
cescoffier opened this issue Jun 28, 2022 · 3 comments
Closed

OpenTelemetry support enhancement #1784

cescoffier opened this issue Jun 28, 2022 · 3 comments
Labels
core epic Large task generally split into multiple sub-tasks

Comments

@cescoffier
Copy link
Contributor

In order to improve the OpenTelemetry tracing support in reactive messaging we need:

  1. Introduce an SPI that allows decorating messages emitted by emitters. This SPI would be called on the same thread as the one calling emitter.send(...), and the SPI implementor should be able to extract the current OTel Context and create the TracingMetadata. This metadata will be added to the emitted message.
  2. When a message is associated with a duplicated context (the message could be created from an emitter or from an inbound connector), an SPI should be created to extract the potential TracingMetadata and attach it to the duplicated context. This would allow OTel to re-attach.

In terms of ITs, there are already existing tracing-related IT, which verify the propagation along a pipeline and within a single protocol (like Kafka).
In addition to this, we need to check that:

  • when emitting a message using an emitter, existing tracing details are propagated
  • when emitting a payload using an emitter, existing tracing details are propagated
  • when receiving a message from a protocol supporting tracing, the tracing details are propagated and associated with the duplicated context
  • OTel can re-attach from the duplicated context

\CC @radcortez @brunobat @ozangunalp

@cescoffier
Copy link
Contributor Author

@ozangunalp @radcortez, where are we on this one?

@radcortez
Copy link
Member

I believe that #1678 takes care of this.

@ozangunalp
Copy link
Collaborator

Closing this as #1678 takes care of it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core epic Large task generally split into multiple sub-tasks
Projects
None yet
Development

No branches or pull requests

3 participants