Sentryで大量のエラー通知を監視するために、カスタムフィルタリングを実装した話

はじめに

こんにちは、アソビューでフロントエンドエンジニアをしている村井です。皆さんは、Sentryを使っていてエラーにノイズが多くて困ったことはありませんか？

私のチームでも、Sentryを導入した際に同様の課題に直面しました。本記事では、このエラー通知のノイズを削減した方法とその効果について解説します。

Sentryを利用している方や、エラー監視の効率化を図りたい方の参考になれば幸いです。

カスタムフィルタリングが必要になった背景と課題

Sentryを導入した当初、私のチームでは想定以上のエラー通知が発生し、その多くが実際の問題解決には直結しないものでした。具体的には、以下のようなケースが頻発していました。

ユーザーの操作による意図的なエラー：フォームのバリデーションエラーや、アクセス権限がないページへの遷移など、ユーザーの操作によって発生するエラー
特定のAPIから頻発するエラー：サービスの仕様上特定のAPIから特定のステータスコードが返されるエラー

これらのエラーはサービスの正常な動作であり、開発者の対応が不要なものですが、大量に報告されることで本当に対応が必要な重要なエラーが埋もれ、見逃すリスクが高まっていました。

Sentryの既存フィルタリング機能とその限界

Sentryには、以下のような公式のフィルタリング機能があります。

Inbound Filters：一般的なエラー（例：ブラウザ固有のエラー、特定のHTTPステータスコード）を除外する機能。
Data Scrubbing：個人情報や機密データをマスキングまたは削除する機能。

これらの機能には以下の課題があります。

柔軟性の不足：特定のAPIパスや、カスタムのエラーコード、メッセージに基づいたフィルタリングが困難です。
メンテナンス性：フィルタリング条件が増えると設定が複雑になり、管理が難しくなります。

そのため、カスタムロジックを適用できるbeforeSendフックを使用することにしました。

beforeSendを用いたカスタムフィルタリングの実装

beforeSendフックを使用することで、エラーがキャプチャされた際に任意の処理を挟み、特定の条件下でエラーをフィルタリングすることが可能です。以下に実際の実装例を示します。

import * as Sentry from '@sentry/browser';
import type { AxiosError } from 'axios';

// 無視したい条件のリストを定義
const ignoreConditions = [
  { path: '/api/v1/mockApi01', statuses: [409] },
  { path: '/api/v1/mockApi02', statuses: [400, 401] },
];

// 指定したURLパスとステータスコードが無視条件に合致するかチェック
const shouldIgnore = (url: string, status: number): boolean =>
  ignoreConditions.some(
    (condition) =>
      url.includes(condition.path) && condition.statuses.includes(status)
  );

Sentry.init({
  dsn: 'YOUR_SENTRY_DSN',
  beforeSend(event, hint) {
    const exception = hint.originalException as AxiosError | undefined;
    if (!exception || !exception.response) return event;

    const url = exception.response.config.url ?? '';
    const status = exception.response.status ?? 0;

    if (shouldIgnore(url, status)) return null;

    return event;
  },
});