はじめに
プラットフォーム部 SREチームのショウゴ(@shogo_452)です。 最近、TUNAGの新たなエラー監視ツールとして「Sentry」を導入しました。 本記事では、Railsアプリケーションに対するSentryの導入事例について紹介します。
初期設定
まずは、sentry-ruby
とsentry-rails
というGemをインストールします。
Sidekiqを使用している場合は、sentry-sidekiq
も必要です。
gem 'sentry-ruby' gem 'sentry-rails' gem 'sentry-sidekiq'
次に設定ファイルです。config/initializers/sentry.rb
という設定ファイルを作成し、設定を行います。
この設定まで行えば、基本的なエラーの検知が可能となります。
Sentry.init do |config| config.enabled_environments = %w(production staging) config.dsn = 'https://xxxxxxx.ingest.sentry.io/xxxxxxx' config.breadcrumbs_logger = [:sentry_logger, :active_support_logger, :monotonic_active_support_logger, :http_logger] config.sample_rate = 1 config.traces_sample_rate = 0.1 config.send_default_pii = true config.environment = Rails.env config.include_local_variables = true end
include_local_variables
はローカル変数の値の情報を送ることができます、また、traces_sample_rate
はトランザクションのサンプリング率の設定オプションなのですが、
ドキュメント通りに「1」と設定するとサンプリング率100%となり、AWSのNATゲートウェイを使用している環境の場合は、外部通信の通信量が大幅に増え、通信コストが大きく増える可能性があるため注意が必要です。
詳細設定
任意のイベントを送りたい場合は、capture_message
を使用します。levelは、:fatal
, :error
, :warning
, :log
, :info
, :debug
の6種類が使用できます。
Sentry.capture_message("Message", level: :error)
rescueしている箇所で例外の情報を送りたい場合は、capture_exception
を使用します。
begin # Process A rescue StandardError => e Sentry.capture_exception(e) # Process B end
set_tags, set_user, set_contextなどを用いるとデバッグ時に有用な情報を送ることができます。
set_tags
は、Sentryの標準のタグに加えてタグ付けをカスタマイズすることができます。
TUNAGでは複数台のステージングの識別のためにタグ付けをしたり、アラームの設定用にbooleanの値でタグ付けしています。
Sentry.set_tags(staging_no: ENV['STAGING_NO']&.to_i) if Rails.env.staging?
set_user
は、id, username, email, ip_addressの4種類の情報を送ることができ、影響を受けているユーザー数や傾向の分析に役立てれます。
Sentry.set_user(id: current_user.id)
set_context
は、任意の情報をkey, valueの形式で送ることができ、デバッグに必要になる情報を送る際に便利です。
Sentry.configure_scope do |scope| scope.set_context( 'user_details', { user_status: current_user.status, tenant_id: curernt_tenant.id } ) end
Slack連携とアラートの整備
Sentryは、Slackとの連携可能でアラートの通知をSlackに送ることができます。
TUNAGでは、主に下記の4つのアラートを設定しています。
- Issueの発行
- エラー件数の閾値超過
- 影響を受けているユーザー数の閾値超過
- 直近のリリースが原因のエラーの発生
閾値もCritical Conditions
とWarning Conditions
の2段階で設定できるため、緊急性の判断がしやすいのも特徴的です。
CircleCIとの連携によるRelease Managementの活用
Sentryは、CircleCIと連携させることができ、リリース単位でエラーをトラッキングすることができます。
下記がCircleCIのconfigファイルの抜粋です。
jobs: notify-sentry-deploy: executor: deploy environment: SENTRY_ORG: OrganizationName SENTRY_PROJECT: Project Name SENTRY_ENVIRONMENT: Environment steps: - run: name: Create release and notify Sentry of deploy command: | curl -sL https://sentry.io/get-cli/ | bash sentry-cli releases new -p $SENTRY_PROJECT $CIRCLE_SHA1 sentry-cli releases set-commits $CIRCLE_SHA1 --commit "own-repo@$CIRCLE_SHA1" sentry-cli releases finalize $CIRCLE_SHA1 sentry-cli releases deploys $CIRCLE_SHA1 new -e $SENTRY_ENVIRONMENT workflows: deploy_ecs_production: jobs: - build_tunag_production_image: filters: branches: only: main - notify-sentry-deploy: filters: branches: only: main requires: - build_tunag_production_image
CirlceCIの環境変数の CIRCLE_SHA1
を用いるようにし、checkoutの時間を省略するようにしました。
この設定により、下図のようにリリース単位でエラーの発生をトラッキングできるようになり、 最新のリリースが原因のエラーが発生した場合のアラートの設定もできるようになりました。
運用
運用を開始するにあたり、下記のドキュメントを整備しました。
ドキュメント①:Sentryの運用方針
- 導入背景
- プロジェクトの切り方
- Issueのステータスの説明
- 通知用のSlackチャットルームの命名規則
- 必須設定のアラート etc.
ドキュメント②:プロジェクト個別のIssueのトリアージ手順
- 分担
- 新規発行されたIssueのトリアージ
- アラート対応 etc.
また、週1回のSentryデーという日を設けて棚卸しを行うことを始めました。 トリアージ漏れのIssueの処理、Issueのマージ、アラートの閾値の見直しを行っています。
運用を始めたばかりなので、まだ上手く回っていないところもあるため、 今後の改善を模索しています。
今後について
Sentryでできることが把握でき、運用方針をまとめることができたため、 今後はTUNAGのフロントエンドや他のプロダクトへの横展開を今後進めていきます。 また、まだまだ活用できていないSentryの機能があるため、それらを活用して効率が良く漏れの無いエラー監視ができる仕組み作りをしていきたいです。
まとめ
本記事では、Railsアプリケーションに対するSentryの導入事例について紹介しました。
最後に、スタメンではエンジニアを募集しています。興味をもっていただけましたら、ぜひ下記からご応募ください。