開発の所(@ctokoro_me)です。 インド音楽の演奏が趣味の一つなのですが、興味のある人が全然いない（そもそもインド音楽自体がほぼ知られてない）のが隠れた悩みです。
さて、みなさんが運用中のアプリケーションでは、エラーモニタリングはどのように行っているでしょうか？ ログを tail / grep している感じですか？？ それとも、エラーが起きたらメールが飛んで来るようになっているのでしょうか？ どちらにしても、ユーザーが増えてくると管理が大変になってきてしまいますよね 😵
「一行のログの向こうには、一人のユーザがいる」 *2 という格言(!)もある通り、エラーが起きたということはそのユーザーがサービスを正常に使えていないということです。 しっかりと対応していきたいですね。
エラーモニタリングサービス
クラウドワークスではエラーモニタリングサービスとして Rollbar を採用しています。
このようなエラーモニタリングサービスは数年前まで Airbrake しかなかったように記憶していますが、今ではたくさんのサービスが存在しています。クラウドワークスで導入する際にも主要と思われるサービスについて比較検討を行いました。
- Sentry - Track exceptions with modern error logging for JavaScript, Python, Ruby, Java, and Node.js
- Bugsnag - Detect and diagnose crashes in your applications
- Raygun - Actionable Application Insights For Developer Teams | Raygun
- Airbrake - The best bug tracker and error tracking software.
- errbit
これらと比較した上で、機能・対応言語・導入しやすさ・使いやすさ・価格・ライブラリの更新頻度等の観点から最も要件に適していた Rollbar を選択しました。
基本的なモニタリング機能はどのサービスも良く出来ており、後述する GitHub Issue を利用したエラー対応フロー相当の機能を有しているサービスもあります。
エラー発生通知
エラーが発生した際の即時通知として Rollbar から Slack へメンション付きで通知を行い、エラーが発生したことをまず知らせています。
アプリケーションエラーだけではなくクライアントブラウザでのJSエラー検知も導入しています。
JSエラーはたくさんのブラウザが存在することもあってテストで網羅が難しい部分ですが、ユーザーエージェントと組み合わせて検知することで特定ブラウザでのエラーを簡単に特定できるので重宝しています。
また、Rollbar では SourceMap もサポート しているので minified されて配信されているのJSのデバッグもできます。 Rails においては現行の Sprockets v3 では残念ながら SourceMap を出力できませんが version 4 で対応 していますし、弊社の鈴木(@suzan2go)の記事のように webpack を使用するようにすれば webpack から SourceMap を出力できます。
GitHub Issue を利用したエラー対応フロー
Rollbar には新規エラーが発生した場合に、エラーに対応する GitHub Issue を自動的に発行してくれる機能があります。
該当エラーに対するコード修正を行う場合は Issue に関連付けて Pull Request を発行します。
ここで Rollbar のデプロイトラッキングとコミットメッセージにエラーIDを含めておけば、修正したコードのデプロイが完了した時点で自動的に該当エラーが close されるように連携することができます。
エラーが再発した場合は再び issue が open されるので、エラーが直ってなかった場合を見逃すこともありません。
再発した場合も同じように Pull Request を作って対応していきます。この対応フローを使えばエラー対応の経緯をデプロイも含めて全て GitHub 上で一元的に管理することができます。
コード修正内容も含めて GitHub Issue に全てまとまっているのは、開発者にとってとても見通しが良くて管理しやすいのではないでしょうか 🌞
エラー対応フローまとめ
Slack にエラー通知が来る （自動的に GitHub Issue が発行される）
Rollbar でエラーの詳細を確認する
Rollbar から発行された GitHub Issue に対して Pull Request を作成
Pull Request をマージ、デプロイ （自動的に GitHub Issue が close される）
※エラーが再発した場合
Slack にエラーの再通知が来る （自動的に GitHub Issue が reopen される）
上記の対応フロー 2, 3, 4 と同じように対応
まとめ
今回はクラウドワークスで行っているエラー対応の一部をご紹介しましたが Rollbar をはじめとするエラーモニタリングサービスはかなり高機能で、他にもバッチ上でのエラー検知も行っていたり、運用上では SpreadSheet と Slack API を組み合わせてエラー監視を当番制にしていたりします。 *3
もしまだエラーモニタリングサービスを使っていないのなら、ぜひ導入の検討をおすすめします。大体のサービスがトライアル期間を設けていますし、価格もさほど高くありません（規模にもよりますが数十ドル程度から使えます）また、OSSとして提供されているものもあるのでセルフホスティングもできます。
現在の流行りは StackShare が参考になると思うのでリンクを貼っておきます。
今回ご紹介したフローについても Rollbar でなくても同等の機能を有しているサービスがあるので、うまく組み合わせれば実現できるでしょう 💪
We're Hiring !
クラウドソーシングのクラウドワークスではエラーを見逃さない 👀 エンジニアを募集しています！
