[BUG] Missing DependencyTelemetry for EventHub Consumer Receive Events

Describe the bug We recently made the upgrade from the older Microsoft.Azure.EventHubs library to the newer Azure.Messaging.EventHubs 5.6.0.

After we made the switch, we realized that the DependencyTelemetry for EventHub Receive events (which had useful information such as partition_key, start_sequence_number, consumer_group, event_count, etc) is no longer there.

We now only see DependencyTelemetry for types “Azure Event Hubs” and “Queue Message | Azure Event Hubs”, neither of which has the received message information.

Expected behavior DependencyTelemetry for Receive events is still logged with useful fields such as partition_key, start_sequence_number, consumer_group, event_count, etc.

Actual behavior (include Exception or Stack Trace) No telemetry out of the box for receive events.

To Reproduce Set up producer and consumer and instrument w/ Application Insights.

Look in the DependencyTelemetry table and look for receive events.

Environment:

• Name and version of the Library package used: Azure.Messaging.EventHubs 5.6.0
• Hosting platform or OS and .NET runtime version (dotnet --info output for .NET Core projects): Dotnet Core and Azure AppService

[jsquire]

Looping in @lmolkova, who is our knowledge expert on OpenTelemetry and the author of the spec that we based our implementation on. Liudmila had some thoughts around the “receive events” activity, both as it existed in the legacy package and would apply to the current generation.

[jsquire]

Hi @xinyi-joffre. The spec that we were following had those operations split into two different activities:

• One for “processing events” that was marked as high value and implemented in the processor types
• One for “receiving events” that was marked as low value and would apply to the EventHubConsumerClient and PartitionReceiver (Orleans uses the latter)

To be honest, I don’t recall why the decision was made to not instrument the “receive events” activity at the time. I’ll take a follow-up to track down the folks who own our OpenTelemetry story and see what I can find out. If there are no blockers from that perspective, I’ll bring it up for consideration with the rest of the Event Hubs feature team.