Add info about missing instrumentation to SDK context

[smeubank]

Problem Statement

Commonly seen in the product in a waterfall of spans, there can be gaps in time which are unaccounted for, or in Sentry UI specifically on the trace view, transactions with no spans. This leads to an incomplete product experience. And the user is often told that there is generically a missing instrumentation problem. When it is actually far more nuanced. Auto vs manual, what type span is being collected, which framework, which runtime etc can all impact why the span information is missing.

Solution Brainstorm

The product should have the right information to tailor the product experience to correctly inform the user.

Starting from the SDK we can investigate ways to send the information in a better way, so the product has a reliable way to react.

Maybe we should add some extra on the scope if we detect missing instrumentation, would make it easier to figure this out without relying on logs of users

basically when we log this through the error handler, also add this to the scope as data

{
  type: 'transaction',
  extra: {
    'node.missing_instrumentation_detected': true
  }
}

[lforst]

Would you mind elaborating? If the SDK were to be able to detect that instrumentation is missing, it could just add the instrumentation no?

Do you have heuristics in mind the SDK could use to determine said missing instrumentation?

[Lms24]

Adding a summary from a related slack thread for posterity:

Our Node error handlers already detect if an integration is missing (e.g. express error handler detects missing express instrumentation). This we could also add to the event.

Code idea from @mydea:

{
  type: 'transaction',
  extra: {
    'node.missing_instrumentation_detected': true
  }
}

However, this won't work universally for all kinds of missing instrumentations. For example, DB instrumentations.

[timfish]

Using import-in-the-middle/require-in-the-middle we could potentially instrument ALL functions found when evaluating exports in user code and automatically create spans on existing transactions.

This wouldn't help with bundled code and I'm sure this would have some performance implications. We could discard spans with lengths below a certain threshold, or simply offer suggestions for functions that could be instrumented?

[mydea]

So I think adding on to the detection we already do, which should be pretty "safe", would be an easy enough first step (we can just set some extra on the global scope or something like this, so this is added to all events). Would that work @smeubank ? Who do we need to sync with for this, also in regards to what this should be called? @JonasBa maybe?