SentryやNew Relicを使ったエラー監視とパフォーマンスモニタリング

Railsアプリケーションを本番環境で運用する上で、「何も問題が起きていないこと」を確認し、問題が発生した際には迅速に検知・対応することは非常に重要です。ユーザーがエラー報告をしてくれるのを待っていたり、サーバーにログインして手動でログファイルをgrepしたりするのは、現代的な運用方法とは言えません。

そこで不可欠となるのが、**エラー監視（Error Tracking）とアプリケーションパフォーマンスモニタリング（APM）**のツールです。

この記事では、この分野で代表的なSaaSであるSentryとNew Relicを中心に、これらのツールがどのようにRailsアプリケーションの安定運用を支えるのかを解説します。

エラー監視 (Error Tracking) - Sentry

Sentryは、アプリケーションで発生した例外（エラー）をリアルタイムで収集、集約、通知してくれるサービスです。

なぜエラー監視が必要か？

プロアクティブな問題発見: ユーザーが気づく前に、開発者がエラーの発生を検知できます。
詳細なコンテキスト: エラーが発生した際のスタックトレース、リクエストパラメータ、セッション情報、ブラウザのバージョンなど、デバッグに必要な情報が自動的に収集されます。
エラーの集約と管理: 同じ種類のエラーは一つにまとめられ（グルーピング）、発生頻度や影響を受けたユーザー数で優先順位付けができます。「修正済み」「無視」といったステータス管理も可能です。
アラート通知: 新しいエラーが発生したり、特定のエラーが急増したりした際に、Slackやメールで即座に通知を受け取れます。

RailsでのSentryの使い方

sentry-rubyとsentry-rails gemをインストール
ruby
```
# Gemfile
gem 'sentry-ruby'
gem 'sentry-rails'
```

イニシャライザを作成

Sentryのプロジェクト設定ページで取得できるDSN（Data Source Name）を使って、イニシャライザを設定します。

ruby

# config/initializers/sentry.rb
Sentry.init do |config|
  config.dsn = 'https://examplePublicKey@o0.ingest.sentry.io/0'
  config.breadcrumbs_logger = [:active_support_logger, :http_logger]

  # パフォーマンスモニタリングの設定（後述）
  config.traces_sample_rate = 0.5
end

これだけで、Railsアプリケーションで未捕捉の例外が発生すると、自動的にSentryにレポートが送信されるようになります。

パフォーマンスモニタリング (APM) - New Relic

New Relicは、エラー監視に加えて、アプリケーションのパフォーマンスに関するあらゆる側面を可視化してくれる、より包括的なAPMツールです。（SentryにもAPM機能はありますが、伝統的にNew Relicがこの分野のリーダーです）

なぜAPMが必要か？

アプリケーションがエラーを起こしていなくても、「遅い」というだけでユーザー体験は著しく損なわれます。APMは、その「遅さ」の原因を特定するのに役立ちます。

トランザクションの可視化: 個々のリクエスト（トランザクション）が、どの処理（DBクエリ、外部API呼び出し、Rubyのコード実行）にどれだけ時間を費やしているかを詳細にブレークダウンして表示します。
N+1問題の検出: 非効率なデータベースアクセス（特にN+1クエリ）を自動で検出し、改善箇所を特定します。
Apdexスコア: 業界標準の指標であるApdexスコアを用いて、ユーザーの満足度を客観的に評価します。
インフラ監視: CPU使用率、メモリ使用量、サーバーの負荷なども合わせて監視できます。
フロントエンド監視: JavaScriptのエラーや、ページの描画速度（Core Web Vitals）など、ユーザーのブラウザ側でのパフォーマンスも計測できます。

RailsでのNew Relicの使い方

newrelic_rpm gemをインストール
ruby
```
# Gemfile
gem 'newrelic_rpm'
```

設定ファイルの生成

New Relicのサイトで取得したライセンスキーを使って、設定ファイルを生成します。

bash

# Gemをインストール後、Railsルートで
cp node_modules/newrelic/newrelic.js newrelic.js # for browser monitoring

実際には、newrelic.ymlをconfig/ディレクトリに配置し、ライセンスキーやアプリケーション名を設定します。

yaml

# config/newrelic.yml
common: &default_settings
  license_key: 'YOUR_LICENSE_KEY'
  app_name: My Rails App
  # ...

production:
  <<: *default_settings
  monitor_mode: true

newrelic_rpm gemは、Railsアプリケーションの起動時に自動的に各種ライブラリ（Active Record, Net::HTTPなど）に計装（instrumentation）を行い、パフォーマンスデータの収集を開始します。

Sentry vs New Relic: どう選ぶか？

	Sentry	New Relic
主な焦点	エラー監視	パフォーマンス監視 (APM)
強み	詳細なエラーコンテキスト、優れたUI、グルーピング精度	詳細なトランザクション分析、N+1検出、インフラ監視
価格	比較的安価（エラーイベント数ベース）	比較的高価（データ転送量やユーザー数ベース）
始めやすさ	非常に簡単	やや設定項目が多い

一般的な選択指針:

スタートアップや小規模チーム: まずはSentryから導入するのがおすすめです。エラー監視はすべてのアプリケーションにとって必須であり、Sentryは手軽に始められ、コストも抑えられます。Sentryの基本的なAPM機能で十分な場合も多いです。
パフォーマンスが重要な大規模サービス: アプリケーションの速度がビジネスに直結するようなサービスや、複雑なパフォーマンス問題を抱えている場合は、New Relicの導入を検討する価値があります。その詳細な分析能力は、ボトルネックの特定において非常に強力です。

両方のツールを併用する（Sentryでエラー監視、New RelicでAPM）という選択も一般的です。

まとめ

本番環境の運用において、推測で行動するのは危険です。SentryやNew Relicのようなツールは、アプリケーション内部で何が起きているかを客観的なデータとして示してくれる「計器」です。

Sentryは、エラーという「事故」を即座に知らせ、原因究明を助けてくれる。
New Relicは、アプリケーションの「健康状態（パフォーマンス）」を常に監視し、病気の兆候を教えてくれる。

これらのツールに投資することは、開発者のデバッグ時間を削減し、ユーザー体験を向上させ、ビジネスの安定性を高める上で、非常に費用対効果の高い活動です。まだ導入していないのであれば、無料プランからでも始めてみることを強くお勧めします。

SentryやNew Relicを使ったエラー監視とパフォーマンスモニタリング ​

エラー監視 (Error Tracking) - Sentry ​

なぜエラー監視が必要か？ ​

RailsでのSentryの使い方 ​

パフォーマンスモニタリング (APM) - New Relic ​

なぜAPMが必要か？ ​

RailsでのNew Relicの使い方 ​

Sentry vs New Relic: どう選ぶか？ ​

まとめ ​