feat(active-job): Add performance metrics to process span

[bdewater-thatch]

Record cpu_time, idle_time, gc_time, and allocations as span attributes on the perform.active_job process span, mirroring the metrics that ActiveSupport::Notifications::Event captures internally.

We don't get these for free because these are only captured on the EventObject path (ActiveSupport::Notifications.subscribe('perform.active_job') { |event| ... }) where OTel uses the Evented path instead (fanout.rb).

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: bdewater-thatch / name: Bart de Water (44dded4)

[thompson-tomo]

As a first point of discussion I am not sure if we should be adding them as attributes on the span. Creating them as metrics seems more appropriate.

[bdewater-thatch]

@thompson-tomo thanks for having a look. IMO it is useful to know for a specific job execution what these numbers are, as well as seeing them in aggregate. TIL about exemplars

I can add (or complete change over to metrics, but I didn't see any examples in this repo to work from. I did find a bunch of old pull requests but I'll need to know what the desired direction is.

[arielvalentin]

@bdewater-thatch thanks for this contribution.

This is not the first time someone has requested or submitted a PR to add Rails internal measurements as span attributes.

Although I agree that the Rails internal measurements should be derived from existing spans, I find there is mixed messaging in the spec about recording metric type values on span attributes.

E.g. database batch size and response return rows or HTTP body size, resend count but you can also record any arbitrary HTTP header.

They seem to draw the line on latency attributes, which would very likely be more interesting and familiar to Rails users.

I used to be much more opinionated that these Rails measured performance values should not be added as span attributes but not I'm not so sure.

As a compromise here I'd like to offer up a suggestion that allows users the option to opt-in level:

https://opentelemetry.io/docs/specs/semconv/general/attribute-requirement-level/

I haven't looked at how other SDKs are implementing opt-in yet but I think this is a good use case for us to consider with the caveat that there may be a need to have more complex configurations and these attributes would be absent by default.

[bdewater-thatch]

On today's SIG call we discussed this PR and agreed to an opt-in, I'll work on that this week.