フロントエンドからバックエンドまで一貫してSentryを活用

ツール導入前の課題

新規事業のサービスでサーバのログだけを収集しており、ブラウザやサーバーでエラーが発生した時に直ぐに検知できる仕組みがなかった。

また、フロントエンドやサーバサイドのパフォーマンスについてもモニタリングできる仕組みがなかった。

どのような状態を目指していたか

アプリケーションでエラーが発生した時にSlackへアラートが通知され不具合や障害が検知できること。

サービスのパフォーマンスが良好な状態に保てること。

• Datadog Error Tracking

• 管理画面の使いやすさ
• 導入の手軽さ
• 利用料金

• 導入の手軽さ
• 充実したエラートラッキングとトレース
• Slackへのアラート通知

改善したかった課題はどれくらい解決されたか

フロントエンド、サーバの両方でエラーが発生した際に、Slackへアラートの通知から直ぐに気が付ける体制ができた。 さらに、エラーが発生した時の調査も分散トレーシングにより、原因を調査しやすくなった。

また、フロントエンドのパフォーマンスを実際のユーザのブラウザからWeb Vitalsのスコアが収集されているので、これを元にユーザ体験が良いかをモニタリングできている。

料金プランについても既にTeamプランで契約をしていたが、エラー数やスパンの従量制の料金を上げる必要があった。

また、Next.jsとRailsの両方にSentryを導入し分散トレーシングを活用している。 これを全てのリクエストで行うと料金が高くなるので、割合でサンプリングをするよう設定をしている。

ただ、RailsのSentryの設定にサンプルレートを指定しても、反映されず原因の特定に苦労した。 調査の結果、Sentryの分散トレーシングでは"head-based"というアプローチでサンプリングが決定しており、前段のNext.jsでサンプルレートを設定する必要があった。

https://docs.sentry.io/concepts/key-terms/tracing/distributed-tracing/#consistency-within-a-trace

エラートラッキングからトレースまで一つのSDKで実現できるので、小規模なプロジェクトでも手軽に始めることができます。

スロークエリーやバックエンドのトレースを含めたパフォーマンス機能の活用を考えている。