本記事では、エラートラッキングサービスのSentryを使用した際のAlertのフィルタリング方法をいくつか解説します。

アプリケーションでエラーが出た時に、それをキャッチしてSlackに通知を飛ばす……みたいな構成にする場合、「ノイズになるエラーが多すぎて重要なエラーがわかりにくい！」ということがあると思います。

このノイズとなるエラーについて、Sentryでフィルタリングする方法について解説します。

Alertのフィルタリング方法については、主に以下の三つがあります。

1. issueのignore機能
2. Alertのフィルタ機能
3. Configのexcluded_exceptions設定

issueのignore機能

Sentryに通知されたエラー（正確に言うとエラー以外でも通知できる）は、issueという形で管理されます。

このissueをignoreすると、Alertに設定している条件でも通知が飛ばなくなります。

ignoreは各issue画面や、issue一覧などから出来ます。issue画面だと、画像右上のボタンからignore出来ます。

この機能を使ってフィルタリングする利点としては、以下の通り。

• ・Sentry上にはエラーがissueとして記録され続けるので、後から見返せる
• ・ソースコードに手を加えず、GUI上から通知を切り替えられる
• ・「今から何週間の間、無視する」「今から何回まで無視する」といった条件付きのフィルタリングが簡単に出来る

issueは発生したソースコードの行ごとなど、Sentry上のルールでグループ化されます。
「同じエラーなのに別々のissueになってしまって管理が面倒」という場合は、「Merge」でissueを一つまとめてからignoreしてください。
Mergeはissueの一覧でチェックマークを付けた後に、Mergeボタンを押すことで出来ます。（Merge出来るのは同じ種類のエラー等、一定の条件があるようです）

詳しくはMergeの公式ドキュメントもご確認してください。公式ドキュメントには、他にもissueのグループ化方法が書いています。

Alertのフィルタ機能

Slackなどに通知を飛ばしているAlert自体もフィルタリング機能を持っています。

かなり細かい条件が設定できます。例としては以下のような条件。

• ・Messageに含まれる文字列
• ・issueの発生頻度（１時間に5回以上なら通知する等）
• ・アクセスしたURL
• ・issueに付けたタグの種類

画像のようにAlertの「Edit Rule」画面で設定できます。上記以外にもかなり細かい条件を設定できます。詳しくは、公式ドキュメントのアラートの作成や、アラートのベストプラクティスを確認してください。

また、Alertでは通知先のSlackのチャンネルなども変更できるので、重要なエラーだけSlackチャンネルを振り分けるといったこともできます。

上記のignoreと組み合わせて使うこともできますが、両方でフィルタリングすると、どちらの条件でフィルタリングされたかわかりづらくなります。運用上は片方に寄せるか、それぞれ役割を決めて設定・管理するのがよいと思います。

アプリケーションのConfig設定

アプリケーション内のSentrySDKのconfigでSentryに通知するエラーを限定することが出来ます。

excluded_exceptionsを使うと、指定したエラーを通知から除外できます。

以下の例はRubyでHTTP404エラーを通知から排除しています。

config.excluded_exceptions += ['ActionController::RoutingError', 'ActiveRecord::RecordNotFound']

詳細は公式ドキュメントをご確認ください。

他にも送信前に判定を行うbefore_sendや、特定のトランザクションがSentryに通知しないように判定できるtraces_samplerやbefore_send_transactionなどもあります。こちらは公式ドキュメントがありますので、そちらをご確認ください。

これらのアプリケーションでのエラーフィルタリングは、Sentryにそもそも通知を行わないため、issueとして記録されません。

このため「不要なノイズだと思っていたけど、実は不具合が裏に隠れていた」みたいな場合に、後からの追跡が難しくなる場合があります。原因がはっきりしている記録が必要ないエラーだけをアプリケーション側で指定し、基本的にはSentryに通知してSentry側でフィルタリングすることをおすすめします。

Sentryは多機能なエラートラッキングサービスです。通知のフィルタリングについても色々な方法で行えます。その一方であちこちでフィルタリングすると使用者側が混乱する可能性があります。
フィルタリングする際にはプロジェクト内で運用方針を定めてルール化し、「どこで何をフィルタリングしているのか」がわかるようにしておくようにしましょう。