初めに
こんにちは。今年4月からカナリーに新卒で入社した小野です。（記事テーマの実装中はインターン中でしたが、無事卒業・入社することができました🎉）
私たちは現在「Canary」というお部屋探しのアプリを作っています。
今回はそのCanaryのネイティブアプリのエラー監視に関するお話です！
以前から、私たちはSentryを用いてエラー監視をしていたのですが、さまざまな問題を抱えていました。
問題点
大きな問題点が3つありました。
- アラート通知が整備されていないので、わざわざSentry上に見に行く必要がある
- エラー自体は把握できるが、発見後の解消フローが未確立
- 無駄に通知されているエラーが多く、オオカミ少年アラートになっている
今まではサービスを軌道に乗せるために機能開発に全力を注いできましたが、Canaryのインストール数が250万を突破し、テレビCM放映も決まったことで今後もユーザー数の増加が予想されるなか、「バグを早期に検知し、対応できる」体制を作るためにもこれらの課題を克服する必要がありました。
以上のような理由で「Sentry運用策定プロジェクト」が誕生しました。
目指したこと
このプロジェクトで成し遂げたい点は以下の通りです。
- メンバー全員がエラーの発生に気づけるようにする
- バグを解決するまでの時間を最小限にし、機会損失を最小限にする
- リリース前にバグに気づけるようにする
取り組んだこと
上記のことを達成するためにプロジェクトで取り組んだことは以下です。
SentryのAlerts機能を整備する
オオカミ少年アラートを解決するために、把握するべき「やばいエラー」の定義を決め、特定のエラーのみ通知されるようにしました。
エラーが発生した場合のフローを策定する
エラーが発生した場合の解決フローも策定します。
それでは、実装に入っていきます！
前提
ちなみに設定方法については以下から確認できます。
環境
- react-native: 0.69.6
- @sentry/react-native: 4.2.2
実装
SentryのAlerts機能を整備する
公式Document この機能は、Sentryに送られたエラーの中で条件に当てはまるもののみをメールやSlackなどに通知できます。
今回は、社内で使われているSlackに通知するように設定したいと思います！
SlackとSentryの接続
公式Document
- Sentryの左側メニューから、Settings > Integrations > Slackと進みます
- "Add WorkSpace"をクリック
- 右上のメニューから接続するSlackワークスペースを選択し、Allowボタンをクリック
以上でSlackとSentryの接続が完了しました。
アラートを作成
SlackとSentryの接続が完了したので、次にSlack上にエラーが流れるようにしていきたいと思います。
まず、Slackに流したいエラーの定義を決めます。
今回は以下のようにしました。
- JS側のエラー
Sentryは追加の設定や明示的な処理なしにランタイムで発生した未処理のエラーを自動的に捕捉して報告してくれますが、ネイティブ側のエラーも含まれるとノイジーなので、アプリケーション側でエラーハンドリングのコードを充実させた上でSentry側のフィルターでerror.unhandled: falseとし、ハンドリングできているJS側のエラーのみを通知するようにしました
- エラーレベルが
fatal
ユーザーに影響を与える、緊急性の高いエラーに絞ることができます。
ちなみにこのエラーレベルはカスタマイズ可能です🙆
- 最新バージョンからのエラー
修正済みのエラーが通知される可能性があるので、最新バージョンのみにします。 - 1時間あたり100件以上発生したエラー
たとえ重要度の低いエラーでも、異常な回数発生していたら対応する必要があるので、通知されるようにします。
以上の定義に当てはまるエラーがSlack上に流れるように以下の2つのアラートを作成します。
- fatalエラーを通知
- エラーレベルがfatal
- 最新バージョンからのエラー
- handled errorなもの
- 1時間あたりに100回以上発生したエラーを通知
- エラーレベルや、handled、unhandled関係なく、1時間に100回以上発生したもの
- 最新バージョンからのエラー
このアラートをprod用とdev用の二種類用意します。
では、作成していきます！
-
menuからAlertsを選択します
-
今回はエラーが発生した場合に通知するようにしたいので、issuesのSet Conditionsを選択します
-
この画面で、詳細設定をします
Select an environment and project
対象のプロジェクトと環境を選択できます。
Set Conditions
通知するエラーの条件を指定できます。
エラーが送られるタイミングや、通知するエラーの条件を細かく設定できます。
今回は以下のように設定しました。
-
fatalエラーを通知
-
1時間あたりに100回発生したエラーを通知
また、THEN perform these actionsでSlackのチャネルを指定することによって、特定のSlackチャネルに通知するようにできます。
Set action interval
何分おきに通知がされるかを選択できます。
Preview
これまでに設定した条件に一致するエラーを一覧で表示してくれます。
Add a name and owner
作成するアラートの名前とオーナーを設定します。
以上でAlertの作成が終わりです。
そうすると、、
画像のように無事にSlackにエラーを流すことができました👏
Alerts機能では他にもさまざまな条件を設定できます。
もし対応の必要のないエラーが通知されてしまっても、個別で対応するようにしています！
たとえば、
Network request failedエラーを通知しないようにしたい場合は、
このように設定します。
設定できる条件は以下で確認できます🙆
エラーが発生した場合のフローを策定する
以上で対応すべきエラーをSlackに通知できるようになったので、次にそのエラーを解決するためのフローを策定します。
フロー策定において意識した点
フロー策定にあたり以下の3つを意識しました。
- エラー通知を見逃すことがないようにする
- 今後同じようなエラーが発生しても瞬時に対応できるようにする
- たとえチームメンバーが入れ替わっても運用できるよう、属人的にならないようにする
フローについて
そして策定されたフローがこちらになります。
- Slackにエラーが流れる
- エラーに気付いたメンバーはスタンプでリアクションをし、内容を確認する
- Alerts機能の設定ミスの場合は設定を修正
- 修正に着手
- ユーザーに直ちに影響を与えるものでなければ、いったん調査ログのみを残す
- 週一の定例MTGで調査ログだけ残されているエラーについて議論する
- そもそも対応が必要なのか
- 原因と工数について確認
- PMに対応を相談
- 週一の定例MTGで調査ログだけ残されているエラーについて議論する
- 修正後はdev用チャネルでエラーが発生しないか確認
- 確認が完了次第、本番環境に反映
- ユーザーに直ちに影響を与えるものでなければ、いったん調査ログのみを残す
- ユーザーに影響があったエラーについては、修正後にNotionで発生記録を残す
- 調査済みのエラーか判断できるようにSentryのActivityにも調査ログを残す
以上のようなフローを策定しました。
まとめ
今回SentryのAlerts機能を用いてエラーをSlackに通知されるようにしたのですが、思っていたよりも簡単に実装できました。
また、今まで把握しにくかったエラーも瞬時に気づくことができるようになりました👏👏
Discussion