Sentry のエラー数を抑えてクォーターを守る方法
この記事では、Sentry において特定のエラーが大量に送信されてしまっている時に止める方法と、このような事態にならないように予防する方法を解説します。
はじめに
Sentry は、プロダクトで発生するエラーをキャッチして送信し、発生箇所やスタックトレースなどを蓄積してくれる SaaS です。とても便利なツールなのですが、プランごとに送信できるエラー数の上限 (クォーター) があります。知らぬ間に大量のエラーが送信されてしまい、クォーターを使い果たしてしまうことがあります。
一度クォーターを使い果たすと、一定の猶予期間後、次に課金されるまでの間は容赦なくエラーが全て破棄されます。この頃にはすでに私たちは Sentry がないと安心できない体になっているので、エラーが検知できないのは怖すぎるということで追い課金をしなければならない状況になってしまいます。
対象読者
- エラーによってクォーターが消費される条件を知りたい方
- 今まさに大量のエラーが送信されていて危機的状況にある方
- 事前にクォーターの消費を予防したい方
クォーターが消費される条件
まず、クォーターが消費される条件を確認してみます。
公式ドキュメントの「Quota Management」というページで解説されています。
執筆時点では、以下のように記載されています。
消費されるケース
まず、クォーターが消費される主なケースは下記のとおりです。
勘違いされているケースが多いのですが、エラーを Ignore した場合でもクォーターは消費されます。
- エラーを Resolve した後に同じエラーが再度発生した場合
- エラーを Ignore した後に同じエラーが再度発生した場合
消費されないケース
次に、クォーターが消費されない主なケースは下記のとおりです。
意外と多くの方法でクォーターの消費を抑制できることがわかります。
- エラーを Delete and discard future events した後に同じエラーが再度発生した場合
- Inbound Filters で除外された場合
- Spike Protection で除外された場合
- SDK 側のフィルターや設定によって除外された場合
- Rate Limits で除外された場合
特定のエラーがクォーターを消費している時に緊急で止める方法
まずは、特定のエラーがクォーターを消費してしまっており、緊急で止めたい場合の対処方法を解説します。
Issue での操作
特定の 1 つの Issue がクォーターを消費してしまう場合は、該当の Issue で操作します。
Delete and discard する
特定の 1 つの Issue がクォーターを消費してしまう場合、よく Ignore される場合が多いのですが、通知が止まるだけでクォーターは引き続き消費してしまいます。
"Ignore" でなく "Delete and discard future events" を選択します。その後は同じ Issue に該当する場合、クォーターは消費されず自動で破棄されます。操作ユーザーに強い権限が不要なのも特徴です。Business plan 以上であれば、これでほとんどのケースに対応できるのではないでしょうか。
一方で、下位プランの場合はこの機能が使用できないので、SDK 上でフィルターをする必要があります。これについては後述します。
「…」というボタンを押下すると、選択できます
Inbound Filters での操作
特定の 1 つの Issue でなく、カスタマイズしてフィルターしたい場合は、Inbound Filters を設定します。
"Project Settings" → "PROCESSING" → "Inbound Filters" から設定できます。
glob パターンでエラーをフィルターする
エラーメッセージが完全に同一でなく Issue が分かれてしまう場合は Delete and discard しても別の Issue が作成されてしまいます。一部の文字列が異なるだけであれば、Error Message に glob パターンを設定することで、特定のエラーをフィルターできます。
こちらも下位プランの場合はこの機能が使用できないので、SDK 上でフィルターをする必要があります。これについては後述します。
glob パターンでエラーメッセージをフィルター
特定のリリースバージョンのエラーをフィルターする
または、Releases に特定のバージョンを設定することで、そのバージョンのエラーをフィルターできます。
glob パターンでリリースバージョンをフィルター
特定のユーザーからのエラーをフィルターする
特定のユーザーが Internet Explorer を使用していて大量のエラーを送信していたり、再試行を繰り返していて大量のエラーを送信していたりする場合は、ブラウザやそのユーザーの IP アドレスをフィルターすることで対応できます。
Inbound Filters に "Filter out known errors from legacy browsers" という項目があります。
この設定から Internet Explorer などの古いブラウザからのエラーをフィルター可能です。
古いブラウザをフィルター
他方で、 "IP Addresses" という項目から特定の IP アドレスからのエラーをフィルター可能です。
IP アドレスをフィルター
クォーターを抑制しないように予防する方法
次に、そもそもこのような事態にならないように予防する方法を解説します。
Spike Protection
Spike Protection は、一定期間に大量のエラーが発生した場合に、そのエラーを無視する機能です。
デフォルトで有効になっていますが、無効な場合は有効にしておきましょう。
"Organization Settings" → "Spike Protection" から設定できます。
アルゴリズムはドキュメントに記載されています。発動基準が緩めなので、最後の砦として使用されると考えると良さそうです。
SDK の設定
SDK の設定を変更することで、エラーの送信を抑制できます。
設定の難易度が低いものを紹介します。
(JavaScript SDK を参考にしたため、他の技術構成の場合は使用できない可能性があります)
sampleRate
sampleRate を設定すると、エラーを送信する割合を設定できます。例えば、 0.1 を設定した場合 10 % のエラーしか送信されません。
一方で、送信するエラーの選定はランダムなため、発生頻度が低いエラーを取り逃したり、エラーを検知できるまで時間がかかるリスクはあります。
ignoreErrors
ignoreErrors を設定すると、エラーのメッセージを正規表現で指定することで、合致したエラーを無視できます。
Inbound Filters でのフィルターは Business plan 以上でしか使用できませんが、こちらは下位プランでも使用できます。
denyUrls / allowUrls
denyUrls / allowUrls を設定すると、サードパーティ製のライブラリのエラーを無視できます。
よくあるのが、埋め込んでいる計測ツールで障害が起きたタイミングで全ユーザーからエラーが送信されてしまうケースです(昔 Lucky Orange でありました…)。事前に allowUrls でプロダクト以外のエラーをフィルターしておくことで、リスクを軽減できます。
Spend Allocation
Spend Allocation は、プロジェクトごとにエラー数のクォーターを設定できます。これによりエラーが極端に増えても、影響をプロジェクト内に閉じ込めることができます。
"Settings" → "Spend Allocation" から設定ができます。
Rate Limits
Rate Limits は、プロジェクトごとに一定期間中で受け入れるエラー数の最大値を指定できます。これによりエラーが極端に増えても、受け入れるエラー数を抑えることができます。
"Project Settings" → "Client Keys (DSN)" から設定ができます。
まとめ
Sentry におけるクォーター消費の仕組みと、クォーターの消費を抑える対策や予防策について紹介しました。
Business plan 以上であれば、Spend Allocation や Rate Limits による予防をした上で、Delete and discard による Issue の除外や Inbound Filters を活用するのがおすすめします。
下位プランであれば、SDK の設定を変更して予防とフィルターを行うのがおすすめです。
-
余談ですが、機能が削られていることによって下位プランの方がエラー数は増えやすいため、設計がうまいなと良い意味で感心しています。Business plan 以上にアップグレードしたいけど予算を取れないという場合、エラー数を削減できることで追加課金が減らせるというメリットも織り込んでみてください。 ↩︎
Discussion