Developer forum

Hi Unnsteinn,

Those log events are categorized by a level. We have the same loglevels as NLog, but we currently only use 3: Information, Warning and Error. If the level is below Error, then the exception will probably always be empty (because an exception is an error), and even some errors are not the result of exceptions. So, in short, you cannot be sure that a logevent contains an exception, which is completely what we expect.

IF a logevent contains an exception, by the way, then it's already logged to disk and you can see it in Settings -> System -> Event Viewer.

Lastly, please measure your sites performance when you use this notification. If you add slow custom code here, pretty much all of your site will be slow as a result, so keep that in mind. :)

BR

Martin

We are using this to enhance our logging to get better overview. I managed to use the file content like this logArgs.Event.GetLogFileContent() to get the stack trace but that will slow things even more down for me since I am reading from disk every time.

When I observe the Event class the Exception object is being used there and what I was thinking was a method that would simply return that object if it exists, then I can directly access the stack trace and slower performance due to disk read.

Hm, well, that's not something out logging framework currently supports.

Out of curiosity, why do you have so many uncaught exceptions, that it's an issue to read a stacktrace from disk? Im trying to understand, because I get what you want me to do, but I don't understand why, which makes it hard for me to "sell" as a feature request. :)

Currently we use the model to both Persist the event to database and disk AND to present the information in the UI. The exception won't be available as a property on the presentation time, so simply adding something that exposes the exception is not possible. It will have to be some sort of sneaky inheritance - and this will make the models harder to understand, so I need to really understand the usecase to make this in a nice way.

My fix was to read it from disk but then you mentioned that by hooking into this observer I could run into performance issues, then I got concerned about reading from disk. There are somtimes uncaught exceptions that do occur even though it is not frequent. But I just noticed that the Exception object was there in the Event so I thought that it would be simple to expose it through a function but if that is problematic then for sure don´t waste any time on it. I will keep on reading from the log file to access the stack trace.

One of the reason we are not relying on the DW UI for the event viewer is that it cannot show but one page so I can only view recent erros and we are logging to a 3rd party platform other errors as well so we have everything in one place.

I see no reason why it should give you any problems to do what you describe that you are doing. IF you run into performance issues, taking a look at that piece of custom code is probably a good idea, though. :)

It sounds like you have an interesting idea for giving an overview of what is happening on the site. Please let me know how it goes.

It is going well so far, we are using Influx to store all our error logs and display them on a monitor in the office for easy access, we are now logging with the stack trace the uncaught exceptions that the LogEventBeforeSave is catching, this will help us identify the errors and where they are raised. The reason for the importance of the stack trace is like I mentioned above, when we go to the event viewer we can only see one page, therefore locating errors that are not recent enough is problematic.

Additionally we are logging all other errors to Influx so we have errors in one centralized place. And we are using an in house tool to blurr sensitive data so that we can log failed requests to payment gateways and other 3rd party solutions.

This path to better logging is just recent and we are always trying to improve it.