Sentry Rails: initializer, gems, and the relative profile rate

# Sentry Rails: initializer, gems, and the relative profile rate

## Setup

```ruby
# Gemfile
gem "sentry-ruby"
gem "sentry-rails"
gem "stackprof" # only if you want profiling
```

```ruby
# config/initializers/sentry.rb
Sentry.init do |config|
  config.dsn = '___PUBLIC_DSN___'
  config.breadcrumbs_logger = [:active_support_logger, :http_logger]
  config.traces_sample_rate = 0.1 # docs example is 1.0; adjust for production
  config.profiles_sample_rate = 1.0 # relative to traces_sample_rate, not absolute
end
```

## profiles_sample_rate is relative

This is the trap: `profiles_sample_rate = 1.0` does not mean profile everything. It means profile 100% of sampled traces. With `traces_sample_rate = 0.1` you get profiles for ~10% of requests. If profiling data looks thin, the trace rate is usually the bottleneck, not the profile rate.

## Ruby defaults to restrictive data collection

Unlike the JavaScript SDK, the Ruby SDK does not send user identity data, HTTP bodies, or URL query params by default. You opt in per category with the `data_collection` option. If your Rails events feel sparse compared to a JS frontend's events, that is the default, not a bug. Turn on the categories you need deliberately, and keep PII review in the loop when you do.

## Verify

Raise in a controller action and hit it through a real request. Then check the issue stream. Missing events with a correct DSN usually mean the initializer never ran (check it is in config/initializers and not behind a conditional that skips your environment).