Http server semconv span stable

[dyladan]

Updates semconv to 1.27 for server spans.

Metrics to be done in followup.

[dyladan]

Note

NEW DEPENDENCY

This is needed to parse the somewhat complex forwarded header

[pichlermarc]

thanks for pointing this out - I also had a quick look and it does not seem like there's a easy way to do it 😞
I think using the library is justified.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 93.39%. Comparing base (f8ab559) to head (1054a44).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4978   +/-   ##
=======================================
  Coverage   93.39%   93.39%           
=======================================
  Files          46       46           
  Lines         712      712           
  Branches      120      120           
=======================================
  Hits          665      665           
  Misses         47       47           

[JamieDanielson]

Thank you for working on this!

[JamieDanielson]

I'm not sure how best to update without making this big PR even bigger, but the section with the table of attributes will need to be updated in some way (starting on line 114 that still references Server Spans). It may be worth having two tables - 1 representing old, 1 representing new. I'm happy to help craft that table in a separate issue and we can issue a follow-up PR. I would recommend at least a small change to that section though along the lines of "These are the attributes in the default behavior using only experimental attributes".

[dyladan]

I left the old table as-is for now. The new semconv is documented already in the semconv repo. When we remove this fallback the old table will be removed entirely. Would that be sufficient or do you think we need a table here as well?

[JamieDanielson]

I've gotten a lot of requests for showing what attributes are included in instrumentation, especially as different instrumentations (and languages) are in different versions. Folks also ask about other attributes (non-semconv) in different instrumentations, e.g. express.name, though that's less relevant for http here. The semconv might be in the semconv repo but it doesn't specify what we include, and may not be easily navigable by end users. Ideally we autogenerate a list of attributes vs handcrafting a table though, but with the table already there we may as well use it.

[pichlermarc]

thanks for pointing this out - I also had a quick look and it does not seem like there's a easy way to do it 😞
I think using the library is justified.

[JamieDanielson]

Actually, hm. I wonder if we should use the new ATTR_ imports here from incubating. So the ATTR_ stable attributes should still get imported as-is, but the ATTR_ incubating/experimental attributes should be used and imported from semantic-conventions/incubating.

[JamieDanielson]

On second thought, this is probably right. It feels a bit awkward to have a mix of SEMATTRS_* and ATTRS_* but one of the reasons to avoid using the new attributes is if anything has changed. For example, we've been advised not to update db attributes because they are close to stability and we may end up with multiple breaking changes before then. Maybe we only use the new ATTRS_* if something didn't exist in the previous version

[dyladan]

Yeah I decided to leave the old attribute names to be sure there isn't a change/regression

I think we may want to use the new ATTR_ imports even for old semconv. So the ATTR_ stable attributes should still get imported as-is, but the ATTR_ incubating/experimental attributes should be used and imported from semantic-conventions/incubating.