フロントエンドのSentryを実運用に持ち込むためにやったことメモ

sentry

Last updated at 2025-06-04Posted at 2025-06-04

背景

弊社ではフロントエンドのエラートラッキングにSentryを導入していたのですが、ほとんど運用されていませんでした。
フロントエンドで重大なエラーが発生することは稀であり、エラー調査においてSentryが必須な場面がほとんどなかったためです。

ただし、小さなバグやユーザーからの問い合わせは定期的に発生しており、その調査を行う際にSentryがあった方が便利だと感じる場面は多々ありました。

そのため、Sentryを適切に活用しようと思ったのですが、現状を整理したところ以下の課題がありました。

SourceMapsがなく、エラー箇所のコードが読みにくい
エラーが解決されずに放置され、Issueに大量に溜まっている
頻繁に発生するエラーがクォーターを多く消費する
ユーザーがら問い合わせがあった際に、エラーの再現が難しい(これは可能であれば改善したい課題)

上記の課題を解決するために調査・実施したことを紹介します。

動作環境

Nuxt(SPA): v3.8.1
sentry/tracing: v7.38.0
sentry/vite-plugin: v2.16.1
sentry/vue: v7.108.0

1. SourceMapsの導入

nuxi generate時に、SourceMapsを生成するようにします

nuxt.config.ts

  sourcemap: {
    server: true,
    client: true
  }

assetsにビルドしたコードと生成したSourceMapのディレクトリのパスを指定します。
filesToDeleteAfterUploadを指定することで、Sentry送信後にSourceMapsを削除します。これにより、SourceMapsがホスティングされて外部に公開されるのを防ぎます。

nuxt.config.ts

plugins: [
  sentryVitePlugin({
    sourcemaps: {
      assets: [
        '.nuxt/dist/client/_nuxt/*.js',
        '.nuxt/dist/client/_nuxt/*.js.map'
      ],
      filesToDeleteAfterUpload: [
        '.nuxt/dist/client/_nuxt/*.js.map',
      ],
    }
  })
]

ただ、弊社の環境ではfilesToDeleteAfterUploadを使用してもSourceMapsが削除されなかったので、CI上でホスティング前にSourceMapsを削除する処理を追加しました。

SourceMapsの導入することでコードの可読性が上がり、エラー調査がやりやすくなりました。

エラーの整理

大量に溜まっているエラーを整理するために、以下を実施しました。

エラー内容を確認し、恒久的に発生しないよう修正する
エラーの修正が難しい場合
- 重要度の低いエラーや発生頻度の低いエラーはPriorityを下げるか、一旦アーカイブする
- ノイズになる場合や発生頻度が高くクォーターを大量消費する場合は、Sentryに送信しないようにする
  - ライブラリ内で発生した例外は原因の特定が難しく、かつノイズになるので送信しないようにしました
  - 4xx系のエラーやネットワークエラーはノイズになるため、送信しないようにしました

エラーを恒久的に発生させないようにするのが最も良いので、1つ1つのバグを潰すような作業を1-2ヶ月かけて実施しました。
null(undefined)の値をメソッドチェーンで参照しようとして発生したエラーが多い印象でした。再現が難しく解決に時間を要するものもありました。

エラーを送信しないようにする方法

Sentryでエラーを送信しないようにする方法は2つあります。

エラーの送信前にフィルタリングするコードを書く(beforeSend)
Business plan以上の場合、Delete & Discardで画面上からエラーを送信しないようにできる

弊社はチームプランなので、エラー送信前にフィルタリングする方法を採用しました。

送信前のエラーに対して操作できるbeforeSend関数

第一引数がevent、第二引数がhintです。eventとhintの2つの引数があり、それぞれエラーやイベントなどの情報が入っています。
beforeSendを使って、送信前にエラーオブジェクトに対して操作できます(以下のコードは公式ドキュメントより引用

Sentry.init({
  dsn: "https://1e30cec9a9124eb6a66f70a799cee948@o360365.ingest.us.sentry.io/3631418",

  // Called for message and error events
  beforeSend(event) {
    // Modify or drop the event here
    if (event.user) {
      // Don't send user's email address
      delete event.user.email;
    }
    return event;
  },
});

エラーを送信しないようにするためには、beforeSendの戻り値をnullにします。

Sentry.init({
  dsn: "https://1e30cec9a9124eb6a66f70a799cee948@o360365.ingest.us.sentry.io/3631418",

  // Called for message and error events
  beforeSend(event) {
    // Modify or drop the event here
    if (event.user) {
      // Don't send user's email address
      delete event.user.email;
    }
    return null;
  },
});

beforeSendを使用して、特定のエラーのみ送信しないようにすることが可能です。
例えば、ノイズになるため4xx系のエラーやネットワークエラーは送信しないようにしました。

Sentry管理画面から見ることのできる情報

Issue一覧画面とIssue詳細画面をよく使用します

Issue

エラーはIssueと呼ばれます。Sentry管理画面のIssues画面から確認できます。
ステータスについては、Issueのステータス一覧に詳しい説明が記載されています。

新しいエラーが発生するとUnresolvedでIssueが作成されます。エラーを修正した場合は画面からResolvedにステータスを変更します。

緊急性が低いもの、またはノイズになるエラーはArchivedに変更します。Archivedにするとアラートを停止します。短時間に大量のエラーが発生するとEscalatingになります。

Issueを完全に削除した場合は、同様のエラーが再発すると新しいエラー扱いになります。

Issue Grouping

Sentryはエラーの類似性を評価し、同様のエラーを同じIssueにグルーピングしています。

fingerprint→stack trace→exception→messageの順でグルーピングに使用されます。後者に行くほどグルーピング精度は下がります。

どの方ほグルーピングされたかは、Issue詳細ページの一番下で確認できます。

Activity

Issueに対してコメント可能です。

Environments

環境tagを設定し、どの環境で発生したエラーか区別できます。

SDK初期化時に設定します。

Releases

ソースコードにバージョンをつけることができます。

どのバージョンのソースコードで発生したエラーか区別できます。

Session Replay

Session Replayを導入すると、ユーザーの行動(画面録画、ネットワークリクエスト、DOMイベントやコンソールログ)を記録し再生することができます。

エラーを手元で再現しやすくしたり、ユーザーが操作に戸惑っている箇所を確認しUI/UX向上に役立てることができます。

ユーザーのエラーの再現が今回の目的なので、エラー発生時のみSession Replayを記録するようにしました。

Set up

こちらを参考に、以下のような設定にしました。

import * as Sentry from "@sentry/vue";

Sentry.init({
  replaysSessionSampleRate: 0.0, // 正常時の記録は不要なので0.0

  replaysOnErrorSampleRate: 1.0, // エラーを記録したいので1.0

  integrations: [
    Sentry.replayIntegration({
      maskAllText: true, // テキストは個人情報を含むのでマスキング
      blockAllMedia: true, // img、svgやvideoなどは全て記録しない
      networkCaptureBodies: false // リクエスト・レスポンスボディは記録しない
    }),
  ],
});