No software is complete without bugs and no Rails application is complete without proper exception tracking. In most cases we choose Airbrake to collect those exceptions for us.
Here’s a couple of tips to make Airbrake more useful.
Server-specific environment names
Here at the Playhem team we have multiple independent staging servers for testing multiple features simultaneously. If all the staging servers use the same Rails environment, Airbrake’s exception logging becomes messed up, because it categorises errors by Rails environments; it isn’t always clear as to which server and feature is the exception related to.
We could use a separate Rails environment for each staging server, but since they are otherwise identical, there is a simpler solution. Airbrake has custom
environment_name setting, which can be set manually to whatever you want. I chose to customize the environment name using server-specific configs and our wonderful multi-deploy tool, but you could also use the server name, or any environment variable.
Airbrake.configure do |config| config.api_key = 'myapikey' config.environment_name = `hostname` # or whatever else end
The best practice is to use a unique Airbrake
environment_name for each server to avoid any confusion as to where did the exception happen.
Another important benefit of using server-specific environment names is that the “mark exceptions as resolved upon deploy” setting doesn’t make sense when the environment_name is not tied to the actual server.
Most, but not us! I added a separate
Airbrake.configure do |config| config.api_key = 'myapikey' config.js_api_key = 'myjsapikey' end
After that you can make use of the Airbrake error aggregation to see what exceptions are most common — and then you can start fixing them.
Have fun squashing those bugs out there!