A holiday bundle!

[mattfysh]

Note: this is only a discussions PR with no intention of merging (hence no tests)

Wanted to get feedback on this PR :) primarily, which of these ideas might be worth pursuing. At the moment, I've forked 4 modules which can be difficult to work with, so the less modules that deviate from the main branch the better.

One thing I've noticed is that when Hub Branching is enabled, breadcrumbs do not appear, likely due to the heavy use of hub & scope cloning, which breaks bubbling of breadcrumbs back to the transaction - does that sound right? I noticed some discussion here: https://develop.sentry.dev/sdk/research/performance#conflicting-data-propagation-expectations

Features included:

Hub Branching

• Enables hubs to branch into units of concurrency, and nested hubs are containers for scope/span branching & concurrenc
  • this was implemented as trace in the node package (src/utils.ts) and is a workaround for the limitation of scopes being stored in a Stack data structure (and not a Tree, that would be required to trace concurrent spans)
  • using nested domains underneath
  • behind a flag, ie. Sentry.init({ enableHubBranching: true })
  • Better scope management for async code #3751
  • Sentry produces incorrect data when async code is involved #4071

HTTP

• HTTP spans do not end until the response has finished streaming
  • Prior to this change, there were many "Missing instrumentation" spans appearing
  • This matches OpenTracing implementation
• Added option to prevent sentry-trace header being sent in a request, while retaining the tracing functionality
  • Maybe Do not add sentry-trace header by default? #4184
  • Sentry-trace may cause CORS errors #4114
  • Option to not send sentry-trace header to certain origins #3203
• Added data to http.client span, to include time to lookup hostname, and time to establish connection

AWS Lambda

• AWS Lambda handler wrapper creates a new hub per invocation (similar to how Express uses domain.create when accepting incoming HTTP messages)
  • Serverless Function Tracing Needs an Isolated Scope #3572
• AWSDynamoDB operations include table name in description
  • Display AWS SDK context, e.g. DynamoDB table #4159
• Any outgoing HTTP requests triggered by an AWS request are not included in the trace (the aws.request op stays as the leaf span)

Postgres

• Avoids using dynamic loadModule which tends to break bundlers. Integration user passes in module to constructor (similar to the Express tracer)
  • Postgres Integration was unable to require pg package when using webpack #4099
  • fix(utils): Fix loadModule when using PnP #4077
• Instrumented client.connect
  • Instrument pg connection, i.e. client.connect() #4158

[AbhiPrasad]

Hey, happy new year! Thanks for the PR. The maintainers are slowly getting back from vacation, but we've put this on the docket to discuss further internally.

For now though, I think the http and postgres changes can def become it's own PRs without much need for discussion, those patches lgtm.

[mattfysh]

Hey @AbhiPrasad - happy new year :)

I've decided to move to OpenTelemetry as most of the features I've implemented in this branch were already available in their auto-instrumentation plugins

Do you know when Sentry will begin ingesting OTel spans?

Thanks!

[AbhiPrasad]

@mattfysh there is no timeline for Sentry ingesting Otel data, but it's on our roadmap.

If you're using the Otel collector, we do have a Sentry exporter https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/sentryexporter, but that has some limitations (details in the exporter readme).