💸

Sentry のエラー数を抑えてクォーターを守る方法

2023/05/15に公開約5,400字

この記事では、Sentry において特定のエラーが大量に送信されてしまっている時に止める方法と、このような事態にならないように予防する方法を解説します。

はじめに

Sentry は、プロダクトで発生するエラーをキャッチして送信し、発生箇所やスタックトレースなどを蓄積してくれる SaaS です。とても便利なツールなのですが、プランごとに送信できるエラー数の上限 (クォーター) があります。知らぬ間に大量のエラーが送信されてしまい、クォーターを使い果たしてしまうことがあります。

一度クォーターを使い果たすと、一定の猶予期間後、次に課金されるまでの間は容赦なくエラーが全て破棄されます。この頃にはすでに私たちは Sentry がないと安心できない体になっているので、エラーが検知できないのは怖すぎるということで追い課金をしなければならない状況になってしまいます。

対象読者

  • エラーによってクォーターが消費される条件を知りたい方
  • 今まさに大量のエラーが送信されていて危機的状況にある方
  • 事前にクォーターの消費を予防したい方

クォーターが消費される条件

まず、クォーターが消費される条件を確認してみます。

公式ドキュメントの「Quota Management」というページで解説されています。

https://docs.sentry.io/product/accounts/quotas/#what-counts-toward-my-quota-table-view

執筆時点では、以下のように記載されています。

消費されるケース

まず、クォーターが消費される主なケースは下記のとおりです。

勘違いされているケースが多いのですが、エラーを 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 上でフィルターをする必要があります。これについては後述します。

Sentry の Issue 画面。アクションエリアに「…」というボタンがあり、押下すると Delete and discard future events を選択できる
「…」というボタンを押下すると、選択できます

Inbound Filters での操作

特定の 1 つの Issue でなく、カスタマイズしてフィルターしたい場合は、Inbound Filters を設定します。

"Project Settings" → "PROCESSING" → "Inbound Filters" から設定できます。

https://docs.sentry.io/product/data-management-settings/filtering/

glob パターンでエラーをフィルターする

エラーメッセージが完全に同一でなく Issue が分かれてしまう場合は Delete and discard しても別の Issue が作成されてしまいます。一部の文字列が異なるだけであれば、Error Message に glob パターンを設定することで、特定のエラーをフィルターできます。

こちらも下位プランの場合はこの機能が使用できないので、SDK 上でフィルターをする必要があります。これについては後述します。

Sentry の Inbound Filters 画面。 Error Message を glob パターンで入力する欄がある
glob パターンでエラーメッセージをフィルター

特定のリリースバージョンのエラーをフィルターする

または、Releases に特定のバージョンを設定することで、そのバージョンのエラーをフィルターできます。

Sentry の Inbound Filters 画面。リリースバージョンを glob パターンで入力する欄がある
glob パターンでリリースバージョンをフィルター

特定のユーザーからのエラーをフィルターする

特定のユーザーが Internet Explorer を使用していて大量のエラーを送信していたり、再試行を繰り返していて大量のエラーを送信していたりする場合は、ブラウザやそのユーザーの IP アドレスをフィルターすることで対応できます。

Inbound Filters に "Filter out known errors from legacy browsers" という項目があります。

この設定から Internet Explorer などの古いブラウザからのエラーをフィルター可能です。

Sentry の Inbound Filters 画面。"Filter out known errors from legacy browsers" の設定がある
古いブラウザをフィルター

他方で、 "IP Addresses" という項目から特定の IP アドレスからのエラーをフィルター可能です。

Sentry の Inbound Filters 画面。IP Addresses を入力する欄がある
IP アドレスをフィルター

クォーターを抑制しないように予防する方法

次に、そもそもこのような事態にならないように予防する方法を解説します。

Spike Protection

Spike Protection は、一定期間に大量のエラーが発生した場合に、そのエラーを無視する機能です。

デフォルトで有効になっていますが、無効な場合は有効にしておきましょう。

"Organization Settings" → "Spike Protection" から設定できます。

アルゴリズムはドキュメントに記載されています。発動基準が緩めなので、最後の砦として使用されると考えると良さそうです。

https://docs.sentry.io/product/accounts/quotas/spike-protection/

SDK の設定

SDK の設定を変更することで、エラーの送信を抑制できます。

設定の難易度が低いものを紹介します。

https://docs.sentry.io/platforms/javascript/configuration/options/

(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" から設定ができます。

https://docs.sentry.io/product/accounts/quotas/spend-allocation/

Rate Limits

Rate Limits は、プロジェクトごとに一定期間中で受け入れるエラー数の最大値を指定できます。これによりエラーが極端に増えても、受け入れるエラー数を抑えることができます。

"Project Settings" → "Client Keys (DSN)" から設定ができます。

https://docs.sentry.io/product/accounts/quotas/manage-event-stream-guide/#6-rate-limiting

まとめ

Sentry におけるクォーター消費の仕組みと、クォーターの消費を抑える対策や予防策について紹介しました。

Business plan 以上であれば、Spend Allocation や Rate Limits による予防をした上で、Delete and discard による Issue の除外や Inbound Filters を活用するのがおすすめします。

下位プランであれば、SDK の設定を変更して予防とフィルターを行うのがおすすめです。

脚注
  1. 余談ですが、機能が削られていることによって下位プランの方がエラー数は増えやすいため、設計がうまいなと良い意味で感心しています。Business plan 以上にアップグレードしたいけど予算を取れないという場合、エラー数を削減できることで追加課金が減らせるというメリットも織り込んでみてください。 ↩︎

Discussion

ログインするとコメントできます