こんにちは、st-1985 です。
弊社バックエンドチームでは Rails アプリケーションのエラー監視ツールとして BugSnag を使用しており、チーム内の当番制で確認しています。
今回は BugSnag に通知された各エラーに対して行える Ignore や Snooze といったアクションの働きと、各アクションの弊社チームでの運用ついて紹介したいと思います。
以下は今回の内容の簡易まとめ表になります。
| アクション | エラーの移動先 | アクションの補足 | 弊社チームでの運用 |
|---|---|---|---|
Assign |
Assigned to anyone および Assigned to me
|
再発しても Open には戻らない。 |
当番制でエラー確認を行っているため使用していない。修正が必要な場合は後述の Create or link an Issue を使用する。 |
Create or link an issue |
Issue created |
Issue tracker と連携し、自動で Github 等の Issue の作成が可能となっている。 |
エラー調査後、対応が必要な場合に使用する。既存の Issue に紐付ける場合もある。 |
Mark as Fixed |
Fixed |
異なるバージョンで再発すると Open に戻る。 |
リンクした Issue の完了で自動的に移動するため使用していない。 |
Snooze |
Snoozed |
条件を満たした場合に Open に戻る。発生回数やユーザー数などの条件指定が可能となっている。 |
リトライ回数や復旧予定タイミングを考慮して一時対応に使用している。惰性的スヌーズ防止のため定例会で確認を実施している。 |
Ignore |
Ignored |
再発しても Open に戻らない。 |
無視可能なエラーは通知しないように修正する方針のため使用していない。 |
Discard |
移動なし | 通知されたエラーを破棄し表示しない。件数制限にもカウントされない。 | エラー通知に気づけなくなるため使用していない。 |
Delete |
Inbox から削除され表示なし |
過去のエラーも含め削除し、Inbox から消える。再発時の動作を選択可能となっている。 |
Discard と同様の理由で使用していない。 |
また、アクションについての公式ドキュメントは以下にありますので必要に応じて参照して頂ければと思います。
Assign
エラーについての担当者を管理画面上で割り当てます。
エラーは Assigned to anyone に移動し、自分が割り当てられている場合は Assigned to me にも表示されるようになります。
再発しても Open には戻りません。
弊社チームでの運用
当番制で確認している為、このアクションは使用していません。
もしその日の担当者で判断が難しい場合は Slack 上や毎日のミーティングで共有・相談をして調査を進めています。
また、コードの修正等、本格的な対応が必要な場合は後述する Create or link an issue で issue を作成して対応しています。
Create or link an issue
URL のリンクを登録し、Issue created に移動します。
Project settings > Issue tracker から GitHub 等と連携する事で、Issue を自動で作成することも可能です。
弊社チームでの運用
エラー調査後、修正等の対応が必要な場合に使用し、その後は作成した Issue で対応を管理しています。
エラーによっては既存の Issue で対応可能な場合もあるので、その場合はその Isuue に紐付けを行います。
Mark as Fixed
エラーは Fixed に移動します。異なるアプリケーションのバージョンで同じエラーが再度発生すると Open に移動します。
弊社チームでの運用
基本的に リンクされた Issue が完了した時に自動で Fixed に移動する為、Mark as Fixed を実行する事は少ないです。
(「プルリクエストをマージ → 紐づけられた Issue が自動で close → エラーが自動で Fixedに移動」 という流れ)
開発中にステージング環境で発生したエラーについては Issue を経由しない為、修正時に手動で Mark as Fixed を行う事があります。
なお、Bugsnag に通知するアプリケーションのバージョンについては、現在のコミットハッシュを読み込んで設定する事で毎回のデプロイが変わるようにしています。
Bugsnag.configure do |config|
config.app_version = `git rev-parse HEAD`.chomp
end
Snooze
エラーは Snoozed に移動します。
「指定した条件」を満たした場合に Open に戻ります。
Snooze は「指定した条件」として以下のいずれかのオプションを選択します。
-
「This occurs again…」:
指定回数エラーが追加で発生した場合にOpenに戻ります。弊社チームでの運用
リトライ等により今後発生するエラー件数を把握できている場合はSnoozeを使用します。
また、ネットワークエラー等の一時的なエラーや、原因がはっきりとしていないがサービスに影響が出ていないエラー等で次回発生まで様子見する時に使用したりします。 -
「This occurs again after…」 :
指定期間以降にエラーが発生した場合に
Openに戻ります。弊社チームでの運用
あまり使用する機会はありませんが、バッチ処理による更新等エラーの復旧が期待されるタイミングがある場合に使用します。 -
「This occurs at least…」:
このオプションは動作が少し特殊で、エラー発生時刻を1時間単位で切り捨てし、指定した時間枠の中で指定件数以上のエラーがあればOpenに戻る動きをします。# 1時間に2件以上で Open に戻る設定にした場合 12:59 にエラー > 12:00 に切り捨てしてカウント。1時間に1件なので Open に戻らない。 13:01 にエラー > 13:00 に切り捨てしてカウント。1時間に1件なので Open に戻らない。 13:02 にエラー > 13:00 に切り捨てしてカウント。1時間に2件なので Open に戻る。Snooze 前に発生していたエラーもカウントの対象なので、1時間に10件等の指定をしていも、Snooze 直後のエラーで
Openに戻ってしまう場合があるので注意が必要です。弊社チームでの運用
普段からある程度発生が想定されているエラーについて、スパイクを検出したい場合に使用しています。 -
「This impacts an additional…」:
エラー通知に含まれるユーザーの種類が増加した場合に
Openに戻ります。
ユーザー情報は BugSnag が提供しているライブラリを使用して、アプリケーションにコードを記述する事で任意に追加する事ができます
以下はbugsnag gemを使用してユーザーを追加しているコードです。Bugsnag.notify("Snooze error based on user count") do |report| report.user = { id: user.id } end追加されたユーザー情報はエラー詳細画面の
Usersタブで確認可能です。
弊社チームでの運用
使いどころが難しく、現状では使用していません。
Snooze 機能を活用することで、一時的なエラーや対応待ちのエラーをスヌーズして対応を後回しにすることが可能ですが、解決が進まず同じエラーが惰性的にスヌーズされ続けるケースも発生し得ます。
これに対して弊社バックエンドチームでは定期的に未解決のままスヌーズされ続けているエラーが存在しないかを確認し、対応について議論する運用もしています。
Ignore
エラーは Ignored に移動します。
再発しても Open ステータスには戻りません。
弊社チームでの運用
無視して良いエラーはそもそもアプリケーション側の実装で BugSnag に通知しないように修正するべき、という方針なので使用していません。
Discard
その後に通知されたエラーを破棄します。
破棄が行われている為、エラー詳細に追加のエラーが表示されなくなります。
エラーの Inbox 上の移動はありません。
Discard した後 Undiscard を行うことで再通知が行われるようになります。
弊社チームでの運用
エラーが通知されている事に気づけなくなる為、このアクションは基本的に使用していません。
Delete
過去に受信したエラーを含めてエラー情報を削除し、Inbox 上から消えます。
エラーが再発した場合は新しいエラーとして Open に表示されます。
Delete 実行時に「Capture future instances as a new error」のチェックを外すと、エラーが再発しても破棄されるようになります。
破棄されたエラーは Project settings > Discard errors > Discard specific errors に一覧があり、削除すると再通知が行われるようになります。
Delete と Discard の違いは、Delete で消去すると、過去のエラーデータも完全に削除され、Inbox からも表示が消える事です。
弊社チームでの運用
Discard と同様の理由からは使用していません。
参考になれば幸いです。
Discussion