-
Notifications
You must be signed in to change notification settings - Fork 278
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
High quantity of intermittent failures when using DD Trace v0.5 protocol #5314
Comments
Relates to/Duplicate of #5313 |
We lose all trace data with 1.15.0+, so if you have some, you're doing better than we are! :) Same work around for us. |
@internetstaff @kayman-mk Are you also running in fargate? |
I am indeed. |
I am running on Fargate too, yes. |
We're releasing 1.15.2 soon that will revert the enabled by default behavior and will continue to look into this issue |
This should now be resolved with the release of 1.15.3. |
@nayeem-kamal Still not working. Upgraded to 1.15.3 and the error message is still there. It seems that almost nothing is transferred now to Datadog. APM shows a blank screen. Application runs on Fargate and uses the EU API endpoint.
|
@smola Could you please have a look, what's wrong with 1.15.3? |
For me, the new version 1.15.3 works (whereas 1.15.0 did not work). I have a similar setup (Fargate with Datadog sidecar calling the EU API endpoint). The error messages are gone and the APM traces appear again. |
Ever since the v1.15.0 release of dd-trace-java we've had the overwhelmingly majority of our traces failing across a number of services.
We occasionally will get some successes seen in the logs, though none of these are coming through as traces in Datadog itself and will still always show at least one error.
We're running our services in ECS Fargate, using the Datadog Agent as a sidecar container running the latest version.
We can get the traces working by enabling
DD_TRACE_AGENT_V0_5_ENABLED=false
on our Java application, or by downgrading the dd-trace-java to the previous release whereDD_TRACE_AGENT_V0_5_ENABLED
is set to false by default.That said, pinning to the old protocol version doesn't seem like an ideal long-term fix.
Any idea why the new protocol would be throwing these kinds of errors?
The text was updated successfully, but these errors were encountered: