Extract Incoming Trace Information - needed for all backend SDK's

[thinkocapo]

Core or SDK?

Platform/SDK

Which part? Which one?

all backend SDK's

Description

A lot of time wasted debugging why tracing doesn't work. It happened recently with Azure Functions, and there's no clear code example workaround (Custom Instrumentation) on how to do it.

relates to getsentry/sentry-javascript#8996
may relate to getsentry/sentry-javascript#9011

Python docs have the example code on how to extract trace info and set it properly.

It's under Usage > Distributed Tracing > Custom Instrumentation > Extract Incoming Trace Information

Documentation for...
Node does not have it
PHP does not have it

Suggested Solution

1. put it under Performance Monitoring > Customer Instrumentaiton > Extract Incoming Trace Information, instead of 'Usage'. I already wasted a few minutes not realizing it's not under Performance Monitoring, but rather Usage. Or at least link to it, from Performance > Custom Instrumentation. Note - now we have multiple Custom Instrumentation sections
2. this 'Extract Incoming Trace Information' section needs to exist for all backend SDK's. We have it for python, but python has plenty of framework integrations already.

[getsantry]

Assigning to @getsentry/support for routing ⏲️

[getsantry]

Routing to @getsentry/product-owners-sdks-web-backend for triage ⏲️

[getsantry]

Routing to @getsentry/product-owners-docs for triage ⏲️

[getsantry]

Routing to @getsentry/product-owners-sdks-web-backend for triage ⏲️

[cleptric]

PHP is documented in the same place as Python, see https://docs.sentry.io/platforms/php/usage/distributed-tracing/custom-instrumentation/.

We had some internal debate about where to put this piece of information. I definitely agree with you that this is a bit hidden. We'll take another look!

[smeubank]

as per discussion this should be discoverable coming from either direction

1. due to tracing without performance
   i. tracing should not be tightly coupled to performance, but to any event
2. at a bare min, the docs should have it under usage as is, and linked in performance

[thinkocapo]

I had 2 customers in the past month request this for Golang. Contact me for details.

[antonpirker]

I agree with @thinkocapo and @cleptric that putting it under "Sentry for X > Usage > Distributed Tracing > Custom Instrumentation" is basically hiding it.

We should have a top level section like "Performance Monitoring" for "Distributed Tracing".

This was not done in the past, because we have no product called “distributed tracing” and we only have those top level sections for products of Sentry.

I think it still makes sense though to have a top level section “distributed tracing”.