BugSnagを利用したエラー監視体制の構築と運用
参考になった
0
株式会社GROWTH VERSE / tabamarine
メンバー / フルスタックエンジニア
| 利用プラン | 利用機能 | ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
|---|---|---|---|---|
Select Error Plan 2 | エラー監視・通知 | 10名以下 | 2020年8月 | B to B |
| 利用プラン | Select Error Plan 2 |
|---|---|
| 利用機能 | エラー監視・通知 |
| ツールの利用規模 | 10名以下 |
| ツールの利用開始時期 | 2020年8月 |
| 事業形態 | B to B |
アーキテクチャ
アーキテクチャの意図・工夫
アプリケーションの監視と品質の向上を主な目的として、フロントエンドとサーバーサイドの両方でBugSnagによるエラー監視を導入している。
発生したエラーはSlackへ即時通知し、エンジニアが迅速に対応できる環境が整備できている。
BugSnagの他に、Cloud FunctionsとBigQueryを活用したユーザーの操作ログの収集基盤を整備し、分析結果をアプリケーションの品質改善や安定稼働に役立てている。
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
- エラー検知の課題
- 本番環境で発生したエラーの発見が遅れ、顧客からの連絡で判明することがあった
- 非同期処理で発生するエラーの検知が不十分
- 原因調査・対応の課題
- エラー発生状況の可視化ができておらず、原因特定に時間がかかっていた
- フロントエンドとバックエンドのエラーを別々のツールで監視しており、問題の全体像の把握が困難
- エラーの重要度や優先順位の判断基準が曖昧で属人的
どのような状態を目指していたか
- エラーの早期発見と、迅速な対応を実現する監視体制
- フロントエンド・バックエンドを統合的に監視できる環境
- エラーの発生状況を可視化し、チーム内で影響範囲や重要度の共通認識が取れる状態
選定理由
- 価格と機能のバランスが適切
- GoとTypeScript向けの公式ライブラリがあり導入が容易
- シンプルで直感的なUI
導入の成果
改善したかった課題はどれくらい解決されたか
導入前に抱えていた課題の大半が解決できている。
BugSnagを導入したことで、エラーの検知から調査、修正までの流れがスムーズになり、「先回りして対処できる」状態になっている。
また、監視体制が整ったことで、チームとしての安心感や対応力が大きく向上した。
どのような成果が得られたか
- 顧客からの連絡で判明する不具合・エラーが減少
- エラーの検知から調査完了までの所要時間が短縮
- フロントエンド・バックエンド間の問題の対応関係が明確になった
- バッチ処理のエラー検知が自動化
- エラーの発生パターンや頻度の可視化
- エラー発生時のチーム内でのコミュニケーションが効率化
導入時の苦労・悩み
- 既存のエラーハンドリングのコードとBugSnagの統合作業
- エラーを適切にグルーピングするための設定（コードとBugSnagダッシュボードの両方から設定を行う必要あり）
- Echoフレームワークに対応した独自のBugSnagミドルウェアや、非同期処理でのエラーハンドリングの実装
導入に向けた社内への説明
上長・チームへの説明
- 現状のエラー検知の課題とそれによる顧客への影響を説明
- 普段の開発・調査における効率低下の具体例を提示し、導入による効果を定量的に説明
- 導入時に必要な工数・リソースの見積もり
活用方法
BugSnagからSlackのアラート通知チャンネルに通知し、その投稿の内容を元にログ調査、対応の要否を判断している。
ReleaseStageの設定を利用し、ステージング・本番などの環境名でログを区分けしている。
フロントエンド（React + TypeScript）では、ErrorBoundary を利用した未処理エラーの検知に加え、ライフサイクルやランタイムエラーも監視。
バックエンド（Go）では、Echoミドルウェア、Pub/Subワーカー、バッチ処理などを通じて発生する各種エラーを対象としている。
エラーの通知
- Slack連携による即時通知
- 本番環境でのエラー発生時に自動で通知
- エラー発生数の集計（例：100 events in 1h）
- 具体的なエラー発生箇所（例：Location: components/atoms/InputForm/index.tsx:14）
- エラーアクションの利用（通知の投稿に含まれるアクションボタン、BugSnagダッシュボードのどちらからでも設定可能）
- Mark as fixed：修正済みエラーとしてマーク
- Snooze 1hr：一時的に通知を停止
- Ignore：特定のエラーを無視（今後通知しない）
エラーの収集と分析
BugSnagで収集した以下のような情報をもとに、エラーの原因調査や影響範囲の特定を行っている。
- エラーの発生箇所（StackTrace、BreadCrumbs）
- エラーの種類の区別（Handled error/Unhandled error）
- エラーメッセージ
- ブラウザのバージョンや利用端末
- リポジトリ・プロジェクト別のエラー追跡
- エラーの発生頻度と影響範囲の分析
定期的な設定の見直し
- エラー通知対象の整理
- 無視すべきエラーのフィルタリング設定
- エラーのグルーピングのルールを調整
よく使う機能
- エラーのグルーピング（Error grouping）
- エラーの重要度設定（Severity indicator）
- ユーザーセッション・操作の追跡（Session tracking、Logging breadcrumbs）
- Slackへのエラー通知機能（Configuring notifications）
- エラーアクションの利用（Error Actions）
ツールの良い点
- 直感的なUIで使いやすい
- 低価格から導入できる
- フロントエンド・バックエンドの統合的な監視が可能
- 高いカスタマイズ性と充実した設定項目
- エラー時のリクエストの詳細やスタックトレースが表示されるためエラーの分析が容易
ツールの課題点
- 細かな設定項目が多く、初期設定に時間がかかる
- エラーのグルーピングの精度が不正確な時がある
- エラー件数やセッション数に応じた従量課金が発生するため、大規模プロジェクトでは高コストになる可能性あり
- Rate limitを設定した場合、超えた分のログは補足・通知が行えなくなる
ツールを検討されている方へ
BugSnagを使うことで、フロントエンド・バックエンドのエラーを統合して監視・可視化できます。
使いやすいダッシュボードや柔軟な設定により、快適なエラー監視が実現できるツールです。
一方で、初期設定やエラーのグルーピングの調整には多少の手間がかかるため、段階的に導入・設定を進めることをおすすめします。
大規模プロジェクトでは、従量課金によるコスト増に注意し、アプリケーション側の通知量の調整も併せて行う必要がありそうです。
株式会社GROWTH VERSE / tabamarine
メンバー / フルスタックエンジニア
よく見られているレビュー
株式会社GROWTH VERSE / tabamarine
メンバー / フルスタックエンジニア
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法