my question should be quite simple, but unfortunately I had no luck in solving it.
Basically, I have some Web API controllers hosted by OWIN and deployed on Azure.
I really need to track down exceptions that occur in each middleware (for example OAuthAuthorizationServerProvider or SignalR Persistent Connections), but I definitely don't have a clue on how to achieve it.
I tried Elmah, but it doesn't seem to work properly with OWIN due to lacking HttpContext.
I tried using log4net, but I'm only able to log exceptions thrown by Web API Controllers using a custom ExceptionFilterAttribute.. others are ignored.
I tried to define a custom LoggerFactory and to assign it in Startup, using app.SetLoggerFactory(new MyLoggerFactory()),
but exception thrown by other middlewares are not logged.
I tried to get at least a meaningful error message sent to the client, but despite <customErrors mode="Off"/> and <deployment retail="false"/>, Azure refuses to return anything but {"message":"an error has occurred"}.. I tried both Azure Web Sites and Azure Cloud Services.
I saw some cloud alternatives that should work with OWIN, like Elmah.io or Raygun.io, but I don't need their cloud features and it is definitely not worth paying hundreds $ per year just to log some exceptions.
What should be the best way to log any possible exception thrown by my application?
Thanks for your help
have you take a look at this link ? http://www.asp.net/web-api/overview/error-handling/web-api-global-error-handling
Because you can't catch all the exceptions using an exceptionFilter, they propose to use a IExceptionLogger and IExceptionHandler to allow global error handling in Web Api 2.
After that, if it's not fit your need, you can construct an OwinMiddleWare that you will place in first position (before the Authenticate stage), this middleware could :
create a requestId in the header of the response
analyse the response code, before sending response, and if it's not a IsSuccessStatusCode, you could log the exception message to a DB and replace the content of the response to send a simple error message to the client using the requestId (to allow you to find the related exception in your db)
hope this help
Related
We have a NodeJS app that uses Express. We've seen a few PayloadTooLargeError message start to pop up, but the problem is we don't know whats causing it or how to recreate. The error message also doesn't give us any indication of which route the error is occurring on. Is there a way for the stack trace or error message to detail which route is causing the error? We have quite a few routes with APIs from multiple services, so debugging them all is almost impossible.
Adding a custom middleware that logs the request uri before the route is called will allow you to see which uris are throwing errors.
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 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'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
I have created a custom SharePoint web service that was deployed to, and successfully tested on, a test environment. Unfortunately, the web service has since stopped working, and I am trying to determine what the error is.
The web service now returns the following error in the SOAP response:
SOAP:server
Server was unable to process request. Object reference not set to an instance of an object.
There have been no changes to the deployed web service, so I am assuming that a more recent deployment has altered the SharePoint configuration. My web service .asmx is deployed to the _vti_bin folder, and the assembly is deployed to the GAC. I can see the WSDL file being displayed when I browse to http://servername:port/_vti_bin/MyCustomWebService.asmx. The web methods in the assembly make use of logging (to the Windows Event log), but no logging is occurring when I try and access the web service, which suggests that the call is not getting as far as entering the web method.
Given the above, can anyone offer any suggestions as to debug this issue?
Thanks. MagicAndi.
Update
I have now realised that when I consume the web service from the endpoint http://servername:port/Site/_vti_bin/MyCustomWebService.asmx, it works, but when I use the endpoint http://servername:port/_vti_bin/MyCustomWebService.asmx, the web service fails as described above. I will update further when I diagnose the cause of the issue.
this is a try catch to get more infomraion on the exception. It will give you more information which will help debug your problem
try {
// Do soap call here
}
catch (System.Web.Protocols.SoapException soap_ex)
{
Console.WriteLine(soap_ex.Detail.OuterXML);
}
catch(System.Exception ex)
{
Console.WriteLine(ex.Message);
}
The easiest option is to attach a debugger set to break on exceptions. If your infrastructure rules don't allow that, you'll probably need to add some additional logging to your code on the server. If you are lucky there may be enough information available in the soap message, but in my experience null reference exceptions usually need more information to be found easily.