Sentry で JavaScript ランタイムエラーを監視してみて
はじめに
会員数約 40 万人のサブスクリプションサービスを提供するアプリケーションの JavaScript ランタイムエラーを Sentry で監視しています。私が携わった約 1 年半の間で、やって良かったことなどを振り返りも兼ねてまとめてみようと思います。
前提として、この記事で登場するアプリケーションの 1 月あたりの Issue (類似したエラーイベントをグループ化したもの) とエラーイベントは相当多くありました。私が取り組みを開始した 2021 年の 12 月から 2023 年の 5 月までのデータを表にしています。
| 年月 | 月間エラーイベント数 | 月間 Issue 数 |
|---|---|---|
| 2023 年 5 月 | 70,321 | 2,235 |
| 2022 年 12 月 | 122,555 | 5,351 |
| 2022 年 6 月 | 50,982 | 4,718 |
| 2021 年 12 月 | 259,946 | 不明 |
また、このアプリケーションは、10 月から年末に向けてユーザー訪問数が増加する傾向があるので、12 月はエラーイベントと Issue 数が多くなっています。また、PR のタイミングで突発的に大きく訪問数が増えることもあります。この様な性質のアプリケーションなので、エラーイベント数は増減が激しく新しいエラーが発生しているのか、単に訪問数が増えたことによってエラーイベント数が増えているのかを見極めにくいので、Issue 数を減らすことを特に重視して取り組みました。
この記事では、Sentry の Issue を減らすために取り組んだことや決めたことを、書いても問題無さそうな範囲で記載しています。技術的な内容よりは、チームで取り組むためのルールだったり、観点について多く書いています。
目標と計画
このアプリケーションは Issue 数が多いので、とにかくトリアージできる状態に近づけたかった。大きな目標として、以下の 2 つが立てられた。
- 異常状態検知の早期化を実現すること
- 都度トリアージできる程度にエラーイベント数および Issue 数が低減していること
Issue が少ないアプリケーションであれば、また違う目標を設定することになるだろう。
トリアージできる状態が目標なので、月間ではなく 1 日あたりの平均 Issue 数を KPI にして、(実際の計画とは異なるが) 以下の様な雰囲気で計画した。
| 年月 | 1 日あたりの平均 Issue 数 | 1 ヶ月あたりのエラーイベント数 |
|---|---|---|
| 2022 年 12 月 | 45 | 40,000 |
| 2022 年 11 月 | 50 | 41,000 |
| 2022 年 10 月 | 60 | 42,000 |
| 2022 年 9 月 | 75 | 44,000 |
| 2022 年 8 月 | 95 | 46,000 |
| 2022 年 7 月 | 120 | 48,000 |
| 2022 年 6 月 | 150 | 50,000 |
計画の設定基準などは割愛する。
目標達成のために必要であろうこと
われわれのアプリケーションに対しては、概ね以下のようなことが必要だと思っていた。
- アラートに素早く対応する
- slack に通知されたアラートに反応して原因を調査し対応方法を決定する
- 今すぐ対応する必要がない場合、(GitHub の) Issue を起票する
- 自分で対応が難しい場合は対応が可能な人に相談や対応の依頼をする
- これができるとエラーイベント数が増えにくい
- slack に通知されたアラートに反応して原因を調査し対応方法を決定する
- アラート設定のチューニング
- 本当に対応すべき異常に敏感に対応するために適切なメンテナンスが必要
- 例: 対象外ブラウザで発生した Issue を除外する
- 本当に対応すべき異常に敏感に対応するために適切なメンテナンスが必要
- Issue をチューニングする
- Sentry の Issue はスタックトレースやエラーメッセージなどの情報に基づいて、同様のエラーであろうエラーイベントをグループ化したもの
- これは、必ずしも単一のエラーであるわけではない
- このアプリケーションはサーバーサイドでレンダリングされて、html として返却される性質上、実は同じ箇所の記述が原因で発生しているエラーも条件（ユーザーのタイプ等）によっては別の Issue にまとめられることがあるので、以下などをして正しくグルーピングする必要がある
- Merging Issues する
- Stack Trace Rules を設定する
- これは、必ずしも単一のエラーであるわけではない
- 検知する必要のない Issue を除外する
- 例: アプリケーション内ではなく、連携している外部サービスが影響して発生しているエラー
- Sentry の Issue はスタックトレースやエラーメッセージなどの情報に基づいて、同様のエラーであろうエラーイベントをグループ化したもの
- エラー解消
- 発生した（している）エラーを、エラーが発生しない正常な状態に修正する
役割
先に書いた 目標達成のために必要であろうこと を踏まえて、以下の様な役割分担をした。
| アクション | 対象メンバー | 内容 |
|---|---|---|
| アラートに素早く対応する | 全員 | 積極的に対応しようとする人を週に 2~3 人設定する。後述する アラート対応の手順と観点 に沿って対応する。 |
| アラート設定のチューニング | 必要だと感じた人 | 必要な時に必要だと感じた人が行う。 |
| Issue のチューニング | 目標に設定したい人 | それぞれが任意のタイミングで実施する。 |
| エラー解消 | 目標に設定したい人 | 後述する エラー対応手順 に従って任意のタイミングで対応する。 |
- 「アラートに素早く対応する」について
- 全てのメンバーが月に 1 週間（平日の日中）交代制で担当することを想定している
- 全員がエラーに対応できる様な状態が望ましいと思うため
- 担当はランダムで決定して開始前に通知する
- 積極的に対応をしようとするだけで、必ず対応する必要があるわけではない
- 重荷に感じてほしくない
- 割り当てられたメンバー以外も対応することが望ましい
- 全てのメンバーが月に 1 週間（平日の日中）交代制で担当することを想定している
- 「 Issue のチューニング」・「エラー解消」について
- 任意で個人目標に設定してほしい
- 設定するなら以下の様な目標になりそう
- Sentry の Issue を月に 3 つマージする
- Sentry の Issue を月に 1 つ対応する（Issue 選定の基準は以下）
- 多くのページで利用されているファイルでエラーが発生している Issue
- エラーイベント数が多い Issue
- 設定するなら以下の様な目標になりそう
- 任意で個人目標に設定してほしい
Sentry の Issue 数を削減することに以外にもやるべきことが多くあったので、これらの対応を開発イテレーションに組み込むことはできなかった。
エラー対応手順と観点
以下の理由で、エラー対応手順に沿って対応することを推奨する。
- 対処すべきエラーと対処したエラーを可視化したい
- 各自が同じエラーの原因を調査したり、解消するのは効率が悪い
- 方針があると実施の際に迷わない
手順概要
大きく以下の工程に分類した。社内に限るフローが多いので汎用的な工程のみ補足する。
- 起票
- 実装
- テスト
- レビュー
- リリース
- 試験
- 作業完了
- クローズ
1. 起票 の補足
error のラベルを設定したうえで、以下のテンプレートを用いて GitHub の Issue を起票する。起票は誰が行っても良い。
起票の観点として、ユーザの行動が制限される (何かできなくなる) 類のエラーから優先して対処できると好ましいと考える。また、「大量のエラーイベントが出ている ≠ 大量のユーザに影響がある」は意識しておく必要がある。
## Sentry issue
https://sentry.io/organizations/foo/issues/~~~
## 概要
## 再現手順
<!-- 可能であれば再現手順を記載する -->
## 対象ファイル
- https://github.com/foo/bar/blob/main/src/main.ts#L306-311
## 対応方針
## 試験
### 対象ページ
- https://foo.com/bar
### 内容
- [ ] 〇〇がされていること
8. クローズ の補足
完了から数日様子を見て、リリース後からエラーが発生していないことが確認できたら、Sentry の Issue を Resolve する。
アラート対応の手順と観点
slack に通知される Sentry のアラートに対して、どの様な観点でどの様に対応するかまとめる。
観点
- アラートの原因になっているエラーが、ユーザの行動が制限される（何かできなくなる）であろう場合は早急に対応すべきであると考える
- アラートの原因になっているエラーが、最近の変更によって発生しているであろう場合は早急に対応すべきであると考える
- 古くからある Issue も早く対処すべきだが、「今までに大きな問題になっていない = ユーザーの行動が制限される類のエラーでは無い」可能性が高いので、優先順位は低くなる
- アラートの原因を調査した人が、Issue の解決までする必要がないことを理解しておく
- 原因になったであろうエラーの関係者に依頼・相談し、協力して解決をしようとすることが大事
- 関係者が分からない場合は自分よりも詳しいと思う人に相談する
- 原因になったであろうエラーの関係者に依頼・相談し、協力して解決をしようとすることが大事
手順
クリティカルなエラーとは、ユーザの行動が制限される（何かできなくなる）であろうエラーを指す。また、クリティカルなエラーか判断できない場合は、関係者にまず相談すること。
エラー発生原因調査の例
新たにエラーが発生、増加した場合、何らかの変更があったと考えるのが自然である。このアプリケーションは 1 日に多くのリリースが行われており、リリース内容を事前に把握しておくことが困難な為、以下の様に発生時間から推測するすることが多くなりそう。
- Sentry の Issue で最初に発生したエラーイベントの時間を確認する
- その辺りでリリースされた差分を確認する
- Issue のエラー内容を元にそれっぽい記述を探す
この方法で原因調査を行なった場合、リリースした人が関係者となる。
対応手段の例
アラートのルールを変更する
推奨環境に含まれない環境でのエラーは対応する必要がない。ノイズとなるため除外することが好ましい。
なお、検知の対象であるにも関わらず除外してしまうことがないよう、メンバーに周知することを徹底する。
Issue を無視か破棄 （Delete and discard future events） する
対処する必要のないエラーも検知される。ノイズとなるため無視 (ignore) or 破棄 (Delete and discard future events) することが好ましい。
なお、検知の対象であるにも関わらず破棄しまうことがないよう、メンバーに周知することを徹底する。
その他やっていて良かったこと
エラー発生記録を残す
Sentry は Business プランでも 90 日間しかデータを保持できない (Enterprise だと無制限っぽい)。なので、面倒だが過去の記録としてキャプチャーするなり、エラーイベント数や Issue 数やトランザクション数を記録しておく必要がある。
各種設定の動機などを残す
例えば Fingerprint Rules など、なぜその設定をしたのか、いつから設定したのかをコメントしておかないと、意図した効果が得られているか、今もまだ必要なのかが判断できない (複数人で運用するなら当然のことだが)。
Issue をマージする観点を明文化しておく
チームメンバーが作成してくれた文書なのでここには書かないが、Issue をマージする観点を例をもって記載しておくと迷いが少なく助かった。
ペアやモブプロでエラー解消
エラーを解消するシーンでのペアプロは知識共有に最適だった。そもそも Sentry を利用したことがないと、Sentry の管理画面を眺めるだけで時間を使ってしまう。
運用監視メンバーへアンケート
運用監視を数ヶ月実施した後、メンバーへアンケートを行った。私たちのチームは 異常に対する感度が上がった と答えた人が 75% であった。継続、中止、改善の判断材料に効果的だった。
さいごに
公開できない情報を多分に含んでいた文書を改変したので、ぼんやりした記事になってしまいました。
ここに書けていない取り組みもたくさんありますが、以下の成果がありました。
- 運用監視により異常発生を即日検知し、関係者へ対応を依頼し、検知から数日の内に解決する仕組みができた
- 開始時 1 日平均 157 あった Sentry の Issue 数を、1 日平均 72 まで削減することができた
まだまだトリアージするには難しい Issue 数なので、継続して改善が必要です (イテレーションに Issue 削減のタスクを組み込みたいな)。
Discussion