Jetty httpclient support

[robododge]

Hello, my company has a large distributed java platform that has centralized http communication. All communication is routed through the Jetty http client. Looking at the source code in opentelemetry-java-instrumentation, I can only find java instrumentation for Jetty on the server side.

Of course we loose the OpenTelemerty span propagation as http calls progress through the JettyHttp client. I am wondering if there is interest in OpenTelemetry support for the JettyHttp client?

[mateuszrzeszutek]

Hey @robododge,
Yes, definitely! We probably won't have the capacity to implement this ourselves, but we'll gladly accept external contributions.

[robododge]

Hi @mateuszrzeszutek , I have some jetty-client instrumentation now working.

1. fully working Jetty-9 client module. Uses the multiple Jetty-9.x client listener interfaces to feed an HttpClientTracer
2. fully working Jetty-8 client module. Uses the Jetty-8.x "exchange" model to feed an HttpClientTracer.

the Jetty-9 client should work for both Jetty 9&10. I have not touched Jetty 11 or newer.

I will need to refactor and build the proper library and testing modules. Should I submit a PR when I have it cleaned up?

[trask]

hey @robododge, yes, that would be great!!

[robododge]

Hi @trask, sorry it took me so long. Learning the ropes of the testing framework here was a bit of a battle. But, I have something mostly working for jetty client v9. I have some questions that I put in the PR. Here they are.

• How to handle API drift in the minor versions. There is an API drift from Jetty9.0 to Jetty9.1 client, but after 9.1, things seem to be stable for the instrumentation. So, how typically do you handle a small gap like that, is it worth it to do a v9.1 only instrumentation?
• How to make use of the testing framework to progress up the target library's versions to find where you cap off is, I'm thinking v10 may be the cut off but not sure. That's where I tentatively set muzzle.
• I have two HttpClient tests that I am un sure how to solve for right now. They are two callback-related tests. I think the parent span is not being scoped properly so when the callback get's executed, it doesn't register with the existing span from the http client. connection error unopendport with callback[0]. and trace request with callback and parent[0]

EDIT - I am getting good feedback on these questions in #3079