I have added Azure Application Insights to a number of my .Net WebAPI applications. I've noticed that I do not receive successful request telemetry from these applications. I do receive dependency telemetry and failed requests but not the actual telemetry that the request has been made. By fudging the URL or the request and forcing a failure, I can see that get sent to AI, so my issue is definitely not with the instrumentation key.
I initialize the instrumentation key as follows:
Microsoft.ApplicationInsights.Extensibility.TelemetryConfiguration.Active.InstrumentationKey =
ConfigurationManager.AppSettings["ApplicationInsightsKey"];
I have attempted to remove AI from the application entirely and added it again using the Configure Application Insights option but it still does not work. There is another of my web apps that uses AI that was configured a while back and it works perfectly, I have replaced the set up of the broken app with that of the working app and also made the package versions line up but I still only get telemetry for failed requests. The capture below from the Live Stream shows this, the red arrow points to the dependency calls made for the successful request, yet nothing shows in the Request Rate graph for it. In contrast there is a failure before it, and that is logged.
I just found the answer for this in a solved issue on the Application Insights Github. The solution is to open your ApplicationInsights.config and scroll to the telemetry module Microsoft.ApplicationInsights.Web.RequestTrackingTelemetryModule below it comment out the line System.Web.Handlers.TransferRequestHandler
This issue has been fixed and is due to go out in version 2.5 of the packages. You can read through the issue here https://github.com/Microsoft/ApplicationInsights-dotnet-server/issues/175
Try below one, it works for me:
Microsoft.ApplicationInsights.Extensibility.TelemetryConfiguration configuration = Microsoft.ApplicationInsights.Extensibility.TelemetryConfiguration.CreateDefault();
configuration.InstrumentationKey = System.Web.Configuration.WebConfigurationManager.AppSettings["InstrumentationKey"];
Related
I have written some simple functions and enabled Application Insights,
Its all showing as connected and I can see that's its tracking http statues, eg I get a failed request count and server response times etc.
I understand that I can add application insights to node with the following code
let appInsights = require("applicationinsights");
appInsights.setup("[your ikey]").start();
But I was hoping it would just work without this, I can see that the function is outputting logs when I use the log stream
But when I use app insights I don't see anything in any of the log tables
Do I need to add insights via code to my function or I am missing some secret config option.
That's also a good idea to add application insights module into your node project to achieve monitor feature for your function. Both code and codeless are good choices.
In my opinion, the biggest difference between code and codeless monitor is the custom telemetry data. But I think in most scenarios, default information collected is enough for daily using, official doc says:
Application Insights collects log, performance, and error data, and
automatically detects performance anomalies.
So I think it's ok for you when you could get traces and error messages after adding appinsights module and recreate a new appinsights instance. And you can also try to use codeless configuration I mentioned in the comment(azure portal-> your function written by nodejs-> Application insights-> enable-> create new resource)
This is a similar post to Azure Web App Trace logs not appearing in log, however the original poster seems to have abandoned the question without resolving/accepting an answer.
I am trying to trace an issue that only happens on the Azure web app (now called app service). I'm unable to perform any remote debugging due to our company policies, so tracing is our best tool.
However, I've tried following various tutorials, but I still can't seem to get any of my trace information logged.
I've tried:
Setting the Application Logging (Filesystem) Level to Verbose, Information, Error -- nothing.
Looking for the logs in
the FTP server at /LogFiles/Application
the KUDU interface at https://.scm.azurewebsites.net and again, navigated to /LogFiles/Application
portal's Monitoring > Live stream (the section under Diagnostic Logs for the website)
Nada. I've even waited a few hours (thinking it might be a delay), and still nothing.
I setup a very basic hello world ASPX and all it does (in the Page_Load) is try to write 'hello' to the trace log using
Trace.TraceError
Trace.TraceInformation
Trace.TraceWarning
Trace.WriteLine
Console.Out.WriteLine
Console.Error.WriteLine
Some weird stuff I've also tried
setting my debug=true in my web.config
setting CustomErrors from RemoteOnly to Off
trying to use System.Diagnostics.TextWriterTraceListener
Anyone have any ideas I might try?
Exceptions in your live web app are reported by Application Insights. You can correlate failed requests with exceptions and other events at both the client and server, so that you can quickly diagnose the causes. You may refer this article: https://learn.microsoft.com/en-us/azure/application-insights/app-insights-asp-net-exceptions.
If you use NLog, log4Net or System.Diagnostics.Trace for diagnostic tracing in your ASP.NET application, you can have your logs sent to Azure Application Insights, where you can explore and search them. Your logs will be merged with the other telemetry coming from your application, so that you can identify the traces associated with servicing each user request, and correlate them with other events and exception reports. You may refer this article: https://learn.microsoft.com/en-us/azure/application-insights/app-insights-asp-net-trace-logs.
I had an issue on my test server that was throwing an exception, I noticed that it logged nothing to application insights so first tried to debug on my local machine. I managed to replicate the issue, and low and behold in my DEV application insights I have server exceptions logged.
So I go back to my Test Application insights and again replicate the issue but still no errors logged (Even after an hour or so).
However I can see it logs them as "Failed Requests", just not Server Exceptions. Without the server exceptions I can't see the stacktrace/error message.
I am using the Log4Net app insights extension to log these exceptions. It's obviously not a code issue because the same code is being run in both cases. So I looked at configuration issues.
My log4net.config and applicationinsights.config have no transforms from Dev to Test (Or to prod). They stay the same.
My Web.config only has a transform to remove the debug=true as is standard.
I do set some environment properties in Azure (Using Azure Websites), but the only one that is actually application changing is the AppInsightsInstrumentation key to switch it to a different AppInsights. However I know that this key is correct because I'm logging some things, just not others.
Here's the answer (Kinda)
I was logging the exception in a Basecontroller, this worked fine on my local machine and I could debug through.
What happens though is when I push it remotely, .net's out of the box error handling kicks in. Notably the global "HandleErrorAttribute" (Check your FilterConfig.cs). This seems to capture and swallow the exception. There is lots of other talks about this if you wish to override this behaviour, mostly when talking about other logging tools like Elmah.
The reason I only see this in my test environment is because CustomErrors defaults to remoteOnly. So I only see it not logging when it's not on my machine.
Because I'm handling errors myself, I can remove this line from my FilterConfig.cs
filters.Add(new HandleErrorAttribute());
And server exceptions should be logged now (I also handle showing the user a nice error page in my BaseController for now)
I am setting up an ASP.NET WebApi application running on the Azure web application environment. Most of my controllers and endpoints work fine, but there are about 10 routes that return 500 errors "An error has occured". It's not random. It's the same routes every time and I can find no pattern (not all the HTTP methods, from different controllers where other routes in that same controller work fine, and so forth)
When these errors occur, no error logging gets triggered as far as I can tell in the app. (I am using Raygun.IO if that matters). I tried adding a global.asax file with following lines in the Application_Error function:
Exception ex = Server.GetLastError();
new RaygunClient().SendInBackground(null, ex);
but as far as I can see, it doesn't get triggered when these 500 errors occur. The only thing I have found in the Azure server logs is the following warning in the Failed Requests log:
However, I don't see any errors in the trace previous to that point. I'm also not finding any other errors in any of my Azure logs that I can relate to these failing routes.
It's .NET 4.6 (tried 4.5.1 and 4.5.2 with no difference) WebApi using an OWIN startup class. Also tried updating all my packages to no effect.
Check to be sure you don't have routes that conflict. When a URI matches two or more controller actions, and thus Web API can't pick one, you will get a 500 error.
If you have a consistent repro, then you can use remote debugging to attach to your web app and debug it (https://azure.microsoft.com/en-us/documentation/articles/web-sites-dotnet-troubleshoot-visual-studio/). If you can repro it through the browser, you can also turn the custom errors page off so that it shows the stack trace through the browser (<customErrors mode="off"/> under <server.web>).
Also, you can enable better diagnostic logs using the web app settings. Information on how to do so is here: https://azure.microsoft.com/en-us/documentation/articles/web-sites-configure/ under the section "Enabling diagnostic logs".
Also, as Brent said, URL conflicts can cause some nasty errors which aren't immediately obvious.
I figured out what was going on. There were actual errors occurring (mostly SQL related), but the way that we had configured the functions and error logging in those functions, the actual errors were being swallowed up and lost, overriding the error logging behavior of Raygun. I went through and ripped out the Try/Catch blocks we were using for error trapping and logging and the real errors finally emerged into the Raygun dashboard.
I am supporting a web app that uses the DocuSign Connect API to handle signature processing. We are running in production and demo environments (our production environment is using the DocuSign production environment; our demo envrionment is using the DocuSign demo environment).
The interface between my app and DocuSign Connect has been working smoothly for over a year. Sometime in the last week or so, the demo environment began misbehaving. In that time, the production environment has continued to work fine.
The problem is this:
In demo, when a signature event occurs, DocuSign is unable to call our callbackUrl. The failure log indicates the following:
https://[mywebsite]/SignedDocument/DocuSignSignatureEvent :: Error - The request was aborted: Could not create SSL/TLS secure channel.
When I look at my DocuSign Connect Settings, I see a new setting -- "Require Mutual TLS" -- that does not exist in production. I'm not sure if this is related -- I have no idea when this setting was added to the demo environment.
Even though this is a demo app, it poses a problem for us (because our demos no longer completely work). But it poses a much bigger problem if/when this same thing (via a code push or something else) begins happening in production.
Again, this interface has been working fine. Nothing has changed on my web app since the last successful callback occurred (roughly a week ago).
Please try this again, DocuSign Support indicates this should be resolved now.
We've been getting the same error starting today. Nothing has changed recently on our side to affect the demo environment. I'm thinking this might be an issue on DocuSign's end.