feat(http-instrumentation): allow filtering of host name on metrics

[daniel-white]

Which problem is this PR solving?

i discovered that the metrics attribute net.host.name could be unbounded if a server on a single IP responds to multiple host headers. This would create additional metrics in various scenarios, such as multi tenant applications.

I would like validation on this approach before i write tests, thanks!

For more concrete example

GET / HTTP/1.1
Host: request1.example.com

GET / HTTP/1.1
Host: request2.example.com

GET / HTTP/1.1
Host: request3.example.com

each of these requests would generate new metric values without any mechanism to curtail it. with this change, the consumer of HttpInstrumentation can decide whether or not to include the net.host.name attribute on their metrics.

Short description of the changes

adds ignoreIncomingRequestHostMetricAttribute to the HttpInstrumentationConfig. Then uses that in the utilities for mapping from span to metric attribute.

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

• Test A

Checklist:

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

[Flarna]

I think this should be discussed in the semconv/spec part of OTel as it is not specific to JS.

There is a somewhat similar topic ongoing regarding HTTP method (see here).

fyi @joaopgrassi

[codecov]

Codecov Report

Merging #3880 (3ba993f) into main (228e67b) will decrease coverage by 0.02%.
The diff coverage is 71.42%.

❗ Current head 3ba993f differs from pull request most recent head 7c26be0. Consider uploading reports for the commit 7c26be0 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3880      +/-   ##
==========================================
- Coverage   92.98%   92.96%   -0.02%     
==========================================
  Files         300      300              
  Lines        9104     9109       +5     
  Branches     1862     1866       +4     
==========================================
+ Hits         8465     8468       +3     
- Misses        639      641       +2     

Impacted Files	Coverage Δ
...es/opentelemetry-instrumentation-http/src/utils.ts	98.39% <66.66%> (-0.79%)	⬇️
...ges/opentelemetry-instrumentation-http/src/http.ts	93.31% <100.00%> (ø)

[pichlermarc]

I see that this can be a big problem. The solution we'd adopt would highly depend on the solution that the Semantic Conventions folks come up with.

While this is being discussed, would creating a view and passing a list of allowed attributes (leaving out net.host.name) be an option for you? 🤔

[daniel-white]

@pichlermarc can you provide an example/link? I’m also using Prometheus

[pichlermarc]

Setting up views works like this (this is applied in the SDK metrics pipeline before the prometheus exporter, so it affects all exporters): https://opentelemetry.io/docs/instrumentation/js/manual/#examples

In this specific case you'd do:

const view = new View({
          instrumentName: 'http.server.duration',
          instrumentType: InstrumentType.COUNTER,
          // everything not in attributeKeys would be ignored
          attributeKeys: [
            // 'http.host',
            // 'net.host.name',
            'http.method',
            'http.scheme',
            'http.route',
            // 'net.host.port',
            'http.status_code',
          ],
        }),

All items in the list will be allowed to be added to the metric, all the commented out attributes (i.e. attributes that are not in the list) will be dropped.

Then add the view to your MeterProvider constructor to apply it. You can do it like so:
https://opentelemetry.io/docs/instrumentation/js/manual/#attach-to-meter-provider

[daniel-white]

thanks! that makes sense.

i'm more than happy to help anyway i can to help make otel better, especially in these scenarios, lmk

[joaopgrassi]

@daniel-white thanks for bringing this concern up, was really relevant for discussions we are having right now in the semantic conventions group.

Just FYI this is being tracked now on open-telemetry/semantic-conventions#108. Most likely these attributes will be "opt-in" on http metrics

[pichlermarc]

@daniel-white thanks for bringing this concern up, was really relevant for discussions we are having right now in the semantic conventions group.

Just FYI this is being tracked now on open-telemetry/semantic-conventions#108. Most likely these attributes will be "opt-in" on http metrics

Looks like the PR on the semconv repo has now merged with the recommendation to only add these attributes when the user opts-in. @daniel-white would that something you'd be interested in implementing? 🙂

[daniel-white]

@daniel-white thanks for bringing this concern up, was really relevant for discussions we are having right now in the semantic conventions group.

Just FYI this is being tracked now on open-telemetry/semantic-conventions#108. Most likely these attributes will be "opt-in" on http metrics

Looks like the PR on the semconv repo has now merged with the recommendation to only add these attributes when the user opts-in. @daniel-white would that something you'd be interested in implementing? 🙂

Sure! It will likely be closer to this weekend

[daniel-white]

@pichlermarc should we fix/remove/swap the usage of net.host.name in this package? the attributes collected in getIncomingRequestAttributes are all over the place and do not seem to follow the conventions here https://opentelemetry.io/docs/specs/otel/trace/semantic_conventions/http/

i'm guessing this instrumentation was written prior to OTEL_SEMCONV_STABILITY_OPT_IN stuff...

[daniel-white]

@pichlermarc i've put up a wip at #3948 to see what you think about this strategy pattern. i'll iterate more on it as needed

[github-actions]

This PR is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[github-actions]

This PR was closed because it has been stale for 14 days with no activity.