You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the Phoenix auto-instrumentation library handles HTTP connections and LiveView sockets. As part of my work for open-telemetry/opentelemetry-demo#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 open-telemetry/opentelemetry-demo#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
The text was updated successfully, but these errors were encountered: