I have a netcore 3.1 Worker Service listening for messages from multiple ASB topics/subscriptions. The service is configured to push telemetry to an Application Insights instance.
There are no messages being sent through the topic => the service just sits idly and waits for messages.
The ASB SDK logs a heartbeat like Application Insights dependency every 60s for every subscription.
The problem is that, if the SubscriptionClient is configured with MaxConcurrentCalls > 1, the SDK will log just as many (= MaxConcurrentCalls) such dependencies every 60s.
If your service (as mine does in the real scenario that prompted this) listens to 5 subscriptions with 20 MaxConcurrentCalls you will get: 5 subscriptions 20 MaxConcurrentCalls 60min * 24h = 144000 individual dependency log entries / day / service isntance (with the service just sitting idly by).
As Application Insights bills by the GB of data ingested, you can see how this could become a problem.
Another issue is that these completely swamp out other "real" dependencies logged in the same interval.
Is this behavior by design? If so, what is the reasoning behind it? Can it be configured / filtered out / reduced somehow?
I'm using Application Insights to have end-to-end observability over a workflow that spans (via ASB) multiple services. I'm interested to retain the ASB dependencies logged as part of those workflows. How can I do that while still reducing the amount of heartbeat noise?
--- Repro available here - it uses the latest ASB and Application Insights SDKs
Actual Behavior
the ASB SDK loges every 60s , for each subscription it listens to, exactly as many Application Insights dependency entries as the subscription's MaxConcurrentCalls
Expected Behavior
just one dependency log entry per subscription should be enough
LE : seems that Microsoft.Azure.ServiceBus v5.1.3 is not the latest ASB related SDK, but rather Azure.Messaging.ServiceBus v7.1.2
Still, the behavior remains, just that now instead of dependencies, request type log entries are used. The number of log items is the same as with the old SDK.
razvangoga
commented
3 years ago
Description
I have a netcore 3.1 Worker Service listening for messages from multiple ASB topics/subscriptions. The service is configured to push telemetry to an Application Insights instance.
There are no messages being sent through the topic => the service just sits idly and waits for messages. The ASB SDK logs a heartbeat like Application Insights dependency every 60s for every subscription.
The problem is that, if the SubscriptionClient is configured with MaxConcurrentCalls > 1, the SDK will log just as many (= MaxConcurrentCalls) such dependencies every 60s.
If your service (as mine does in the real scenario that prompted this) listens to 5 subscriptions with 20 MaxConcurrentCalls you will get: 5 subscriptions 20 MaxConcurrentCalls 60min * 24h = 144000 individual dependency log entries / day / service isntance (with the service just sitting idly by).
As Application Insights bills by the GB of data ingested, you can see how this could become a problem. Another issue is that these completely swamp out other "real" dependencies logged in the same interval.
Is this behavior by design? If so, what is the reasoning behind it? Can it be configured / filtered out / reduced somehow?
I'm using Application Insights to have end-to-end observability over a workflow that spans (via ASB) multiple services. I'm interested to retain the ASB dependencies logged as part of those workflows. How can I do that while still reducing the amount of heartbeat noise?
--- Repro available here - it uses the latest ASB and Application Insights SDKs
Actual Behavior
Expected Behavior
LE : seems that Microsoft.Azure.ServiceBus v5.1.3 is not the latest ASB related SDK, but rather Azure.Messaging.ServiceBus v7.1.2
Still, the behavior remains, just that now instead of dependencies, request type log entries are used. The number of log items is the same as with the old SDK.