Introduction

Applications that poll Azure Service Bus often produce a large number of dependency telemetry entries named ServiceBusReceiver.Receive. Those entries can flood Application Insights, increase ingestion cost, and make genuinely useful failures harder to spot.

Why These Logs Appear So Often

Application Insights and Azure SDK instrumentation treat Service Bus operations as external dependencies. If your code calls receive in a loop, every receive attempt may generate dependency telemetry, even when no message is returned.

That behavior is technically correct, but it is not always useful. A high-volume worker that polls frequently can generate far more receive telemetry than business telemetry.

First Fix the Receive Pattern

Before filtering telemetry, make sure the application is using the right API. If you currently poll manually with ServiceBusReceiver.ReceiveMessagesAsync, consider ServiceBusProcessor, which is event-driven and usually produces less noisy code.

1using Azure.Messaging.ServiceBus;
2
3var client = new ServiceBusClient(connectionString);
4var processor = client.CreateProcessor("orders");
5
6processor.ProcessMessageAsync += async args =>
7{
8    Console.WriteLine(args.Message.Body.ToString());
9    await args.CompleteMessageAsync(args.Message);
10};
11
12processor.ProcessErrorAsync += args =>
13{
14    Console.WriteLine(args.Exception.Message);
15    return Task.CompletedTask;
16};
17
18await processor.StartProcessingAsync();
19Console.ReadLine();
20await processor.StopProcessingAsync();

This approach reduces the need for an explicit receive loop and often makes the telemetry pattern easier to reason about.

Filter the Dependency Telemetry in Application Insights

If the receive calls are still too noisy, add a telemetry processor that drops only the dependencies you do not want. This is more precise than global sampling because you can target the exact dependency name.

1using System;
2using Microsoft.ApplicationInsights.Channel;
3using Microsoft.ApplicationInsights.DataContracts;
4using Microsoft.ApplicationInsights.Extensibility;
5
6public sealed class IgnoreServiceBusReceiveTelemetryProcessor : ITelemetryProcessor
7{
8    private readonly ITelemetryProcessor _next;
9
10    public IgnoreServiceBusReceiveTelemetryProcessor(ITelemetryProcessor next)
11    {
12        _next = next;
13    }
14
15    public void Process(ITelemetry item)
16    {
17        if (item is DependencyTelemetry dependency &&
18            string.Equals(dependency.Type, "Azure Service Bus", StringComparison.OrdinalIgnoreCase) &&
19            dependency.Name.StartsWith("ServiceBusReceiver.Receive", StringComparison.OrdinalIgnoreCase))
20        {
21            return;
22        }
23
24        _next.Process(item);
25    }
26}
27
28public sealed class IgnoreServiceBusReceiveTelemetryProcessorFactory : ITelemetryProcessorFactory
29{
30    public ITelemetryProcessor Create(ITelemetryProcessor next)
31    {
32        return new IgnoreServiceBusReceiveTelemetryProcessor(next);
33    }
34}

Register it in your application startup:

1using Microsoft.ApplicationInsights.Extensibility;
2
3var builder = WebApplication.CreateBuilder(args);
4
5builder.Services.AddApplicationInsightsTelemetry();
6builder.Services.AddSingleton<ITelemetryProcessorFactory,
7    IgnoreServiceBusReceiveTelemetryProcessorFactory>();
8
9var app = builder.Build();
10app.MapGet("/", () => "ok");
11app.Run();

This keeps requests, traces, exceptions, and other dependencies intact while dropping only the ServiceBusReceiver.Receive noise.

Sampling Versus Filtering

Sampling reduces overall telemetry volume, but it does not specifically solve this problem. If your goal is to remove one repetitive dependency and keep everything else, filtering is the better tool. Sampling is still useful when the total telemetry volume is high across the board, but it can also hide rare events if you set it too aggressively.

A practical strategy is:

• Use targeted filtering for known noisy dependencies
• Use sampling only if ingestion volume is still too high after filtering

Verify the Effect Safely

After deploying the filter, run a short validation window in a non-production environment. Compare total dependency counts before and after the change and confirm that failed Service Bus operations you care about are still visible. If you need failures but not successful receives, extend the processor so it only drops successful dependencies.

Common Pitfalls

• Filtering by name alone can be too broad if other dependencies share similar names, so include the dependency type as well.
• Do not rely on sampling when the real issue is one specific high-volume dependency.
• If polling is the root cause, filtering telemetry treats the symptom rather than the design.
• Always verify that useful failures are still retained after adding a telemetry processor.

Summary

• 'ServiceBusReceiver.Receive entries are common in polling-based Service Bus consumers.'
• Start by improving the receive model, often by switching to ServiceBusProcessor.
• Use a custom telemetry processor to drop only the noisy dependency entries.
• Validate the filter carefully so you do not remove the failures and latency data you still need.