Emit 'busy_threads' as 'workers.busy_threads'

[pifantastic]

Puma reports the number of threads currently serving requests as busy_threads. This exposes it as a workers.busy_threads metric, alongside the existing workers.spawned_threads and workers.max_threads.

It's a useful signal on its own: spawned_threads tells you how many threads exist, but not how many are actually doing work. Together with queue.capacity it makes saturation directly visible rather than something you infer.

Puma version handling

Puma only added the busy_threads stat in 6.6, and this gem's dependency is puma < 9 with no lower bound. Rather than raising the floor, the metric is version-aware:

• On puma >= 6.6 it's part of DEFAULT_PUMA_TELEMETRY, so it's published out of the box.
• On older puma it's dropped from the defaults, so nothing changes for those users.
• Selecting it explicitly on an older puma raises a Puma::Plugin::Telemetry::Error that names the required version, instead of silently publishing a metric that is always 0.

The puma dependency in the gemspec is unchanged.

Notes

• Both WorkerData (single mode) and ClusteredData (clustered mode, summed across workers) are covered.
• The integration specs assert that workers.busy_threads is present rather than pinning its value, since it depends on what the server happens to be doing when telemetry is published.
• Metrics/ModuleLength is now excluded for spec/**/*, matching the existing exclusions for Metrics/BlockLength and Metrics/ClassLength.

bundle exec rake passes: 65 examples, 0 failures (1 pending — the socket telemetry spec, which is skipped on macOS), RuboCop clean.

🤖 Generated with Claude Code