Closed gongdo closed 7 years ago
Do you also call UseApplicationInsightsTelemetry()
from your code? If so, remove it. See #336
@pharring No I didn't add any other code except as I mentioned above.
And I'm sure there's no ApplicationInsights
related code in the Startup.cs
except ConfigureServices
one.
Here's the
Startup.cs
and .csproj
that I used.https://gist.github.com/gongdo/ef888bfeaa73d0fb0488ab78175954c6
Whole solution to reproduce it.
https://www.dropbox.com/s/wogc9u7ojg0ehzb/WebApplication2.zip?dl=0
I've a similar issue. Each Request
is logged 4 times. I'm also tracking manually some Dependency
and use Serilog.Sinks.ApplicationInsights
. Dependency
and Trace
appear as expected, the issue only impact Request
.
Configuration:
Microsoft.ApplicationInsights.AspNetCore
- Can reproduce the issue with both 2.0.0
and 2.1.0-beta1
Serilog.Sinks.ApplicationInsights
- 2.2.1
Let me know if you need anything else / more details. Happy to assist.
@pakrym is there a possibility End event was fired four times?
If there is UseApplicationInsights
call in Program.cs
and application insights is added to services again via AddApplicationInsightsTelemetry
this might happen. We should make AddApplicationInsightsTelemetry
call idempotent.
So the workaround is to remove the call to AddApplicationInsightsTelemetry
? I thought we were going to mark it as obsolete and make empty bodied.
We kept it so users can have more control then what UseApplicationInsights
gives them, we obsolete only middlware methods.
How embarrassing, I realized I was actually calling UseApplicationInsights()
in Program.cs
. Once I removed this call things started to work as expected (no more duplicate events). Sorry about that.
I just hit this too, suggestion to remove UseApplicationInsights()
worked for me as well.
I agree with @pakrym, AddApplicationInsightsTelemetry()
should be smart enough to avoid causing duplicate entries, especially since most of your online documentation says it must be added. (But the Visual Studio new project template is already adding UseApplicationInsights()
to the WebHostBuilder, which apparently does the same thing.) Makes it confusing for us users!
I plan to make the calls idempotent after the next release (don't have time for this release) so this issue doesn't occur again.
Hi, I am getting duplicate entry in Azure for exceptions. In my Configure method in startup.cs have following code which is my custom global exception handler which uses telemetry.trackexception to log exception details along with POST request's body as custom property. app.UseExceptionHandler((options) => GlobalExceptionWrapper.HandleException(options));
And in my Program.cs I have following code..
var host = new WebHostBuilder()
.UseKestrel()
.UseContentRoot(Directory.GetCurrentDirectory())
.UseIISIntegration()
.UseStartup
host.Run();
so wondering what's wrong going on here? And what's the best approach to handle the exception in ASP.Net Core 2.0 Web API project with Application Insights? Is there any document or sample for Web API project? This document is for MVC error handling but what's the best way for web api?
Thanks!
I'm not sure where to post this question, but this seems like a good place. We are currently calling UseApplicationInsights
in Program
, but App Insights Live Metrics Stream says "Not available: your app is offline or using an older SDK". Will calling AddApplicationInsightsTelemetry
in Startup
fix this issue? Is that the recommended approach going forward?
I created new ASP.NET Core Web Application in Visual Studio 2017. And I added only this line in the
ConfigureServices
ofStartup.cs
When I run it on local machine, it duplicates every telemetries by 4 times. This telemetry duplication happens on both debug session and actual Azure Application Insights service. When I run it on azure Web App, it even doesn't send any telemetries at all.
If I remove above line of code, then it runs as well as I expected on both local machine and Azure Web App.
It doesn't look like an expected behavior at all, right?
The version of
Microsoft.ApplicationInsights.AspNetCore
was2.0.0
in this experiment.