Datadog使っているけど、Sentryによるエラートラッキング機能が便利という話

DMMプラットフォームではアラートモニタリングにDatadogを利用しているが、 最近Sentryを導入しようと思っている（自分のチームだけ2年前くらいから先行して導入しているけど、良さそうなので組織全体で利用しようと思っている）。 この記事はDMMプラットフォームのエンジニアにSentryを紹介した際のドキュメントを加筆修正したものである。

Sentryとは?

Sentryを一言で説明すると、アプリケーションモニタリングとエラートラッキングに特化したサービスである。 Webサービスに対するユーザー体験の改善が主な目的になる（と思う）。
https://sentry.io/welcome/

デモが利用できるので、気になる人は実際に触ってみるといい。
https://try.sentry-demo.com

なぜSentryを導入するのか?

結論から言うと、"エラートラッキングによって開発効率とユーザー体験向上させたい" というモチベーションがあるからである。

DMMプラットフォームではDatadogを利用しているので、 アラートモニタリングは問題なく実現できているが、 もう一歩踏み込んだエラートラッキングをしようとするとSentryのようなエラートラッキングサービスが必要であり、 これをDatadogで実現しようとすると難しいと思っている。

Sentryの機能紹介

Senrtyにはエラートラッキング機能とアプリケーションモニタリング機能があるが、 ここではエラートラッキング機能を中心に紹介する。

エラートラッキング機能

Sentryのエラートラッキング機能は "エラーを管理する" 機能である。 「これを同じことがDatadogでできるかな?」と思いながら読むと、Datadogとの使い分けをイメージできると思う。

1. エラーをグルーピングしてくれる

Sentryのエラートラッキング機能で一番重要なものは "エラーの自動グルーピング機能" である。

SentryはWebアプリケーションで発生したエラーを "エラーメッセージ", "スタックトレース" ごとにグルーピングして一覧表示してくれる。 同じエラーメッセージであってもソースコード上で発生場所が異なるエラーは別のエラーとみなされる。 単にエラーをグルーピングしているだけだが、Sentryのエラートラッキング機能はこの仕組みを中心に展開されているので、 とても重要な機能である。

ちなみに、エラーのグルーピングアルゴリズムはある程度カスタマイズできる。
https://docs.sentry.io/product/data-management-settings/event-grouping/

2. グルーピングしたエラーごとに対応優先度を決めることができる

Sentryはグルーピングしたエラーごとに以下の情報を一覧で可視化してくれる。

  • 発生件数
  • 発生頻度
  • エラーが発生したユーザー数

これによって "頻繁に発生していて影響ユーザー数が多いエラー" から優先的に不具合を修正することができる。 逆に "頻度が低かったり、影響ユーザーが少ないエラー" は優先度を下げて対応することができる。

3. グルーピングしたエラーごとにリクエスト情報、クライアント情報を可視化してくれる

実際にエラーを修正する場合、エラーの原因を特定できる情報は多い方がいい。

Sentryは以下のようにエラーメッセージやスタックトレースだけでなく、リクエスト情報やクライアント情報を可視化してくれる。 以下の画像はクライアントがAndroidの場合だが、ブラウザの場合はユーザーエージェントなどを表示してくれる。 1画面で完結するのでとても見やすい。

そして、タグに関しては、具体的な値の割合を可視化することができる。 例えば以下のようにクライアントの割合を確認することができるので、クライアントを扱うエンジニアに役立つと思う。

"ブラウザ検出"など、タグの値によってSentryが自動的にやってくれるものもあるが、 基本的にタグ情報は以下のようにアプリケーションの実装でセットする必要がある。
https://docs.sentry.io/platforms/go/enriching-events/tags/

そして、JS, Android, iOS のようなクライアントアプリケーションであれば、必要に応じてファイルを添付することもできる。 ログを送信するのが主な用途になるだろう。 https://docs.sentry.io/platforms/javascript/enriching-events/attachments/

4. エラーごとに対応記録（Activity）を管理することができる

Sentryはエラーごとに対応記録を管理することができるので、 対応記録を残しておけば、過去のエラーを検索して、当時実施した対応を確認することができる。 ドキュメントなどで管理している"エラー対応方法まとめ"みたいなものをSentryに置き換えることができる可能性もある。

5.Datadogでは補足しづらいエラーを可視化することができる

Sentryはエラーを管理する機能に特化しているが、Datadog のようにアラート機能も備えているので、 PagerDutyやSlackに通知を送信することが可能である。
https://docs.sentry.io/product/alerts/

Datadogの監視は "エラー率が10%を超えたらアラートを発火する" というように、 ある程度ざっくりとしたボリュームのエラーを検知することで発火させるのには適しているが、 Sentryはエラーを "スタックトレース" と "エラーメッセージ" で自動的にエラーをグルーピングしてくれるので、 個々のエラーに対して個別にアラートを発火させることができる。

例えば、"今まで発生したことのないエラー" や "発生件数が少ないエラー" を可視化し、アラート発火させることができる。 Datadog でこれを実現しようとする場合、エラーの種類ごとにカスタムメトリクスやモニターを定義する必要があるが、 Sentryはエラーを自動的にグルーピングしてくれるので、そういった面倒な作業が不要である。

以下は "Sentryで新規エラーを検知したときに発火するアラート" の設定である。 Sentryはスタックトレースとエラーメッセージでエラーをグルーピングするので、"新規エラーかどうか" を検知することができる。

アプリケーションモニタリング機能

Sentryにはアプリケーションモニタリング機能もあるが、自分はたいして使ったことないので軽く触れるだけにする。

（たいして使ったことないので分からないが）アプリケーションモニタリング機能は"アプリケーションの状態"を可視化する機能である。 代表的なのはパフォーマンスモニタリングという機能で、主に以下を可視化することができる。

Datadogに比べると比較的クライアントアプリケーション（iOS, Android, Web FE）寄りの便利な機能が揃っている印象がある（特にトレンドとか便利そう）。

DMMプラットフォームはサーバサイド中心の開発組織なので、こういったパフォーマンスモニタリングはDatadogでも代替できると思っている。 むしろ、Datadogはサーバやアプリケーションのリソースメトリクス（CPU, Memory Usage みたいなやつ）を取得し、 それをログやパフォーマンスメトリクス（APM）と紐付けて可視化することができるので、 サーバサイド中心のDMMプラットフォームの場合はDatadogで十分だと思う。

ということで、DMMプラットフォームではアプリケーションモニタリングを積極的に利用することはあまり想定していない。 おそらく一部のクライアントアプリケーションで利用するにとどまるだろう。

Sentryの料金体系

Sentryの料金体系は以下になっている。
https://sentry.io/pricing/

契約プランに依存する部分はあるが、 基本的にアプリケーションモニタリングもエラートラッキングも従量課金になっている。

エラートラッキング機能では、あくまで "トラッキングしたいエラー" だけSentryに送信すればいいので、 場合によってはそれなりに費用を抑えられると思っている。 DMMプラットフォームはエンジニアが100人以上の組織規模なので、 こういったツールの導入は費用（コスパ）との相談になるが、 Sentryは比較的コスパの良いツールだと思っている。

Datadog との使い分け

Datadogはアラートモニタリングサービスで、Sentryはアプリケーションモニタリング&エラートラッキングサービスである。 一部重複する機能はあるが、Sentryを導入することでユーザー体験や開発効率を向上させることができると思う。 特にWebFE, Android, iOSといったクライアントアプリケーションを開発しているチームは積極的に導入して欲しい。

DatadogとSentryで同じような機能を利用しても仕方ないので、 重複する機能をどう扱うかは事前に考えておくと良い。

Datadog にもエラートラッキングの機能がある

このドキュメントはDMMプラットフォームの社内向けドキュメントを加筆修正したものだが、 実はあとになってDatadogにもエラートラッキングの機能があることに気づいた・・・。 どうやらDatadogのAPMを利用していると、エラートラッキング機能にエラーが記録されていくっぽい。

これが結構Sentryのエラートラッキング機能と似たようなものになっていて、 （ちょっとUIを確認しただが）以下の特徴があるっぽい。

  • エラーをグルーピングして、発生件数を可視化してくれる。
  • エラーログとメトリクスの値を紐付けてくれる。
  • APMのトレースとSpan Tagの値を紐付けてくれる。
  • 今まで発生したことのないエラーを検出してくれる。


Sentryとの違いは・・・多分以下だと思う。

  • 保存期間はAPMの保存期間に依存する（14日くらい・・・?）。
  • Activityはない。
  • "ブラウザ検出"などクライアント情報を可視化する機能はない。
  • エラーをグルーピングするアルゴリズムを変更することはできない。
  • ユーザー単位で影響を可視化することができる。

最後にある "ユーザー単位で影響を可視化することができる" というのは、 エラー件数ではなく影響を受けたユーザー数を可視化することができるというものである。

ユーザーの識別は以下のいずれかで行われる。

ref: https://docs.sentry.io/platforms/go/guides/http/enriching-events/identify-user/#id

以下はメールアドレスベースで影響を受けたユーザーを可視化している例である。

例えば、エラーが100件発生しても、影響を受けたユーザーが100人とは限らない。 クライアントがリトライ処理を実装していて、"サーバへのリクエストに失敗したら1回だけリトライする" という実装になっている場合、 エラーが100件あっても実際に影響を受けたユーザー数は半分の50人である。 このようにエラー件数とユーザーへの影響度が同じとは限らないので、 "ユーザー単位で影響を可視化することができる" というのはとても便利である。

エンドユーザーに直接影響を与えるようなプロダクトはSentryの方が良いと思う。

宣伝

DMMプラットフォームのマイクロサービスアーキテクトチームではサーバサイドエンジニアとSREを募集しています。 チームの話を聞くことができるカジュアル面談をMeetyで実施中なので、 興味のある方は連絡してください。