Honeybadger Gem v3の新機能徹底解説

要約だけ知りたい方は、CHANGELOGをご覧ください。

このたび、Rubyで発生した例外をレポートするためのgemの最新メジャーアップデートをリリースしました。前回のv2は設定戦略を一新する完全な書き直しでしたが、今回のv3では破壊的変更を最小限に抑えつつ、機能面と使いやすさの両方で大幅な改善を行っています。内容が盛りだくさんなので、早速見ていきましょう。

プレーンなRubyモード

Railsの世界では、gemをインストールすれば自動的にアプリケーションと統合されるのが一般的です。多くのgemは独自のRailtieを提供し、Railsの初期化時に自らのコードを実行します。

Honeybadger gemもこのアプローチを全面的に採用しており、Rails、Sinatra、Sidekiqなどの人気フレームワークやgemに対して、包括的なエラーレポートを簡単にセットアップできます。実際、require 'honeybadger'と書くだけで済みます。

しかし中には、自分で統合コードを書きたいと考えるRubyistもいます。Railsで頻繁に行われるモンキーパッチに抵抗があり、requireしただけでアプリケーションが目に見えない形で変更されてしまうことを嫌う人たちです。その気持ちはよく分かります（筆者自身もどちらかというとそのタイプです）。

また、私たちが統合しているライブラリを使っておらず、Honeybadger.notifyだけで自分でエラーを報告したいユーザーもいます。実行時に不要な初期化処理を避けたいというわけです。

そこで追加したのが「プレーンなRubyモード」（非公式名称）です。設定やミドルウェアのインストールをゼロから行いたい方（あるいは素のRubyを使っている方）は、通常のrequire 'honeybadger'の代わりにrequire 'honeybadger/ruby'を使用できます。これにより、自動統合を一切有効化せずに、Honeybadger.notifyやHoneybadger.contextなどを利用可能になります。ミニマルで予測可能なRuby向けエラー追跡が実現します。

require 'honeybadger/ruby'

begin
  # エラーが発生するコード
rescue => exception
  Honeybadger.notify(exception)
end

複数エージェントのサポート

プレーンなRubyモードに関連して、Rubyのコードから追加のエージェントを作成できるようになりました。エージェントとは、Honeybadgerプロジェクトへエラーを報告する仕組みのことです。これにより、同じアプリケーション内で複数のHoneybadgerプロジェクトへエラーを報告できるようになりました。以下のように使います。

OtherBadger = Honeybadger::Agent.new

OtherBadger.configure do |config|
  config.api_key = 'project api key'
end

begin
  # エラーが発生するコード
rescue => exception
  OtherBadger.notify(exception)
end

Honeybadger.configureの復活

まず安心してほしいのですが、現在honeybadger.ymlでgemを設定している方には何も変わりません。引き続きこれがデフォルトの方法です。

とはいえ、Rubyコードからプログラム的にgemを設定したいというご要望をいただいていました。v3.0では両方のメリットを享受できます。honeybadger.ymlと環境変数によるフル設定をサポートしつつ、Honeybadger.configureが復活しました。

Honeybadger.configure do |config|
  config.api_key = 'project api key'
  config.exceptions.ignore += [CustomError]
end

設定の優先順位は YAML → ENV → Ruby となっています。つまり、環境変数はhoneybadger.ymlを上書きし、Honeybadger.configureは環境変数を上書きします。

cronジョブやコマンドラインプログラムでのエラー報告

cronの長年の課題の一つは、自動メール機能がエラー出力を理解できないことです。タスクが失敗したときにはメールが届きますが、成功したタスクが標準出力を出した場合にもメールが届いてしまいます。

Honeybadgerを使っているのは、むしろ対応不要なメールアラートを減らすためではないでしょうか？ cronの失敗をメールの代わりに、あるいはメールに加えてHoneybadgerで報告できたら便利だと思いませんか？ 今回それが可能になりました。

CLI（コマンドラインインターフェース）にhoneybadger execコマンドを追加しました。これはcronの失敗だけでなく、普段コマンドラインから実行しているあらゆるコマンドのエラーを報告できます。bashスクリプト、実行ファイル、makeタスクなどが対象です。使い方は、任意のコマンドの前にhoneybadger execを付けるだけです。

$ honeybadger exec my-command --my-flag

コマンドが正常に実行されれば、終了コード0で何も出力せずに終了します（標準出力もデフォルトでは無効ですが、特別なフラグで有効化できます）。一方、コマンドが失敗した場合は、実行されたコマンドと完全な出力を含むHoneybadger通知を受け取れます。

honeybadger execは成功時の出力をデフォルトで抑制するため、cronのメール機能との相性が特に良いです。honeybadger execとcronメールを併用すれば、コマンドが失敗したときにHoneybadger通知が届きます。さらに、接続問題などでHoneybadger通知自体が失敗した場合でも、元のコマンドの出力が出力され、cronが引き続き失敗についてメールで通知してくれるので安心です。

コマンドラインからのカスタムエラー報告

こちらはシンプルな機能です。bashスクリプト（または任意のシェル）からカスタムのHoneybadger通知を送りたい場合は、honeybadger notifyを使います。

$ honeybadger notify --message "This is an error from the command line"

--class、--component、--actionなどのオプションフラグを使えば、通知に追加のプロパティを付けられます。

その他の改善点

v3ではさらに多くの機能追加と改善を行いました。

• Honeybadger.notifyが例外オブジェクトに加えて文字列引数も受け取れるようになりました。Honeybadger.notify("these are not the badgers you're looking for")のような書き方が可能です。
• gitリポジトリ内で実行した場合、gitのリビジョンが自動的に例外とともに報告されます。新しい:revision設定オプションで、リビジョンを手動で追加・変更することもできます。
• CLIのユーザーインターフェースが大幅に改善され、詳細なエラーメッセージが表示されるようになりました。また、Rails外のスタンドアロン実行ファイルとしても利用できます。
• テストスイートが約10倍高速化され、新機能や統合の開発をさらに迅速に行えるようになりました。
• リクエストデータのフィルターがデフォルトでワイルドカード一致方式になりました。「password」をフィルター指定すると、「password」と「password_confirmation」の両方のリクエストパラメータがフィルターされます（Railsのフィルターと同じ挙動です）。

変更点と削除された機能

意味をなさなくなった一部の機能については、変更または削除を行いました。

• Ruby 1.9.3および2.0.xのサポートを終了しました。今後は2.1.0が公式にサポートされる最低バージョンとなります。
• v2のすべての非推奨機能を削除しました。
• 非推奨となっていたメトリクスとトレーシングのコードを削除しました。
• Honeybadger.startは不要になり、使用すると例外が発生します。以前Rails外でHoneybadgerを使っていた場合は、別途Honeybadger::Configインスタンスを作成したりHoneybadger.startを呼び出したりすることなく、Honeybadger.configureだけでエージェントを設定できます。
• plugins.skipオプションをskipped_plugginsに改名し、sidekiq.use_componentはデフォルトでtrueになりました。
• CGI変数がホワイトリスト制になったことで、機密データを誤って漏洩しにくくなりました。
• 開発環境では、Honeybadger.notifyが無効な引数で呼ばれた場合に例外を発生させるようになりました。本番環境ではエラーをログに記録します。
• honeybadger.ymlの評価時に発生するエラーは、ログに記録する代わりに例外として発生するようになり、設定問題を早期に発見できるようになりました。ERBタグ内のエラーに関するバックトレースも改善され、デバッグが容易になっています。