Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[java] Tracing without Performance #2768

Closed
Tracked by #5
smeubank opened this issue Jun 5, 2023 · 3 comments · Fixed by #2788
Closed
Tracked by #5

[java] Tracing without Performance #2768

smeubank opened this issue Jun 5, 2023 · 3 comments · Fixed by #2788

Comments

@smeubank
Copy link
Member

smeubank commented Jun 5, 2023

Problem Statement

It should be possible that tracing information is propagated from/to incoming/outgoing HTTP requests even if performance is disabled and thus no transactions/spans are available.

Solution Brainstorm

See the PHP implementation as a template: getsentry/sentry-php#1516

@smeubank smeubank transferred this issue from getsentry/team-webplatform-meta Jun 5, 2023
@smeubank smeubank changed the title Tracing without Performance [java] Tracing without Performance Jun 5, 2023
@smeubank
Copy link
Member Author

smeubank commented Jun 5, 2023

to check with @markushi if he is working on this for android

@adinauer
Copy link
Member

adinauer commented Jun 5, 2023

to check with @markushi if he is working on this for android

Not yet. I'll involve him on PRs.

@adinauer
Copy link
Member

Questions that came up + answers:

  1. For incoming requests we want to either continueTrace from incoming headers or if none are present create a new PropagationContext with random traceId and spanId, correct?
    Answer: Yes

  2. If there's no incoming headers on the request do we even create a DSC and attach baggage header to outgoing requests?
    Answer: Yes, initially in this case DSC (Baggage for Java) is null on PropagationContext and created when an outgoing request is performed (e.g. HTTP request by user or a request to Sentry). * If there's no transaction.

  3. There's other places where we start transactions that don't originate from incoming requests but some user interaction / system call on Android. Do we create a new PropagationContext in all those spots where we'd create a transaction if performance was enabled?
    Answer: If the button click (or similar) creates a new TraceID today when using performance, it should also create a new TraceID when performance is off, so a new PropagationContext

  4. OTEL: Is there ever a scenario where users would add our OTEL integration but have performance disabled? Does that mean we should still extract and attach headers in our OTEL integration?
    Answer: We'll ignore this for now as it seems rather unlikely.

  5. Should tracesSampling be considered.
    Answer: Yes, we shouldn't attach headers or trace context if it's set to false. We can think about removing the option in an upcoming major.

  6. For context keyed trace on envelope header do we simply check if performance is enabled then try to find a transaction on scope and use its TraceContext and if performance is disabled we use PropagationContext on the scope?
    Answer: Yes. Also: "In order to make Dynamic Sampling work, it’s crucial that the correct data is in the envelope header. So if there is a transaction going to be sent to Sentry, you should never fallback to the PropagationContext to generate the header values."

@stephanie-anderson stephanie-anderson changed the title [java] Tracing without Performance Tracing without Performance Jun 19, 2023
@smeubank smeubank changed the title Tracing without Performance [java] Tracing without Performance Jun 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Archived in project
Development

Successfully merging a pull request may close this issue.

4 participants