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)
Related
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'm able to successfully call my functions and make them do what I want them to do. The problem is that it doesn't look like the logs are being saved anywhere and I don't see how I can view them. Which I'll want to do in the event of an error. As a test I have my working function just doing a log.Info as soon as it's called. When testing locally it prints the message to the console. I believe I've enabled everything correctly but let me explain what I've done in case I didn't.
In my app service, under Monitoring -> Diagnostic Logs, I have enabled everything. Application Logging (filesystem) verbose, Application Logging (Blob) verbose (with the storage location set), detailed error messages and failed request tracing turned on.
In my function, I'm using the TraceWriter object that's passed to my run method (I started from a template).
Please note that functions are set to require authentication. If I click on the "Monitor" tab nothing appears. It just says "Loading..." forever and there's no information. Perhaps this is because of the authentication?
I used the Azure Storage Explorer to browse to my blob. The "log" blob exists, and I do see a set of nested directories that lead up to now. However it just contains a 354 byte file that contains a few lines of some random info. This file never seems to update or get larger.
I used FTP to try and browse to where the logs might be, but there's no directory on there that contains any log files.
I also went to KUDU for my function app ({myfunctionapp}.scm.azurewebsites.net/azurejobs/#/functions). While I do see that my function was called successfully, I don't see anything from the call to log.Info anywhere.
I tried using a different logger, and as a test did: System.Diagnostics.Trace.TraceError("test error");
I also don't see this message appearing anywhere.
Am I missing something as far as set up goes? Is the problem the fact that I require authentication? If it's the latter, is there still a way to view logs? I definitely have to have auth enabled. Thanks. And if it helps, below are links to what my settings and the monitor tab look like.
Settings: https://postimg.org/image/u57m2xbl5/
Monitor: https://postimg.org/image/uou10arch/
Authentication should not cause any problems with logging and Log.Info should work out of the box, no setup required.
I highly recommend that you enable AlwaysOn for your dedicated function app. The long loading of the Monitor tab could be because your site is in a 'cold' state, where it takes longer to start up.
If you go to {myfunctionapp}.scm.azurewebsites.net/DebugConsole and navigate to LogFiles/Application/Functions do you see any expected logs there? Also, when you run a function from the portal do you see logs in the log window?
Same thing happened to me if I had Fiddler open....close Fiddler and all is good.
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'm trying to figure out why I'm getting 500 errors in setting up a website in IIS.
So far I've tried the following steps:
Enabled Failed Request Tracing (Doesn't write logs for this site, but
works for other sites)
Enabled detailed error messages. Still Getting the default 500 page
with no additional information.
Give app pool full permission to the project directory.
Made sure app pool was running on classic .NET 2 (old app)
Running the site under a permutation of (Classic/Integrated, .NET
2/4)
Enabled anonymous authentication
So my thinking is, somehow, the site fails before the logging modules are ran.
I suspect this is the case because I see no new entities in Event Viewer, IIS Advanced Logs folder, Or in Failed Request Tracing folder. My only source of information (besides 500 error) is a new entry in the IIS log:
2012-12-04 13:06:05 127.0.0.7 GET / - 80 - 127.0.0.1 Mozilla/5.0+(compatible;.....)
To verify this, is there a way to check which stage of the pipeline a request failed? Is it possible to run the logging modules before the failure occurs?
There is a trace event logger for HTTP.sys. With this you can determine if the request is even making it to the right app pool in IIS. Direction on usage
As a last resort, Microsoft offers a tool called Debug Diagnostic. When you have no other option, use this. It will produce a crash dump of the app pool of your choice. Not easy to go through, but it’s a lead. Direction on usage
I've got an Azure app up and running, but various requests generate a 500 error. There are no other details that come back from the server to let me know exactly what the problem is. No stack trace, no error message. The only thing I get back from the server are the http headers indicating I've got an error.
I've done a little looking around but can't seem to find a way to retrieve the error details that I'm looking for. I've seen some articles that suggest that I enable logging, but I'm not sure 1) how to do that, 2) where those log files would go and 3) how to access said log files. I've seen posts that say to add a whole bunch of code to my application to enable logging, but all I'm looking for is an error message and a stack trace from a 500 error. Do I really have to add a bunch of code to my app to see that information? If not, how can I get at it?
Thanks!
Chris
The best long-term solution is to enable Azure Diagnostics, which I think is what you're referring to. If you want a quick-and-dirty solution, you can log errors out to a file and then RDP into the role instances to view them. This is very similar to what you would do on a server in your own datacenter.
You can create the logs however you like. I've used log4net and RollingFileAppenders with some success. Setting the logfile path to something like "\logs\mylog.txt" will place the logs in the E: drive of the VM. Note you'll still need code somewhere in your app to capture the error and write it to the log - typically the global error handler in Global.asax is a good place for that.
You'll also have to enable RDP access to your role instances. There are many articles detailing how to do that. Here's one.
This is not a generally recommended approach because the logs may disappears when the role recycles or is recreated. It's also a pain in the butt to log to keep an eye on all those different servers.
One other warning - it's possible that the 500 error is due to some failure in your web.config. If that is the case, all the the application-level error logging in the world isn't going to help you. So be sure that your web.config is valid, and also check the Windows Event Logs while you're RDP'd into the server.
500 internal server error is most generally caused by some problem on the server when it was not able to understand incoming requests or there was some problem in configuration. So, try to run the app locally and see if there is some problem. You can record errors in a database in catches/application_error and also can use tracing. Believe me they are very helpful and worth a few extra lines of code.
For tracing have a look here, http://msdn.microsoft.com/en-us/magazine/ff714589.aspx