You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm attempting to disable creating Sentry issues whenever application level critical errors are thrown on a nodeJS application.
The nodeJS application is being executed on a local machine within a Docker container. This is how Sentry initialization is currently implemented:
"use strict";
const Sentry = require("@sentry/node");
const settings = require("./config")();
const logger = require("./logger");
const express = require("express");
const expressApp = express();
const expressAppDevice = express();
const initializeSentry = (callback = () => {}) => {
if (settings.SENTRY_ENABLED) {
logger.info("sentry enabled", settings.SENTRY_DSN);
Sentry.init({
dsn: settings.SENTRY_DSN,
environment: settings.SENTRY_ENVIRONMENT,
integrations: [
// enable HTTP calls tracing
new Sentry.Integrations.Http({ tracing: true }),
// enable Express.js middleware tracing
new Sentry.Integrations.Express({ expressApp }, { expressAppDevice }),
new Sentry.Integrations.Postgres({
usePgNative: false,
}),
],
tracesSampler: (samplingContext) => {
// Examine provided context data (including parent decision, if any) along
// with anything in the global namespace to compute the sample rate or
// sampling decision for this transaction
// https://docs.sentry.io/platforms/node/guides/express/configuration/sampling/#default-sampling-context-data
if (
samplingContext?.transactionContext?.name
?.toLowerCase()
?.startsWith("get /docs")
) {
// This endpoint is used as a healthcheck - take a small sample
return 0.01;
} else if (
samplingContext?.transactionContext?.name
?.toLowerCase()
?.startsWith("get /ping")
) {
// This endpoint is used as a healthcheck - don't track transactions
return 0;
} else {
// Default to sample all
return 1.0;
}
},
});
// RequestHandler creates a separate execution context using domains, so that every
// transaction/span/breadcrumb is attached to its own Hub instance
expressApp.use(Sentry.Handlers.requestHandler());
// TracingHandler creates a trace for every incoming request
expressApp.use(Sentry.Handlers.tracingHandler());
// The error handler must be before any other error middleware and after all controllers
expressApp.use(Sentry.Handlers.errorHandler());
// RequestHandler creates a separate execution context using domains, so that every
// transaction/span/breadcrumb is attached to its own Hub instance
expressAppDevice.use(Sentry.Handlers.requestHandler());
// TracingHandler creates a trace for every incoming request
expressAppDevice.use(Sentry.Handlers.tracingHandler());
// The error handler must be before any other error middleware and after all controllers
expressAppDevice.use(Sentry.Handlers.errorHandler());
callback();
} else {
Sentry.close(0).then((_) => {
logger.info("sentry disabled");
callback();
});
}
};
try {
initializeSentry();
.
.
.
// continued application implementation
async function main() {
.
.
.
// continued application implementation
}
} catch (error) {
const throwError = () => {
throw new Error(error);
};
initializeSentry(throwError);
}
The idea is for when application variable SENTRY_ENABLED=true, that Sentry issues/events are created accordingly as HTTP transactions or critical application errors are thrown.
The issue is when SENTRY_ENABLED=false, Sentry issues can still be created if there are any critical errors caused by any code written outside of the try catch block.
Is there are better way to appropriately "disable" Sentry issue tracking dynamically as is needed on an application level?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I'm attempting to disable creating Sentry issues whenever application level critical errors are thrown on a nodeJS application.
The nodeJS application is being executed on a local machine within a Docker container. This is how Sentry initialization is currently implemented:
The idea is for when application variable SENTRY_ENABLED=true, that Sentry issues/events are created accordingly as HTTP transactions or critical application errors are thrown.
The issue is when SENTRY_ENABLED=false, Sentry issues can still be created if there are any critical errors caused by any code written outside of the try catch block.
Is there are better way to appropriately "disable" Sentry issue tracking dynamically as is needed on an application level?
Beta Was this translation helpful? Give feedback.
All reactions