feat(metrics): report scheduler utilization in runtime metrics

[solnic]

Adds elixir.runtime.scheduler.utilization, a number between 0.0 and 1.0 for how much of the VM's capacity to run code is actually in use. 0.0 is idle, 1.0 means there is no headroom left.

In practical terms, this will show you how busy the VM's main worker threads were - running application code plus the runtime's own work (GC, memory management, drivers, BIFs) - excluding time blocked on I/O.

Screenshot

If this is close to 1.0 very often for significant periods, you may want an alert set up.

[sentry]

Bug: The dispatch_utilization/2 function is missing a guard for an empty previous argument, which can cause a spurious 0.0 metric to be emitted on the first successful sample.
_{Severity: LOW}

Suggested Fix

Add a function clause to dispatch_utilization/2 to handle cases where the first argument is an empty list, preventing the incorrect metric calculation. For example: defp dispatch_utilization([], _current), do: :ok.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: lib/sentry/metrics/runtime.ex#L113-L122

Potential issue: The `dispatch_utilization/2` function does not handle cases where the
`previous` sample is an empty list but the `current` sample is not. This can occur if
the first call to `scheduler_sample()` returns `[]` (due to
`:erlang.statistics(:scheduler_wall_time)` returning `:undefined` initially) and a
subsequent call returns valid data. In this scenario, `Enum.zip([], current_data)`
results in an empty list, the reduce operation defaults to `{0, 0}`, and `ratio(0, 0)`
calculates `0.0`. This leads to a spurious `0.0` utilization metric being emitted for a
single polling cycle before normal operation resumes.

Also affects:

• lib/sentry/metrics/runtime.ex:96~102

_{Did we get this right? 👍 / 👎 to inform future reviews.}