Getting started with Exceptional
For Exceptional to work you need to install a plugin to your Rails app. Installing the Exceptional plugin is similar to other plugin installs, you use script/plugin to add it in. Exceptional needs an API key placed in a file called exceptional.yml. You’ll get this key from Exceptional when you’re adding the application. After that you’re all set. Naturally we give you the commands you need, so it’s just copy & paste
Once it’s installed the plugin contacts our server to let us know that we’re ready to go. If you only have one application running Exceptional your first screen will show you that app by default, and you should see some Exceptions start to creep in. By default Exceptional auto-ignores Exceptions that cause 404s. You can still view them, but they won't trouble you with notifications. You can disable this if you want to know about every single exception.
As you add more apps, your dash board will appear and give you an overview of how everything is getting along. Beta accounts can add as many applications as they want. Here is how things look for a busy developer with many applications…
Next up, we’ll look at how we display a particular Exception.
2 Responses to “Getting started with Exceptional”
Sorry, comments are closed for this article.
August 7th, 2008 at 02:25 PM
Here's some feedback with my experience trying to integrate with a local app for testing (YMMV).
Because there wasn't much documentation, I had to make a few guesses as I went along. I set up a new Rails app with a single controller and a single action that raises. My first observation was that you do need to be running in production mode for this to work, as the plugin hooks into rescueactionin_public.
If you want to test locally, run in production and also be sure to override the localrequest? method in your application controller to return false otherwise the rescueaction_in_public method will still be bypassed.
I use mod_rails for my local development setup and I had problems getting the plugin to work. Tailing the exceptional log, it seemed to start up its worker but exceptions didn't seem to be being sent. Once I got the app up and running with mongrel, it seemed to come to life.
Looking at the plugin code, it seems that the plugin defines rescueactioninpublic so it can catch exceptions and send them to the service and then it does some generic error handling. This means any custom error handling you might have in your own rescueactionin_public method will not work (I think). Perhaps it would be better to use aliasmethod_chain and delegate after sending the exception?
The other problem I had is that currently, there is no solid Ruby API - the code is very heavily coupled to the way the plugin works with its background worker mechanism. We currently capture all of our exceptions on a beanstalkd messaging queue (using our beanstalkd plugins on labs.reevoo.com) which means we can defer the decision of how we handle our exceptions and do so in the background, meaning our requests are not slowed down at all. What we really need is a simple Ruby interface to the getexceptional API that we can use in our queue pollers to send the exceptions off in a separate process.
I did look at doing this but was reluctant to do so until the API becomes more permanent. At the moment, the web API itself also seems coupled to the way the plugin works, with workers needing to register themselves (using the connect method) before sending off exceptions. What would be really nice is a simple RESTful API for submitting exceptions without having to do the connect/disconnect dance around it.
The plugin also seemed to want to know things like the RAILS_ROOT and various other application environment information but I'm not sure how much of this is necessary (or why it was necessary).
I hope this feedback is useful.
August 7th, 2008 at 11:43 PM
Hi Luke,
Thanks a lot for trying out Exceptional and sending your feedback. We're all ears and it's early days yet so a lot of what you mentioned is already on our plate.
The way we have chosen to architect the plugin with it registering with our application on startup was a decision to add even more benefit to the service... more to come on that later. We targeted mongrel & webrick initially for this release but will be adding support for Thin, mod_rails etc. in the next.
I took a look at how your handling exceptions in your plugin, opening up the API so that it can be used in any script/daemon/service and not just in a Rails environment is something we want to support as well.
The extra data we capture about the application environment will become useful as we bring it to light in the application.
We'll let you know when our service is ready to integrate with how you handle exceptions. Thanks again.