-
Notifications
You must be signed in to change notification settings - Fork 375
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
Faraday default middleware doesn't work #978
Comments
The example app is super helpful, thank you. We'll take a look at this. Thanks for the report! |
Hi @patrobinson, with a detailed you provided I was able to run through the concerns you raised rather easily, thank you for providing that code! I made one modification to the app you provided: Distributed headersExplicit Faraday connection configurationThe app provided explicitly configures This is what I get as the output of
I get three No connection configurationIf I remove the explicit configuration from the connection, line
Diffing them shows that only the autogenerated numbers are different, but all fields are present in both cases. 15,16c15,16
< "HTTP_X_DATADOG_TRACE_ID"=>"7912611079601621711",
< "HTTP_X_DATADOG_PARENT_ID"=>"4373350161476094012",
---
> "HTTP_X_DATADOG_TRACE_ID"=>"1663428667407258401",
> "HTTP_X_DATADOG_PARENT_ID"=>"8621448459079188098",
22c22
< "rack.input"=>#<StringIO:0x00007f93fe3ab828>,
---
> "rack.input"=>#<StringIO:0x00007fc9d32d1e88>,
29c29
< "rack.hijack"=>#<Proc:0x00007f93fe3ab738@~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/rack-2.2.2/lib/rack/handler/webrick.rb:83 (lambda)>,
---
> "rack.hijack"=>#<Proc:0x00007fc9d32d1dc0@~/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/rack-2.2.2/lib/rack/handler/webrick.rb:83 (lambda)>,
34c34
< "rack.logger"=>#<Logger:0x00007f93fe3ab5d0 @level=1, @progname=nil, @default_formatter=#<Logger::Formatter:0x00007f93fe3ab580 @datetime_format=nil>, @formatter=nil, @logdev=#<Logger::LogDevice:0x00007f93fe3ab508 @shift_period_suffix=nil, @shift_size=nil, @shift_age=nil, @filename=nil, @dev=#<IO:<STDERR>>, @mon_mutex=#<Thread::Mutex:0x00007f93fe3ab4b8>, @mon_mutex_owner_object_id=70136801090180, @mon_owner=nil, @mon_count=0>>,
---
> "rack.logger"=>#<Logger:0x00007fc9d32d1c80 @level=1, @progname=nil, @default_formatter=#<Logger::Formatter:0x00007fc9d32d1be0 @datetime_format=nil>, @formatter=nil, @logdev=#<Logger::LogDevice:0x00007fc9d32d1b68 @shift_period_suffix=nil, @shift_size=nil, @shift_age=nil, @filename=nil, @dev=#<IO:<STDERR>>, @mon_mutex=#<Thread::Mutex:0x00007fc9d32d1ac8>, @mon_mutex_owner_object_id=70252404051380, @mon_owner=nil, @mon_count=0>>, I can't seem to be able to reproduce the distributed header issue. There is a chance that you were running a version Timing misreportedRegarding the span reporting incorrect time, I unfortunately wasn't able to reproduce it. I enabled the tracer debug configuration, I see the I don't have any concrete suggestions for the timing issue with the information provided so far. If you have more information on how to specifically reproduce it that would be very helpful. |
We are also experiencing the same timing mirepresentation - it is extremely underreporting the time of each span. We are using the default Datadog configuration:
and Faraday 0.15.4. |
Hi all - I started looking into this. Looking at the Faraday middleware: def call(env)
# Resolve configuration settings to use for this request.
# Do this once to reduce expensive regex calls.
request_options = build_request_options!(env)
request_options[:tracer].trace(Ext::SPAN_REQUEST) do |span|
annotate!(span, env, request_options)
propagate!(span, env) if request_options[:distributed_tracing] && request_options[:tracer].enabled
app.call(env).on_complete { |resp| handle_response(span, resp, request_options) }
end
end I'm wondering if the span could be underreported because it does not wait for the on_complete hook to finish? From the Faraday documentation:
|
@sdrioux I've found once you explicitly instrument the Faraday connection with |
Great write up @sdrioux! |
Hey @patrobinson, we've just released 0.39.0, which adds a fix for a Faraday warning when patching the library. Could you give this new |
@marcotc works fine now,thanks for your help! |
I've upgraded to the latest version of the Gem, to include #843, but still distributed tracing doesn't seem to work. We can now see seperate Faraday spans in Datadog APM, but:
x-datadog-trace-id
header etc. are not sent to the downstream client.I've setup an example app which shows the behaviour. When we just
use :faraday
, no Datadog tracing headers are sent.When I explicitly configure the Faraday connection to
use :ddtrace
then we see the headers as expected.The text was updated successfully, but these errors were encountered: