Checkout Hoptoad by thoughtbot, inc.
I’ve been using Hoptoad for about two months now, and I’m sold. Hoptoad is a product by thoughbot, inc. Previously, I’ve always used the excellent exception_notification plugin. The exception_notification plugin is easy to use, and it works great. However, there are a couple of problems with it.
- You could flood your inbox if there is a bad problem on a popular page.
- It’s difficult to collect all the emails and track errors.
Enter Hoptoad. Hoptoad solves both problems, and it is super simple to use and setup. It’s free for one project and two users. If that isn’t enough for you, the premium services are very reasonable.
How does it solve both problems? First, Hoptoad will still send you an email when there is an error. However, it won’t flood your inbox if there are hundreds of the same email. Second, Hoptoad provides a simple web-based system that groups your errors by exception class. That makes it easier to track down problems. Finally, you can mark errors resolved so you don’t have to wade through noise to solve the real problems.
Hoptoad installation:
REMOVE EXCEPTION_NOTIFIER
- In your ApplicationController, REMOVE this line:include ExceptionNotifiable
- In your config/environment* files, remove all references to ExceptionNotifier.
- Remove the vendor/plugins/exception_notifier directory.
INSTALL HOPTOAD_NOTIFIER
From your project’s RAILS_ROOT, run:
script/plugin install git://github.com/thoughtbot/hoptoad_notifier.git
CONFIGURATION
You should have something like this in config/initializers/hoptoad.rb.
HoptoadNotifier.configure do |config| config.api_key = '1234567890abcdef' # You get your key when you sign up end
(Please note that this configuration should be in a global configuration, and is not enrivonment-specific. Hoptoad is smart enough to know what errors are caused by what environments, so your staging errors don’t get mixed in with your production errors.)
Once you do the above, any Exception not caught by your controllers will be sent to Hoptoad where where they can be aggregated, filtered, sorted, analyzed, massaged, and searched.
Now, if you have read anything I’ve done before, you know I do a lot of asynchronous processing with Workling. By default, Hoptoad will not log errors from anything outside of your controllers. Fear not. Hoptoad provides a webservice API to send errors. Here is an example.
In workling/lib/workling/base.rb:
# takes care of suppressing remote errors but raising Workling::WorklingNotFoundError
# where appropriate. swallow workling exceptions so that everything behaves like remote code.
# otherwise StarlingRunner and SpawnRunner would behave too differently to NotRemoteRunner.
def dispatch_to_worker_method(method, options)
begin
self.send(method, options)
rescue Exception => e
raise e if e.kind_of? Workling::WorklingError
logger.error "Workling Error: runner could not invoke #{ self.class }:#{ method } with #{ options.inspect }. error was: #{ e.inspect }\n #{ e.backtrace.join("\n") }"
# DND: Let HopToad know of the issue
params = options || {}
HoptoadNotifier.notify(
:error_class => "Workling Error - #{e.class.name}",
:error_message => "Workling Error(#{e.class.name}): #{e.message}",
:request => { :params => params.merge(:worker_class => self.class.name, :worker_method => method) })
# DND: end of change
end
end
Now, any error not caught by your workers will be sent to Hoptoad for processing. You can use a similar method from Rake tasks or any scripts that run outside of controllers. Remember, Hoptoad will collect errors by :error_class, so you can use different classes to separate errors into bins based on where they came from.
Give Hoptoad a try. You will not be disappointed.
