はじめに
Sentry(エラー追跡のサービス)を使えば各種アプリのエラー情報を収集でき、即座の発生検知や原因調査などに役立ちます。
典型的な利用法としては、予期しないエラーが届いたらSlackなどに通知させて素早く対応、といった感じでしょうか。
そんなSentryに今月(2019年5月)、Businessプラン専用の新機能がいくつか追加されました。
https://blog.sentry.io/2019/03/06/new-features-greater-visibility
その中で、監視・分析用途に使える以下の機能を今回は紹介します(まだBetaです)。
Businessプランの試用をオンにして、ちょっと触ってみました。
- Dashboards
- Events
- Discover
Businessプラン
その前にBusinessプランの概要について。
Businessプランは料金が一番高いプランなのですが、それでも毎月払いの月額が$89と、そう高くはありません。
https://sentry.io/pricing/
基本的な性質は以下の通りで、これらはTeamプラン(安い方の有料プラン)と同じです。
- 基本、受け取れるイベント件数は月間10万件まで。それを超えると追加の従量課金が発生します。
- 組織に作れるユーザー数は無制限。料金には影響しません。ありがたい。
- イベントの詳細が保管されるのは直近90日分まで。それより古いイベントの詳細は見られなくなります。
それに加えて、今回紹介するDashboardsなどの機能が使える点が、Businessプラン特有になります。
Dashboards
選択した期間(最長で直近90日)の様子を俯瞰する画面です。
各種件数がそれっぽい線グラフや地図上の濃淡で表示されたりしますが、まあそれだけと言えばそれだけかも・・・。
Events
Dashboardsより一歩踏み込んで、色々な条件を入力してイベントの絞り込みができます。
また、ヒットした個々のイベントが表によって表示されます。リンクをクリックすると、お馴染みのIssues
の詳細画面に飛びます。
ある種類のエラーを対象として、件数の推移や、どんなユーザーや環境でよく起きているかなどを調べるのに使えそうです。
1件1件のイベント詳細を地道に調べ上げられる規模の現象について、調査・分析するのに向いているでしょう。
Discover
一番リッチで、威力を発揮しそうなのがこのDiscoverです。
DBを検索するような感覚で、
- 知りたいフィールドを指定して(
SUMMARIZE
)、 - 必要に応じて集計方法を指定したり(
AGGREGATION
)、 - 絞り込み条件を指定しながら(
CONDITIONS
)、
クエリを組み立ててイベントを検索します。
結果は表形式やグラフで表示されます。
グラフは何種類かあります。Bar by Day
の例がこちら。
よく使うクエリは、名前をつけてSave
することもできます。
エンジニア以外の人も気軽に使えるようになるでしょう。
Sentryをエラー検知、原因調査以外の用途に使えるのでは
Sentryの典型的な利用法は、やはり予期しないエラーの検知でしょう。
しかしDiscoverなどの機能を視野に入れると、予期しないエラー以外の現象もSentryに送信して、色々と活用する使い方もありです。
(Slack通知などが来ないように、例えばwarnやinfoなどのレベルで)
そうしたことは、Firebase Analyticsのようなユーザー行動分析のサービスが本業とするところではあります。
しかし、「Firebaseのコンソールではイマイチ物足りない。かといってイベントの生データをBigQueryと連携させてがっつり分析したりするのはハードルが高い」といった隙間ニーズに対しては、Sentryという選択肢も挙がってきます。
まとめ
BusinessプランのSentryなら、予期しないエラー以外のイベント監視・分析にも使えます。
とはいえ本業のユーザー行動分析サービスと比べると、Sentryには以下の短所があります。
- 直近90日のイベントしか対象にできない。
- イベント件数が月間10万件を超えると、追加の従量課金が発生してくる。
その代わり、Sentryには以下の長所があります。
- Discoverの画面ポチポチで、そこそこ凝ったクエリを作れる。集計・可視化できる。
- Discoverのクエリは保存できるので、エンジニア以外にも使えるぐらいに敷居を下げられる。
- クエリにヒットしたイベント1件1件の詳細を見るのも簡単(むしろそれが基本機能)。
- そのわりに月額$89でユーザー数が無制限と、コスパはなかなか。
月間件数が数千以下に収まるぐらいの現象に関して近況を把握するなら、Sentryは選択肢の一つになるでしょう。
例えばこんな使い方が考えられます。
- 「レアケースに備えて仕込んだあの処理、どれくらい実行されてるのかな。逆に、実はレアケースじゃなかったりするかな」
- 「正しく使うのが少し難しいこの機能の(予期した)エラー頻度を監視しよう。UI再考の必要はあるかな」
- 「ビジネスKPIに関連するこの重要機能について、実行件数の推移が見たい」