feat: Support including host name in faraday span names

[joshwestbrook]

Faraday span names appear as just "HTTP <METHOD>" which doesn't provide a ton of context when visualizing the spans.

For some specific context about our use case:
We use Grafana span metrics to create alerts when any of our critical 3rd-party APIs we use have a high latency. But since those metrics don't include the net.peer.name attribute that were on the original span, we only really have the span name to filter down the metrics to what we're looking for.

Including the host name in the span name makes this process significantly easier for us and makes it much easier to identify what API call was performed at a quick glance rather than having to click into the span's attributes each time 😄

[arielvalentin]

Although I appreciate the challenges you're facing at the moment the instrumentation should have predictable low cardinality span names.

I don't have any alternatives for you at the moment in Ruby other than writing a custom span provessor but if there are any other @open-telemetry/ruby-contrib-approvers that may have opinions or suggestions on what we can offer I hope we can discuss them at the next SIG.

[joshwestbrook]

Although I appreciate the challenges you're facing at the moment the instrumentation should have predictable low cardinality span names.

I don't have any alternatives for you at the moment in Ruby other than writing a custom span provessor but if there are any other @open-telemetry/ruby-contrib-approvers that may have opinions or suggestions on what we can offer I hope we can discuss them at the next SIG.

Hey @arielvalentin! I appreciate the quick response 😄

Could you elaborate a bit more on how my proposed changes differ from the alternate span naming conventions provided by other instrumentations such as Sidekiq or ActionController?

To me, providing the option to include the request hostname in the span name doesn't feel like it would introduce significantly more variance in span names than what the alternates provided in other instrumentations already do.

[arielvalentin]

We follow the spec in those cases HTTP server instrumentations use low cardinality templated routes like GET /users/:id or HTTP {method}.

Similarly Messaging/Job consumers and producers use the topic name they are use.

Earlier versions of the instrumentations were implemented incorrectly and used class names. We kept them around for backward compatibility.

The HTTP client libraries that we instrument here don't offer options like this and they would be closer to what is expected by the specification.

Unless my knowledge is out of date, the same low cardinality rules should apply. A templated route or the http method are the recommended span names.

Using the host name may result in high cardinality values.

In these cases I would recommend using the collector to transform span names but that may not be an option for everyone.

Another option would be to change the faraday instrumentation that would ensure it was the first middleware in the stack and then you can add a custom middleware to rename the span.

There are other options but they open up potential challenges for "foot-guns" so I'd rather not even mention them 😔

I hope that helps clarify my concerns. I'm interested in what others think about this.