A nice coincidence a few weeks was the news of Raygun going in to public beta crossing my radar.
At the time we were fine tuning some things in an application that was in a private beta, we had put a little effort in to ensure that we would get reliable results about errors that happened to the users, but at that point we were just storing the details in a database table.
Background
We were capturing 3 levels of errors in the application.
– Client-side (JavaScript)
– Web Tier (ASP.NET MVC / WebApi)
– Back-end (Topshelf hosted services)
Any client side error would be captured, and sent to the Web Tier, Web Tier forwards that and it’s own errors on to the back end where they would be persisted with low overhead. In a previous post I have covered this approach.
But to get from entries stored in a database to something actually useful to correctly monitory and to start a resolution process is quite a bit of work.
From our own application structure; we can easily query that table, and just as easily send emails to the dev team when they occur. But this is still short of a robust solution, so a quick glance at the Raygun features and there was very good reason to give it a go.
What it took for us to set up Raygun
A quick look at the provided setup instructions and their github sample, it looked very easy.
With our particular application structure the global Application_Error method and the sample usage of Server.GetLastError() didn’t fit well. The clearest example is the arrival of data from client side, which isn’t a .NET exception, so simply issuing the RaygunClient().Send(exception); call doesn’t work. In this scenario we basically recreate an exception that represents the issue in the web tier, then have that sent to Raygun.
For errors that originate in our controllers (regular and WebApi) which extend a common base class, we make use of the HandleError attribute so we can execute a method to do some extra work, the code looks like:
[HandleError]
public abstract class BaseController
{
protected override void OnException(ExceptionContext filterContext)
{
//our other logic, some to deal with 500s, some to show 404s
//make the call here to raygun if it was anything but a 404 that brought us here.
new RaygunClient().SendInBackground(filterContext.Exception);
}
}
In the scenarios where we actually do have the exception, then it’s great and it “just works”, and we send it off asynchronously, in the catch block by calling a wrapping function like this:
public static void LogWithRaygun(Exception ex)
{
new RaygunClient().SendInBackground(ex);
}
Conclusion
So Raygun really helped us avoid using a weakly hand-rolled half-way solution for tracking errors, now with nice email notifications that look like this, and link into the Raygun detailed information view.
It’s lacking a few nice to have features, but that’s more than acceptable for version 1 of the application, and from what we’ve been told our suggestions are already on track for a future release. One particular one that would benefit lots of people would be to allow an association of errors to be mapped by the user. An example is, 2 seemingly different errors get logged but in actual fact are the same cause, this way the reporting and similarity tracking can continue to group the 2 variations under the one umbrella.
Image may be NSFW.
Clik here to view.
Along with the dashboard summary.
Image may be NSFW.
Clik here to view.
It’s one less thing we need to worry about. Just an FYI we didn’t stop saving records into our own database table, we’re just unlikely to have to go looking in there very much, if ever.
Image may be NSFW.
Clik here to view.
Image may be NSFW.Clik here to view.
