-
Notifications
You must be signed in to change notification settings - Fork 287
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do not report ServiceBus receive and AcceptMessageSession calls that result in timeout #1348
Comments
Any news here? When is a fix to be expected. It bloats the AI with logs over and over with Dependency call failures. |
Hi, we are trying to get rid of the "AcceptMessageSession" errors when using Service bus client and a SerivceBusTimeoutException happens. As I understand it is "not an issue" since it recovers internally, but how do I get access to the very underlying exception during ITelemetryProcessor? In VS I do see in the Debugger / Local apparentely the $exception listed, which seems to be the underlying exception, but don't know how to use the pipeline to access it in a proper way.. This is my current approach though. Any hint is highly appreciated :) @lmolkova public class SkipAcceptMessageSessionDependencyFailuresTelemetryProcessor : ITelemetryProcessor
{
private ITelemetryProcessor Next { get; set; }
// next will point to the next TelemetryProcessor in the chain.
public SkipAcceptMessageSessionDependencyFailuresTelemetryProcessor(ITelemetryProcessor next)
{
this.Next = next;
}
public void Process(ITelemetry item)
{
// To filter out an item, return without calling the next processor.
if (FilterTelemetry(item)) { return; }
this.Next.Process(item);
}
private bool FilterTelemetry(ITelemetry item)
{
var dependency = item as DependencyTelemetry;
if (dependency == null) return false;
return dependency.Type == "Azure Service Bus" && dependency.Name == "AcceptMessageSession" && dependency.Success != true;
}
} |
Any update here? |
Sorry, don't have any updates on this. |
Today we noticed also thousands of failed 'AcceptMessageSession' logs under 'Dependencies' tab. |
I think we're having the same issue. We are using ================================= |
This has been ongoing for quite some time. Any update on a fix? |
I also experience this error. Is there any plan to fix it? |
I have the same issue |
I was going to raise an issue relating to what I can see in this screenshot. Shouldn't this telemetry at least be sent as a dependency rather than a request? As a work around I'm currently filtering out ServiceBusReceiver.Receive using a telemetry processor as it's bloating the logs |
@ben-burton any chance you could share that telemtry processor, because its annoying as hell and we also want to filter it out. |
@esbenbach sure here is my ITelemetryProcessor
and how it could be used
If you want to use the services.AddApplicationInsightsTelemetryProcessor<> way of configuring App Insights then see this link for ideas how to use DI to pass in the excludedTelemetryNames: #1563 (comment) |
This issue is stale because it has been open 300 days with no activity. Remove stale label or this will be closed in 7 days. Commenting will instruct the bot to automatically remove the label. |
It still needs fixing so we dont have to provider our own workaround.
…On Wed, 13 Jul 2022, 02:05 github-actions[bot], ***@***.***> wrote:
This issue is stale because it has been open 300 days with no activity.
Remove stale label or this will be closed in 7 days. Commenting will
instruct the bot to automatically remove the label.
—
Reply to this email directly, view it on GitHub
<#1348 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKQP7S2DR5GGR6VI2PACD3VTYB4LANCNFSM4JVQA6OQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I am also facing the same issue, TelemetryProcessor is not getting added in workerservice #2726. |
Any update? |
1 similar comment
Any update? |
Azure/azure-sdk-for-net#6813
microsoft/ApplicationInsights-dotnet-server#1259
There is not much value in reporting certain calls from ServiceBus. They could be empty receive calls that end up in timeout (no messages on the Bus).
We need to review calls we collect and see which of them are useful.
The text was updated successfully, but these errors were encountered: