-
Notifications
You must be signed in to change notification settings - Fork 870
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
Trace config property to indicate that the responsibility of deciding to trace or not is delegated to another component #1865
Comments
Do I understand you correctly, that you want an option to run a javaagent in a mode, where it joins already existing trace but will not initiate new ones? |
Yes, this essentially what it boils down to |
I think using |
So I had assumed that the desired behavior would be achieved when setting It is possible that your suggestion might work, however as you say I have no idea how to configure the javaagent to do this. |
another option is #1060 |
Yes, this would definitely solve the issue we have with health checks getting traced |
Closing, this should be possible now using
|
Is your feature request related to a problem? Please describe.
We are in the process of modernizing a legacy application and splitting out components into microservices.
We run in Kubernetes where we have many different APIs (ours is a spring boot API) and we sit behind an API gateway.
In terms of distributed tracing we use b3-multi propagation, and it is the responsibility of a component at the gateway to set the headers before forwarding to the appropriate service. For our product we chose to set
x-b3-sampled
to 1 for 1% of requests.We have some other traffic that hits our API (health checks, integration tests etc), that originates from within the cluster that will not have the b3 headers set. What we find in this scenario is that the java-instrumentation will by default trace all of these, when ideally we would like to not trace them at all.
Of course we can control the probability, but this does not really work as desired for this case.
Describe the solution you'd like
A flag that would indicate that the instrumentation would operate in
passive
mode and rely on the values set as indicated by the selected propagation method, rather than initiating a trace if the headers are not set.Describe alternatives you've considered
We tried setting the
otel.config.sampler.probability=0
, but this has the effect of not tracing anything, even when the headers are set by the gateway, as a workaround we set this to 0.001 so that only every 1/1000 requests that do not have headers get traced as a temporary workaround.The text was updated successfully, but these errors were encountered: