I'm using Log4Net to log a multilayer-ed Enterprise Application.
I know that when I log an exception with Log4Net, it automatically exposes the exception StackTrace, but I want to log the StackTrace for every log call, even if those are not exception throws.
Why do I need that?...
I want to know the call origin of the log (drilldown the layers...)
Thank all...
Tiago Dias
I came to a solution to my problem.
I've wrap around the log4net in my own methods and i've created LoggingEvent intances. In each instance i've used a property with Environment.StackTrace.
This way i have StackTrace foreach log event in my application, even without exceptions being throwned.
Thank U all..
You can get the caller method name and line number using %location, but not the entire stack trace without extending log4net. Check responses to this question:
Does log4net support including the call stack in a log message
Also check the PatternLayout documentation page on apache.org for other location details you can output:
http://logging.apache.org/log4net/release/sdk/log4net.Layout.PatternLayout.html
Not sure if this still applies on modern computers, but the log4net documentation warns that generating caller information is costly.
Related
I'm adding several custom properties to my AppInsights events using Initialize method of ITelemetryInitializer. Some of them are retrieved from the database or other sources which might fail. The question is, are there any official recommendations from the developers on whether or not a try-catch clause should be included inside of Initialize method?
From what I've observed, throwing an exception inside the method doesn't prevent telemetry from appearing, though the custom properties cannot be seen, as expected. Can I rely on this behaviour? Does it somehow affect performance that I don't handle exceptions manually and let AppInsights' code handle them instead?
It depends, doesn't it. If the telemetry initializer adds multiple custom properties and the first one in line fails with an exception, do you want to try to add the others. If so, put a try/catch around each custom property.
If it is just a single property, or all should not be added as soon as the first one fails then you could choose not to handle the exception. In my opinion however, I would want to have control over the exception propagation and choose for handling them myself. (and maybe ignore them with an empty catch, depending on the situation)
Ignoring them completely may give troubles in the future when the SDK for example is altered to not send the telemetry to App Insights when a telemetry initializer fails with an unhandled exception. At least if you decide to go this route try take a peek in the source code of the SDK to see what happens with the unhandled exception.
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
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 am using Log4Net API in my application to log any important event or information as well as logging my exceptions in database.
There might be an exception while using Log4Net API; if it fails to perform logging into database then how will this exception be stored? Where will all other logging and exception logging be stored in case the Log4Net API fails to perform logging?
Log4net will fail silently so that the primary function of the application is not disturbed. If you have an event that you absolutely need to have in the database, the you should make it part of your business logic i.e. write it yourself to the database.
If you insist using log4net for this, then you could write an appender that has some fail over logic that makes sure that all events get logged to the database (eventually). However this does not seem to be a good idea...
As for normal logging: In order to ensure that I have logs I usually use a rolling file appender in addition to other appenders. This way I can be quite sure that in the worst case I have the log available in a file.
I have a WCF Client Proxy connected to a third party webservice.
The proxy works fine with nearly everything except on function.
This function works just fine with a ASMX proxy.
I have added service trace logging and can see the response from the service coming back.
Only the proxy returns null.
So now I know for sure that the proxy is at fault.
Where to from here?
RESOLUTION
I found the issue. WCF is less forgiving than an ASMX proxy.
The service WSDL specifies that the returned object was called "data", and the actual xml passed back was called "result"
So that was a great goose chase! I think i wasted 4 hours on this problem!
You can try to use Trace Viewer to analyse WCF communications in more detail and find out more detail when errors are encountered.
Within the app.config (Client) and web.config (Server), you can add blocks. To enable tracing, simply add dignostics blocks and trace files will be generated in the specified location when the app is run. This should enable you to dig a little deeper with the problem.
Trace viewer can be found:
("C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\SvcTraceViewer.exe")
Info on trace viewer usage:
http://msdn.microsoft.com/en-us/library/aa751795.aspx
Also, what type of method is it? does it return complex types or simple types?
ADDED:
Ah, sorry about the mis-read, didn't realise you had no control of server side. I'd try to update the service reference/proxy (you've probably already done that) and check if anything has changed.
WCF doesn't make tracking down issues very easy i'm afraid. Is it possible to provide the method signatures for a call that works and one that doesn't so we can see what data types are being passed about?