Is your feature request related to a problem? Please describe.
When EventHub processor receives messages, the only telemetry it generates is the processing span. This span is not attributed with any event-hub specific info (endpoint, entity).
I.e. there is no way of knowing which EventHub certain app communicates with and processes messages from. Users may know it, but tools/visualizations don't. Also it requires an extra steps for users to look somewhere up this information or if app talks to mare than one hub/entity, it creates ambiguity.
Describe the solution you'd like
Similarly to send spans, stamp event hub properties on processing spans:
message_bus.destination: EventHub entity namepeer.address: Fully qualified EventHub service endpoint such as sb://<name>.servicebus.windows.net/
Describe alternatives you've considered
Instrumenting some calls (e.g. connection initiation or receive) from app to EventHubs. Connection initiation does not seem to be particularly useful.
Instrumenting 'receive' calls brings low additional value
Additional context
Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report
Is your feature request related to a problem? Please describe.
When EventHub processor receives messages, the only telemetry it generates is the processing span. This span is not attributed with any event-hub specific info (endpoint, entity).
I.e. there is no way of knowing which EventHub certain app communicates with and processes messages from. Users may know it, but tools/visualizations don't. Also it requires an extra steps for users to look somewhere up this information or if app talks to mare than one hub/entity, it creates ambiguity.
Describe the solution you'd like
Similarly to send spans, stamp event hub properties on processing spans:
message_bus.destination: EventHub entity namepeer.address: Fully qualified EventHub service endpoint such assb://<name>.servicebus.windows.net/Describe alternatives you've considered
Instrumenting some calls (e.g. connection initiation or receive) from app to EventHubs. Connection initiation does not seem to be particularly useful.
Instrumenting 'receive' calls brings low additional value
Additional context
Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report