bump @opentelemetry/auto-instrumentations-node to allow enabling only selected instrumentations via env

[atsu85]

Description:

• Updated only @opentelemetry/auto-instrumentations-node version, so it would contain PR that allows enabling selected instrumentations via environment variable.
• Motivation: application startup is super-slow when all instrumentations are enabled

Link to tracking Issue(s):

• Resolves: Allow disabling nodejs auto-instrumentations via environment variables #2622 (but allows enabling/disabling any instrumentation, not just fs instrumentation)

Testing:

• Tests are included in the PR of the updated library
  • The change is backwards compatible - all instrumentations are still enabled by default

Documentation:
Usage example: export OTEL_NODE_ENABLED_INSTRUMENTATIONS="http,nestjs-core".
See the documentation for details.

[swiatekm]

@atsu85 can you add a changelog entry for this change? Usually we don't do this for dependency upgrades, but this enables a few feature and is worth calling out.

Should we add this as an attribute to the NodeJs instrumentation CR as well? @pavolloffay @jaronoff97 @TylerHelmuth

[atsu85]

@swiatekm-sumo

can you add a changelog entry for this change?

I thought i already did that by adding this file into .chloggen folder (as documented in Contribution Guidelines: Adding a Changelog Entry). As i understand content from that file will be used to generate an entry into changelog during the releas:

During the collector release process, all ./.chloggen/*.yaml files are transcribed into CHANGELOG.md and then deleted.

Is there anything else i should do?

[pavolloffay]

Should we add this as an attribute to the NodeJs instrumentation CR as well? @pavolloffay @jaronoff97 @TylerHelmuth

The env var can be already configured in the CR (in a generic way). If the values do not change we could define it as a field in the CR.

@atsu85 do you have a link that lists all instrumentations that can be enabled/disabled?

[atsu85]

@pavolloffay

do you have a link that lists all instrumentations that can be enabled/disabled?

Sure. I indirectly already referenced to it via

See the documentation for details.

that contains the link you asked for:

By default, all Supported Instrumentations are enabled, but you can use the environment variable OTEL_NODE_ENABLED_INSTRUMENTATIONS to enable only certain instrumentations by providing a comma-separated list of the instrumentation package names without the @opentelemetry/instrumentation- prefix.

[swiatekm]

@swiatekm-sumo

can you add a changelog entry for this change?

I thought i already did that by adding this file into .chloggen folder (as documented in Contribution Guidelines: Adding a Changelog Entry). As i understand content from that file will be used to generate an entry into changelog during the releas:

During the collector release process, all ./.chloggen/*.yaml files are transcribed into CHANGELOG.md and then deleted.

Is there anything else i should do?

Sorry about that, the CI failing confused me. It looks like markdown-link-check is complaining about the anchor in the link you added, though I'm not sure why.

[atsu85]

It looks like markdown-link-check is complaining about the anchor in the link you added, though I'm not sure why.

It isn't related to the anchor, the message

Check that anchor links are lowercase

is just a hard coded fallback message in GHA pipeline, that isn't correct in this case, as the command fails for different reason.

It seems that there was a bug with the code (thta didn't expect that ignore argument could be missing on that code execution path), and it should be fixed now with this commit. I'm force pushing to re-trigger the build pipeline, because i can't manually re-trigger it

[atsu85]

@pavolloffay, the GHA changelog workflow is currently waiting for your approval, before it can run again:

This workflow is awaiting approval from a maintainer in #2745

[atsu85]

@swiatekm-sumo , @pavolloffay, thanks for approving! Now all checks are green.
Can you merge and release it as well, or who can do that?

[TylerHelmuth]

@atsu85 would you like to take on the followup PR to the opentelemetry site to update https://opentelemetry.io/docs/kubernetes/operator/automatic/#js-excluding-auto-instrumentation?

[atsu85]

would you like to take on the followup PR to the opentelemetry site to update https://opentelemetry.io/docs/kubernetes/operator/automatic/#js-excluding-auto-instrumentation?

@TylerHelmuth, sure (created an issue)! But perhaps changes in this repo can be released first, so i could test it first by dogfooding it in our setup?

I see that this part of the documentation (source) is now outdated.

[atsu85]

would you like to take on the followup PR to the opentelemetry site to update https://opentelemetry.io/docs/kubernetes/operator/automatic/#js-excluding-auto-instrumentation?

@TylerHelmuth, I created a PR to update the documentation - currently in draft status since this PR isn't released, but please review that as well!

[atsu85]

@pavolloffay, thanks for merging!

@TylerHelmuth, @swiatekm-sumo, @pavolloffay, can you releas the changes, so i could test it first by dogfooding it in our setup, or should i prepare (manually??) the release branch myself based on this?

[pavolloffay]

@atsu85 the new release can be triggered by updating https://github.com/open-telemetry/opentelemetry-operator/blob/main/autoinstrumentation/nodejs/package.json#L28 along other dependencies.

PRs are welcome :)

[atsu85]

the new release can be triggered by updating https://github.com/open-telemetry/opentelemetry-operator/blob/main/autoinstrumentation/nodejs/package.json#L28 along other dependencies.

Thanks! I created a PR #2754 - @pavolloffay, please review and approve, so it could start the GHA pipelines

[atsu85]

@pavolloffay

the new release can be triggered by updating https://github.com/open-telemetry/opentelemetry-operator/blob/main/autoinstrumentation/nodejs/package.json#L28 along other dependencies.

NB! Looks like this PR actually already overrode release of docker image autoinstrumentation-nodejs:0.46.0, that was previously released with the same version number also for example on 2024.01.18 and 2023.12.20

@pavolloffay, @TylerHelmuth , @swiatekm-sumo, were you aware of it? This seems like a bug to me. Maybe autoinstrumentation-nodejs docker image version shouldn't be read based on @opentelemetry/sdk-node version (that can be left unchanged), but perhaps based on package version in autoinstrumentation/nodejs/package.json that should be bumped with every release?