Everyone who has opened up the event log in DNN has undoubtedly been struck by the fact that there is a lot of information there. The event log is like a huge bin into which the platform and modules can drop anything they wish to log. To help you navigate the flood of information we use color coding and filters. This will allow you to answer questions like “User X had an error when they went to page Y. What happened?” You’d probably want to know when user X had this experience as the log is basically just a chronological list of events. But the event log is not able to answer the question “Who else had this error?” and “Is this error recurring often?” The event log was simply not designed to answer those questions. To address this, I’ve made a few changes to the framework which I’ll elaborate on.

An important shortcoming in the old event log design

The way the old event log worked was that it logged things like portal id, user id, tab id, time and type of event (error, information, etc) into separate fields in the EventLog table in SQL. But the most important parts of an error were stuffed into an XML blurb that was stored in a field (called LogProperties) of type “Text”. This makes it extremely complicated to drill down to the questions mentioned above in SQL. What you see on screen is that XML pumped through some XSL to make it look nice. But there is no way to select and sort by the various details of an error. Only on the main fields like user id, etc.

Solution approach

The way I’ve approached this is to first change the data layer without changing anything further up in the application. In other words: you won’t notice any changes (yet) in the UI. But we should begin logging the specifics of errors (i.e. exceptions) in a way that allows us to filter by them and get meta information. Like how often a specific error occurs, etc.

In the future I’d love to revise the event log module to allow users to quickly drill down into issues plaguing their DNN installation. But given that we are in a transition period where admin module will be broken out of the main platform into their own projects, it is not the right moment to start working on this.

Changes

If we’re logging an exception what we’ll do is to create a (MD5) hash of the complete StackTrace field of that exception. The exception is stored into its own table called Exceptions and the hash serves as the key. The ExceptionHash field is added to the Eventlog so for error events we can link to the exception. Obviously, if we have the exception already in the table, we don’t create a new record. We also no longer log the exception in the LogProperties blurb. This should save on the total size of the EventLog table.

Secondly we create a table ExceptionEvent which attaches to the EventLog table to just add a few typical fields if an exception is being logged like portal id, tab id, and user id. The changed result in the following structure:

Final words

As said before there is still work to be done to improve the event log (notably in the UI). This is but a first step and from now on people will be logging the exceptions in their own table. For those of you who work in support: you can already leverage these changes by going to SQL directly to analyze errors.