fix(instrumentation-http): use semantic convention metric descriptions

[puckpuck]

Which problem is this PR solving?

Updates description for HTTP auto instrumentation metrics to match semantic conventions.

If the proper description is not provided the Prometheus exporter from the OpenTelemetry Collector will report an error on the http.server.duration metric.

Fixes this issue in the Demo repo.

• Bug fix (non-breaking change which fixes an issue)

Checklist:

• Followed the style guidelines of this project
• Unit tests have been added
• Documentation has been updated

[codecov]

Codecov Report

Merging #3710 (af79d1c) into main (4b04407) will increase coverage by 0.02%.
The diff coverage is n/a.

❗ Current head af79d1c differs from pull request most recent head d227121. Consider uploading reports for the commit d227121 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3710      +/-   ##
==========================================
+ Coverage   93.65%   93.67%   +0.02%     
==========================================
  Files         277      277              
  Lines        8462     8462              
  Branches     1756     1756              
==========================================
+ Hits         7925     7927       +2     
+ Misses        537      535       -2     

Impacted Files	Coverage Δ
...ges/opentelemetry-instrumentation-http/src/http.ts	94.26% <ø> (ø)

... and 2 files with indirect coverage changes

[pichlermarc]

Thank you for fixing this! It's interesting that this would cause an error as the description is not part of the metrics identity. 🤔

[austinlparker]

I think the underlying issue here is actually in the prometheus exporter itself? I'm not actually sure what the specified behavior for two metrics with the same name but conflicting help text, but it appears that the otel collector prom exporter will race on it and only the last unique metric + description wins.

[pichlermarc]

I think the underlying issue here is actually in the prometheus exporter itself? I'm not actually sure what the specified behavior for two metrics with the same name but conflicting help text, but it appears that the otel collector prom exporter will race on it and only the last unique metric + description wins.

I aggree, I would also assume that the underlying issue is that at some point in the prometheus export the description is considered identifying. 🤔

AFAIK there's no specified way to resolve these kinds of problems as a non-OTLP (or even OTLP) consumer. If I understood the spec correctly, it should be resolved on the producer's (either SDK or downstream processor) side by taking the longer string when there are two conflicting descriptions. That works inside one SDK instance (and is not helping in this case, as most real world applications have multiple SDK instances across many apps), and in a downstream processor, this would also not be feasible as there can be multiple collectors that each can have different states. So the only way left to deal with it is:

• consider description non-identifying on the metrics backend, as OTel does
• having each SDK produce an identical description for any given metric (which we can and should do for any metric for which semantic conventions exist, like the ones in this PR. For custom metrics, however, a typo in a metric description may still cause pain for users. 🙁 )