Wantedly ではアプリケーションレイヤーのエラー収集ツールとして HoneyBadger を使っています。HoneyBadger は Slack と連携して、エラー通知が来たときに Slack にメッセージを流すことができます。

課題

しかし、デフォルトだと以下のようにエラーのクラス名とエラーメッセージしか表示されません。これだけではアプリケーションのどこで起きたエラーなのかがわかりづらいですね。

そのため、多くの場合リンクを踏んで詳細を見にいかないと、そのエラーがすぐ対応した方がいいエラーなのかや、自分が最近変更した箇所で起きたエラーなのか、といったことが判断できませんでした。この一手間の面倒くささもあり、Slack にエラー通知が流れて来てもトリアージされずにそのまま流れてしまっていることがよくありました。特にたくさんの人が触り、デプロイ回数も多いようなモノリシック Rails のサービスでそうした状況が顕著でした。

解決策

HoneyBadger のリファレンスを見る限り、Slack に流すメッセージの内容を調節する方法はなさそうだったので、少しハッキーな方法で解決することにしました。

以下のように HoneyBadger にエラー通知を送る際に実行することができる before_notify フックで、エラーメッセージにエラーが起きた場所の情報を追記します。バックトレースを正規表現でフィルタリングしているところは、gem や Ruby そのもののコードの中で起きた例外のときに、その呼び出し元のアプリケーションコードの位置を取るためです。

Honeybadger.configure do |config|
  config.before_notify do |notice|
    line = notice.backtrace.find { |s| s.match?(/^#{Regexp.escape(config.root)}\//) && !s.match?(/^#{Regexp.escape(config.root)}\/vendor\//) }
    notice.error_message = "#{notice.error_message}\n\nin #{notice.controller}\##{notice.action}\n#{line}"
  end
end

こうすると、Slack 上では以下のように表示されます。コントローラーやアクション、起きたコードの行位置が追加され、どこで起きたエラーかがぐっとわかりやすくなりました。

本来こうした情報を入れる場所ではないので、エラーの詳細画面上ではちょっとうるさくはなりましたが、メリットを考えれば我慢できる範囲です。

結果

Slack 上で見れる情報量が増えたことで、前よりもスムーズにトリアージされるようになりました。

今回の解決策はエレガントな方法ではありませんが、実用的には便利で、課題は解決できました。

ところで

Wantedly には Ruby のサービスだけでも10個以上あり、すべてに同じ設定を入れて回るのは面倒です。が、すべてのサービスに共通で入れている servicex という社内ライブラリがあり、こうした設定をそこに入れれば簡単に各サービスに配布することができます。今回はまず一つのサービスで小さく試して、エラーがトリアージしやすくなることがわかったので、servicex に入れて他のサービスにも配布しました。

以上です。servicex についてもっと詳しく知りたい方は、ぜひ話を聞きに来てください！