feat(perf_hooks): add node instrumentation perf_hooks

[d4nyll]

Which problem is this PR solving?

#1106 - currently there is no Otel way to expose metrics provided by the Node.js runtime

(...continuation from #1272 and #1689)

Description of changes

This PR adds a @opentelemetry/instrumentation-perf-hooks package that exposes the utilization measurement from Node.js Performance measurement APIs' performance.eventLoopUtilization method.

The exposed metric will look something like this:

# HELP nodejs_performance_event_loop_utilization Event loop utilization
# UNIT nodejs_performance_event_loop_utilization 1
# TYPE nodejs_performance_event_loop_utilization gauge
nodejs_performance_event_loop_utilization 0.010140079547955264

Notes / Questions

• I've named this package @opentelemetry/instrumentation-perf-hooks as this initial version only exposes one metric. Happy to use @opentelemetry/instrumentation-runtime but that implies a bigger scope than what this PR does.
• The exposed metric is called nodejs.performance.event_loop.utilization, but perhaps nodejs.event_loop.utilization is sufficient?

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: d4nyll / name: Daniel Li (ed5a7be, c2fa8be, e8e81a7, c3aec39, a46448c, 69d8901, 0f643bf, 9fdcf08, 0ecc3e4, 1d17f12, d585607, 193ea77, 928f8ac, c0ef756, 18299f7, dfe2840, 624d779, 1b13e4c)
• ✅ login: pichlermarc / name: Marc Pichler (15028c0)

[pichlermarc]

Referring to the question from the PR body, I think omitting performance should be just fine 🙂

Suggested change

	.createObservableGauge('nodejs.performance.event_loop.utilization', {
	.createObservableGauge('nodejs.event_loop.utilization', {

[pichlermarc]

Thanks for working on this 🙂

[codecov]

Codecov Report

Merging #1902 (15028c0) into main (a7861f6) will increase coverage by 0.04%.
The diff coverage is 100.00%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1902      +/-   ##
==========================================
+ Coverage   91.00%   91.04%   +0.04%     
==========================================
  Files         146      147       +1     
  Lines        7493     7530      +37     
  Branches     1503     1507       +4     
==========================================
+ Hits         6819     6856      +37     
  Misses        674      674              

Files	Coverage Δ
.../instrumentation-perf-hooks/src/instrumentation.ts	100.00% <100.00%> (ø)

[d4nyll]

Updated to fix the failed release-please-config and peer-api-checks workflows

[d4nyll]

I believe the unit-test (18.18.2) failed due to the test being flakey (c0ef756 should have fixed it)

However, I am struggling to see why unit-test (14) hangs and I don't see any test output. (would 928f8ac have fixed it? It's currently passing on my machine using Node.js v14.21.3)

@pichlermarc can we run the tests again?

[d4nyll]

@pichlermarc Hey, just want to double check if there are still changes that needs addressing, or we are just waiting for this to be included in the next release. Should I keep merging/resolving conflicts (which will cause the tests to be rerun) or just leave it be? Thanks

[pichlermarc]

@pichlermarc Hey, just want to double check if there are still changes that needs addressing, or we are just waiting for this to be included in the next release. Should I keep merging/resolving conflicts (which will cause the tests to be rerun) or just leave it be? Thanks

Sorry for the delay. I should've merged it long ago. Running tests again and then this should be good to merge.

[trentm]

(Sorry this Q comes after this is reviewed and merged.)

Is this something that needs to be implemented as an instrumentation? Could it not be something like host-metrics (https://github.com/open-telemetry/opentelemetry-js-contrib/blob/main/packages/opentelemetry-host-metrics/README.md#usage) where one separately creates and starts it after a MeterProvider has been registered (via using NodeSDK or whatever). IIUC, this isn't actually instrumenting perf_hooks, but just using it.

[d4nyll]

IIUC, this isn't actually instrumenting perf_hooks, but just using it.

Yes, this is only using perf_hooks but not instrumenting the perf_hooks Node.js API.

Is this something that needs to be implemented as an instrumentation?

The purpose of the package is to export metrics exposed by the Node.js runtime. I see similar packages in other languages (e.g. Go) exposing the language runtime internals implemented as instrumentation packages.

If it is a matter of naming, I would be happy for it to be renamed to @opentelemetry/instrumentation-runtime.

If it is a matter of whether it should be a non-instrumentation package, I would need more guidance from the maintainers as to the distinction between an 'instrumentation' package and other types of packages. From my perspective, yes, it could work as a package similar to @opentelemetry/host-metrics

[trentm]

@d4nyll Thanks. I moved my Q to a new issue (#1956) so this doesn't get lost on a merged PR.