Dd-trace-rb: Feature request: HTTP.rb gem trace support

[bjeanes]

It'd be great if I could trace HTTP requests a la Net::HTTP and Faraday for https://github.com/httprb/http, including splitting resource name by host.

FWIW (I can open a second issue if preferred), it'd also be great to be able to pass a block for resource name for many of these gems so that we could inspect the request object and build a custom resource name for it.

[renchap]

I was going to open the same feature request, so 👍

HTTP.rb is used by a few highly-used gems (twitter, kubeclient, …), cf https://rubygems.org/gems/http/reverse_dependencies and by Shrine (file upload management) in my case.

[delner]

I'd be happy to add HTTP.rb to our backlog @bjeanes : we're always looking to expand our coverage over service endpoints, so this will fit right in.

Regarding the resource block, it might be best to open that in a separate issue, since presumably that kind of configuration support could be implemented separately, and we prefer to do things in smaller steps when possible. When you open that issue, could you add some configuration examples and a few relevant use cases demonstrating how you'd expect it to behave? Any details you can provide will really help us build a feature that covers your needs.

And of course thank you for suggesting both of these things; we love to hear this kind of feedback!

[renchap]

HTTP.rb now seems to have an instrumentation feature that could be used for the Datadog integration: https://github.com/httprb/http/issues/499

[bjeanes]

I'd be happy to add HTTP.rb to our backlog @bjeanes : we're always looking to expand our coverage over service endpoints, so this will fit right in.

Any sense of what this will take to get done @delner? Currently this is a growing gap in our trace coverage.

[delner]

@bjeanes It's on our backlog but we're unlikely to work on it in the near future.

We do routinely incorporate integrations developed by the community in the form of pull requests: that would likely be the fastest route to have this added. Alternatively, you could patch HTTP.rb using our trace API included in dd-trace-rb; there are a fair number of integrations that demonstrate how this works.

[joaovitoras]

Any updates on the progress of this implementation?
PR has been WIP for some time, I don't know if I can help with anything, but I wanted to revive this topic
I would like to be able to track the HTTP.rb trace on the datadog

[delner]

@joaovitoras Looks like https://github.com/DataDog/dd-trace-rb/pull/853 is still in progress but has grown stale. Not sure if/when @ericmustin planned on continuing this.

I think the fastest way this would be implemented would be with community assistance which would likely constitute updating that PR or developing a similar one. I'm more than happy to provide any support/consultation/reviews to aid that effort if anyone decides to undertake it.

In lieu of that, I will bring this up again with the team, to see if we can get it prioritized. The more bumps and votes we get from the community, the easier I can sell this one :) So thanks for drawing attention to it, and please don't hesitate to show your interest in features like this!

[ericmustin]

Hey folks, i believe the last of this was here https://github.com/DataDog/dd-trace-rb/pull/853#discussion_r346636353 . Tl;dr there has been an ask to scrap the approach this PR has taken in favor of one that uses the ActiveSupport hooks/conventions. I need to refresh myself on this a bit but I believe it's relatively straightforward work, I'll sync with @delner internally and try to carve out some time to do that in the coming weeks.

[rahul342]

+1 on adding this. We use this as a default client as well.

[marcotc]

👋 @bjeanes @renchap @joaovitoras @rahul342, we've just released 0.38.0 which includes support for http.rb.

Let us know if you have any issues or suggestions on improving this new instrumentation.