feat(instrumentation-runtime-node)!: add prom-client-metrics

[pikalovArtemN]

Which problem is this PR solving?

• Make a part of request in Runtime instrumentation #1106

Short description of the changes

• Add implementation for collecting event loop lag, garbage collector, heap size and heap space

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: pikalovArtemN / name: LowArt (fd8d803, 3cba596, dbb34ff, 926f052, 54858de, 046072e, 7418c78, 2cd9093, 5121a0b, 460003f, d99c458, fdfea51, 6506489, a69fc5c, 247403e, 922d677, ade0ab9, 012f370, d7c5108, ed6596f, 5efdd9d, 8bf14b5, 184be5e, 184b212, 43ba51c, 7a98bfd, 6a84254, 2d31e98, 97d8d92, 6b5fc8b, ad88f98, 310a2b2, b663012, cab7e6c)
• ✅ login: david-luna / name: David Luna (2189d51, feb3f36, 4941407, a6a9e81)

[maryliag]

curious about this change, can you give more context why the rename?

[pikalovArtemN]

Because right now i use it for every metrics, not only for eventLoopUtilization. You think I needed to add parameters for every new metrics group ?

[maryliag]

No need

[JCMais]

I am super excited for this one, I think it was the main thing missing from OpenTelemetry's Node.js instrumentation! Thanks for opening this PR.

[dyladan]

Can you please take a look at open-telemetry/semantic-conventions#991 and give your input there? It looks like you made some different decisions than what was made there and I want to make sure we're all on the same page before merging something.

[pikalovArtemN]

Can you please take a look at open-telemetry/semantic-conventions#991 and give your input there? It looks like you made some different decisions than what was made there and I want to make sure we're all on the same page before merging something.

Thanks. Yes, i have some mismatches.

[maryliag]

@pikalovArtemN I would love to hear your opinion on the mismatches. Let me know what you think makes more sense 😄

[pikalovArtemN]

@pikalovArtemN I would love to hear your opinion on the mismatches. Let me know what you think makes more sense 😄

I have mismatches in names like eventloop => event_loop, and i need to fix units, i totaly forgot to set it properly XD. And fix attributes.

I decided to devide the metrics not by label, but names like it was in the prom-client library, but i think you do a better solution in the convension.

I think we need to colobarate, not all of metrics and attributes that i added exists in convention such as:

1. attribute nodejs.eventloop.lag.type -> stddev and mean not exists
2. nodejs.eventloop.utilization metric does't exist in specification
3. nodejs.active_handles.count -> does't exist in runtime-node, do i need to add it ?
4. nodejs.memory.size -> i have 2 splited metrics heap size and heap space, i think we need to split it by memory, heap size, and heap space in different metrics with attributes nodejs.memory.state: (total and used), nodejs.heapsize.state (total and used), nodejs.heapspace.state( total, used, available) and i add nodejs.memory.size in instumentation-runtime-node
5. nodejs.active_libuv_requests.count -> does't exist in runtime-node, do i need to add it ?

[maryliag]

attribute nodejs.eventloop.lag.type -> stddev and mean not exists

I can add that

nodejs.eventloop.utilization metric does't exist in specification

I can add that

nodejs.active_handles.count -> does't exist in runtime-node, do i need to add it ?

I think it would be good, I got that from the prom-client metrics list, so should be possible

nodejs.memory.size -> i have 2 splited metrics heap size and heap space, i think we need to split it by memory, heap size, and heap space in different metrics with attributes nodejs.memory.state: (total and used), nodejs.heapsize.state (total and used), nodejs.heapspace.state( total, used, available) and i add nodejs.memory.size in instumentation-runtime-node

I can make those changes on the convention

nodejs.active_libuv_requests.count -> -> does't exist in runtime-node, do i need to add it ?

I think it would be good, I also got that from prom-client, but it doesn't have libuv in the name, I added on the convention because of a feedback to make it more clear what it is

[maryliag]

heads up: because the semantic convention could be for all JS runtime (not just nodejs, but also others such as denojs or bunjs), it was suggested to not use nodejs on the metric name, so I replaced with jsruntime. I'm still waiting on more feedback if people think that is a good name, but that means you would also probably need to make the same update here

[pikalovArtemN]

heads up: because the semantic convention could be for all JS runtime (not just nodejs, but also others such as denojs or bunjs), it was suggested to not use nodejs on the metric name, so I replaced with jsruntime. I'm still waiting on more feedback if people think that is a good name, but that means you would also probably need to make the same update here

Ok

[Flarna]

If it is about any js runtime the node.js specific parts should be removed/renamed/...

• anything coming from v8 is not automatically applicable to js engine in firefox or safari
• browsers do not use libuv as far as I know (not sure about bun either)

[maryliag]

anything coming from v8

I don't understand what you mean here.

For things that are node specific, we can still create the metrics for it, such as the active libuv requests, I just need remove that from the semantic convention, but this PR can still keep it because can be useful.
This way we can move comments about the semantic convention to that PR, to keep things in one place

[Flarna]

There are JS engines (e.g. quickjs) which use a different heap structure/gc then google v8 (the JS engine used by node.js or deno).
The proposed gc/heap metrics match fine to node.js because it uses v8 but they might not fit well to other JS engines.

As a result I'm not sure if GC metrics should have v8 in the name to allow to distinguish them from other engines.
Alternative would be to create universal gc metrics for all types of runtimes using a gc. But I doubt that will be easy.

[pikalovArtemN]

I think right now we need to concentrate on nodejs realization only, because Node is most popular and in the next iteration adopt instrumentation to work with different engines. Right now it's so much work to do

[david-luna]

@pikalovArtemN

now I've noticed the package-lock.json file seems to be out of sync with too many changes although you made a small one in you package.json. That explains the installation issues.

Please get the latest version of package-lock.json file from main branch and run npm i from the root folder to add your small update. Push the changes and I'll run the CI again :)

[codecov]

Codecov Report

Attention: Patch coverage is 87.70950% with 22 lines in your changes missing coverage. Please review.

Project coverage is 90.79%. Comparing base (6234918) to head (4941407).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
...umentation-runtime-node/src/metrics/gcCollector.ts	72.00%	7 Missing ⚠️
...entation-runtime-node/src/metrics/baseCollector.ts	66.66%	4 Missing ⚠️
...untime-node/src/metrics/eventLoopDelayCollector.ts	93.47%	3 Missing ⚠️
...nstrumentation-runtime-node/src/instrumentation.ts	90.00%	2 Missing ⚠️
...runtime-node/src/metrics/eventLoopTimeCollector.ts	90.47%	2 Missing ⚠️
...-node/src/metrics/eventLoopUtilizationCollector.ts	88.23%	2 Missing ⚠️
...node/src/metrics/heapSpacesSizeAndUsedCollector.ts	94.11%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2136      +/-   ##
==========================================
- Coverage   90.86%   90.79%   -0.07%     
==========================================
  Files         161      169       +8     
  Lines        7858     8009     +151     
  Branches     1612     1632      +20     
==========================================
+ Hits         7140     7272     +132     
- Misses        718      737      +19     

Files with missing lines	Coverage Δ
...trumentation-runtime-node/src/consts/attributes.ts	100.00% <100.00%> (ø)
...n-runtime-node/src/types/ConventionalNamePrefix.ts	100.00% <100.00%> (ø)
...nstrumentation-runtime-node/src/instrumentation.ts	89.65% <90.00%> (+0.46%)	⬆️
...runtime-node/src/metrics/eventLoopTimeCollector.ts	90.47% <90.47%> (ø)
...-node/src/metrics/eventLoopUtilizationCollector.ts	88.23% <88.23%> (ø)
...node/src/metrics/heapSpacesSizeAndUsedCollector.ts	94.11% <94.11%> (ø)
...untime-node/src/metrics/eventLoopDelayCollector.ts	93.47% <93.47%> (ø)
...entation-runtime-node/src/metrics/baseCollector.ts	66.66% <66.66%> (ø)
...umentation-runtime-node/src/metrics/gcCollector.ts	72.00% <72.00%> (ø)

[maryliag]

@dyladan you still have a request here, which was already addressed, can you take a look again?

[david-luna]

@dyladan is seems you need to approve since previously requested changes in this PR.

[dyladan]

I assume these are just temporary until the next semconv release?

[maryliag]

actually, they already exist on the current release (they didn't when the PR was created), so @pikalovArtemN you can replace for the final values. For example, this one is ATTR_V8JS_HEAP_SPACE_NAME

[pikalovArtemN]

fix

[david-luna]

@pikalovArtemN this is almost done :)

could you fix the conflicts and address the last comment from @maryliag? Thank you

[kristian240]

suggestion(non-blocking): update the default

You changed the default to 10 so we should update the README too

Suggested change

	| [`monitoringPrecision`](./src/types.ts#L25) | `int` | millisecond | `5000` | The approximate number of milliseconds for which to calculate event loop utilization averages. A larger value will result in more accurate averages at the expense of less granular data. Should be set to below the scrape interval of your metrics collector to avoid duplicated data points. |
	| [`monitoringPrecision`](./src/types.ts#L25) | `int` | millisecond | `10` | The approximate number of milliseconds for which to calculate event loop utilization averages. A larger value will result in more accurate averages at the expense of less granular data. Should be set to below the scrape interval of your metrics collector to avoid duplicated data points. |

[kristian240]

Fixed in 6b5fc8b

[kristian240]

@david-luna any idea how fast this can be released after it is merged?

[maryliag]

@kristian240 after this gets merged, we can aim for a new relase in a couple of days 😄

[trentm]

minor Q: It looks like the default is 10 ms (from lower down in this README). Should the example here show 10 rather than 5000?