feat(tracing): Log start and end of spans

[lobsterkatie]

Right now, if one of our SDKs is running on a cloud provider and therefore all the user has is logs, there's no real way to debug missing spans. Are they not finishing in time and getting dropped? Are they even starting in the first place? No way to know.

This fixes that by adding logging to the start and end of spans, the same way we have with transactions.

[github-actions]

size-limit report 📦

Path	Size
@sentry/browser - ES5 CDN Bundle (gzipped + minified)	19.36 KB (-0.02% 🔽)
@sentry/browser - ES5 CDN Bundle (minified)	59.92 KB (0%)
@sentry/browser - ES6 CDN Bundle (gzipped + minified)	17.92 KB (-0.02% 🔽)
@sentry/browser - ES6 CDN Bundle (minified)	52.79 KB (0%)
@sentry/browser - Webpack (gzipped + minified)	19.69 KB (0%)
@sentry/browser - Webpack (minified)	64.13 KB (0%)
@sentry/react - Webpack (gzipped + minified)	19.71 KB (0%)
@sentry/nextjs Client - Webpack (gzipped + minified)	44.15 KB (+0.31% 🔺)
@sentry/browser + @sentry/tracing - ES5 CDN Bundle (gzipped + minified)	25.81 KB (-0.01% 🔽)
@sentry/browser + @sentry/tracing - ES6 CDN Bundle (gzipped + minified)	24.06 KB (-0.01% 🔽)

[Lms24]

I'm just wondering: Has this problem come up before? I think it's a good idea to log more information but considering that transactions can have a lot of spans, this could mean quite a lot of logs. Plus a few bytes more in the bundle for people that don't tree-shake out debug logging.

But those are overall not real concerns...

[lobsterkatie]

I'm just wondering: Has this problem come up before?

It's come up for me in my vercel/nextjs testing in the past (all you have there is the logs from the serverless functions your app gets turned into), but what actually prompted this was a user yesterday who's not seeing DB spans when his app is deployed to Heroku, and me feeling like I had zero way to debug that.

I think it's a good idea to log more information but considering that transactions can have a lot of spans, this could mean quite a lot of logs.

It's funny, I almost added a sentence to the end of the PR description like, "It's true this may get a little spammy for users, but let's add it in and see how much of an issue that is vs how useful it seems in terms of debugging." So, consider it added. 🙂

Plus a few bytes more in the bundle for people that don't tree-shake out debug logging.

Yeah, this is something I considered, too. We haven't really discussed/decided how free we should now feel to add logging, given that users now have the ability to treeshake it out. I wonder if we should think about doing that automatically in the webpack plugin, and/or making a bigger deal about it/suggesting it more strongly in the docs.

WDYT (about any or all of the above)?

[Lms24]

So about spammy logs: let's see how it goes. I think it's to revert this if people complain.

About the size aspect: Thinking about it, I guess it's not a problem at this point (especially because users now can do something about it). But I think we should nevertheless be mindful of adding new log messages (also because of the spam aspect ofc).

doing that automatically in the webpack plugin

I'd vote yes on that (as long as we provide the option to continue including it ofc)

making a bigger deal about it/suggesting it more strongly in the docs

Also worth considering. We could link to the tree-shaking guide from the main install page (e.g. in the "Next Steps" section).

But I think both things can happen whenever. No immediate action required