While using EventHubTrigger Azurefunction such a ugly exception received (As below) in telemetry traces of ApplicationInsights.
AI (Internal): [Microsoft-ApplicationInsights-Core] EventSourceException while processing event "LogVerbose": System.NullReferenceException:Object reference not set to an instance of an object.
Details :
timestamp [UTC] : 2019-01-24T04:10:02.5700507Z
message : AI (Internal): [Microsoft-ApplicationInsights-Core] EventSourceException while processing event "LogVerbose": System.NullReferenceException:Object reference not set to an instance of an object.
sdkVersion: dotnet:2.8.1-22898
https://github.com/Microsoft/ApplicationInsights-dotnet/issues/973
The recommended workaround is to use 2.7.2 of Application Insights dependency.
For now, the options are:
use the same version of AppInsihgts that Functions use (or lower)
Filter out internal SDK messages. You can do this by creating and configuring telemetry processor. You can have a filter that checks if telemetry is TraceTelemetry and traceTelemetry.Context.Operation.SyntheticSource is SDKTelemetry
<PackageReference Include="Microsoft.ApplicationInsights" Version="2.7.2" />
Otherwise there is pretty much nothing except to wait and hope that version 2.9 will contain a bugfix for this.
As I have mentioned the link in comment regarding open GitHub issue: https://github.com/Microsoft/ApplicationInsights-dotnet/issues/1029
And #Alex AIT shared a link which is an open issue related the same problem :
https://github.com/Microsoft/ApplicationInsights-dotnet/issues/973
However, I found a concrete answer with the reference of Microsoft Docs:
Application Insights for Azure Functions supported features
In summary:
According to the reference by Microsoft Docs on Supported feature on azure function V2 with Application Insight, If you want to use Application Insight then set an Application Insights version 2.7.2 rather than 2.8.0 and 2.8.1.
Some issues are responsible due to the Application Insights version: 2.8.0 and 2.8.1.
So, we should use Application Insight version 2.7.2 till the new update is not coming from Microsoft/stable version for V2.
https://learn.microsoft.com/en-us/azure/azure-monitor/app/azure-functions-supported-features
Other Exceptions faced with Application Insights 2.8.1 such as
AI (Internal): ERROR: Exception in Command Processing for EventSource Microsoft-ApplicationInsights-Core: An instance of EventSource with Guid 74af9f20-af6a-5582-9382-f21f674fb271 already exists
AI (Internal): EventSourceException while processing event "DiagnosticsEventThrottlingHasBeenResetForTheEvent": System.NullReferenceException:Object reference not set to an instance of an object.
Now, which is resolved via to degrade the Application Insights version as 2.7.2 which is actually supported to Azure function V2.
Related
Our application is using azure application insights. What I read is that, using application insights end to end tracking, we can even get the query which gets executed at database and how much time that query took.
But as shown in the screenshot, azure app insights shows me that there are 3 calls made to database but not the actual query that was executed against the database in those calls.
What I need to know is that what i need to do inorder to get the query that was executed against the database?
This is one of breaking changes as part of SDK 2.14.
You just need to simply modify ConfigureServices() with the line below for ASP.NET Core:
services.ConfigureTelemetryModule<DependencyTrackingTelemetryModule>((module, o) => { module.EnableSqlCommandTextInstrumentation = true; });
and for ASP.NET modify ApplicationInsights.config file:
<Add Type="Microsoft.ApplicationInsights.DependencyCollector.DependencyTrackingTelemetryModule, Microsoft.AI.DependencyCollector">,
<EnableSqlCommandTextInstrumentation>true</EnableSqlCommandTextInstrumentation>
</Add>
Yes, the application insights can track sql query. But note that there are some changes in the latest version of application insights nuget package, which makes it does not automatically track sql query.
You can do it via the workaround below.
Assume you're using the .net core web project. Then you need to downgrade the Microsoft.ApplicationInsights.AspNetCore to version 2.12.0.
Here is my test result with version 2.12.0 of that package:
And also, you can use other workarounds, see here for more details.
We have a function deployed to azure running the v2 runtime. If I go to the function in the portal to try to upgrade it to v3, I see this message "Cannot upgrade with existing functions: Major version upgrades can introduce breaking changes to languages and bindings. When upgrading major versions of the runtime, consider creating a new function app and migrate your functions to this new app."
However, I was able to change the function in Visual Studio and deploy, using a simple test deploy of right-click publish, and the publishing process upgraded the deployed function to runtime v3.
Are there any gotchas we may run into using this approach? Is it better practice to create new azure function resources to deploy to a clean v3 azure function?
Thanks
Apparently no one else has this question or the answer is obvious. In any case, here's Microsoft's recommendation from their support personnel (grammar/language translation is Microsoft's):
Based on the official documentation changing the version can be made by changing the App Setting "FUNCTIONS_EXTENSION_VERSION" value form ~2 to ~3 however this can cause some problems if there are any dependencies unique to version 2 of the runtime, you can read more about this in the following link
https://learn.microsoft.com/en-us/azure/azure-functions/functions-versions#migrating-from-2x-to-3x
Now based on my experience the safest an easiest way to archive [achieve] this is to deploy the code into a Function app that was created targeting the version 3 of the runtime this is to assure [ensure] that it will only have the dependencies form [from] version 3 and not having anything extra from 2 left after changing the version directly from the portal
The idea with this is to avoid having conflicts from between assets form version 2 or missing assets from version 3
Suppose you are using c# function, if yes, the major update about v2 to v3 is the .net core version. So mostly if your code could work with the update that means your dependencies are compatible with .net core3, so mostly it won't crash.
And there is an official doc about migrating from 2.x to 3.x.
And about deploying, if the runtime is different when you deploy it will prompt to update the portal runtime, so it won't affect the function running.
TL;DR: Does ExcludedTypes in Microsoft.ApplicationInsights.AspNetCore SDK default to Exception and Trace?
I am running an ASP.NET Core 2.2 app with version 2.6.1 Microsoft.ApplicationInsights.AspNetCore SDK. I am reading: https://learn.microsoft.com/en-us/azure/azure-monitor/app/sampling#configuring-adaptive-sampling-for-aspnet-applications where they write that the default values for ExcludedTypes is Trace and Exception, which is just the way i like it, but I am wondering, since the default values is for ASP.NET (actually specified in the application insights config for the host), if these default values also apply for ASP.NET Core applications that doesnt have an application insights config file (all config is done through code).
I know that the SDK is open sourced, but I haven't been able to search through it and find the initial values: https://github.com/microsoft/ApplicationInsights-aspnetcore. Maybe I am just searching for the wrong things.
Update:
Yes, the default ExcludedTypes for asp.net core is Event. There'are 2 places mentionded that:
1.In this article, it says "In ASP.NET Core, exact same default behavior is enabled in code.":
2.In the source code, you can find it's defined here:
First, the default values for ExcludedTypes is not Trace and Exception, it is Event. There is a GitHub issue for that. And I also tested it myself, the default ExcludedType is Event indeed.
For asp.net core, the default ExcludedType should be same as asp.net, you can take a look at this section of the article you provided. I'll try to go through the code to find out what's in the code for asp.net core and will update you later.
It's possible to install Application Insights via the extensions section in Azure App Services, but it's also possible to just install the packages via NuGet and define the APPINSIGHTS_INSTRUMENTATIONKEY application setting. You can also do both.
What is the difference?
Edit:
I have found what the differences are between installing the extension or the NuGet packages:
You can configure monitoring by instrumenting the app in either of two ways:
Run-time - You can select a performance monitoring extension when your web app is already live. It isn't necessary to rebuild or re-install your app. You get a standard set of packages that monitor response times, success rates, exceptions, dependencies, and so on.
Build time - You can install a package in your app in development. This option is more versatile. In addition to the same standard packages, you can write code to customize the telemetry or to send your own telemetry. You can log specific activities or record events according to the semantics of your app domain.
Source: https://learn.microsoft.com/en-us/azure/application-insights/app-insights-azure-web-apps#run-time-or-build-time
But what if you do both? Will there be anything beneficial about it?
But what if you do both? Will there be anything beneficial about it?
The extension detects that your app has already brought Application Insights with it and won't do anything, except dropping a profiler, which helps collect full SQL Statement in Dependencies. Without the profiler full SQL Statement won't be collected but everything else should just work fine.
(If you are using 2.3.0 or earlier of SDK or if you application is targeting old .NET Framework like 4.0, then profiler does better correlation of dependencies as well.
In short, Starting with 2.4.0 of SDK, the only advantage of installing extension on top on nuget installation is to get full SQL Statements in Dependency Telemetry.
But what if you do both? Will there be anything beneficial about it?
As you know we could install the packages via NuGet to use Application Insights .For this way, we could add custom telemetry data in my code,and monitor the telemetry data in application insights tools in Visual Studio. This will be very convenient. You could also refer to this article to add custom telemetry data.
Code in MVC Porject:
public ActionResult Index()
{
Trace.TraceInformation("my trace info Home/Index");
var telemetry = new Microsoft.ApplicationInsights.TelemetryClient();
RequestTelemetry requestTelemetry = new RequestTelemetry();
telemetry.TrackTrace("Home/Index Main");
telemetry.TrackPageView("Home/Index");
return View();
}
The telemetry data in Application insight tool:
The application insights in App Service,you can only see limited data and trends in past 24 hours. This is very convenient for you to view the main telemetry data in the app service directly. But if you want to know more details, that is not a good choose.
The most comprehensive monitor data and services are in application insight service. You could click 'View more in application insights' in App Service monitor extension to go. Or you could go to application insight service directly.
Time Range in application insight service(include custom time range).
I'm trying to read a message from an Azure ServiceBus queue using an Azure WebJob but it's throwing and exception:
Unhandled Exception: System.InvalidOperationException: Found 2 DNS claims in authorization context.
I've set the correct connection strings named "AzureWebJobsServiceBus", "AzureWebJobsDashboard" and "AzureWebJobsStorage"
The WebJob Program code has been updated to use JobHostConfiguration:
class Program
{
static void Main()
{
var config = new JobHostConfiguration();
config.UseServiceBus();
var host = new JobHost(config);
host.RunAndBlock();
}
}
And the actual Job method
public class Functions
{
public async static Task ServiceBusResizeRequest(
[ServiceBusTrigger("blah")] string message,
TextWriter log
)
{
await log.WriteLineAsync("got message " + message);
}
}
I can successfully create and write to the queue via a separate console application.
But when I run the webjob application, it throws that exception.
Any ideas?
EDIT: Using .net 4.6.1
The answer marked as solution, is not the solution, it is a botched job.
The solution to use it in .Net Framework 4.6.1 is to add in the rutime block in App.config:
<AppContextSwitchOverrides value="Switch.System.IdentityModel.DisableMultipleDNSEntriesInSANCertificate=true" />
Read this article Mitigation: X509CertificiateClaimSet.FindClaims Method
Very IMPORTANT for now Azure WebApps / WebJob etc, doesn't support 4.6.1 I will note here when (said at jan 21, 2016).
It means, that you can develop a web job application with 4.6.1, but when you push it to Azure, you can see exceptions like Job failed due to exit code -2146232576
January 29th Microsoft released version 3.1.3 of the NuGet package WindowsAzure.ServiceBus.
From the release notes:
• General: .Net 4.6.1+ compatibility fix. Fixing custom DNS IdentityVerifier so that we honor multiple DNS claims returned by WIF
Upgrading the package solved the problem for us.
As outlined in this answer above, the snippet below does the trick
<runtime>
...
<AppContextSwitchOverrides value="Switch.System.DisableMultipleDNSEntriesInSANCertificate=true" />
...
<runtime>
BUT be carefull to add it to the correct project in your solution! Add it to the project containing the Azure code and Azure references.
Microsoft released a new package (under a new name) to fix this issue. So ...
remove the Microsoft.AspNet.SignalR.ServiceBus package,
install the Microsoft.AspNet.SignalR.ServiceBus3 package instead, and
upgrade the WindowsAzure.ServiceBus package.
More info here: https://github.com/SignalR/SignalR/issues/3548#issuecomment-296326048
Downgrading from .net 4.6.1 to 4.6 seems to prevent the issue from occurring.
Today, I ran into this issue and had no idea about it. Finally, I decided to upgrade all the Azure nuget packages that I am using (including webjobs, servicebus ...) and BOOM! it WORKS. Hopefully, it will help if anyone runs into this issue in the future
For me it started failing after I updated .NET Framework from 4.5.2 to 4.7
All I did to fix it was update the Nuget Package WindowsAzure.ServiceBus to 5.2.0