Using ErrLog.IO Diffs to track down the cause of errors

You may have noticed when reviewing your logs on the dashboard that we collate similar logs. Each instance in the collated group is viewable once you click through to look at the log details. We tag each instance to let you know if it is different to the currently viewed instance. We also apply tags to the current and first instance in the group. These tags are useful for getting an overview of the group without the need to inspect each instance.

When the different tag is applied to an instance, you can click through using the view button to review the differences using the diff viewer.

When viewing an instance, each component of the logg data is compared. Deltas are displayed below the regular details view. This is helpful for determining elements that are different between logged instances. These diffs become even more useful when you begin to utilize ErrLog.IO for sequential logging.

That's right! It's possible to manually log using ErrLog.logger.log at any point in your code. Something else you may not know, however, is that you can easily specify more optional parameters including the log type, a custom "page name", "application name", and even a custom JSON dataset. Let's consider a scenario where these parameters could be extremely useful.

Imagine you've started seeing ErrLog logs from your production deployment, but you can't replicate the issue in your local environment and there doesn't seem to be enough information to apply a reliable fix. Perhaps this is a familiar situation for some developers out there?

For the sake of expedience, let's say we know the issue is occuring during some unspecified event on a user profile page. We can add some custom logging to each event handler in the profile page. It would look something like this:

public void UserAccept_click(object sender, EventArgs e) {
	ErrLog.logger.log(new Exception("Logging user profile progress: Accept_agreement step 3"), "profilepage", 
		NewtonSoft.JsonConvert.SerializeObject(HelpfulUserDataLog), "", "TrackingIllusiveIssue");
	// ... Do things. Perhaps complicated things.
}

Above, we've specified the optional parameters with some helpful data. We're specifying the log type as TrackingIllusiveIssue, which we can use to filter the dashboard to help track these logs. We've also included an imaginary HelpfulUserDataLog object - let's assume this has the kind of debug data we need to figure out what's happening. I've left the application_name parameter as an empty string - which will let the ErrLog system use the default. Of course, we could use named arguments notation as well:

public void UserAccept_click(object sender, EventArgs e) {
	ErrLog.logger.log(your_exception: new Exception("Logging user profile progress: Accept_agreement step 3"), 
	page_name: "profilepage", custom_json: NewtonSoft.JsonConvert.SerializeObject(HelpfulUserDataLog), 
	exception_type: "TrackingIllusiveIssue");
	// ... Do things. Perhaps complicated things.
}

In our assumed scenario we're tracking multiple steps, perhaps also logging the result of some specific function calls, where each log contains a custom JSON string detailing useful information for identifying the root cause.

Now, all we need to do is correlate the ErrLog Errors with the associated TrackingIllusiveIssue logs. Identifying logs that have resulted in errors and comparing with those that did not. With the additional data from HelpfulUserDataLog, our diffs become a powerful tool. We can compare the HelpfulUserDataLog JSON objects and see exactly what is different in cases that fail vs. cases that pass.

Obviously the devil is in the details, and that's exactly what ErrLog.IO logging aims to expose in an easy to use API and powerful logging and reviewing tools.