{"id":2342,"date":"2012-06-21T01:11:27","date_gmt":"2012-06-20T22:11:27","guid":{"rendered":"http:\/\/railsware.com\/blog\/?p=2342"},"modified":"2021-08-16T13:10:03","modified_gmt":"2021-08-16T10:10:03","slug":"a-couple-of-airbrake-tips","status":"publish","type":"post","link":"https:\/\/railsware.com\/blog\/a-couple-of-airbrake-tips\/","title":{"rendered":"A couple of Airbrake tips"},"content":{"rendered":"\n

No software is complete without bugs and no Rails application is complete without proper exception tracking. In most cases we choose Airbrake<\/a> to collect those exceptions for us.<\/p>\n\n\n\n

Here’s a couple of tips to make Airbrake more useful.<\/p>\n\n\n\n

Server-specific environment names<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

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<\/code> 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.<\/p>\n\n\n\n

Airbrake.configure do |config|\n  config.api_key = 'myapikey'\n  config.environment_name = `hostname` # or whatever else\nend\n<\/pre>\n\n\n\n
The best practice is to use a unique Airbrake environment_name<\/code> for each server to avoid any confusion as to where did the exception happen.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Separating Javascript exceptions into a separate project<\/h2>\n\n\n\n
Capturing Javascript exceptions can prove to be useful over time to pinpoint browser-specific errors that the QA rounds have missed. Unfortunately, enabling Javascript error notification usually brings you an enormous<\/em> number of errors (and a lot of them unfixable, such as when a user on a faulty connection gets a Script load error). These errors flood out Rails exceptions and make Airbrake unusable, so most people turn Javascript error notification off and forget about it.<\/p>\n\n\n\n
Most, but not us! I added<\/a> a separate js_api_key<\/code> Airbrake configuration option that allows you to direct Javascript exceptions to a second Airbrake project.<\/p>\n\n\n\n
Airbrake.configure do |config|\n  config.api_key = 'myapikey'\n  config.js_api_key = 'myjsapikey'\nend\n<\/pre>\n\n\n\n
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.<\/p>\n\n\n\n
Have fun squashing those bugs out there!<\/p>\n","protected":false},"excerpt":{"rendered":"
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…<\/p>\n","protected":false},"author":21,"featured_media":2417,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[3],"tags":[],"coauthors":["Leonid Shevtsov"],"class_list":["post-2342","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-development"],"acf":[],"aioseo_notices":[],"categories_data":[{"name":"Engineering","link":"https:\/\/railsware.com\/blog?category=development"}],"post_thumbnails":"https:\/\/railsware.com\/blog\/wp-content\/themes\/railsware\/vendors\/images\/article-thumbnail-default.jpg","amp_enabled":true,"_links":{"self":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts\/2342","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/comments?post=2342"}],"version-history":[{"count":16,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts\/2342\/revisions"}],"predecessor-version":[{"id":14105,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts\/2342\/revisions\/14105"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/media\/2417"}],"wp:attachment":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/media?parent=2342"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/categories?post=2342"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/tags?post=2342"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/coauthors?post=2342"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}