Add runtimemetrics instrumentation

[jmacd]

Revival of #316
Part of #2624

My team has been looking at Golang runtime instrumentation and specifically are interested in access to runtime/metrics, which addresses the problem described in #316. As an example, with this instrumentation and any modern Go runtime, we get a process.runtime.go.cpu.time metric with attributes like

      class=gc,class2=mark,class3=assist
      class=gc,class2=mark,class3=dedicated
      class=gc,class2=mark,class3=idle
      class=gc,class2=pause
      class=scavenge,class2=assist
      class=scavenge,class2=background
      class=idle
      class=user

This allows you to construct graphs comparing the total for class=gc with the sub-total for class3=assist, which is an indicator of relatively bad GC performance.

This code was forked from https://github.com/lightstep/otel-launcher-go/tree/main/lightstep/instrumentation/runtime.

[codecov]

Codecov Report

Attention: Patch coverage is 74.91289% with 72 lines in your changes missing coverage. Please review.

Project coverage is 81.4%. Comparing base (6027a45) to head (3477335).
Report is 73 commits behind head on main.

Files with missing lines	Patch %	Lines
instrumentation/runtimemetrics/builtin.go	55.5%	48 Missing and 4 partials ⚠️
instrumentation/runtimemetrics/descriptor.go	85.7%	18 Missing and 2 partials ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #7499     +/-   ##
=======================================
- Coverage   82.3%   81.4%   -1.0%     
=======================================
  Files        205     201      -4     
  Lines      17967   18250    +283     
=======================================
+ Hits       14797   14862     +65     
- Misses      2734    2983    +249     
+ Partials     436     405     -31     

Files with missing lines	Coverage Δ
instrumentation/runtimemetrics/defs.go	100.0% <100.0%> (ø)
instrumentation/runtimemetrics/descriptor.go	85.7% <85.7%> (ø)
instrumentation/runtimemetrics/builtin.go	55.5% <55.5%> (ø)

... and 16 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[dashpole]

I haven't reviewed closely, but have a few questions: How do you see this relating to the ones we defined in semconv: https://opentelemetry.io/docs/specs/semconv/runtime/go-metrics/?

• Are they complementary or supplementary?
• When would someone use one vs the other?
• Is there any way for us to achieve our goals with a single instrumentation library, or do we need both as separate libraries?

[jmacd]

@dashpole I understand your questions, and they are ones I have tried to avoid. This library represents a literal translation from an existing thing into the OTel model, so these are not OTel semantic conventions. I would be glad to change the prefix used, if you think that will help.

Are they complementary or supplementary?

I would call this instrumentation independent: definitely supplementary, possibly duplicative. I like the idea of a straightforward integration allowing us to expose the Go teams' metrics without these questions getting in the way.

When would someone use one vs the other?

I would replace the instrumentation/runtime library with this one for my own uses. I do not care for the existing OTel semantic conventions, I care for what the Go-team gives me verbatim.

Is there any way for us to achieve our goals with a single instrumentation library, or do we need both as separate libraries?

Probably. If someone could tell me what to do, I'll do it. (What should I do?)

[jmacd]

To be clear, the new semantic conventions will be updated in the go-contrib/instrumentation/runtime package?
That is all I wanted to ensure, so that we can have these metrics in the collector by default.
Thank you!