Add async http instrumentation

[tannalynn]

Adds instrumentation for async-http

resolves #1176

[kaylareopelle]

GitHub is showing me "4" comments, so I think some of what shows up will be moot based on more recent changes!

[kaylareopelle]

@tannalynn - Out of curiosity, did you add this manually or use the script? (If you used the script, I'm a bit concerned about why the first version was outdented one level)

[tannalynn]

I used the generator originally, but there was a merge conflict so i had to copy it and put it back, it's very possible that i messed up the indentation when i resolved the merge conflict.

[kaylareopelle]

Not for this PR, but maybe it's time to move these constants to a shared location.

[github-actions]

SimpleCov Report

	Coverage	Threshold
Line	94.1%	94%
Branch	85.66%	85%

[trevorturk]

Exciting stuff, thank you!

/cc @ioquatix in case he's interested in having a look 👀

[ioquatix]

Thanks for working on this.

I don't want to come across as negative as I think it's awesome someone is getting value from this, but:

1. There is a chance instrumentation that's injected like this will break due to internal changes or interface changes.
2. In order to deal with this, I created a gem, traces.
3. That gem provides a generic interface for tracing traces and spans, and provides implementation specific backends e.g. traces-backend-open_telemetry, traces-backend-datadog.
4. This ensures any tracing (including across service boundaries) is handled correctly and is compatible, as the tracing is provided by the library itself.

I'm cautious about monkey patching approaches as unless tested in non-production (non-instrumented) environments, can suddenly break on deploying to production. Ideally, we can implement traces-backend-newrelic?

[tannalynn]

@ioquatix
Thanks for bringing this to our attention! I didn't realize that existed, I must have missed it when I looked originally, sorry about that! Before I started, I looked at the readme for async-http to see if there was anything built in for observability (like subscriptions or something like this) but didn't see anything mentioned so I ended up just approaching it the way we instrument most gems (with monkey patching and prepend options).

An initial question I have after a quick look at it: Is there a way to insert into the headers? I see there is a w3c trace context method built in, but the new relic ruby agent has other types of headers that we will need to insert into outgoing request headers in certain situations. I'm not sure if that would be possible though.

I'll have to spend a little time setting up my test app to use traces and see how the things looks when creating a span with the new relic ruby agent with the traces interface. Once I've had a chance to do that I'll have a better idea of if we'll be able to move our instrumentation there.

Thank you for pointing this out and letting us know about traces!

[ioquatix]

If you use traces, you will get instrumentation across all the socketry gems where it's implemented.

It is not currently possible to inject headers. I don't think we should change this but maybe that's something that can be monkey patched for legacy code?

[tannalynn]

Creating a new relic implementation of traces seems like it would be a great thing for us to do to get more visibility, so I've created an issue #2283 for us to work on it and tentatively plan to work on it next quarter.

As for being able to insert headers, the agent does that on the HTTP client side in order to then parse it out on the HTTP server side (presuming both client and server are instrumented by New Relic). This is something we need to do to support other new relic products (for example: synthetics monitoring https://newrelic.com/platform/synthetics). If that's not something we can do with traces, we'll have to carry on monkey patching for async http still.

[trevorturk]

Hello, I know it sounds like even more good stuff is coming later with #2283 but I wanted to say thank you for working on this feature. I just rolled out a NR gem update in an app where I'm using Async::HTTP heavily and things are working great. It's lovely having this extra visibility now -- I really missed that when migrating from Typhoeus. Thank you!