-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
feat(node): Add @sentry/node/preload
hook
#12213
Conversation
What happens if a user manually initializes OpenTelemetry? Can they still delay calling |
How does this differ from using I assumed |
size-limit report 📦
|
In our tests, import/execution order sadly still mattered. If something was imported before we added the OTEL instrumentation, it did not work :( Actually, the test is not "good" because in this specific test stuff does work. I updated this now, it fails when something is used before Sentry is run. E.g.: import express from 'express';
const app = express();
// setup app...
// somewhere later
setTimeout(function() {
Sentry.init(...);
}, 1000); In this case, express is already uninstrumented before we run init :/
This should all still work, basically this does nothing except setup the instrumentations, it does not actually setup otel itself (e.g. no span processor etc. is created yet). |
If I understood correctly, some people didn't have a DSN ready by the time we need to import/init everything for instrumentation to work. This would be a workaround. |
You can use |
Ah that does make sense for that case. Is there any reason not to encourage using an
// instrument.js
const Sentry = require('@sentry/node');
const dsn = await getSentryDsn();
Sentry.init({ dsn });
// app.js
const express = require('express'); |
Yeah, we generally do recommend that, but this is not possible if users cannot init at this point - e.g. if they load their DSN from somewhere else (something that we don't recommend, but there are people out there that have setups like this...) So this is really just an alternative way to get stuff running for these people, and will def. not be the recommended way to init sentry, but just an escape hatch! |
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.
Ah yes understood!
My only minor concern is that we're racking up quite a few different ways to initialise the SDK.
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.
My only minor concern is that we're racking up quite a few different ways to initialise the SDK.
yeah I also feel this, but I think this is an important thing to expose, so let's release. Maybe we can iterate and combine @sentry/node/preload
and @sentry/node/import
somehow 🤔.
We could, eventually, make import be a variant of preload with some env var set 🤔 but let's get this out for now and tweak stuff later as needed! |
Out of curiosity, what's a use case for this? I can't imagine any situation in which you don't have control over the entry point of your code. Maybe with frameworks like Next? |
This PR adds a new way to initialize
@sentry/node
, which allows to use the SDK with performance instrumentation even if you cannot (for whatever reason) callSentry.init()
at the very start of your app.CJS usage
In CommonJS mode, you can run the SDK like this:
ESM usage
in ESM mode, you can run the SDK like this:
Configuration options
This script will by default preload all opentelemetry instrumentation. You can choose to instrument only specific packages like this:
SENTRY_PRELOAD_INTEGRATIONS="Http,Express,Graphql" --import @sentry/node/preload ./app.mjs
You can also enable debug logging for the script via
SENTRY_DEBUG=true
.Manually preloading
It is also possible to manually call
preloadOpenTelemetry()
to achieve the same thing. For example, in a CJS app you could do the following thing if you want to initialize late but don't want to use--require
: