目次
BugSnag導入によるログ監視効率化とエラー対応のスピードアップ
参考になった
11
会員限定コンテンツです。無料登録すると制限なしでお読みいただけます。
レビュー投稿日の情報になります
ソーシャルデータバンク株式会社 / hsrmy
メンバー / フロントエンドエンジニア / 従業員規模: 51名〜100名 / エンジニア組織: 11名〜50名
最終更新日投稿日
| 利用プラン | 利用機能 | ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
|---|---|---|---|---|
Preferred Plan | エラー監視 | 11名〜50名 | 2020年9月 | B to B B to C |
| 利用プラン | Preferred Plan |
|---|---|
| 利用機能 | エラー監視 |
| ツールの利用規模 | 11名〜50名 |
| ツールの利用開始時期 | 2020年9月 |
| 事業形態 | B to B B to C |
アーキテクチャ
会員限定コンテンツ無料登録してアーキテクチャを見るアーキテクチャの意図・工夫
- FireLens for Amazon ECSとAmazon Data Firehoseを使用してAmazon S3にログを保存することでAmazon CloudWatch Logsにログを保存する場合と比較してコスト削減・ログ検索可能期間の延長を図ることができる
- BugSnagにはログレベルがWarning、Errorのログを送信するようにするにしてBugSnagのイベント数のクォータを超えないようにする
- エンジニアはSlackに投稿されるBugSnagからの通知を元にAmazon Athena等も使用しログ調査を実施
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
- Slackのログ監視用チャンネルにログが垂れ流しになっている
- 1週間で約1800件のログが投稿される
- ログ監視担当者はSlackを開いて流れてくるログを確認しつつ各々のタスクを進める必要があった
- 障害時に重要なログが優先度が低いログに埋もれる
- 一見しただけでエラーの重要度や初めて発生したエラーなのかわからない
- 今すぐ対応すべきログなのかわからない
どのような状態を目指していたか
- 一見しただけで重要度と発生回数がわかるようになる
- ログが垂れ流しになっているのを止める
比較検討したサービス
- Sentry
- New Relic
- Airbrake
比較した軸
- PHP(Laravel)とJavascript(特にVue.js)に対応していること
- Go言語に対応しているのが好ましい
選定理由
- 重要視していたプログラミング言語に対応していた
- 料金プランが他のツールと比較して豊富であった
- 有料プランではcollaborator(BugSnagにログインできる人)の数が無制限である
- イベント数(BugSnagに送信されたログの数)で課金される料金体系
- 導入当時は数ヶ月ごとにエンジニアがジョインしていたので、人数で課金されないのはありがたかった
- 社内に触ったことがある人がいた
導入の成果
改善したかった課題はどれくらい解決されたか
- ログがSlackに垂れ流しになることがなくなった
- ログ通知チャンネルへの投稿が約98%削減された
- エラーの重要度、発生回数が一目見ただけでわかるようになった
どのような成果が得られたか
- ログ監視担当者の負荷が削減された
- 導入前からサーバー台数が約4倍に増えたが、ログ監視担当者がSlackに張り付く必要がなくなり、多くのタスクを進められるようになった
- ログ調査が初めての新メンバーからも便利という声が出てくる
- 発生したエラーを再現させるための調査期間が短縮された
- 特定の環境で発生しているエラーの発見が容易になった
- ログのエラーレベルを意識付けが自然とできた
- 特定の機能の障害発生時に気付きやすくなった
導入時の苦労・悩み
- ドキュメントとダッシュボード上のガイドで説明されている内容が若干異なり、どちらの内容で実施すべきか悩みました
導入に向けた社内への説明
上長・チームへの説明
上長に向けて
説明したこと
- 本番環境においてもPHPのエラー時のリクエストの情報がDebugbar for Laravelと同じぐらい取得できる
- BugSnag上で確認したい情報を簡単に追加できる
フィードバックをもらったこと
- Release StageごとやApp Versionごとなど特定の条件でエラーを絞り込むことができるのは好ましい
- エラーが多く発生する障害時にエラーがグルーピングできるのはわかりやすい
チームに向けて
- BugSnag導入後のLaravelバージョンアップとログ基盤改善プロジェクトの成果をエンジニア全員に共有する会で、今後のログ監視はBugSnagからの通知を基に行うことを説明した
活用方法
ログ監視チームがSlackに投稿されたBugsnagからの通知を元にログ調査を行い、根本解決を行っている
よく使う機能
エラー監視機能
- Slackへの通知
- Githubとの連携によるIssue管理
ツールの良い点
- エラー発生時のStack Traceやリクエスト情報、ログインしているユーザーの情報を取得できる
- エラーを再現・修正するために役に立つアプリケーション固有のカスタムデータを簡単に付与できる
- 通知の設定が柔軟
- 設定できる通知の数が多い
ツールの課題点
- エラーグルーピング能力が若干弱い
- 同じExceptionでエラーメッセージが異なる場合でも同じグループに入る場合がある
- Grouping Hashを使うことでカスタマイズは可能
- 同じExceptionでエラーメッセージが異なる場合でも同じグループに入る場合がある
ツールを検討されている方へ
BugSnagのダッシュボードとドキュメントが全部英語ですが、ダッシュボードの方はわかりやすい単語が多いのでエンジニアの方ならあまり困らないと思います
今後の展望
可観測性の向上のためにOpenTelemetryの導入を考えているため、BugSnagのAspectoとの統合とAWS X-rayとの比較することを検討しています
ソーシャルデータバンク株式会社 / hsrmy
メンバー / フロントエンドエンジニア / 従業員規模: 51名〜100名 / エンジニア組織: 11名〜50名
ソーシャルデータバンク株式会社 / hsrmy
メンバー / フロントエンドエンジニア / 従業員規模: 51名〜100名 / エンジニア組織: 11名〜50名
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法