Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Node.js support for
--import
flag #3416base: main
Are you sure you want to change the base?
Add Node.js support for
--import
flag #3416Changes from 2 commits
6bb45bf
30c7f36
f4e5a79
3b65d65
4421cc0
993d67f
555ddcb
a8e0a47
d6747dd
da2827e
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One subtlety that might impact the choice of the config var name.
The feature for the user is whether a module import hook is added (via
module.register()
) to support instrumentating ESM code.That is actually independent of whether
--import something.mjs
or--require something.js
is used to run the OTel setup when Node.js is starting up. It is definitely possible to callmodule.register("@opentelemetry/instrumentation/hooks.mjs");
from the CommonJSautoinstrumentation.js
(loaded via--require
).So I wonder if a config name something like
instrumentEsm
or something like that would be clearer.There are a few subtleties discussed at open-telemetry/opentelemetry-js#4933, but I don't think you need to read and grok all that. Eventually we'd like it so that there is just the one obvious way to setup OTel -- and that would be via
--import some-esm-file-that-calls-module.register.mjs
. However, for now we need to make the ESM support opt-in because:There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think
instrumentEsm
here would be a bit of a misnomer, given that functionality could be added without an import flag, and a custom image could also require the use of an import flag for top level await support (which is actually our usecase for this addition) without providing ESM instrumentationThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I misunderstood the use case then. Using
import
in the var name makes sense then. The docs for this feature should mention the two things then: (1)--import ...
is used to load "autoinstrumentation.mjs" (so custom versions can use ESM and top-level await), (2) the default "autoinstrumentation.mjs" differs from "autoinstrumentation.js" in that it registers the hook for ESM instrumentation.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@raphael-theriault-swi how does the
--import
flag with with the upstreamopentelemetry/auto-instrumentations-node
? We are trying to minimize the nodejs code and rely only on that package.Related ticket: #3465
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@trentm could you please take a look here? cc) @JamieDanielson
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pavolloffay Are you asking if
node --import @opentelemetry/auto-instrumentations-node/register ...
works? If so, I think yes it should work fine becausenode --import something ...
works withsomething
being either ESM or CommonJS code. I haven't tried it, though.However, whether to move the operator to using
@opentelemetry/auto-instrumentations-node
instead of the bootstrap code in "autoinstrumentation.js" doesn't need to be part of this PR, right?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would also add that the
instrumentation.js
file needs to exist. Adding a--require @opentelemetry/auto-instrumentations-node/register
option alone will not work, since this requires the package to be present in thenode_modules
search path of the application itself, which would require the application to have the package installed and defeat the entire purpose of the operator autoinstrumentation.The contents of the file could be replaced by
require("@opentelemetry/auto-instrumentations-node/register")
instead, which would not conflict with this PR whatsoever.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The issue is that, if we keep adding new features here it will be harder to migrate them to
auto-instrumentations-node
(or other node packages)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Like I mentioned above switching to
auto-instrumentations-node
would be not require any change to the code added by this PR now or in the future.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pavolloffay Are there any changes you would like to see with regards to the switch
auto-instrumentations-node
? I can make that part of the PR, but again either way it wouldn't really change any files this PR touches.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The current code will crash if used on a verison of node that doesn't yet have
module.register
:An option might be to gracefully warn (untested code):
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the SDK setup a logger for the diag API by default ? If not I'm thinking this should probably be a
console.warn
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The NodeSDK sets a DiagConsoleLogger if the
OTEL_LOG_LEVEL
env var is set. (Per open-telemetry/opentelemetry-js#3693 it does not set a diag logger at all if the env var isn't set at all. So by default logging is effectively off.)node -r @opentelemetry/auto-instrumentations-node/register ...
does turn it on by default (https://github.com/open-telemetry/opentelemetry-js-contrib/blob/main/metapackages/auto-instrumentations-node/src/register.ts#L23-L26).Using the diag logger is the intended mechanism for logging by the OTel JS packages, but that doesn't necessarily have to mean that the OTel Operator uses it. I don't have a strong opinion whether the diag logger or
console.*
is used here.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this documentation should be expanded a bit. It is relevant that
useImport: true
also changes to using theautoinstrumentation.mjs
file (rather thanautoinstrumentation.js
). Anyone providing a custom image for nodejs injection should be aware of that.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's documented in the Dockerfile which is where the related info about
autoinstrumentation.js
was, I don't feel strongly about it either way but I wasn't sure whether documenting the internal filenames made sense in the user-facing documentation.