Sentry のイベント枠を数日で使い切ったとき — 送る前にノイズを削って本当のエラーを残す運用メモ

tracesSampleRate と sampleRate は別物

コードに入る前に、取り違えやすい2つの設定を分けておきます。ここを混同すると、エラーを絞ったつもりでパフォーマンストレースが枠を食い続けます。

私が最初に枠を溶かしたときの原因の半分は、開発中に tracesSampleRate: 1.0 のまま公開してしまったことでした。エラーではなくトレースが枠を食っていたのです。エラー側の sampleRate はむしろ下げず、ノイズだけを beforeSend で外科的に落とす。この役割分担が出発点になります。

import * as Sentry from "@sentry/react-native";
 
Sentry.init({
  dsn: "https://YOUR_KEY@o0.ingest.sentry.io/YOUR_PROJECT",
  environment: __DEV__ ? "development" : "production",
  release: "app@1.4.0",
 
  // エラーは原則すべて送る。ノイズは beforeSend で個別に落とす
  sampleRate: 1.0,
 
  // パフォーマンストレースは本番で大きく絞る（ここが枠を食う主因になりやすい）
  tracesSampleRate: __DEV__ ? 1.0 : 0.05,
 
  // 既知の無害なメッセージはそもそも送らない
  ignoreErrors: [
    "AbortError",
    "Network request failed",
    "TypeError: Network request failed",
    /Non-Error promise rejection captured/,
  ],
});

ignoreErrors は文字列・正規表現でメッセージを前方一致的に弾く、いちばん手軽な入口です。ただしこれだけだと「本当は見たい Network エラー」まで一律に消えます。そこで、条件付きで判断できる beforeSend に進みます。

beforeSend でクライアント側で捨てる

beforeSend は、イベントが Sentry に送られる直前に実行されるフックです。ここで null を返せば、そのイベントは送信されません。枠を消費する前にクライアント側で捨てられるのが大きい利点です。

握りつぶしてよいノイズの条件を、意味のある単位で書きます。

Sentry.init({
  // ...前述の設定...
  beforeSend(event, hint) {
    const error = hint?.originalException;
    const message =
      (typeof error === "string" ? error : error?.message) || "";
 
    // 1. ユーザーが画面を離れたことによる fetch 中断は無害
    if (error?.name === "AbortError") {
      return null;
    }
 
    // 2. オフライン起因のネットワーク失敗は、頻度が高く原因も明白なので落とす
    //    （ただしオフライン以外のネットワーク失敗は残したいので条件を限定する）
    if (
      message.includes("Network request failed") &&
      event.contexts?.app?.in_foreground === false
    ) {
      return null;
    }
 
    // 3. 特定サードパーティ SDK の内部警告は自分では直せないため落とす
    const frames =
      event.exception?.values?.[0]?.stacktrace?.frames || [];
    const fromNoisySdk = frames.some((f) =>
      (f.filename || "").includes("some-analytics-sdk")
    );
    if (fromNoisySdk) {
      return null;
    }
 
    return event;
  },
});

ポイントは、beforeSend を「一律に減らす場所」ではなく「無害と判断できる根拠を書く場所」として使うことです。AbortError だから落とす、フォアグラウンドでないネットワーク失敗だから落とす——このように理由が言語化できるものだけを落とせば、後から読み返しても安全に判断できます。

なお、React のコンポーネントツリー由来の未捕捉例外を Sentry に載せる方法は、Error Boundary と未処理 Promise を本番で捕まえる設計で扱った内容と組み合わせると、捕捉と抑制の両輪が揃います。

恒常的なノイズは fingerprint でまとめる

beforeSend で完全に消すほどではないけれど、大量に同じものが飛んでくる——そういうイベントは、消すのではなく 1つの issue にまとめるのが有効です。Sentry はスタックトレースの差異で別 issue に分割しますが、fingerprint を指定すると強制的にグルーピングできます。

beforeSend(event, hint) {
  const error = hint?.originalException;
  const message = error?.message || "";
 
  // HTTP 5xx は、URL のクエリ差やリクエストIDでバラバラの issue に
  // 分裂しがち。エンドポイント単位で1つにまとめる
  if (message.startsWith("HTTP 5")) {
    const endpoint = (error?.url || "unknown").split("?")[0];
    event.fingerprint = ["http-5xx", endpoint];
  }
 
  return event;
}

グルーピングそのものは枠の消費量を直接は減らしません。しかし、100件に分裂していた issue が1件に集約されると、「本当に多いのはどれか」が一目で分かるようになります。すると次にサンプリングや beforeSend で狙うべき対象がはっきりし、結果として無駄な送信を止める判断が速くなります。

Crashlytics 側は無制限だが、無限に見ていい訳ではない

コスト観点でひとつ補足します。Firebase Crashlytics はイベント数に上限がなく、送信量そのものを気にする必要はありません。この点では気楽です。

ただし「無制限だから全部送る」を続けると、今度はダッシュボード側がノイズで埋まります。非致命エラーを recordError() で無条件に記録し続けると、致命的クラッシュが件数の海に沈みます。

import crashlytics from "@react-native-firebase/crashlytics";
 
// 非致命エラーも「重大度」を属性として付けておくと、
// 後からダッシュボードで絞り込める
function recordNonFatal(error, severity = "warning") {
  crashlytics().setAttribute("severity", severity);
  crashlytics().recordError(error);
}

枠の制約がない Crashlytics でも、「記録する前に重大度を判断する」姿勢は同じです。上限があるかどうかにかかわらず、ノイズを送らないことが結局は自分の可視性を守ります。この分類の考え方は実行可能なクラッシュレポートと段階配信の運用とも地続きです。

サンプリング後も致命的エラーは必ず通す

ノイズを削る作業でいちばん怖いのは、勢い余って重要なエラーまで落としてしまうことです。これを防ぐために、私は beforeSend の先頭に「必ず通す」ガードを置いています。

const ALWAYS_SEND = new Set([
  "PaymentError",       // 課金は絶対に見逃せない
  "AuthTokenMissing",   // 認証破綻はユーザーを完全に止める
  "DataCorruption",     // 保存データの破損は信頼を失う
]);
 
beforeSend(event, hint) {
  const error = hint?.originalException;
 
  // allowlist に該当するものは、他の抑制ルールより前に無条件で通す
  if (error?.name && ALWAYS_SEND.has(error.name)) {
    return event;
  }
 
  // ここから下に AbortError などの抑制ルールを書く
  // ...
  return event;
}

抑制ルールは「疑わしきは残す」で設計します。落とすのは、無害だと理由をもって言い切れるものだけ。判断に迷うエラーは通す。枠を守ることより、見逃さないことを優先する。この順序を崩さない限り、サンプリングは安全な道具であり続けます。

導入してからの数字（実体験メモ）

これらを一つのアプリに入れて2週間ほど運用しました。個人開発なので、変更はすべて私自身が入れて、私自身の目で観測します。

月あたりの送信イベントは、対策前のペースで約18,000件でした。内訳を Discover で見ると、AbortError が約61%、tracesSampleRate: 1.0 由来のトレースが枠圧迫のもう一方の柱でした。

tracesSampleRate を 0.05 に下げ、AbortError とフォアグラウンド外のネットワーク失敗を beforeSend で落とした結果、送信ペースは約3,200件/月まで下がりました。無料枠の5,000件に対して6割強、という水準です。

大事なのはここからで、削った後にわざとステージングで課金エラーを発生させ、ALWAYS_SEND の allowlist を通って Sentry に届くことを確認しました。ノイズは減ったが致命的エラーは通る——この2点を両方確認して、はじめて「枠を守れた」と言えます。数字が下がっただけで安心しないことが、この手の作業では一番の落とし穴だと感じています。

週次トリアージに落とし込む

最後に、これを単発の作業で終わらせないための最小の運用手順をまとめます。作り込みすぎず、5分で回せる粒度にしておくのがコツです。

監視の目的は、たくさん記録することではなく、必要なときに必要なエラーが残っていることです。ノイズを送る前に削る習慣は、無料枠の中でその状態を保つための、地味だけれど効く一手だと考えています。一律にサンプリング率を下げるより、私はこの「名指しで削る」やり方を好みます。理由を言語化できる分だけ、後から安心して読み返せるからです。

まずは自分のプロジェクトの Discover を開き、直近7日で最も多い issue を1つ見つけてみてください。それが無害なら、beforeSend に一行足すだけで枠の消費はすぐに変わります。実装の参考になれば幸いです。お読みいただきありがとうございました。