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
プロダクト内で Ignore は Archived に名前が変わったようです。時機を見て更新します。
(公式ドキュメント内ではまだ更新されていなかったです)