Currently the Phoenix auto-instrumentation library handles HTTP connections and LiveView sockets. As part of my work for https://github.com/open-telemetry/opentelemetry-demo/issues/1511 I used the phoenix auto-instrumentation with a Phoenix Channels-based chat app, and found that the channel messages were not automatically traced the way that I would have expceted.
Describe the solution you'd like
I would like to see spans for messages sent on Phoenix channels when using Phoenix auto-instrumentation. I would like context to be set so that any downstream processing (e.g. with ecto) can have appropriate span context set.
Based on conversations with @bryannaegele and @tsloughter this issue has come up before. A requirement is that these spans should be opt-in on a module basis to avoid noisiness for certain architectures, perhaps as a macro.
Part of the challenge in creating these spans is that Phoenix currently only has telemetry events for the end of these messages, not for the entire lifecycle like with request handlers and LiveView.
The spans for these messages should include a conversation ID that is persistent for the life of the connection, and the spans should follow the semantic conventions for messaging.
Describe alternatives you've considered
An alternative would be to simply provide an extension macro that can add spans (and conversation ID as a span attribute) for messages passing through a channel.
Currently the Phoenix auto-instrumentation library handles HTTP connections and LiveView sockets. As part of my work for https://github.com/open-telemetry/opentelemetry-demo/issues/1511 I used the phoenix auto-instrumentation with a Phoenix Channels-based chat app, and found that the channel messages were not automatically traced the way that I would have expceted.
Describe the solution you'd like I would like to see spans for messages sent on Phoenix channels when using Phoenix auto-instrumentation. I would like context to be set so that any downstream processing (e.g. with ecto) can have appropriate span context set.
Based on conversations with @bryannaegele and @tsloughter this issue has come up before. A requirement is that these spans should be opt-in on a module basis to avoid noisiness for certain architectures, perhaps as a macro.
Part of the challenge in creating these spans is that Phoenix currently only has telemetry events for the end of these messages, not for the entire lifecycle like with request handlers and LiveView.
The spans for these messages should include a conversation ID that is persistent for the life of the connection, and the spans should follow the semantic conventions for messaging.
Describe alternatives you've considered An alternative would be to simply provide an extension macro that can add spans (and conversation ID as a span attribute) for messages passing through a channel.
Additonal Context https://cloud-native.slack.com/archives/C01N75YMZCN/p1712771861414629